AWS Lambda Layer Shared Externally

edit

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS Lambda Layer Shared Externally

edit

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-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

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

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

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

Rule query

edit

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

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Serverless Execution
- ID: T1648
- Reference URL: https://attack.mitre.org/techniques/T1648/
Tactic:
- Name: Defense Evasion
- ID: TA0005
- Reference URL: https://attack.mitre.org/tactics/TA0005/
Technique:
- Name: Modify Cloud Compute Infrastructure
- ID: T1578
- Reference URL: 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/

« AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key AWS Bedrock High-Frequency Single-Model Inference API Probing »