English
Español
Français
Deutsch
日本語
한국어
العربيةAWS privilege escalation map
The Pathbreak Attack Map for AWS
Curated by Pathbreak Research · Updated October 2026
The most comprehensive public map of AWS permissions an attacker can chain to administrator, data or persistence: how each one is used, the CloudTrail events that catch it, the MITRE ATT&CK technique, and the single change that breaks the path. Every path is checked against real authorization before Pathbreak reports it.
Start here
Combinations worth knowing
Plenty of AWS permissions only reach admin when they line up with others. Those combinations are the ones a one-policy-at-a-time review tends to miss. Here are a few. The full map is searchable below.
Hijack EC2 user-data
A principal can stop the instance, rewrite its user-data with ec2:ModifyInstanceAttribute, and start it again; on boot the instance runs the attacker's user-data script as its already-attached instance-profile role, no iam:PassRole needed. A privileged instance profile means arbitrary code execution as that role: full privilege escalation against a box that was already trusted.
Hijack CloudFormation stack role via change set
A principal can call cloudformation:CreateChangeSet and cloudformation:ExecuteChangeSet on an existing CloudFormation stack that already carries the service role. By staging a modified template as a change set and executing it, the principal makes CloudFormation apply the attacker's changes using the target role, no iam:PassRole needed, because the target role is already bound to the stack. A privileged service role means the attacker's template can provision admin resources: full privilege escalation against a stack that was already trusted.
Hijack instance role via SSM command
A principal can call ssm:SendCommand to run an AWS-RunShellScript document on an SSM-managed instance that already carries the instance-profile role, executing attacker commands that read the instance's live credentials from IMDS and ship them out, non-interactively, with no shell session, key, or open port. Because the instance is already bound to the box, command execution on it is enough to steal the role, no iam:PassRole needed. If the instance is privileged this is full privilege escalation against an instance that was already trusted, and it is scriptable across many instances at once.
Check your own account against these paths. pathbreak-audit is our free, open source command line tool for defenders: point it at an AWS account, read-only, and it shows you the risky roles and users, and exactly what to cut.
pip install pathbreak-audit
Search by permission, service or MITRE technique. Multiple words narrow the results.
No permissions match that filter.
Loading the map...
What the data shows
Patterns across every path in the map. These describe where AWS privilege escalation concentrates and where a defender gets the most coverage for the least change. Each percentage is the share of entries in this map that have the property, counted from the map's own catalog, so the figures describe the documented paths and say nothing about any particular AWS account.
of the privilege-escalation paths in the map rely on iam:PassRole. iam:PassRole is the most frequently reused permission across the dataset. It appears in paths that reach 23 AWS services, because every service that runs workloads for you will accept a role you hand it. Scoping iam:PassRole to specific role ARNs and pinning iam:PassedToService removes most of these at once.
need only a single permission to reach impact. Most paths in the map require just one over-broad action. The remainder depend on a combination of two or more permissions held together. A least-privilege review of individual actions addresses the larger share.
of privilege-escalation fixes are a scoping or condition change, not a removal. The recommended change is usually to constrain a permission (a resource scope, an iam:PassedToService condition, or an org guardrail) rather than to take it away, so the team keeps the capability while the path closes.
of paths are observable from a single CloudTrail event. Each entry lists the management-plane events that record the action. Most map to one event, so detection rules can be written per path without heavy correlation.
double as a persistence mechanism. A large share of these actions let an attacker keep access after the initial entry is closed (a standing credential, an MFA change, a trust edit). These are worth alerting on even when they look like routine administration.
are defense-evasion moves against your own logging and guardrails. Stopping CloudTrail, disabling GuardDuty or Security Hub, deleting flow logs, or detaching an SCP each appears as its own entry. They are single-call actions, so a deny on the security tooling is the cleanest control.
Who uses these paths? The same moves turn up in real cloud incidents. See the groups behind them in the Cloud Threat Actors reference.
See which of these exist in your account
Pathbreak connects with a read-only role, finds the paths that resolve against your real authorization, and ranks the few changes that cut the most. One account, one scan, first validated paths within the hour.
Questions
What are the most dangerous AWS IAM permissions?
The permissions that let a principal change who can do what, or run code as a more privileged role: iam:PutRolePolicy, iam:AttachRolePolicy, iam:CreatePolicyVersion, iam:UpdateAssumeRolePolicy and iam:PassRole paired with a compute service. This map lists every one Pathbreak tracks, and the change that breaks the path.
Why is iam:PassRole dangerous?
iam:PassRole lets a principal hand an IAM role to an AWS service. Granted on a wildcard resource, an attacker passes a privileged role to a service it can run (EC2, Lambda, ECS and others) and inherits that role. Scope iam:PassRole to specific role ARNs and pin iam:PassedToService.
How do I prevent AWS privilege escalation?
Scope iam:PassRole, keep permissions boundaries on roles, deny IAM policy and trust edits outside a change-management role, and alert on the CloudTrail events listed here. Pathbreak validates which paths resolve in your account and ranks the few changes that cut the most.
Does this cover more than privilege escalation?
Yes. It also covers credential access, defense evasion, resource exposure, data access and persistence, because real attack paths cross those categories on the way to impact.
What is the AWS Privilege Escalation Map?
It is a public reference of the AWS permissions an attacker can chain to administrator access, data or persistence. Each one has its own page with how it is used, the CloudTrail events that catch it, the MITRE ATT&CK technique, and the control that would remove the path. It is the public version of what Pathbreak reasons about inside an account.
Who is it for?
Cloud security engineers, detection engineers, red teams and anyone writing IAM policies. Use it to understand what a permission opens up before you grant it, to build detection rules, or to threat model an account.
How do I use it?
Search by permission, by service, or by a combination of permissions. Open any entry to see the attack chain, the detection events you can alert on today, the MITRE technique, and the change that would break the path. Each page is a standalone reference you can link to.
How is a single permission different from a toxic combination?
Some permissions grant escalation on their own. Many only do so when held together with others, for example iam:PassRole with a service action. Those combinations are the ones a one-policy-at-a-time review tends to miss, so the map labels each entry and lets you filter to just the combinations.
Is this the complete list of dangerous AWS permissions?
It covers the paths Pathbreak tracks today and we keep it current as AWS ships new services. If you think something is missing or wrong, email hello@pathbreak.io and we will look at it.
How does Pathbreak use this in my account?
Pathbreak connects read-only, resolves your real IAM policies, roles and trust relationships, and confirms which of these paths actually exist for your identities. It ranks them by how much each one opens up and, with your threat model and business context, shows which few changes cut the most. First validated paths come back within the hour.
Service glyphs are based on the AWS Architecture Icons set, recolored to identify each service. AWS and the service names are trademarks of Amazon Web Services. Pathbreak is not affiliated with or endorsed by AWS.