AWS IAM Privilege Escalation Paths: How to Find the 40 Known Attack Routes Before Your Next Pentest Does
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AWS IAM privilege escalation differs from most attack techniques in that it requires no exploitation of a software vulnerability. The attacker uses only the permissions they were legitimately granted, chained in a sequence that produces a higher privilege outcome than the policy author intended. A developer role with lambda:UpdateFunctionCode and iam:PassRole can become an administrator by updating a Lambda function that runs with an admin execution role.
Pentests against AWS environments find privilege escalation paths in the majority of enterprise accounts because the IAM policies that produce them are written to solve access problems without modeling the privilege implications of each permission in combination.
This guide covers the five most common escalation techniques, how to run automated analysis tools against your own accounts, and the specific IAM changes that close the highest-risk paths without breaking legitimate workflows.
The five most common escalation paths in enterprise environments
Path 1: iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion. A principal with these permissions can create a new version of any managed policy, including a policy attached to a more privileged user or role, and set it as the default version. This effectively lets the attacker rewrite any IAM policy in the account. Remediation: remove both actions from all non-administrator roles. These actions have no legitimate use case for non-platform engineering principals.
Path 2: iam:PassRole combined with lambda:CreateFunction and lambda:InvokeFunction. The attacker creates a new Lambda function, passes an administrator IAM role as the execution role, and invokes the function with a payload that performs the privileged action (creating an IAM user, attaching a policy to themselves, exfiltrating secrets). Remediation: restrict iam:PassRole to specific role ARNs using a condition key: Condition: StringLike: iam:PassedToService: lambda.amazonaws.com and restrict the passable role ARN to non-administrator roles.
Path 3: iam:CreateAccessKey on another user. If a principal can create access keys for any IAM user (not just themselves), they can create credentials for a more privileged user. Remediation: scope iam:CreateAccessKey to Resource: arn:aws:iam::*:user/${aws:username} (only the current user's own account).
Path 4: ec2:RunInstances with iam:PassRole and ec2:DescribeInstances plus ssm:StartSession. The attacker launches an EC2 instance with an administrator instance profile and then opens an SSM session into it, gaining a shell that runs as the administrator role. Remediation: restrict iam:PassRole for the EC2 service to specific non-administrator instance profile roles.
Path 5: sts:AssumeRole without condition key restrictions. Broad AssumeRole permissions on a role without a Condition on the principal ARN, external ID, or MFA allow any compromised principal in the account to assume the target role. Remediation: add Condition: StringEquals: aws:PrincipalArn to every AssumeRole trust policy, listing only the specific principals that should be able to assume the role.
Running PMapper against your AWS account
PMapper (Principal Mapper) is an open-source tool from NCC Group that builds a directed graph of every IAM principal in an account and maps all possible privilege escalation paths between them. It is the most comprehensive automated tool for finding these paths in a defender context.
Installation: pip install principalmapper
Create the graph for an account (uses your current AWS CLI profile): pmapper --profile [profile-name] graph create
This pulls all IAM users, roles, groups, and policies. The graph creation takes 5 to 30 minutes depending on account size.
Query who can reach admin: pmapper --profile [profile-name] query --who admin
This outputs every principal that has a path to administrator access, including multi-hop paths. The output format is: [principal] can reach admin via: [intermediate role or service] using [action].
Query a specific principal: pmapper --profile [profile-name] query "who can do iam:CreateUser"
Generate a visual graph: pmapper --profile [profile-name] visualize --output-type png
The visual graph makes it easy to show non-technical stakeholders the blast radius of a compromised developer credential.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Running Cloudsplaining for policy-level analysis
Cloudsplaining, from Salesforce, takes a different approach: it analyzes IAM policies directly for overly-permissive actions rather than mapping escalation paths. It is better than PMapper for identifying which specific policies need to change, and PMapper is better for understanding the organizational-level escalation risk.
Installation: pip install cloudsplaining
Download the account authorization details: cloudsplaining download --profile [profile-name] --output-directory /tmp/cloudsplaining/
Analyze the downloaded data: cloudsplaining analyze --input-file /tmp/cloudsplaining/[account-id].json --output-directory /tmp/cloudsplaining-results/
The output is an HTML report that categorizes all policies by risk level and lists specific findings: privilege escalation paths, resource exposure (policies that allow actions on * resources), data exfiltration risks, and credential exposure risks.
Filter the report to focus on the privilege escalation section first. Each finding lists the exact policy name, the IAM action that creates the risk, and the resource scope. Start remediation with findings in attached customer-managed policies (easier to change than AWS-managed policies) and where the resource scope is * (highest risk).
Remediation priority and what not to break
Removing IAM actions that create privilege escalation paths often breaks legitimate developer or automation workflows. The remediation sequence that minimizes operational disruption:
Step 1: Remove wildcard resource scoping on dangerous actions. An action like iam:PassRole is often legitimate but scoped to * resource. Changing the resource scope to specific role ARNs closes most escalation paths without removing the action entirely.
Step 2: Add condition keys to AssumeRole trust policies. Adding aws:PrincipalArn conditions to trust policies does not affect the actions that the legitimate principals can perform; it only prevents unexpected principals from assuming the role.
Step 3: Remove iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion from all non-administrator roles. There is no legitimate use case for a developer or CI/CD pipeline role to modify IAM policies. If a specific pipeline needs to update its own execution policy, scope it to the specific policy ARN.
Step 4: Scope iam:CreateAccessKey to the user's own account using the ${aws:username} variable. This breaks any automation that creates access keys for service accounts programmatically, which should be replaced with IAM role-based authentication rather than access keys.
For each change, test in a non-production account before applying to production IAM policies.
The bottom line
AWS IAM privilege escalation paths exist in almost every enterprise account because IAM policies are written to solve access problems, not to model the privilege implications of each permission combination. PMapper surfaces the organizational-level escalation risk in a single graph. Cloudsplaining surfaces the policy-level actions that drive it. Remediation starts with removing wildcard resource scopes on iam:PassRole, removing iam:CreatePolicyVersion and iam:SetDefaultPolicyVersion from non-admin roles, and adding principal conditions to AssumeRole trust policies. These four changes close the majority of escalation paths in most environments.
Frequently asked questions
What is the most dangerous IAM action for privilege escalation in AWS?
iam:PassRole combined with any service action that executes code (lambda:CreateFunction, ec2:RunInstances, glue:CreateJob, ecs:RegisterTaskDefinition) creates a privilege escalation path that is both common and difficult to detect. iam:PassRole by itself is not dangerous, but combined with the ability to create a service resource that uses the passed role, it allows an attacker to execute actions as any role they can pass to that service. Restricting iam:PassRole to specific passable role ARNs and specific service principals using condition keys closes this class of escalation path.
Is PMapper or Cloudsplaining better for finding IAM privilege escalation?
They answer different questions. PMapper maps who can escalate to admin access and via which path, making it the right tool for understanding organizational-level risk and for briefing leadership on blast radius. Cloudsplaining identifies which specific IAM policies contain the actions that enable escalation, making it the right tool for developers and security engineers doing remediation. Use PMapper first to understand scope, then Cloudsplaining to find the specific policies to change.
How do I prevent privilege escalation via iam:PassRole in AWS?
Add two condition keys to every iam:PassRole grant: iam:PassedToService restricted to the specific service that legitimately needs the role (for example, lambda.amazonaws.com), and restrict the Resource element to the specific role ARN that the service should use. Avoid granting iam:PassRole with Resource: * at all. The condition StringLike on iam:PassedToService restricts which services can receive the passed role, and the Resource ARN restriction limits which roles can be passed.
Which AWS IAM actions should never be granted to non-administrative identities?
The highest-risk IAM actions that should be restricted to administrative roles only: iam:CreateUser, iam:CreateAccessKey, iam:AttachUserPolicy, iam:AttachRolePolicy, iam:PutUserPolicy, iam:PutRolePolicy, iam:PassRole (for sensitive services), sts:AssumeRole with wildcard resources, and iam:UpdateAssumeRolePolicy. These actions, when granted to non-admin identities, create privilege escalation paths to AdministratorAccess. Detect overly permissive grants using AWS IAM Access Analyzer or run Cloudsplaining against your IAM policies to identify which policies contain these actions.
How do I audit AWS IAM for privilege escalation paths at scale?
For accounts with hundreds of roles and policies, use PMapper (Principal Mapper): install with pip install principalmapper, run pmapper graph --create for each account, then pmapper query 'who can escalate privileges?' to get a ranked list of privilege escalation paths. For identifying which specific policy statements contain dangerous actions, run Cloudsplaining against your IAM policy JSON exports: cloudsplaining scan-account --profile your-profile generates an HTML report. Run both tools quarterly and after any significant IAM changes. PMapper's --output-format csv makes it easy to pipe results into a ticketing system for remediation tracking.
What are the most dangerous IAM privilege escalation actions to look for in AWS?
The highest-risk single actions: iam:CreatePolicyVersion (allows replacing an existing policy with a new version that grants AdministratorAccess), iam:SetDefaultPolicyVersion (allows promoting an older policy version that may have had broader permissions), iam:AttachRolePolicy and iam:AttachUserPolicy (allows attaching AdministratorAccess to any role or user), iam:PassRole combined with ec2:RunInstances or lambda:CreateFunction (allows passing a higher-privileged role to a compute resource and executing code under it), and sts:AssumeRole without condition keys (allows assuming any role in the account). These actions should require explicit justification in any IAM policy and should never appear in IAM policies attached to human user identities without compensating controls like MFA conditions and IP restrictions.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.