Detection of Unauthorized AWS Lambda Layer Modifications

Adversaries possessing sufficient permissions to interact with the AWS Lambda API can exploit the service's layer architecture to maintain stealthy persistence. By adding a malicious or unauthorized Lambda layer to an existing function, an attacker can inject code into the function's execution environment without modifying the primary source code. This technique allows for the interception of sensitive data, execution of unauthorized backend tasks, or modification of function output.

This activity is often identified via AWS CloudTrail events where UpdateFunctionConfiguration or PublishLayerVersion actions occur outside of established CI/CD pipelines. Because Lambda layers are designed for legitimate code sharing and dependency management, monitoring requires distinguishing between automated infrastructure-as-code (IaC) deployments and manual or anomalous API requests. Security teams should prioritize visibility into configuration changes originating from non-authorized identities or unexpected source IP addresses.

Impact

Successful exploitation allows attackers to persist within a serverless environment, potentially leading to long-term data exfiltration or the subversion of internal business logic. The impact is significant for organizations relying heavily on serverless architectures, where such modifications can remain undetected if not monitored at the API level.

Recommendation

• Deploy the provided detection logic to monitor for AWS Lambda configuration updates that do not originate from known CI/CD or IaC tooling.
• Audit existing Lambda functions to identify currently attached layers that do not map to authorized internal code repositories.
• Implement IAM policies that restrict the ability to modify Lambda configurations and publish new layers to specific, highly-privileged automation service roles.
• Establish a baseline of expected deployment activity to reduce noise from routine CI/CD releases.