AWS API calls indicating Lambda privilege escalation
Description
AlphaSOC detected an IAM policy change granting permissions for privilege
escalation through AWS Lambda. This detection identifies two patterns: full CRUD
(Create, Read, Update, Delete) permissions on Lambda functions, or the
combination of iam:PassRole, lambda:CreateFunction, and invocation
permissions (lambda:InvokeFunction or lambda:CreateEventSourceMapping). The
detection triggers on CreatePolicy, CreatePolicyVersion, PutUserPolicy,
PutGroupPolicy, PutRolePolicy, AttachUserPolicy, AttachRolePolicy,
AttachGroupPolicy events that introduce these permissions.
Full CRUD permissions grant complete control over Lambda resources, allowing
threat actors to create functions with privileged roles, modify existing
function code, or update configurations to exfiltrate data. The role-based
escalation path allows an attacker to create a Lambda function, attach an IAM
role with higher privileges, and execute the function to inherit those elevated
permissions. Execution occurs directly via lambda:InvokeFunction or
automatically through event source mappings from services like S3, DynamoDB, or
SQS. Once executed, the attacker's code runs with the full permissions of the
attached role.
Impact
If exploited, the attacker gains the ability to execute arbitrary code within Lambda functions using the permissions of their execution roles, which often have elevated access to multiple AWS services. Malicious code can perform data exfiltration, modify resources, or pivot to other services accessible by the function's role. This may enable data access across S3, RDS, DynamoDB, and other integrated services, credential theft from environment variables or Secrets Manager, and lateral movement through service integrations. Attackers can establish persistence by creating functions triggered automatically via event sources, allowing continued access without direct interaction.
Severity
| Severity | Condition |
|---|---|
Low | AWS API calls indicating Lambda privilege escalation |
Investigation and Remediation
Check CloudTrail for the PutUserPolicy, PutGroupPolicy, PutRolePolicy, or
Attach\*Policy event that added Lambda permissions. Identify the target
principal and review requestParameters to examine the exact permissions
granted. Verify whether full CRUD permissions or the iam:PassRole +
lambda:CreateFunction + invocation pattern is required for legitimate use.
If unauthorized, immediately detach or delete the policy. Review CloudTrail for
CreateFunction, UpdateFunctionCode, UpdateFunctionConfiguration,
InvokeFunction, or CreateEventSourceMapping actions performed by the
affected principal. Check Lambda for functions created or modified by the
principal. Examine function code, environment variables, execution roles, and
event source mappings. Review CloudWatch Logs for function invocations to
identify accessed resources. Delete suspicious functions and rotate credentials
for the affected principal and any exploited Lambda execution roles.
Known False Positives
- Authorized administrators provisioning Lambda permissions for serverless application development
- Infrastructure-as-code deployments creating service roles for CI/CD pipelines