AWS IAM Privilege Escalation: Cheat Sheet And Defense (2026)
In the world of cloud penetration testing, there is a harsh reality: you rarely need a zero-day exploit to take over an AWS environment.
According to AWS's own threat research, over 80% of cloud security incidents are not caused by vulnerabilities in AWS infrastructure. They are caused by customer misconfigurations—specifically, overly permissive IAM (Identity and Access Management) policies.
If an attacker compromises a low-privileged developer's AWS access key, they don't need to hack the AWS hypervisor. They just need to find a single misconfigured IAM policy that allows them to chain permissions together to grant themselves AdministratorAccess. This is AWS IAM Privilege Escalation.
Also Read: AWS Security Best Practices: A Complete Checklist
This guide is the definitive, tutor-led masterclass on AWS IAM privilege escalation. We will break down the exact attack vectors (the cheat sheet), show you how attackers chain permissions to take over accounts, and provide the actionable defense strategies you need to lock down your AWS environment.
Primary Cloud Attack Vector: IAM Misconfigurations & Over-privileged Roles.
Average Time to Compromise: < 5 minutes (if a high-risk PassRole chain exists).
Most Dangerous Permission:
iam:PassRole combined with compute services.Top Exploitation Tool: Pacu (Open-source AWS exploitation framework).
Ultimate Defense: Service Control Policies (SCPs) & IAM Permissions Boundaries.
- Understanding AWS IAM Privilege Escalation
- The AWS IAM Privilege Escalation Cheat Sheet
- The Most Dangerous Vector: iam:PassRole Chains
- Real-World Attack Scenario: Lambda + PassRole
- Tools of the Trade: Testing IAM Priv Esc
- Defense Strategies: How to Lock Down AWS IAM
- First Actions for Cloud Security Teams
- Frequently Asked Questions
1. Understanding AWS IAM Privilege Escalation
In a traditional Windows environment, privilege escalation means exploiting a kernel vulnerability to go from a standard user to NT AUTHORITY\SYSTEM. In AWS, there is no kernel to exploit.
AWS IAM Privilege Escalation is the process of leveraging existing, overly-permissive IAM policies to grant yourself higher-level access. It is entirely authorized by the control plane; the attacker is simply using the AWS API exactly as it was designed, just in a way the administrator never intended.
Also Read: What is IAM? Identity and Access Management Explained for Enterprise
2. The AWS IAM Privilege Escalation Cheat Sheet
This cheat sheet categorizes the most common IAM misconfigurations that lead to privilege escalation. If you see these permissions granted to non-admin users, your account is at critical risk.
🔴 Category 1: Direct IAM Policy Manipulation
If a user can modify IAM policies, they can simply grant themselves AdministratorAccess.
| Malicious Permission | What the Attacker Does | Severity |
|---|---|---|
iam:CreateAccessKey |
Creates a new access key for a highly privileged user (or themselves) and uses it to authenticate. | CRITICAL |
iam:CreateLoginProfile |
Sets a console password for a privileged user, allowing GUI access. | CRITICAL |
iam:AttachUserPolicy |
Attaches the AdministratorAccess managed policy to their own user account. |
CRITICAL |
iam:PutUserPolicy |
Creates an inline JSON policy granting *:* (full admin) on their own user. |
CRITICAL |
iam:AddUserToGroup |
Adds their user to the "Admins" or "Domain Admins" equivalent IAM group. | CRITICAL |
🟠 Category 2: Compute & Infrastructure Abuse
These vectors allow an attacker to spin up infrastructure and attach privileged roles to it, effectively "borrowing" admin rights.
| Malicious Permission | What the Attacker Does | Severity |
|---|---|---|
ec2:RunInstances + iam:PassRole |
Launches a new EC2 instance and attaches an Admin IAM Instance Profile. They SSH in and query the instance metadata to steal the admin credentials. | CRITICAL |
cloudformation:CreateStack + iam:PassRole |
Creates a CloudFormation stack using a privileged service role. The stack template contains commands to exfiltrate data or create backdoor admin users. | HIGH |
glue:CreateDevEndpoint + iam:PassRole |
Creates an AWS Glue development endpoint (a Spark cluster) and passes an Admin role to it. The attacker SSHs into the endpoint to steal the role's keys. | HIGH |
3. The Most Dangerous Vector: iam:PassRole Chains
The iam:PassRole permission is the single most dangerous permission in AWS IAM when combined with compute services.
What it does: iam:PassRole allows a principal to pass an existing IAM role to an AWS service (like Lambda, EC2, or ECS) so the service can assume that role and act on your behalf.
iam:PassRole alone does not grant administrative access. It only allows you to hand a role to a service. To achieve privilege escalation, the attacker must also have permission to create or modify that specific service (e.g., lambda:CreateFunction) and execute code within it to extract the temporary credentials.
🔗 The Dangerous Combinations
iam:PassRole+lambda:CreateFunction+lambda:InvokeFunctioniam:PassRole+ec2:RunInstances+ec2:DescribeInstancesiam:PassRole+ecs:CreateCluster+ecs:RunTaskiam:PassRole+sagemaker:CreateNotebookInstance
4. Real-World Attack Scenario: Lambda + PassRole
Let's walk through exactly how an attacker exploits the Lambda + PassRole chain. This is the most common and devastating priv-esc vector in modern AWS pentests.
Step 1: The Vulnerable Policy
A developer is given a policy to manage Lambda functions, but the administrator carelessly included iam:PassRole on all resources.
Step 2: The Attack Execution
The attacker uses the AWS CLI to create a new Lambda function. They write a simple Python script that uses the boto3 library to query the AWS STS (Security Token Service) API to get the credentials of the role attached to the function.
Result: The attacker now has the temporary credentials of the AdminRole. They are effectively a full AWS administrator for the next 1 to 12 hours (depending on the role's max session duration).
5. Tools of the Trade: Testing IAM Priv Esc
If you are a red teamer or a cloud security engineer validating your defenses, you need the right tools to safely test these chains.
| Tool | Type | Primary Use Case |
|---|---|---|
| Pacu | Open-Source (Python) | The "Metasploit for AWS". Automates enumeration and execution of dozens of known IAM privilege escalation chains. |
| CloudGoat | Open-Source (Vulnerable Lab) | Deploys intentionally vulnerable AWS environments. Perfect for practicing priv-esc scenarios safely. |
| Prowler | Open-Source (Auditing) | Scans your AWS account against CIS Benchmarks and finds overly permissive IAM policies before attackers do. |
| Parliament | Open-Source (Linting) | An AWS IAM linting library. Scans your JSON policies in CI/CD pipelines to catch dangerous permissions like iam:PassRole on * resources. |
6. Defense Strategies: How to Lock Down AWS IAM
Knowing how to attack is only half the battle. Here is how you build a defense-in-depth strategy to prevent IAM privilege escalation.
🛡️ Layer 1: Preventative Controls (The Hard Boundaries)
- Service Control Policies (SCPs): Use AWS Organizations to apply SCPs at the root or OU level. SCPs act as a hard ceiling. Even if a user is granted
AdministratorAccess, an SCP can explicitly denyiam:CreateUseror restrict actions to specific regions. This is your ultimate backstop. - IAM Permissions Boundaries: Apply a permissions boundary to IAM roles and users. This caps the maximum permissions they can ever have, even if they manage to attach an Admin policy to themselves.
- Restrict iam:PassRole: Never grant
iam:PassRoleonResource: "*". Always restrict it to the specific ARN of the role that the service actually needs.
🔍 Layer 2: Detective Controls (Finding the Flaws)
- IAM Access Analyzer: Enable this in every region. It continuously analyzes your IAM policies and alerts you when a resource is shared externally or when a policy grants overly broad permissions.
- CloudTrail & GuardDuty: Ensure CloudTrail is enabled in all regions and logs are sent to an immutable S3 bucket. Configure GuardDuty to detect anomalous IAM activity, such as a user suddenly calling
iam:AttachUserPolicyat 3 AM. - AWS Config: Write custom AWS Config rules to automatically flag and remediate any IAM policy that contains
"Effect": "Allow", "Action": "*", "Resource": "*".
⚙️ Layer 3: Shift-Left Security (CI/CD Pipeline)
- Policy as Code: Stop writing IAM policies in the AWS Console. Define them in Terraform or CloudFormation.
- Automated Scanning: Integrate tools like Checkov, Parliament, or PolicySentry into your CI/CD pipeline (GitHub Actions, GitLab CI). If a developer pushes a Terraform file containing
iam:PassRoleon*, the pipeline must fail the build automatically.
⚡ First Actions for Cloud Security Teams
- Run Prowler Immediately. Install Prowler and run a full scan of your AWS organization. Look specifically for checks related to IAM wildcard permissions (
iam:check12) and overly permissive PassRole policies. - Enable IAM Access Analyzer. Go to the IAM console, enable Access Analyzer for your organization, and create a scanner for every active region. Review the findings daily.
- Implement a Deny-All SCP. In AWS Organizations, create an SCP that explicitly denies
iam:CreateUser,iam:CreateAccessKey, andiam:AttachUserPolicyfor all accounts, except for a dedicated "Break-Glass" admin role. - Hunt for PassRole Abuse. Use AWS CloudTrail to search for the
PassRoleevent. Filter by the user/role that called it, and verify if the role they passed was strictly necessary for that specific service.
7. Frequently Asked Questions
What is AWS IAM privilege escalation?
AWS IAM privilege escalation occurs when a user or role with limited permissions exploits misconfigured IAM policies to gain higher-level access, ultimately compromising the entire AWS account. Unlike traditional OS privilege escalation, AWS priv esc relies on chaining permissive IAM actions (like iam:PassRole or lambda:CreateFunction) to assume administrative control.
What is the most dangerous AWS IAM privilege escalation vector?
The combination of iam:PassRole with a compute service like AWS Lambda or EC2 is widely considered the most dangerous vector. It allows an attacker to pass a highly privileged role (like an Admin role) to a new Lambda function they create, execute code within that function, and exfiltrate the role's temporary credentials, effectively granting them full administrative access.
How do attackers test for IAM privilege escalation?
Attackers and red teamers use specialized AWS exploitation frameworks like Pacu (by Rhino Security Labs) or CloudGoat. These tools automate the enumeration of IAM policies and attempt known privilege escalation chains (such as creating access keys, attaching policies, or exploiting PassRole) to safely demonstrate the attack path without causing destructive changes.
How can organizations prevent AWS IAM privilege escalation?
Prevention requires a multi-layered approach: 1) Enforce the Principle of Least Privilege using IAM Access Analyzer. 2) Implement Service Control Policies (SCPs) in AWS Organizations to set hard permission boundaries. 3) Use IAM Permissions Boundaries to cap the maximum permissions a role can assume. 4) Scan Infrastructure as Code (Terraform/CloudFormation) with tools like Checkov or Parliament before deployment.
What is the difference between iam:PutUserPolicy and iam:AttachUserPolicy?
Both lead to privilege escalation if misconfigured, but they work differently. iam:PutUserPolicy creates an inline policy directly embedded within the user object. iam:AttachUserPolicy attaches a managed, reusable policy document to the user. From an attacker's perspective, both allow the modification of a user's effective permissions to grant themselves AdministratorAccess.
Does iam:PassRole alone grant administrative access?
No. iam:PassRole alone does not grant administrative access; it only allows a principal to pass an existing IAM role to an AWS service (like EC2, Lambda, or ECS). To achieve privilege escalation, the attacker must also have permissions to create or modify that specific service (e.g., lambda:CreateFunction) and execute code within it to extract the role's temporary credentials.
