EXPLORE DETECTIONS
Authorization Plugin Modification
Authorization plugins are used to extend the authorization services API and implement mechanisms that are not natively supported by the OS, such as multi-factor authentication with third party software. Adversaries may abuse this feature to persist and/or collect clear text credentials as they traverse the registered plugins during user logon.
AWS Access Token Used from Multiple Addresses
This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts.
AWS Account Closed
Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage.
AWS Account Discovery By Rare User
Identifies the first time, within a lookback window, an identity performs AWS Organizations or IAM account enumeration APIs. Attackers with compromised credentials often map the organization (accounts, OUs, roots, delegated admins) and account-level metadata (aliases, summary) using the AWS CLI or SDKs. This is a New Terms rule detecting a rare occurrence of the `cloud.account.id` and `user.name` pair for these actions.
AWS API Activity from Uncommon S3 Client by Rare User
Identifies AWS API activity originating from uncommon desktop client applications based on the user agent string. This rule detects S3 Browser and Cyberduck, which are graphical S3 management tools that provide bulk upload/download capabilities. While legitimate, these tools are rarely used in enterprise environments and have been observed in use by threat actors for data exfiltration. Any activity from these clients should be validated against authorized data transfer workflows.
AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN
Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Kubernetes service account and the source autonomous system organization is present but not `Amazon.com, Inc.` EKS workloads that obtain IAM credentials via IAM Roles for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.
AWS Attempt to Leave Organization
Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account's ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account's default permissions correctly prevent the action.
AWS Audit or Security Service Tampering via CLI
Identifies use of the AWS CLI to disable, delete, or blind AWS audit logging and security monitoring services, including CloudTrail trails and event data stores, GuardDuty detectors, AWS Config recorders, Security Hub, Access Analyzer, Macie, and Inspector. Adversaries disable these controls early in a cloud intrusion so that subsequent credential abuse, data theft, and destruction go unrecorded. Because the endpoint sees the command as it is issued, this fires even when subsequent CloudTrail visibility is lost.
AWS Backup Recovery Point Deleted by Unusual User
Identifies when an unusual user deletes an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. This is a New Terms rule that uses "cloud.account.id", "user.name", and "aws.cloudtrail.flattened.request_parameters.backupVaultName" to alert on the first time a given identity in an account successfully deletes a recovery point from a specific backup vault within the history window.
AWS Backup Resource Enumeration via Long-Term Access Key
Detects enumeration of AWS Backup resources using long-term IAM access keys (AKIA* prefix). AWS Backup protects EC2 instances, EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and S3 buckets. An adversary who obtains long-term access keys may enumerate backup vaults, backup plans, and protected resources as a precursor to ransomware. Identifying which resources have recent backups (indicating high-value data) and what vault access policies can be modified to delete or corrupt the backups before encrypting the primary data.
AWS Backup Vault Deleted or Vault Lock Removed
Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations.
AWS Batch Job Submitted with Container Override by Unusual Identity
Detects the first time an AWS identity submits an AWS Batch job with a container command override ("containerOverrides.command"), indicating a runtime-modified execution environment. Command overrides allow the submitter to replace the default command of a job definition at submission time. This flexibility is commonly abused by adversaries to inject malicious commands or exfiltration logic into otherwise legitimate Batch compute environments without modifying the underlying job definition — making the malicious activity harder to detect through configuration review alone.
AWS Bedrock Agent Created by IAM User or Root
Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments.
AWS Bedrock Agent or Action Group Manipulation
Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity.
AWS Bedrock AgentCore Execution Role Used Outside Its Runtime
Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is the detectable signal.
AWS Bedrock AgentCore Resource Created with IAM Execution Role
Detects the creation of an AWS Bedrock AgentCore resource (code interpreter, agent runtime, browser, or harness) with an IAM execution role attached. When an attacker with iam:PassRole permission creates an AgentCore resource and attaches a privileged role, subsequent invocations inside that resource execute as the attached role — enabling privilege escalation to roles that trust bedrock-agentcore.amazonaws.com.
AWS Bedrock AgentCore Runtime Prompt Containing Credentials
Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text.
AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata
Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request.
AWS Bedrock AgentCore with Public Network Browser or Code Interpreter Sandbox
Detects the successful creation of an Amazon Bedrock AgentCore Browser or Code Interpreter with an execution IAM role and public network access. These sandboxes run agent-generated code or automated browsing on the caller's behalf, and the attached role lets the sandbox call other AWS services. Public network mode removes the sandbox's network containment, so a sandbox steered by prompt injection, malicious tool output, or code-execution abuse can reach the internet and pivot into other AWS resources with the role's permissions. Review the role scope and whether public egress is required.
AWS Bedrock API Key Phantom User Activity Outside Bedrock
Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary.
AWS Bedrock API Key Used for Destructive or Anti-Recovery Action
Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied.
AWS Bedrock Automated Reasoning Safety Policy Tampering
Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path.
AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User
Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.
AWS Bedrock Detected Multiple Validation Exception Errors by a Single User
Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.