40 AWS IAM Privilege Escalation Paths: Find and Close

AWS IAM privilege escalation requires no software vulnerability. An attacker chains legitimately granted permissions into a sequence that produces higher privileges than the policy author intended. Security researchers documented 21 such methods that allow an attacker to escalate from a compromised low-privilege account to full administrative privileges, and later work expanded the catalog to roughly 40 known paths as AWS integrated IAM actions into additional services. Detecting these paths before a pentester does requires graph-based analysis of every principal’s effective permissions, followed by targeted policy changes that close the highest-risk routes without breaking legitimate workflows.

How IAM Escalation Chains Work

The defining trait of IAM privilege escalation is that it exploits intended AWS API behavior, not a bug. A principal holding the iam:CreatePolicyVersion permission can create a new default version of any managed policy, including one attached to a more privileged user or role. The --set-as-default flag promotes the new version without requiring the separate iam:SetDefaultPolicyVersion permission. An attacker with iam:PassRole and ec2:RunInstances permissions can launch an EC2 instance that carries an administrator instance profile and then retrieve temporary credentials from the instance metadata service, gaining the full permissions of that role. The same iam:PassRole action paired with lambda:CreateFunction lets an attacker deploy code that executes under a privileged execution role. Because it is the mechanism by which a principal delegates a role’s permissions to a service that runs code, iam:PassRole appears in the majority of escalation paths across the documented techniques. For a detailed catalog of specific techniques and blocking controls, see our analysis of AWS IAM privilege escalation techniques and how to block them.

Detecting Paths With PMapper

Manual policy review cannot reliably surface escalation paths because they emerge from combinations of permissions spread across multiple policies, roles, and groups. PMapper, an open-source tool from NCC Group, builds a directed graph of every IAM principal in an account and computes all reachable escalation paths between them. After installing the tool and creating a graph with pmapper graph create, defenders query who can reach administrator access using pmapper query --who admin, which returns every principal with a path to full admin, including multi-hop routes through intermediate roles and services. The graph creation pulls all IAM users, roles, groups, and attached policies and typically takes five to thirty minutes depending on account size. PMapper answers the organizational question of blast radius — how far a single compromised credential can reach — which should drive remediation priority. Cloudsplaining, from Salesforce, complements PMapper by analyzing individual IAM policies for overly permissive actions and resource exposure, producing an HTML report that categorizes findings by risk level.

Scoping Access Analyzer Findings

While PMapper maps escalation paths statically, AWS IAM Access Analyzer’s unused access feature identifies permissions that active principals have never used, which is where over-granting originates. The findings highlight unused roles, unused access keys for IAM users, and unused passwords for IAM users, and for active principals they provide visibility into unused services and actions at a granular level. AWS recently added configuration options that let administrators exclude specific accounts and tagged IAM roles from the analysis scope, reducing noise from sandbox environments and security-auditing roles that intentionally hold broad permissions, as described in the AWS Security Blog guidance on customizing analyzer scope. An organization-level analyzer can be updated with aws accessanalyzer update-analyzer to exclude account IDs or resource tags. In AWS’s own example scenario, excluding a single sandbox account dropped the active findings count from 251 to 194, demonstrating how scoping reduces noise and lets teams focus on the permissions that matter. Organizations pursuing least privilege at scale can pair these findings with CSPM tooling to correlate unused access with broader misconfiguration risk.

Closing the Riskiest Paths

Research indicates that three IAM actions account for the majority of exploitable escalation paths: iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, and iam:PassRole without a condition key restricting the passable role ARN. The remediation sequence that minimizes operational disruption starts with narrowing wildcard resource scopes rather than removing actions entirely. For iam:PassRole, this means restricting the passable role ARNs to specific non-administrator roles using a Condition key instead of allowing Resource: *. For iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion, there is no legitimate use case for non-platform-engineering principals, so these actions should be removed from developer and CI/CD roles outright or scoped to a specific policy ARN if a pipeline needs to update its own execution policy. Audits of enterprise AWS accounts indicate that approximately 85 percent of those environments contain at least one viable escalation path from a non-admin identity to AdministratorAccess, typically through developer roles with broad service permissions.

Remediation Priority Checklist

Follow this ordered sequence to close paths with minimal disruption:

1. Narrow wildcard Resource scoping on iam:PassRole — change Resource: * to specific non-administrator role ARNs with a Condition key.
2. Add aws:PrincipalArn condition keys to every AssumeRole trust policy, listing only the specific principals authorized to assume each role.
3. Remove iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion from all non-administrator roles; scope to a specific policy ARN only when a pipeline requires self-modification.
4. Restrict iam:CreateAccessKey to Resource: arn:aws:iam::*:user/${aws:username} so principals can only create keys for their own identity.
5. Re-run Cloudsplaining after each change to confirm that the policy-level findings driving the escalation risk have been resolved.
6. Re-run pmapper query --who admin in a non-production account to verify no new paths opened before promoting changes to production IAM policies.

Sources

• Rhino Security Labs — AWS IAM Privilege Escalation: Methods and Mitigation
• AWS Security Blog — Customize the Scope of IAM Access Analyzer Unused Access Analysis
• Decryption Digest — AWS IAM Privilege Escalation Paths: How to Find the 40 Known Attack Routes