---
title: AWS Lambda Layer Shared Externally
description: 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...
url: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/integrations/aws/execution_lambda_layer_shared_externally
products:
  - Elastic Security
---

# 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.
**Rule type**: query
**Rule indices**:
- logs-aws.cloudtrail-*

**Rule Severity**: medium
**Risk Score**: 47
**Runs every**: 5m
**Searches indices from**: `now-6m`
**Maximum alerts per execution**: 100
**References**:
- [[https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)
- [[https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)

**Tags**:
- Domain: Cloud
- Data Source: AWS
- Data Source: Amazon Web Services
- Data Source: AWS Lambda
- Use Case: Threat Detection
- Tactic: Execution
- Tactic: Defense Evasion
- Resources: Investigation Guide
- Noise: Unknown
- Performance: Fast
- Rule Type: Custom Query (KQL)
- Platform: AWS
- Data Source: AWS CloudTrail
- Service: AWS Lambda

**Version**: 2
**Rule authors**:
- Elastic

**Rule license**: Elastic License v2

## Investigation guide


## 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_parameters` for the `layerName`, version number, `action`, and the granted `principal` (a specific account id, an organization id, or `*` for public).
- 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.
- 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.arn` or 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:AddLayerVersionPermission` to a small set of trusted roles.


### Additional information

- [AWS Lambda layers](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)
- [AddLayerVersionPermission API](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)


## Rule Query

```kuery
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "lambda.amazonaws.com"
    and event.action: AddLayerVersionPermission*
    and event.outcome: "success"
```

**Framework:** MITRE ATT&CK
- Tactic:
  - Name: Execution
  - Id: TA0002
  - Reference URL: [[https://attack.mitre.org/tactics/TA0002/](https://attack.mitre.org/tactics/TA0002/)](https://attack.mitre.org/tactics/TA0002/)
- Technique:
  - Name: Serverless Execution
  - Id: T1648
  - Reference URL: [[https://attack.mitre.org/techniques/T1648/](https://attack.mitre.org/techniques/T1648/)](https://attack.mitre.org/techniques/T1648/)

**Framework:** MITRE ATT&CK
- Tactic:
  - Name: Defense Evasion
  - Id: TA0005
  - Reference URL: [[https://attack.mitre.org/tactics/TA0005/](https://attack.mitre.org/tactics/TA0005/)](https://attack.mitre.org/tactics/TA0005/)
- Technique:
  - Name: Modify Cloud Compute Infrastructure
  - Id: T1578
  - Reference URL: [[https://attack.mitre.org/techniques/T1578/](https://attack.mitre.org/techniques/T1578/)](https://attack.mitre.org/techniques/T1578/)
- Sub Technique:
  - Name: Modify Cloud Compute Configurations
  - Id: T1578.005
  - Reference URL: [[https://attack.mitre.org/techniques/T1578/005/](https://attack.mitre.org/techniques/T1578/005/)](https://attack.mitre.org/techniques/T1578/005/)