Wildcard iam:PassRole Escalates via Lambda UpdateFunction

01 Incident diagnostics

The Symptom

CloudTrail shows unexplained UpdateFunctionConfiguration calls changing a function's Role parameter, followed shortly by an Invoke event. Security teams notice API calls originating from a Lambda execution role with permissions far broader than the function's stated purpose, or GuardDuty raises a PrivilegeEscalation:IAMUser finding tied to lambda.amazonaws.com as the passed-to service.

Detection

Run: aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=UpdateFunctionConfiguration --max-results 50 and inspect requestParameters.role for unexpected ARNs. Cross-reference with: aws iam simulate-principal-policy --policy-source-arn --action-names iam:PassRole lambda:UpdateFunctionConfiguration --resource-arns arn:aws:iam:::role/* to confirm the wildcard grant resolves to Allow.

Root Cause

The attached IAM policy contains a statement such as {"Effect":"Allow","Action":"iam:PassRole","Resource":"*"} with no iam:PassedToService or resource-ARN restriction. Paired with lambda:UpdateFunctionConfiguration or lambda:CreateFunction, this lets any caller swap an existing function's execution role for one they cannot otherwise assume directly. Because Lambda's runtime credential endpoint (169.254.170.2) issues STS tokens for whatever role is attached at invocation time, calling Invoke immediately materialises those elevated credentials inside attacker-controlled code.

Prevention

Scope every iam:PassRole grant to explicit role ARNs with an iam:PassedToService condition matching lambda.amazonaws.com only. Deploy a Service Control Policy denying iam:PassRole unless that condition is present. Enforce permission boundaries on all Lambda execution roles capping maximum achievable privilege, and add IAM Access Analyzer's unused-access findings to a weekly review so wildcard PassRole grants surface before they're exploited.

Blast Radius

• Every IAM role in the account becomes passable to Lambda, including cross-service roles never intended for compute workloads
• Any function updated this way retains the elevated role until manually reverted, creating a persistent backdoor
• Downstream resources reachable by the assumed role (S3, RDS, Secrets Manager, other Lambda functions) inherit exposure
• CI/CD deploy roles with this pattern let a single compromised pipeline stage pivot to full account control
• Cross-account trust relationships attached to the elevated role extend the blast radius beyond the originating account