← All posts Reference

The AWS Privilege Escalation Map

By the Pathbreak team · October 11, 2026 · 7 min read

Key takeaways

We built a reference of the AWS permissions an attacker can chain to administrator, data or persistence, with a page for each one.
Every entry carries the same four things: how the permission is used, the CloudTrail events that catch it, the MITRE ATT&CK technique, and the control that would remove the path.
Over half of the privilege-escalation entries run through iam:PassRole. It is the one permission that touches the most services.
Some permissions escalate on their own. Many only escalate in a combination, held together with others. Those toxic combinations are the ones a one-policy-at-a-time review misses.
Knowing a permission is dangerous is not the same as knowing it is dangerous in your account. That takes validation against your real authorization, and a business-context call on whether the permission is load-bearing.

Ask ten AWS engineers which permissions are dangerous and you will get ten short lists. Everyone names iam:PassRole. Most name the policy edits. After that it gets vague, because the real answer is long, it changes as AWS ships new services, and most of the danger is in combinations rather than single actions.

So we wrote it down. The AWS Privilege Escalation Map is a page for every permission an attacker can chain to administrator access, data, or a way back in. You can search it by service, by technique, or by a combination of permissions, and each entry reads the same way.

What is on each page

Every entry answers four questions. How is the permission used, on its own or only alongside others. How do you see it, as the CloudTrail events that record the call. Where does it sit in the attacker playbook, as the MITRE ATT&CK technique. And what would remove the path, as the control a defender could apply. The page draws the move as a chain, from the attacker principal to whatever the permission reaches, with the real API action on each step.

One toxic combination from the map. With lambda:CreateFunction and iam:PassRole held together, a principal creates a function, hands it a privileged role, and the function runs as that role. Neither permission is alarming alone.

A path, step by step

Take the move above, the one that more than half of the privilege-escalation entries rely on. Read as two separate policy statements, neither looks dangerous. Chained, they run attacker code as a role the principal was never granted.

Step 1. Start as an ordinary principal. A developer or CI role that holds lambda:CreateFunction and iam:PassRole is enough. Nothing here is administrator yet.
Step 2. Create a function with attacker code (lambda:CreateFunction). The function body is whatever the attacker wants to run.
Step 3. Pass a privileged role to it (iam:PassRole). Point the function at a role with more access than the principal holds, say one that can read every bucket or attach policies.
Step 4. Invoke it, and the code runs as that role. The principal has borrowed access it was never granted, which is the whole escalation.
Step 5. The cut: scope iam:PassRole to specific role ARNs and pin iam:PassedToService. That one change closes this path and a large share of the rest of the map, because every service that runs code for you accepts a passed role the same way.

That is one entry. The map draws the same chain for every permission it covers, so you can see the move before you decide whether the permission is load-bearing in your own account.

iam:PassRole is the common thread

Of the privilege-escalation entries in the map, more than half rely on iam:PassRole. It shows up in paths that reach two dozen different services, because every service that runs code for you will accept a role you hand it. Lambda, EC2, ECS, Glue, SageMaker, CodeBuild, Step Functions and the rest all take a passed role and run as it. That is why a single iam:PassRole grant on a wildcard resource is worth more to an attacker than almost any other permission. Scope it to specific role ARNs and pin iam:PassedToService, and a large share of the map closes at once.

Single permissions and toxic combinations

Some permissions escalate on their own. iam:AttachUserPolicy with a wide enough resource escalates on its own. But many of the most dangerous paths need two or more permissions held together, and neither one looks alarming alone. iam:PassRole is harmless without a service action to use it. lambda:CreateFunction is harmless without a role to pass. Hold both and you have arbitrary code running as a privileged role.

These toxic combinations are the ones that slip through review, because a policy audit that looks at one statement at a time never sees the pair. The map labels each entry as directly exploitable or as a toxic combination, and you can filter to just the combinations.

Why a list of permissions is not the whole story

A reference like this tells you which permissions can be dangerous. It cannot tell you which ones are dangerous in your account. That depends on who actually holds the permission, whether the trust policies and conditions line up, whether an SCP already blocks it, and whether the role it reaches is privileged. The same permission can be load-bearing in one account and pure risk in another.

So the map is deliberately careful about the fix. Each page shows the control that would remove the path, and then says plainly that whether to apply it is a business decision, not an automatic change. Pulling a permission that a pipeline depends on is its own kind of outage.

How to use it

Start from a service you run and read its entries. Search a permission you are about to grant and see what it opens up. Type two permissions to check whether together they form a path. Each page links the detection events you can alert on today and the MITRE technique for your own mapping, so the map is useful whether you are hardening, detecting, or threat modelling.

How Pathbreak uses it

The map is the public version of what Pathbreak reasons about inside your account. We connect read-only, resolve your real IAM policies, roles and trust relationships, and confirm which of these paths actually exist for your identities. Then we rank them by how much each one opens up and, with your threat model and business context, show which few changes cut the most. The first validated paths come back within the hour.

Frequently asked questions

What is the most dangerous AWS IAM permission?

iam:PassRole is the single most reused permission in privilege-escalation paths. Granted on a wildcard resource it lets a principal hand a privileged role to a service it can run, such as Lambda or EC2, and inherit that role. It is dangerous in combination with a service action rather than on its own, which is part of why it is so often left too broad. The Pathbreak AWS Privilege Escalation Map shows every combination that turns it into a path.

What is a toxic combination of permissions?

It is a set of two or more permissions that are safe individually but grant escalation when one principal holds them together. iam:PassRole plus lambda:CreateFunction is a classic example. Reviews that check one policy statement at a time miss these, because the risk is in the pairing, not in either permission alone. The Pathbreak map labels these as toxic combinations.

How do I know which of these permissions are actually dangerous in my account?

You validate them against your real authorization. A permission only forms a path if a principal actually holds it, the trust policies and conditions allow it, no guardrail blocks it, and the role it reaches is privileged. Pathbreak resolves this read-only and reports only the paths that resolve, rather than every permission that could in theory be risky.

Should I just remove every permission on the map?

No. Many of these permissions are doing legitimate work. The map shows the control that would remove each path, but whether to apply it is a business decision. The right approach is to validate which paths exist, rank them by how much they open up, and cut the few that matter most without breaking what depends on them. Pathbreak validates which of them form a real path in your accounts, so you fix those first.

Does the map cover more than privilege escalation?

Yes. Alongside privilege escalation it covers credential access, defense evasion against your own logging and guardrails, resource exposure to outside or public principals, data access, and persistence, because real attack paths cross those categories on the way to impact. Pathbreak maintains the map and validates the same techniques in its platform.

See which of these paths exist in your own AWS accounts.

Request a free scan