EXPLORE DETECTIONS
AWS IAM User Console Login from Multiple Geolocations
Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections.
AWS IAM User Console Login Without MFA
Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap.
AWS IAM User Created Access Keys For Another User
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user.
AWS IAM User Self-Created Access Key Subsequently Used
Detects an AWS IAM user using an existing credential to create a new access key for itself and subsequently using the new key within one hour. This behavior can indicate an adversary converting compromised credentials into an additional long-term credential for persistence. Unlike a standalone self-service key creation alert, requiring subsequent use of the new key reduces noise from unused or abandoned credential-rotation operations.
AWS IAM Virtual MFA Device Registration Attempt with Session Token
Detects attempts to create or enable a Virtual MFA device (CreateVirtualMFADevice, EnableMFADevice) using temporary AWS credentials (access keys beginning with ASIA). Session credentials are short-lived and tied to existing authenticated sessions, so using them to register or enable MFA devices is unusual. Adversaries who compromise temporary credentials may abuse this behavior to establish persistence by attaching new MFA devices to maintain access to high-privilege accounts despite key rotation or password resets.
AWS KMS Customer Managed Key Disabled or Scheduled for Deletion
Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations, impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated data, any modification to their lifecycle should be considered highly sensitive and investigated promptly.
AWS KMS Imported Key Material Deleted
Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants prompt review.
AWS KMS Key Policy Updated via PutKeyPolicy
Identifies successful PutKeyPolicy calls on AWS KMS keys. The key policy is a resource-based policy that controls which principals can use the key for cryptographic operations and administration. Adversaries with "kms:PutKeyPolicy" may add or broaden principals (including external accounts) to decrypt or exfiltrate data protected by the key, or to preserve access after other credentials are rotated. This is distinct from disabling or scheduling deletion of the key.
AWS Lambda Event Source Mapping Creation
Identifies the creation of an AWS Lambda event source mapping, which connects an event source such as an Amazon SQS queue, an Amazon Kinesis or DynamoDB stream, an Amazon MSK or self-managed Apache Kafka topic, or an Amazon MQ broker to a Lambda function so the function is automatically invoked when new records arrive. Adversaries with "lambda:CreateEventSourceMapping" permissions can abuse this to establish stealthy, event-driven persistence and execution, or to continuously siphon records from a stream or queue into attacker-controlled function code. Because the function then runs on its own whenever the source produces events, this grants durable execution without any further interactive activity by the adversary.
AWS Lambda Function Deletion
Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed.
AWS Lambda Function High-Frequency Invocation by a Single Principal
Identifies a single principal directly invoking AWS Lambda functions at a high volume within a one-hour window. Adversaries may drive excessive invocations to abuse functions for resource hijacking or cryptomining, to inflate costs in a denial-of-wallet attack, or to enumerate function behavior. This is a volumetric heuristic: the threshold is environment-dependent and high-throughput applications can exceed it, so tune it to the deployment. This rule relies on AWS Lambda data event logging, which is not enabled by default.
AWS Lambda Function Invoked by an Unusual Principal
Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default.
AWS Lambda Function Invoked Cross-Account
Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default.
AWS Lambda Function Invoked from an Unusual Source ASN
Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default.
AWS Lambda Function Policy Updated to Allow Cross-Account Invocation
Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers.
AWS Lambda Function Policy Updated to Allow Public Invocation
Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly.
AWS Lambda Function URL Created with Public Access
Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review.
AWS Lambda Layer Added to Existing Function
Identifies when a Lambda layer is added to an existing AWS Lambda function. Lambda layers allow shared code, dependencies, or runtime modifications to be injected into a function’s execution environment. Adversaries with the ability to update function configurations may add a malicious layer to establish persistence, run unauthorized code, or intercept data handled by the function. This activity should be reviewed to ensure the modification is expected and authorized.
AWS Lambda Layer Shared Externally
Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review.
AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity
Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work.
AWS Management Console Brute Force of Root User Identity
Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account.
AWS Management Console Root Login
Identifies a successful login to the AWS Management Console by the Root user.
AWS Potential Cryptomining via ECS Task Definition Deployment
Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered.
AWS Rare Source AS Organization Activity
Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint.