AWS IAM privilege escalation paths, explained: why reading policies isn't enough

TL;DR. Most IAM reviews read one policy at a time and ask “what does this allow?” But permissions compose: iam:PassRole plus the ability to create a Lambda function lets you run code as a more privileged role; a chain of sts:AssumeRole can end at an administrator three hops away; iam:CreatePolicyVersion on your own policy lets you write your own permissions. None of these say “administrator” anywhere. To find them you have to treat identity as a graph and ask two more questions: can a human actually reach the start of this path, and what does the end of it touch?

What is an IAM privilege escalation path?

A privilege escalation path is a sequence of individually legitimate AWS permissions that, taken together, let an identity obtain more access than any single policy grants it.

The key word is sequence. Policy review is a static exercise — you open a policy, read the actions, and judge whether they’re appropriate. Escalation is a dynamic one. It asks what an identity can do with what it has, then what it can do with that, and keeps going.

This is why an account can pass a policy-by-policy audit and still be one API call away from a full compromise.

Two approved permissions, no single one of them “admin,” and yet the account arrives there anyway. Each step passes review on its own — the chain is what a one-permission-at-a-time audit misses.

How do ordinary permissions become administrator access?

Three well-documented classes cover most of what you’ll find in a real AWS account.

PassRole plus a compute service

iam:PassRole lets an identity hand a role to an AWS service. On its own it does nothing. Combined with permission to create a compute resource — a Lambda function, an EC2 instance, an ECS task — it becomes powerful: you create something, attach a more privileged role to it, and run your own code inside that role’s context.

Neither permission looks like administrator access. The combination effectively is, bounded only by which roles you’re allowed to pass.

Chained AssumeRole

sts:AssumeRole is the backbone of AWS multi-account access, and it composes. If role A may assume role B, and role B may assume role C, and role C is an administrator, then whoever holds A is an administrator — they just take three steps to get there.

Every hop is legitimate. Every trust policy, read in isolation, looks reasonable. The escalation exists only in the composition, which is exactly what a policy-by-policy review cannot see.

Rewriting your own permissions

Some IAM actions operate on IAM itself. iam:CreatePolicyVersion on a customer-managed policy attached to your own principal means you don’t need broader permissions — you can grant them to yourself and set your version as default. Related actions (iam:AttachUserPolicy, iam:PutUserPolicy, iam:SetDefaultPolicyVersion) create similar self-service routes.

The escalation isn’t a misconfiguration in the usual sense. Every action is being used exactly as designed.

Why does reachability matter more than the count of findings?

Here is where most identity tooling stops being useful: it hands you a list of paths, sorted by nothing in particular.

A path is only as dangerous as its entry point. If an escalation chain starts at a role that nothing and nobody can assume — no human principal, no reachable service — it’s a theoretical risk. It should be fixed, but it isn’t an emergency. If the same chain starts at a human user with console access, a federated identity, or a role assumable by a broad principal, it’s an open door.

That’s the difference between a finding and an incident, and it’s the reason “how many identity findings do you have?” is a much worse question than “which of them can a person actually walk to?”

Reachability analysis is what converts a permission graph into a priority list. Without it, you get volume. With it, you get a queue.

What about blast radius?

The second discriminator is what sits at the end of the path.

An escalation that terminates at a role able to read three log buckets is a genuine problem with a small footprint. An escalation terminating at a role that can read every database in the account is a different severity of event entirely — same path length, same technique, vastly different consequence.

Path length, reachability, and blast radius together give you something a severity label alone never will: an ordering that reflects real risk.

How do you audit paths instead of policies?

1. Build the graph, not the list. Enumerate principals (users, roles) and the edges between them: who can assume whom, who can pass which roles, who can modify which policies. The edges are the analysis; the nodes alone are just an inventory.
2. Enumerate what each identity can become. For each principal, follow the edges transitively until you reach a fixed point. Record the terminal privilege, not just the immediate one.
3. Mark human reachability. Identify which principals a person can actually authenticate as — IAM users, federated/SSO roles, roles with broad trust policies. Propagate that backwards through the graph.
4. Measure the blast radius at each terminus. Count what the end-state role can actually touch.
5. Sort by reachable-and-consequential, not by count or by raw severity.
6. Re-run it on a schedule. The graph changes every time someone adds a trust relationship or attaches a policy. A point-in-time audit is stale almost immediately.

