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/06/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]
79timestamp_override = "event.ingested"
80type = "query"
81
82query = '''
83data_stream.dataset: "aws.cloudtrail"
84 and event.provider: "lambda.amazonaws.com"
85 and event.action: AddLayerVersionPermission*
86 and event.outcome: "success"
87'''
88
89
90[[rule.threat]]
91framework = "MITRE ATT&CK"
92[[rule.threat.technique]]
93id = "T1648"
94name = "Serverless Execution"
95reference = "https://attack.mitre.org/techniques/T1648/"
96
97
98[rule.threat.tactic]
99id = "TA0002"
100name = "Execution"
101reference = "https://attack.mitre.org/tactics/TA0002/"
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104[[rule.threat.technique]]
105id = "T1578"
106name = "Modify Cloud Compute Infrastructure"
107reference = "https://attack.mitre.org/techniques/T1578/"
108[[rule.threat.technique.subtechnique]]
109id = "T1578.005"
110name = "Modify Cloud Compute Configurations"
111reference = "https://attack.mitre.org/techniques/T1578/005/"
112
113
114
115[rule.threat.tactic]
116id = "TA0005"
117name = "Defense Evasion"
118reference = "https://attack.mitre.org/tactics/TA0005/"
119
120[rule.investigation_fields]
121field_names = [
122 "@timestamp",
123 "user.name",
124 "user_agent.original",
125 "source.ip",
126 "aws.cloudtrail.user_identity.arn",
127 "aws.cloudtrail.user_identity.type",
128 "aws.cloudtrail.user_identity.access_key_id",
129 "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
130 "aws.cloudtrail.request_parameters",
131 "aws.cloudtrail.response_elements",
132 "event.action",
133 "event.outcome",
134 "cloud.account.id",
135 "cloud.region",
136]
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 Layer Added to Existing Function
- AWS Lambda Function Deletion
- AWS Lambda Event Source Mapping Creation
- AWS Bedrock Automated Reasoning Safety Policy Tampering
- AWS Bedrock Guardrail Deleted or Weakened