AWS iam:PassRole enables privesc

AWS IAM has a permission that sounds harmless — `iam:PassRole`. It is not harmless. In the wrong combination, it becomes a clean privilege-escalation path inside an AWS account. The trick is simple: if a user can create a Lambda function and pass it a more powerful execution role, that user can make AWS run code with that role’s permissions. That means the real issue is not “can they assume admin directly?” but “can they get a service to do it for them.” (aws.amazon.com) ### What does `iam:PassRole` actually do? `iam:PassRole` lets one principal attach an IAM role to an AWS service resource. AWS’s own example uses Lambda — a developer creates a function and supplies a role ARN, and Lambda then uses that role when the function runs. The caller does not become that role in the usual STS sense, but the service still gets to act with the role’s permissions. That distinction is exactly why teams miss the risk. (aws.amazon.com) ### Why does Lambda make this dangerous? Lambda is dangerous here because it turns role-passing into code execution. A function needs an execution role, and Lambda automatically assumes that role every time the function runs. So if a compromised user can create a function with a stronger role, the user can drop in a few lines of code to read secrets, list buckets, alter IAM-related resources, or call whatever APIs that role allows. (docs.aws.amazon.com) ### Is this a bug in AWS? No — basically, this is expected platform behavior. AWS documents `PassRole` as the mechanism for letting approved users configure services with roles, and it explicitly uses Lambda `CreateFunction` as a normal example. The problem is policy design. If defenders grant `iam:PassRole` too broadly, especially with wildcard resources or access to sensitive roles, they create an escalation path by policy. (aws.amazon.com) ### What permissions make the path work? The core combo is `iam:PassRole` plus `lambda:CreateFunction`. In practice, `lambda:InvokeFunction` makes the path immediately useful, because the attacker can run the function on demand. Datadog flags that exact trio — broad `PassRole`, `CreateFunction`, and `InvokeFunction` — as a privilege-escalation condition because it lets a user create and execute Lambda functions under arbitrary roles. (docs.datadoghq.com) ### Why is this easy to overlook? Because `PassRole` looks like delegation, not impersonation. Teams often think, “this developer needs to ship Lambda functions,” and grant broad role-passing without tightly scoping which roles can be attached. But the mome(docs.datadoghq.com)er, but they can still drive away. (aws.amazon.com) ### Has this shown up in real attacks? Yes — Lambda already shows up in cloud intrusions because it is cheap, quiet, and easy to automate. Wiz documented an incident where an attacker used Lambda and API Gateway to maintain persistence and generate new IAM users on demand. That is not the same writeup as this escalation path, but it shows why service-based executio(aws.amazon.com)ch human logins more closely than service activity. (threats.wiz.io) ### What should defenders change first? Scope `iam:PassRole` to specific role ARNs, not `*`. Separate it into its own policy statement so it is easier to audit. Make sure the roles that can be passed to Lambda do not carry broad admin permissions unless absolutely necessary. Then look for principals that have some mix of `PassRole`, Lambda creation, and invocation ri(threats.wiz.io)nvenience first and cleanup later. (aws.amazon.com) ### What is the bottom line? This is not a flashy zero-day. It is a policy footgun with very real blast radius. If an attacker gets a foothold in AWS, overly broad `iam:PassRole` can turn a narrow compromise into service-backed privilege escalation fast. (aws.amazon.com)