Open-source tooling exists for the graph-building step — PMapper is the best-known, and AWS IAM Access Analyzer covers adjacent ground for external access and unused permissions. The analysis discipline matters more than the specific tool.

How different industries could use this

Path analysis matters most wherever a single over-reachable identity would cross a boundary that’s supposed to hold.

• Healthcare. Environments handling patient data usually separate clinical workloads from analytics. An escalation path that starts in a low-sensitivity analytics account and terminates at a role able to read a clinical data store crosses exactly the boundary an audit assumes is intact — and it would pass a policy-by-policy review, because no single policy spans both.
• Financial services. Segregation of duties is a control, not just a guideline. If the identity that can deploy code can also, three hops later, assume a role that approves or moves transactions, the separation exists on paper only. Path analysis is how you test the control rather than assert it.
• Education. Research computing tends to accumulate long-lived roles and generous trust policies as projects hand off between departments and graduating students. The risk is rarely a deliberate grant; it’s an old trust relationship nobody remembers, still reachable.
• Cybersecurity teams. Security tooling itself often holds broad read access across an estate. That makes the tooling’s own roles high-value terminal nodes, and worth checking as endpoints of paths rather than only as trusted infrastructure.
• SaaS and multi-tenant platforms. Where per-tenant isolation is enforced by IAM, an escalation path that reaches a role able to assume across tenant boundaries is a tenancy failure, not just a permissions issue.
• Data and analytics. Warehouses concentrate everything valuable in one place, which makes them the highest-blast-radius terminus in most accounts. Two paths of identical length differ enormously if one ends at a log bucket and the other at the warehouse.

The common thread: policy review tells you what each identity was granted, and path analysis tells you what it can reach. Regulated and fast-moving environments both need the second view, for different reasons — one to prove a boundary holds, the other because the graph changes faster than anyone can track by hand.

What this doesn’t cover

Path analysis is not a complete identity program. It won’t tell you whether MFA is enforced, whether access keys are being rotated, or whether an identity’s permissions are proportionate to its job. Those are separate, worthwhile checks.

What path analysis uniquely gives you is the compositional view — the risk that exists in the relationships between identities rather than inside any one of them. That risk is invisible to every review method that looks at one policy at a time, which is most of them.

FAQ

What is a privilege escalation path in AWS IAM?

A sequence of individually legitimate permissions that together grant an identity more access than any single policy allows — for example, iam:PassRole combined with permission to create a Lambda function, which lets an identity run code as a more privileged role.

Can an IAM role without administrator permissions become an administrator?

Yes. Through chained sts:AssumeRole relationships, through iam:PassRole plus a compute service, or through IAM actions that let a principal rewrite its own policies. In none of these cases does any single policy contain administrator permissions.

Why isn’t reviewing IAM policies one at a time enough?

Because escalation lives in the composition of permissions, not inside any single policy. A policy-by-policy review evaluates each grant in isolation and cannot see that grant A plus grant B produces access neither one confers alone.

What is human reachability in identity analysis?

Whether a real person can authenticate as the principal at the start of an escalation path. A dangerous path beginning at an unreachable role is theoretical; the same path beginning at a human-accessible identity is an active exposure. Reachability is what turns a list of findings into a priority order.

What is blast radius in the context of IAM?

The scope of what the identity at the end of an escalation path can actually access. Two paths of identical length and technique can differ enormously in consequence depending on what the terminal role can reach.

How often should IAM path analysis run?

Continuously, or at minimum on every significant IAM change. The permission graph changes whenever a trust policy is edited or a policy is attached, so a point-in-time assessment goes stale quickly.