From f66f00e10690a2a9d897ba90482558b73cefe506 Mon Sep 17 00:00:00 2001 From: bryans3c Date: Thu, 18 Jun 2026 08:15:27 +0200 Subject: [PATCH 01/10] [New Rule] AWS Lambda Event Source Mapping Creation --- ...e_lambda_event_source_mapping_created.toml | 134 ++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml diff --git a/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml b/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml new file mode 100644 index 00000000000..4160ace3766 --- /dev/null +++ b/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml @@ -0,0 +1,134 @@ +[metadata] +creation_date = "2026/06/16" +integration = ["aws"] +maturity = "production" +updated_date = "2026/06/16" + +[rule] +author = ["Elastic"] +description = """ +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. +""" +false_positives = [ + """ + Application teams and infrastructure-as-code pipelines routinely create event source mappings to wire data + pipelines, queue consumers, and stream processors to Lambda functions. Verify whether the principal in + `aws.cloudtrail.user_identity.arn`, the function, and the event source are expected for the workload. Known + deployment roles and automation can be excluded after validation. + """, +] +from = "now-6m" +index = ["filebeat-*", "logs-aws.cloudtrail-*"] +interval = "5m" +language = "kuery" +license = "Elastic License v2" +name = "AWS Lambda Event Source Mapping Creation" +note = """## Triage and analysis + +### Investigating AWS Lambda Event Source Mapping Creation + +AWS Lambda event source mappings poll an event source (Amazon SQS, Kinesis or DynamoDB streams, Amazon MSK or +self-managed Kafka, or Amazon MQ) and invoke a target function as records arrive. Creating a mapping is a low-frequency, +high-impact configuration change: it can establish event-driven persistence and execution, or quietly relay sensitive +records from a stream or queue into attacker-controlled code. + +This rule detects successful `CreateEventSourceMapping` calls. Investigate whether the principal, the target function, +and the event source are expected for the environment. + +#### Possible investigation steps + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review + `source.ip` and `user_agent.original` to determine whether the call came from the console, CLI, SDK, or automation. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName`/`functionArn` and the `eventSourceArn` to identify + the target function and the source queue, stream, topic, or broker. +- Determine whether the target function and the event source belong to the same application and account, and whether the + function code, role, and recent changes are trusted (correlate with `CreateFunction`, `UpdateFunctionCode`, and + `AddPermission`). +- Review whether the event source contains sensitive data (for example a DynamoDB stream or SQS queue carrying business + records) that the mapping could be used to exfiltrate. +- Pivot on the same principal and access key for other recent Lambda, IAM, or data-plane activity. + +### False positive analysis + +- Event source mappings are a normal building block of serverless data pipelines and queue/stream consumers. Mappings + created by approved deployment roles, CI/CD pipelines, or application teams are expected. Tune on + `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + +### Response and remediation + +- If the mapping is unauthorized, disable or delete it (`DeleteEventSourceMapping`) and review the target function's + code, configuration, and execution role. +- Determine whether records were processed by the function while the mapping was active and assess potential data + exposure. +- Rotate or restrict credentials for the principal that created the mapping if compromise is suspected, and constrain + `lambda:CreateEventSourceMapping` to a small set of trusted roles. + +### Additional information + +- [AWS Lambda event source mappings](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html) +- [CreateEventSourceMapping API](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) +""" +references = [ + "https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html", + "https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html", +] +risk_score = 47 +rule_id = "94b0b233-1655-4f28-b989-7c82d3c8911a" +severity = "medium" +tags = [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Lambda", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "query" + +query = ''' +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: CreateEventSourceMapping* + and event.outcome: "success" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1546" +name = "Event Triggered Execution" +reference = "https://attack.mitre.org/techniques/T1546/" + + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.user_identity.session_context.session_issuer.arn", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", +] + From e3de389a3f514abda48d5e77aeb56d4bb9aa899a Mon Sep 17 00:00:00 2001 From: Bryan Porras Date: Thu, 18 Jun 2026 08:25:58 +0200 Subject: [PATCH 02/10] Update persistence_lambda_event_source_mapping_created.toml --- ...sistence_lambda_event_source_mapping_created.toml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml b/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml index 4160ace3766..710e8d6b20f 100644 --- a/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml +++ b/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml @@ -1,8 +1,8 @@ [metadata] -creation_date = "2026/06/16" +creation_date = "2026/06/18" integration = ["aws"] maturity = "production" -updated_date = "2026/06/16" +updated_date = "2026/06/18" [rule] author = ["Elastic"] @@ -24,7 +24,7 @@ false_positives = [ """, ] from = "now-6m" -index = ["filebeat-*", "logs-aws.cloudtrail-*"] +index = ["logs-aws.cloudtrail-*"] interval = "5m" language = "kuery" license = "Elastic License v2" @@ -79,7 +79,7 @@ references = [ "https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html", ] risk_score = 47 -rule_id = "94b0b233-1655-4f28-b989-7c82d3c8911a" +rule_id = "5619545b-9738-408c-bdb5-a2807e19133e" severity = "medium" tags = [ "Domain: Cloud", @@ -124,8 +124,8 @@ field_names = [ "aws.cloudtrail.user_identity.type", "aws.cloudtrail.user_identity.access_key_id", "aws.cloudtrail.user_identity.session_context.session_issuer.arn", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements", + ""aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements"," "event.action", "event.outcome", "cloud.account.id", From 6852a9626836bb8ab513c208bd856bef538d755a Mon Sep 17 00:00:00 2001 From: bryans3c Date: Thu, 18 Jun 2026 08:59:07 +0200 Subject: [PATCH 03/10] [New Rule] AWS Lambda Function Deletion --- .../aws/impact_lambda_function_deleted.toml | 129 ++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 rules/integrations/aws/impact_lambda_function_deleted.toml diff --git a/rules/integrations/aws/impact_lambda_function_deleted.toml b/rules/integrations/aws/impact_lambda_function_deleted.toml new file mode 100644 index 00000000000..91a6cb86848 --- /dev/null +++ b/rules/integrations/aws/impact_lambda_function_deleted.toml @@ -0,0 +1,129 @@ +[metadata] +creation_date = "2026/06/18" +integration = ["aws"] +maturity = "production" +updated_date = "2026/06/18" + +[rule] +author = ["Elastic"] +description = """ +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. +""" +false_positives = [ + """ + Lambda functions are routinely deleted during application decommissioning, environment teardown, and + infrastructure-as-code apply/destroy cycles. Verify whether the principal in `aws.cloudtrail.user_identity.arn` and + the deleted function are expected for the workload, and whether the change aligns with an approved maintenance or + deployment window. Known deployment roles and automation can be excluded after validation. + """, +] +from = "now-6m" +index = ["logs-aws.cloudtrail-*"] +interval = "5m" +language = "kuery" +license = "Elastic License v2" +name = "AWS Lambda Function Deletion" +note = """## Triage and analysis + +### Investigating AWS Lambda Function Deletion + +Deleting an AWS Lambda function removes its code, configuration, published versions, and aliases. This can be a +destructive action that disrupts serverless workloads and automation, or a cleanup step an adversary uses to remove a +backdoor function and erase evidence after their objective is met. + +This rule detects successful `DeleteFunction` calls. Investigate whether the principal and the deleted function are +expected, and whether the deletion correlates with other suspicious activity. + +#### Possible investigation steps + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review + `source.ip` and `user_agent.original` to determine how the deletion was performed (console, CLI, SDK, automation). +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and + environment (prod, staging, dev). +- Determine whether the deletion aligns with an approved change, decommissioning, or infrastructure-as-code destroy + operation by comparing `@timestamp` against deployment and change-management records. +- Correlate with recent activity by the same principal or access key, such as `CreateFunction`, `UpdateFunctionCode`, + `AddPermission`, `CreateEventSourceMapping`, log-group deletions, or other destructive or evasive actions. +- Verify whether multiple functions were deleted in a short window, which may indicate broad disruption rather than a + single planned change. + +### False positive analysis + +- Function deletions are common during decommissioning and infrastructure-as-code apply/destroy cycles. Deletions by + approved deployment roles, CI/CD pipelines, or platform automation are expected. Tune on + `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + +### Response and remediation + +- If the deletion is unauthorized, restore the function from source control or an infrastructure-as-code definition and + confirm its code, configuration, and execution role match a known-good state. +- Review CloudTrail for related destructive or evasive actions by the same actor and assess operational impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:DeleteFunction` to a + small set of trusted roles. + +### Additional information + +- [DeleteFunction API](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html) +""" +references = [ + "https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html", + "https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html", +] +risk_score = 47 +rule_id = "bb3ac0e3-2c9c-4069-a26d-75ca6a6e547b" +severity = "medium" +tags = [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Lambda", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "query" + +query = ''' +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: (DeleteFunction or DeleteFunction20*) + and event.outcome: "success" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1485" +name = "Data Destruction" +reference = "https://attack.mitre.org/techniques/T1485/" + + +[rule.threat.tactic] +id = "TA0040" +name = "Impact" +reference = "https://attack.mitre.org/tactics/TA0040/" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.user_identity.session_context.session_issuer.arn", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", +] + From 91fb5dcc6077d3abf22461c50625ab445c1b2d7d Mon Sep 17 00:00:00 2001 From: bryans3c Date: Thu, 18 Jun 2026 09:14:21 +0200 Subject: [PATCH 04/10] [New Rule] AWS Lambda Execution Role Credentials Used Outside Lambda --- ..._role_credentials_used_outside_lambda.toml | 170 ++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml diff --git a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml new file mode 100644 index 00000000000..75fddfcc203 --- /dev/null +++ b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml @@ -0,0 +1,170 @@ +[metadata] +creation_date = "2026/06/18" +integration = ["aws"] +maturity = "production" +updated_date = "2026/06/18" + +[rule] +author = ["Elastic"] +description = """ +Identifies a single AWS Lambda execution-role credential (a temporary assumed-role access key) that is used both from +inside the Lambda execution environment and from outside it within the same window. When a function runs, its temporary +credentials are presented with the Lambda runtime user agent (containing "exec-env/AWS_Lambda") or with a request +invoked by "lambda.amazonaws.com". An adversary who exfiltrates those credentials, typically through a server-side +request forgery or remote code execution flaw in the function, can replay them from their own host, where the same +access key appears without the Lambda runtime markers and from an unrelated source. Observing the same temporary key +both inside and outside the runtime is a strong indicator of stolen Lambda credentials being abused. +""" +false_positives = [ + """ + Some architectures proxy or forward Lambda activity in ways that can strip the runtime user agent, and certain AWS + service integrations may act on a function's behalf. Validate the access key, the principal in + `aws.cloudtrail.user_identity.arn`, the external source IPs, and the user agents observed outside the runtime before + treating the activity as malicious. Known proxies or service integrations can be tuned out after validation. + """, +] +from = "now-60m" +interval = "60m" +language = "esql" +license = "Elastic License v2" +name = "AWS Lambda Execution Role Credentials Used Outside Lambda" +note = """## Triage and analysis + +### Investigating AWS Lambda Execution Role Credentials Used Outside Lambda + +AWS Lambda functions receive temporary credentials for their execution role and use them from within the managed +runtime. CloudTrail records those calls with a user agent containing `exec-env/AWS_Lambda` or with +`aws.cloudtrail.user_identity.invoked_by` set to `lambda.amazonaws.com`. If the same temporary access key is also seen +making calls without those runtime markers, the credentials were almost certainly extracted from the function (for +example via SSRF or RCE against the function code) and replayed from an attacker-controlled location. + +This rule aggregates CloudTrail by the temporary access key and flags keys that were used both inside and outside the +Lambda runtime in the same window. + +#### Possible investigation steps + +- Review `Esql.source_ips` and `Esql.user_agents` for the external (non-runtime) activity and determine whether the + source IPs and clients are expected for the workload. +- Map `aws.cloudtrail.user_identity.arn` to the Lambda function and its execution role, and review the function's code, + dependencies, and recent changes for an SSRF/RCE or credential-exposure path. +- Examine `Esql.actions` for the operations performed with the credential outside the runtime, especially data access, + IAM, or STS calls that exceed the function's normal behavior. +- Determine the blast radius of the execution role's permissions and whether any sensitive actions succeeded. +- Pivot on the external source IPs across other identities and accounts for signs of broader credential abuse. + +### False positive analysis + +- Proxies, log-forwarding layers, or service integrations that act on a function's behalf may occasionally present a + Lambda credential without the runtime user agent. Validate the external source and client, and tune out known benign + patterns on `aws.cloudtrail.user_identity.arn` or the observed user agents. + +### Response and remediation + +- If the credential abuse is confirmed, terminate active sessions and rotate or revoke the execution role's + permissions; the temporary key cannot be individually revoked, so remove or restrict the role's trust and permissions. +- Patch the function's credential-exposure path (for example the SSRF/RCE vulnerability) and redeploy from a known-good + source. +- Review and reduce the execution role's permissions to least privilege, and assess any actions performed with the + stolen credential for data exposure or further compromise. + +### Additional information + +- [Lambda execution role](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) +- [Using AWS Lambda environment variables (runtime identifiers)](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) +""" +references = [ + "https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html", + "https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html", + "https://hackingthe.cloud/aws/exploitation/lambda-steal-iam-credentials/", +] +risk_score = 73 +rule_id = "0ae9b6c5-1deb-4ed4-9337-659dd701dfbc" +severity = "high" +tags = [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Lambda", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-aws.cloudtrail-* + +// Assumed-role sessions only; key on the temporary access key id (one credential) +| where + aws.cloudtrail.user_identity.type == "AssumedRole" + and aws.cloudtrail.user_identity.access_key_id IS NOT NULL + +// Classify each call as originating inside the Lambda execution environment or not +| eval Esql.in_lambda_runtime = case( + user_agent.original LIKE "*exec-env/AWS_Lambda*" + or aws.cloudtrail.user_identity.invoked_by == "lambda.amazonaws.com", + 1, 0) +| eval Esql.out_lambda_runtime = case( + user_agent.original LIKE "*exec-env/AWS_Lambda*" + or aws.cloudtrail.user_identity.invoked_by == "lambda.amazonaws.com", + 0, 1) + +| stats + Esql.lambda_runtime_calls = sum(Esql.in_lambda_runtime), + Esql.external_calls = sum(Esql.out_lambda_runtime), + Esql.source_ips = values(source.ip), + Esql.user_agents = values(user_agent.original), + Esql.actions = values(event.action) + by + aws.cloudtrail.user_identity.access_key_id, + aws.cloudtrail.user_identity.arn, + cloud.account.id + +// Same temporary credential used both inside the Lambda runtime and from outside it +| where Esql.lambda_runtime_calls > 0 and Esql.external_calls > 0 + +| keep + aws.cloudtrail.user_identity.access_key_id, + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.lambda_runtime_calls, + Esql.external_calls, + Esql.source_ips, + Esql.user_agents, + Esql.actions + +| sort Esql.external_calls desc +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1078" +name = "Valid Accounts" +reference = "https://attack.mitre.org/techniques/T1078/" +[[rule.threat.technique.subtechnique]] +id = "T1078.004" +name = "Cloud Accounts" +reference = "https://attack.mitre.org/techniques/T1078/004/" + + + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" + +[rule.investigation_fields] +field_names = [ + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.user_identity.arn", + "cloud.account.id", + "Esql.lambda_runtime_calls", + "Esql.external_calls", + "Esql.source_ips", + "Esql.user_agents", + "Esql.actions", +] + From 263041363082ebcab595345aab82fc867f79c225 Mon Sep 17 00:00:00 2001 From: Bryan Porras Date: Thu, 18 Jun 2026 09:19:56 +0200 Subject: [PATCH 05/10] Delete rules/integrations/aws/impact_lambda_function_deleted.toml --- .../aws/impact_lambda_function_deleted.toml | 129 ------------------ 1 file changed, 129 deletions(-) delete mode 100644 rules/integrations/aws/impact_lambda_function_deleted.toml diff --git a/rules/integrations/aws/impact_lambda_function_deleted.toml b/rules/integrations/aws/impact_lambda_function_deleted.toml deleted file mode 100644 index 91a6cb86848..00000000000 --- a/rules/integrations/aws/impact_lambda_function_deleted.toml +++ /dev/null @@ -1,129 +0,0 @@ -[metadata] -creation_date = "2026/06/18" -integration = ["aws"] -maturity = "production" -updated_date = "2026/06/18" - -[rule] -author = ["Elastic"] -description = """ -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. -""" -false_positives = [ - """ - Lambda functions are routinely deleted during application decommissioning, environment teardown, and - infrastructure-as-code apply/destroy cycles. Verify whether the principal in `aws.cloudtrail.user_identity.arn` and - the deleted function are expected for the workload, and whether the change aligns with an approved maintenance or - deployment window. Known deployment roles and automation can be excluded after validation. - """, -] -from = "now-6m" -index = ["logs-aws.cloudtrail-*"] -interval = "5m" -language = "kuery" -license = "Elastic License v2" -name = "AWS Lambda Function Deletion" -note = """## Triage and analysis - -### Investigating AWS Lambda Function Deletion - -Deleting an AWS Lambda function removes its code, configuration, published versions, and aliases. This can be a -destructive action that disrupts serverless workloads and automation, or a cleanup step an adversary uses to remove a -backdoor function and erase evidence after their objective is met. - -This rule detects successful `DeleteFunction` calls. Investigate whether the principal and the deleted function are -expected, and whether the deletion correlates with other suspicious activity. - -#### Possible investigation steps - -- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review - `source.ip` and `user_agent.original` to determine how the deletion was performed (console, CLI, SDK, automation). -- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and - environment (prod, staging, dev). -- Determine whether the deletion aligns with an approved change, decommissioning, or infrastructure-as-code destroy - operation by comparing `@timestamp` against deployment and change-management records. -- Correlate with recent activity by the same principal or access key, such as `CreateFunction`, `UpdateFunctionCode`, - `AddPermission`, `CreateEventSourceMapping`, log-group deletions, or other destructive or evasive actions. -- Verify whether multiple functions were deleted in a short window, which may indicate broad disruption rather than a - single planned change. - -### False positive analysis - -- Function deletions are common during decommissioning and infrastructure-as-code apply/destroy cycles. Deletions by - approved deployment roles, CI/CD pipelines, or platform automation are expected. Tune on - `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. - -### Response and remediation - -- If the deletion is unauthorized, restore the function from source control or an infrastructure-as-code definition and - confirm its code, configuration, and execution role match a known-good state. -- Review CloudTrail for related destructive or evasive actions by the same actor and assess operational impact. -- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:DeleteFunction` to a - small set of trusted roles. - -### Additional information - -- [DeleteFunction API](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html) -""" -references = [ - "https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html", - "https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html", -] -risk_score = 47 -rule_id = "bb3ac0e3-2c9c-4069-a26d-75ca6a6e547b" -severity = "medium" -tags = [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS Lambda", - "Use Case: Threat Detection", - "Tactic: Impact", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "query" - -query = ''' -data_stream.dataset: "aws.cloudtrail" - and event.provider: "lambda.amazonaws.com" - and event.action: (DeleteFunction or DeleteFunction20*) - and event.outcome: "success" -''' - - -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1485" -name = "Data Destruction" -reference = "https://attack.mitre.org/techniques/T1485/" - - -[rule.threat.tactic] -id = "TA0040" -name = "Impact" -reference = "https://attack.mitre.org/tactics/TA0040/" - -[rule.investigation_fields] -field_names = [ - "@timestamp", - "user.name", - "user_agent.original", - "source.ip", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "aws.cloudtrail.user_identity.access_key_id", - "aws.cloudtrail.user_identity.session_context.session_issuer.arn", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements", - "event.action", - "event.outcome", - "cloud.account.id", - "cloud.region", -] - From 296726de3c0b068151c9aafa27cda7793e473bc6 Mon Sep 17 00:00:00 2001 From: Bryan Porras Date: Thu, 18 Jun 2026 09:20:24 +0200 Subject: [PATCH 06/10] Delete rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml --- ...e_lambda_event_source_mapping_created.toml | 134 ------------------ 1 file changed, 134 deletions(-) delete mode 100644 rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml diff --git a/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml b/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml deleted file mode 100644 index 710e8d6b20f..00000000000 --- a/rules/integrations/aws/persistence_lambda_event_source_mapping_created.toml +++ /dev/null @@ -1,134 +0,0 @@ -[metadata] -creation_date = "2026/06/18" -integration = ["aws"] -maturity = "production" -updated_date = "2026/06/18" - -[rule] -author = ["Elastic"] -description = """ -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. -""" -false_positives = [ - """ - Application teams and infrastructure-as-code pipelines routinely create event source mappings to wire data - pipelines, queue consumers, and stream processors to Lambda functions. Verify whether the principal in - `aws.cloudtrail.user_identity.arn`, the function, and the event source are expected for the workload. Known - deployment roles and automation can be excluded after validation. - """, -] -from = "now-6m" -index = ["logs-aws.cloudtrail-*"] -interval = "5m" -language = "kuery" -license = "Elastic License v2" -name = "AWS Lambda Event Source Mapping Creation" -note = """## Triage and analysis - -### Investigating AWS Lambda Event Source Mapping Creation - -AWS Lambda event source mappings poll an event source (Amazon SQS, Kinesis or DynamoDB streams, Amazon MSK or -self-managed Kafka, or Amazon MQ) and invoke a target function as records arrive. Creating a mapping is a low-frequency, -high-impact configuration change: it can establish event-driven persistence and execution, or quietly relay sensitive -records from a stream or queue into attacker-controlled code. - -This rule detects successful `CreateEventSourceMapping` calls. Investigate whether the principal, the target function, -and the event source are expected for the environment. - -#### Possible investigation steps - -- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review - `source.ip` and `user_agent.original` to determine whether the call came from the console, CLI, SDK, or automation. -- Inspect `aws.cloudtrail.request_parameters` for the `functionName`/`functionArn` and the `eventSourceArn` to identify - the target function and the source queue, stream, topic, or broker. -- Determine whether the target function and the event source belong to the same application and account, and whether the - function code, role, and recent changes are trusted (correlate with `CreateFunction`, `UpdateFunctionCode`, and - `AddPermission`). -- Review whether the event source contains sensitive data (for example a DynamoDB stream or SQS queue carrying business - records) that the mapping could be used to exfiltrate. -- Pivot on the same principal and access key for other recent Lambda, IAM, or data-plane activity. - -### False positive analysis - -- Event source mappings are a normal building block of serverless data pipelines and queue/stream consumers. Mappings - created by approved deployment roles, CI/CD pipelines, or application teams are expected. Tune on - `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. - -### Response and remediation - -- If the mapping is unauthorized, disable or delete it (`DeleteEventSourceMapping`) and review the target function's - code, configuration, and execution role. -- Determine whether records were processed by the function while the mapping was active and assess potential data - exposure. -- Rotate or restrict credentials for the principal that created the mapping if compromise is suspected, and constrain - `lambda:CreateEventSourceMapping` to a small set of trusted roles. - -### Additional information - -- [AWS Lambda event source mappings](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html) -- [CreateEventSourceMapping API](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) -""" -references = [ - "https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html", - "https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html", -] -risk_score = 47 -rule_id = "5619545b-9738-408c-bdb5-a2807e19133e" -severity = "medium" -tags = [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS Lambda", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "query" - -query = ''' -data_stream.dataset: "aws.cloudtrail" - and event.provider: "lambda.amazonaws.com" - and event.action: CreateEventSourceMapping* - and event.outcome: "success" -''' - - -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1546" -name = "Event Triggered Execution" -reference = "https://attack.mitre.org/techniques/T1546/" - - -[rule.threat.tactic] -id = "TA0003" -name = "Persistence" -reference = "https://attack.mitre.org/tactics/TA0003/" - -[rule.investigation_fields] -field_names = [ - "@timestamp", - "user.name", - "user_agent.original", - "source.ip", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "aws.cloudtrail.user_identity.access_key_id", - "aws.cloudtrail.user_identity.session_context.session_issuer.arn", - ""aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements"," - "event.action", - "event.outcome", - "cloud.account.id", - "cloud.region", -] - From b512e4aedae5c40cf671e235c4aef4b3099aa715 Mon Sep 17 00:00:00 2001 From: Bryan Porras Date: Thu, 18 Jun 2026 15:35:18 +0200 Subject: [PATCH 07/10] Update defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml --- ..._role_credentials_used_outside_lambda.toml | 31 ++++++------------- 1 file changed, 9 insertions(+), 22 deletions(-) diff --git a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml index 75fddfcc203..fe0294783f8 100644 --- a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml +++ b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml @@ -32,40 +32,27 @@ note = """## Triage and analysis ### Investigating AWS Lambda Execution Role Credentials Used Outside Lambda -AWS Lambda functions receive temporary credentials for their execution role and use them from within the managed -runtime. CloudTrail records those calls with a user agent containing `exec-env/AWS_Lambda` or with -`aws.cloudtrail.user_identity.invoked_by` set to `lambda.amazonaws.com`. If the same temporary access key is also seen -making calls without those runtime markers, the credentials were almost certainly extracted from the function (for -example via SSRF or RCE against the function code) and replayed from an attacker-controlled location. +AWS Lambda functions receive temporary credentials for their execution role and use them from within the managed runtime. CloudTrail records those calls with a user agent containing `exec-env/AWS_Lambda` or with `aws.cloudtrail.user_identity.invoked_by` set to `lambda.amazonaws.com`. If the same temporary access key is also seen making calls without those runtime markers, the credentials were almost certainly extracted from the function (for example via SSRF or RCE against the function code) and replayed from an attacker-controlled location. -This rule aggregates CloudTrail by the temporary access key and flags keys that were used both inside and outside the -Lambda runtime in the same window. +This rule aggregates CloudTrail by the temporary access key and flags keys that were used both inside and outside the Lambda runtime in the same window. #### Possible investigation steps -- Review `Esql.source_ips` and `Esql.user_agents` for the external (non-runtime) activity and determine whether the - source IPs and clients are expected for the workload. -- Map `aws.cloudtrail.user_identity.arn` to the Lambda function and its execution role, and review the function's code, - dependencies, and recent changes for an SSRF/RCE or credential-exposure path. -- Examine `Esql.actions` for the operations performed with the credential outside the runtime, especially data access, - IAM, or STS calls that exceed the function's normal behavior. +- Review `Esql.source_ips` and `Esql.user_agents` for the external (non-runtime) activity and determine whether the source IPs and clients are expected for the workload. +- Map `aws.cloudtrail.user_identity.arn` to the Lambda function and its execution role, and review the function's code, dependencies, and recent changes for an SSRF/RCE or credential-exposure path. +- Examine `Esql.actions` for the operations performed with the credential outside the runtime, especially data access, IAM, or STS calls that exceed the function's normal behavior. - Determine the blast radius of the execution role's permissions and whether any sensitive actions succeeded. - Pivot on the external source IPs across other identities and accounts for signs of broader credential abuse. ### False positive analysis -- Proxies, log-forwarding layers, or service integrations that act on a function's behalf may occasionally present a - Lambda credential without the runtime user agent. Validate the external source and client, and tune out known benign - patterns on `aws.cloudtrail.user_identity.arn` or the observed user agents. +- Proxies, log-forwarding layers, or service integrations that act on a function's behalf may occasionally present a Lambda credential without the runtime user agent. Validate the external source and client, and tune out known benign patterns on `aws.cloudtrail.user_identity.arn` or the observed user agents. ### Response and remediation -- If the credential abuse is confirmed, terminate active sessions and rotate or revoke the execution role's - permissions; the temporary key cannot be individually revoked, so remove or restrict the role's trust and permissions. -- Patch the function's credential-exposure path (for example the SSRF/RCE vulnerability) and redeploy from a known-good - source. -- Review and reduce the execution role's permissions to least privilege, and assess any actions performed with the - stolen credential for data exposure or further compromise. +- If the credential abuse is confirmed, terminate active sessions and rotate or revoke the execution role's permissions; the temporary key cannot be individually revoked, so remove or restrict the role's trust and permissions. +- Patch the function's credential-exposure path (for example the SSRF/RCE vulnerability) and redeploy from a known-good source. +- Review and reduce the execution role's permissions to least privilege, and assess any actions performed with the stolen credential for data exposure or further compromise. ### Additional information From 9eb79bc6476e900eb50085fbbd505082b72fec9c Mon Sep 17 00:00:00 2001 From: Bryan Porras Date: Mon, 22 Jun 2026 15:03:32 +0200 Subject: [PATCH 08/10] Apply suggestion from @terrancedejesus Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com> --- ...n_lambda_execution_role_credentials_used_outside_lambda.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml index fe0294783f8..54c775e2029 100644 --- a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml +++ b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml @@ -27,7 +27,7 @@ from = "now-60m" interval = "60m" language = "esql" license = "Elastic License v2" -name = "AWS Lambda Execution Role Credentials Used Outside Lambda" +name = "AWS Lambda Execution Role Credentials Used Outside Function" note = """## Triage and analysis ### Investigating AWS Lambda Execution Role Credentials Used Outside Lambda From 08b7e0910190e4af052d2053d745f923d36fd23d Mon Sep 17 00:00:00 2001 From: Bryan Porras Date: Mon, 22 Jun 2026 15:04:02 +0200 Subject: [PATCH 09/10] Apply suggestions from code review Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com> --- ..._role_credentials_used_outside_lambda.toml | 47 +++++++++---------- 1 file changed, 21 insertions(+), 26 deletions(-) diff --git a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml index 54c775e2029..c3df670582f 100644 --- a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml +++ b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml @@ -30,7 +30,7 @@ license = "Elastic License v2" name = "AWS Lambda Execution Role Credentials Used Outside Function" note = """## Triage and analysis -### Investigating AWS Lambda Execution Role Credentials Used Outside Lambda +### Investigating AWS Lambda Execution Role Credentials Used Outside Function AWS Lambda functions receive temporary credentials for their execution role and use them from within the managed runtime. CloudTrail records those calls with a user agent containing `exec-env/AWS_Lambda` or with `aws.cloudtrail.user_identity.invoked_by` set to `lambda.amazonaws.com`. If the same temporary access key is also seen making calls without those runtime markers, the credentials were almost certainly extracted from the function (for example via SSRF or RCE against the function code) and replayed from an attacker-controlled location. @@ -82,46 +82,41 @@ type = "esql" query = ''' from logs-aws.cloudtrail-* -// Assumed-role sessions only; key on the temporary access key id (one credential) | where aws.cloudtrail.user_identity.type == "AssumedRole" and aws.cloudtrail.user_identity.access_key_id IS NOT NULL -// Classify each call as originating inside the Lambda execution environment or not -| eval Esql.in_lambda_runtime = case( +| eval is_lambda_call = case( user_agent.original LIKE "*exec-env/AWS_Lambda*" or aws.cloudtrail.user_identity.invoked_by == "lambda.amazonaws.com", 1, 0) -| eval Esql.out_lambda_runtime = case( - user_agent.original LIKE "*exec-env/AWS_Lambda*" - or aws.cloudtrail.user_identity.invoked_by == "lambda.amazonaws.com", - 0, 1) | stats - Esql.lambda_runtime_calls = sum(Esql.in_lambda_runtime), - Esql.external_calls = sum(Esql.out_lambda_runtime), - Esql.source_ips = values(source.ip), - Esql.user_agents = values(user_agent.original), - Esql.actions = values(event.action) + Esql.lambda_runtime_call_sum = sum(is_lambda_call), + Esql.total_call_count = count(), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_values = values(user_agent.original), + Esql.event_action_values = values(event.action) by aws.cloudtrail.user_identity.access_key_id, aws.cloudtrail.user_identity.arn, cloud.account.id -// Same temporary credential used both inside the Lambda runtime and from outside it -| where Esql.lambda_runtime_calls > 0 and Esql.external_calls > 0 +| eval Esql.external_call_count = Esql.total_call_count - Esql.lambda_runtime_call_sum + +| where Esql.lambda_runtime_call_sum > 0 and Esql.external_call_count > 0 | keep aws.cloudtrail.user_identity.access_key_id, aws.cloudtrail.user_identity.arn, cloud.account.id, - Esql.lambda_runtime_calls, - Esql.external_calls, - Esql.source_ips, - Esql.user_agents, - Esql.actions + Esql.lambda_runtime_call_sum, + Esql.external_call_count, + Esql.source_ip_values, + Esql.user_agent_values, + Esql.event_action_values -| sort Esql.external_calls desc +| sort Esql.external_call_count desc ''' @@ -148,10 +143,10 @@ field_names = [ "aws.cloudtrail.user_identity.access_key_id", "aws.cloudtrail.user_identity.arn", "cloud.account.id", - "Esql.lambda_runtime_calls", - "Esql.external_calls", - "Esql.source_ips", - "Esql.user_agents", - "Esql.actions", + "Esql.lambda_runtime_call_sum", + "Esql.external_call_count", + "Esql.source_ip_values", + "Esql.user_agent_values", + "Esql.event_action_values", ] From 56d9efbb25247c03875f7dd5fb3e2c7623d6fac9 Mon Sep 17 00:00:00 2001 From: Bryan Porras Date: Fri, 26 Jun 2026 15:47:26 +0200 Subject: [PATCH 10/10] Update time window and formatting in AWS Lambda rule --- ...ambda_execution_role_credentials_used_outside_lambda.toml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml index c3df670582f..9b4cd5bf93c 100644 --- a/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml +++ b/rules/integrations/aws/defense_evasion_lambda_execution_role_credentials_used_outside_lambda.toml @@ -23,7 +23,7 @@ false_positives = [ treating the activity as malicious. Known proxies or service integrations can be tuned out after validation. """, ] -from = "now-60m" +from = "now-61m" interval = "60m" language = "esql" license = "Elastic License v2" @@ -36,7 +36,7 @@ AWS Lambda functions receive temporary credentials for their execution role and This rule aggregates CloudTrail by the temporary access key and flags keys that were used both inside and outside the Lambda runtime in the same window. -#### Possible investigation steps +### Possible investigation steps - Review `Esql.source_ips` and `Esql.user_agents` for the external (non-runtime) activity and determine whether the source IPs and clients are expected for the workload. - Map `aws.cloudtrail.user_identity.arn` to the Lambda function and its execution role, and review the function's code, dependencies, and recent changes for an SSRF/RCE or credential-exposure path. @@ -56,7 +56,6 @@ This rule aggregates CloudTrail by the temporary access key and flags keys that ### Additional information -- [Lambda execution role](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) - [Using AWS Lambda environment variables (runtime identifiers)](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) """ references = [