AWS IAM
escalation.

The anatomy.

The pattern is identical across engagements: an attacker compromises a low-privilege identity (often via a forgotten access key in a Git repository or a leaky CI build log). That identity has lambda:UpdateFunctionCode on at least one Lambda. The Lambda’s execution role has iam:PassRole with broad scope — or worse, the Lambda’s own role has AdministratorAccess. Game over.

Why it keeps happening.

Three reasons. First, AWS makes attaching AdministratorAccess the path of least resistance during initial setup. Second, IAM policies are hard to read — especially with nested condition keys and resource patterns. Third, most cloud-posture tools alert on the public S3 bucket but not on the combination of lambda:UpdateFunctionCode + a permissive role. The attack path is invisible without graph-based analysis.

Concrete exploitation.

Given an access key with lambda:UpdateFunctionCode on function thumbnailer, the attacker:

1. Identifies the function’s execution role via aws lambda get-function
2. Confirms the role has a permission they want (e.g., s3:GetObject on a sensitive bucket, or iam:CreateAccessKey)
3. Uploads malicious code via UpdateFunctionCode
4. Triggers the function with any allowed event source
5. Reads the result from CloudWatch logs or an attacker-controlled outbound channel

Within minutes the attacker has the same privileges as the Lambda’s execution role — often Domain Admin equivalent in AWS terms.

Detection rules.

You don’t need a SIEM vendor licence to catch this. CloudTrail captures every relevant call:

• Alert on UpdateFunctionCode outside business hours or from unexpected source IPs
• Alert on CreateFunction with a high-privilege role
• Alert on AttachRolePolicy attaching anything containing * in actions or resources
• Alert on iam:PassRole events from identities not in your developer group
• Alert on access-key creation for service accounts (these should rotate via STS, never via long-lived keys)

Prevention patterns.

• Use Service Control Policies (SCPs) at the AWS Organizations level to forbid iam:PassRole on AdministratorAccess from non-admin identities
• Apply the aws:PrincipalOrgID condition key everywhere you allow cross-account access
• Run Cloudsplaining and PMapper against every account quarterly to map privilege escalation paths
• Enable IAM Access Analyzer findings and act on them
• For Lambda specifically: use scoped execution roles per function — never share roles across functions
• Rotate access keys, or better, eliminate them entirely with IAM Roles Anywhere for on-prem workloads

Where to start.

If you’ve never mapped your IAM privilege escalation paths, that’s the highest-leverage thing you can do this quarter. Open-source tools (cloudsplaining, pmapper, iam-vulnerable) make it tractable. If you’d rather have specialists walk your estate, our cloud security audit includes a complete privilege escalation graph as a standard deliverable.