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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/06/18"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or
11the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the
12execution environment of any function that references them. Sharing a layer with an external account or with everyone can
13leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream
14functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or
15public access warrants review.
16"""
17false_positives = [
18 """
19 Organizations sometimes publish shared utility layers across their own accounts or to partners intentionally. Verify
20 the layer, the granted principal in `aws.cloudtrail.request_parameters`, and the principal in
21 `aws.cloudtrail.user_identity.arn` against approved sharing practices. Known shared layers and distribution accounts
22 can be excluded after validation.
23 """,
24]
25from = "now-6m"
26index = ["logs-aws.cloudtrail-*"]
27interval = "5m"
28language = "kuery"
29license = "Elastic License v2"
30name = "AWS Lambda Layer Shared Externally"
31note = """## Triage and analysis
32
33### Investigating AWS Lambda Layer Shared Externally
34
35AWS Lambda layers bundle code and dependencies that are loaded into the runtime of any function referencing them. `AddLayerVersionPermission` modifies a layer version's permission policy to allow another AWS account, an organization, or the public (`principal=*`) to use it. This can expose code or secrets contained in the layer and can act as a supply-chain vector for any function that consumes the layer.
36
37This rule detects successful `AddLayerVersionPermission` calls. Public grants (`principal=*`) are the highest concern; specific cross-account grants should be validated against approved sharing.
38
39### Possible investigation steps
40
41- Inspect `aws.cloudtrail.request_parameters` for the `layerName`, version number, `action`, and the granted `principal` (a specific account id, an organization id, or `*` for public).
42- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the grant was made.
43- Determine whether the layer contains sensitive code or secrets and whether external sharing was intended and approved.
44- Identify which functions reference the layer and whether the grant could influence their runtime.
45- Correlate with other activity by the same principal, such as layer publication (`PublishLayerVersion`) or function changes.
46
47### False positive analysis
48
49- Shared utility layers distributed across an organization's accounts or to partners are a legitimate pattern. Confirm the grant is approved and exclude known distribution accounts or layers on `aws.cloudtrail.user_identity.arn` or the layer name after validation.
50
51### Response and remediation
52
53- If the sharing is unauthorized, remove the layer permission (`RemoveLayerVersionPermission`) and rotate any secrets that may have been exposed in the layer.
54- Review which accounts accessed or copied the layer while the grant was in place and assess potential exposure.
55- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddLayerVersionPermission` to a small set of trusted roles.
56
57### Additional information
58
59- [AWS Lambda layers](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)
60- [AddLayerVersionPermission API](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)
61"""
62references = [
63 "https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html",
64 "https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html",
65]
66risk_score = 47
67rule_id = "e00c7862-43f1-48fd-aa30-950db838eded"
68severity = "medium"
69tags = [
70 "Domain: Cloud",
71 "Data Source: AWS",
72 "Data Source: Amazon Web Services",
73 "Data Source: AWS Lambda",
74 "Use Case: Threat Detection",
75 "Tactic: Execution",
76 "Tactic: Defense Evasion",
77 "Resources: Investigation Guide",
78 "Noise: Unknown",
79 "Performance: Fast",
80 "Rule Type: Custom Query (KQL)",
81 "Platform: AWS",
82 "Data Source: AWS CloudTrail",
83 "Service: AWS Lambda",
84]
85timestamp_override = "event.ingested"
86type = "query"
87
88query = '''
89data_stream.dataset: "aws.cloudtrail"
90 and event.provider: "lambda.amazonaws.com"
91 and event.action: AddLayerVersionPermission*
92 and event.outcome: "success"
93'''
94
95
96[[rule.threat]]
97framework = "MITRE ATT&CK"
98[[rule.threat.technique]]
99id = "T1648"
100name = "Serverless Execution"
101reference = "https://attack.mitre.org/techniques/T1648/"
102
103
104[rule.threat.tactic]
105id = "TA0002"
106name = "Execution"
107reference = "https://attack.mitre.org/tactics/TA0002/"
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110[[rule.threat.technique]]
111id = "T1578"
112name = "Modify Cloud Compute Infrastructure"
113reference = "https://attack.mitre.org/techniques/T1578/"
114[[rule.threat.technique.subtechnique]]
115id = "T1578.005"
116name = "Modify Cloud Compute Configurations"
117reference = "https://attack.mitre.org/techniques/T1578/005/"
118
119
120
121[rule.threat.tactic]
122id = "TA0005"
123name = "Defense Evasion"
124reference = "https://attack.mitre.org/tactics/TA0005/"
125
126[rule.investigation_fields]
127field_names = [
128 "@timestamp",
129 "user.name",
130 "user_agent.original",
131 "source.ip",
132 "aws.cloudtrail.user_identity.arn",
133 "aws.cloudtrail.user_identity.type",
134 "aws.cloudtrail.user_identity.access_key_id",
135 "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
136 "aws.cloudtrail.request_parameters",
137 "aws.cloudtrail.response_elements",
138 "event.action",
139 "event.outcome",
140 "cloud.account.id",
141 "cloud.region",
142]
Triage and analysis
Investigating AWS Lambda Layer Shared Externally
AWS Lambda layers bundle code and dependencies that are loaded into the runtime of any function referencing them. AddLayerVersionPermission modifies a layer version's permission policy to allow another AWS account, an organization, or the public (principal=*) to use it. This can expose code or secrets contained in the layer and can act as a supply-chain vector for any function that consumes the layer.
This rule detects successful AddLayerVersionPermission calls. Public grants (principal=*) are the highest concern; specific cross-account grants should be validated against approved sharing.
Possible investigation steps
- Inspect
aws.cloudtrail.request_parametersfor thelayerName, version number,action, and the grantedprincipal(a specific account id, an organization id, or*for public). - Identify the actor in
aws.cloudtrail.user_identity.arnandaws.cloudtrail.user_identity.type, and reviewsource.ipanduser_agent.originalto understand how the grant was made. - Determine whether the layer contains sensitive code or secrets and whether external sharing was intended and approved.
- Identify which functions reference the layer and whether the grant could influence their runtime.
- Correlate with other activity by the same principal, such as layer publication (
PublishLayerVersion) or function changes.
False positive analysis
- Shared utility layers distributed across an organization's accounts or to partners are a legitimate pattern. Confirm the grant is approved and exclude known distribution accounts or layers on
aws.cloudtrail.user_identity.arnor the layer name after validation.
Response and remediation
- If the sharing is unauthorized, remove the layer permission (
RemoveLayerVersionPermission) and rotate any secrets that may have been exposed in the layer. - Review which accounts accessed or copied the layer while the grant was in place and assess potential exposure.
- Rotate or restrict credentials for the principal if compromise is suspected, and constrain
lambda:AddLayerVersionPermissionto a small set of trusted roles.
Additional information
References
Related rules
- AWS Lambda Event Source Mapping Creation
- AWS Attempt to Leave Organization
- AWS Backup Vault Deleted or Vault Lock Removed
- AWS Bedrock Automated Reasoning Safety Policy Tampering
- AWS GuardDuty Detection Suppression