AWS Lambda Layer Added to Existing Function
ELASTIC detection rule by Elastic · Elastic License v2
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.
[metadata]
creation_date = "2024/04/30"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"
[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
"""
Lambda function owners or deployment pipelines may legitimately add or update layers as part of normal development
and maintenance workflows. Confirm that the layer addition aligns with approved changes, expected CI/CD behavior, or
routine dependency updates. Known automation roles or build systems can be excluded if they consistently perform
authorized modifications.
""",
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Lambda Layer Added to Existing Function"
note = """## Triage and analysis
### Investigating AWS Lambda Layer Added to Existing Function
Lambda layers introduce external code artifacts into a function’s runtime. Adding a layer to an existing Lambda function
modifies its execution environment and may allow an adversary to run arbitrary code, intercept data, or maintain
persistence without altering the function source itself. This detection highlights successful configuration updates using
`PublishLayerVersion*` or `UpdateFunctionConfiguration*`.
### Possible investigation steps
**Identify the actor**
- Review `aws.cloudtrail.user_identity.arn` and the `access_key_id`. Determine whether the actor normally administers Lambda or has recently exhibited unusual behavior.
**Review what was modified**
- Inspect `aws.cloudtrail.request_parameters` to identify which layer ARN was added, the function name and region, whether multiple layers were applied at once or in rapid succession.
- Compare the added layer version against known and approved layer catalogs.
**Validate the operational context**
- Check the time of the update (`@timestamp`) to see if it aligns with known release pipelines or deployment windows and Normal working hours for the responsible team.
- Determine whether a CI/CD pipeline or IaC tool was expected to update this function.
**Assess where the change came from**
- Review `source.ip` and `user_agent.original` for signs of console access from unusual locations, access via previously unused automation tools, suspicious programmatic access consistent with compromised keys.
**Correlate with additional activity**
- Look for preceding or subsequent events such as:
- Creation of new Lambda layers (`PublishLayerVersion`).
- IAM role modifications affecting the Lambda function.
- Increased invocation volume or unusual invocation patterns after the layer addition.
- Search for other functions modified by the same actor or from the same IP.
### False positive analysis
- Confirm whether the change aligns with a planned deployment, application update, or dependency upgrade.
- Determine whether the user or automation role commonly modifies Lambda function configurations.
- Validate the legitimacy of the added layer by checking internal documentation or release notes.
### Response and remediation
- Remove or roll back the added layer if the modification appears unauthorized or suspicious.
- Review the layer contents, especially for newly published layers, to verify integrity and legitimacy.
- Investigate the IAM role or user responsible for the change and rotate compromised credentials if necessary.
- Tighten permissions by ensuring only approved roles can modify Lambda configurations or publish new layers.
- Implement monitoring for subsequent Lambda configuration changes, invocation anomalies caused by the injected layer, additional persistence techniques targeting serverless infrastructure.
### Additional information
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**
- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
"""
references = [
"https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence",
"https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html",
"https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html",
]
risk_score = 21
rule_id = "7d091a76-0737-11ef-8469-f661ea17fbcc"
severity = "low"
tags = [
"Domain: Cloud",
"Platform: AWS",
"Data Source: AWS CloudTrail",
"Service: AWS Lambda",
"Tactic: Execution",
"Rule Type: Custom Query (KQL)",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset: aws.cloudtrail
and event.provider: lambda.amazonaws.com
and event.outcome: success
and event.action: (PublishLayerVersion* or UpdateFunctionConfiguration*)
and not user_agent.original: (*Terraform* or *Pulumi*)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1648"
name = "Serverless Execution"
reference = "https://attack.mitre.org/techniques/T1648/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1578"
name = "Modify Cloud Compute Infrastructure"
reference = "https://attack.mitre.org/techniques/T1578/"
[[rule.threat.technique.subtechnique]]
id = "T1578.005"
name = "Modify Cloud Compute Configurations"
reference = "https://attack.mitre.org/techniques/T1578/005/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[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",
"event.action",
"event.outcome",
"cloud.account.id",
"cloud.region",
"aws.cloudtrail.request_parameters",
"aws.cloudtrail.response_elements",
]