The permission that promotes itself (AWS PassRole)
An attacker with iam:PassRole and a service that assumes roles can hand a powerful role to a resource they control, then operate as that role. Here is the classic AWS privilege-escalation path, and the fix.
The fastest way up in AWS is rarely a new permission for you. It is handing an existing powerful role to something you control.
What it is
Many AWS services run as an IAM role you pass them: a Lambda, an EC2 instance profile, a Glue or ECS task. An attacker who holds iam:PassRole plus permission to create or run such a service passes a more privileged role to a resource they control, then executes code as that role, escalating well beyond their own permissions. This is T1078 (valid accounts) with T1548 (abuse elevation control mechanism).
Why it works
PassRole is easy to grant too broadly, and combined with a single service that assumes roles it becomes a privilege-escalation primitive. The action looks like normal service usage.
How to detect it
In CloudTrail, look for PassRole of a privileged role followed by creating or running a service as it, from a principal that does not normally do so.
The fix that holds
Scope iam:PassRole tightly with conditions (which roles, to which services), separate who can pass roles from who can create services, and alert on PassRole of sensitive roles. Least-privilege the roles themselves so even a passed role yields little.
Practice it
We built an IAM PassRole escalation scenario in GraphLattice Range so teams learn to spot the promote-yourself pattern and scope it out.