What Is AWS Privilege Escalation?

Key Escalation Paths

AWS privilege escalation typically exploits the gap between the permissions a principal has and the permissions those permissions allow them to grant themselves. The research pioneered by Spencer Gietzen at Rhino Security Labs identified over 20 distinct escalation paths in AWS IAM, and the list has grown since.

The iam:CreatePolicyVersion path is the most straightforward. If a user has permission to create a new version of an existing IAM policy (and that policy is attached to their own user or a group they belong to), they can write a new policy version with Effect: Allow on all actions and resources, then set it as the default version. They have just given themselves administrator access using a single API call.

The iam:PassRole combined with a service creation permission represents a class of escalation paths. PassRole allows a principal to assign an existing IAM role to an AWS service. If a user has iam:PassRole and lambda:CreateFunction, they can create a Lambda function that executes with a high-privilege role, then invoke that function to perform actions their own user cannot. The same pattern applies with iam:PassRole combined with ec2:RunInstances (launch an instance with a powerful instance profile), glue:CreateDevEndpoint, sagemaker:CreateNotebookInstance, or cloudformation:CreateStack. Each of these services accepts a role and executes with that role's permissions.

Cross-account role assumption via sts:AssumeRole is both a legitimate access pattern and a privilege escalation vector. If a role in another AWS account has a trust policy that allows assumption from the compromised account, the attacker can pivot to the second account with whatever permissions that role grants. Misconfigured trust policies, particularly those that trust an entire account (arn:aws:iam::ACCOUNT_ID:root) rather than specific principals, enable this lateral movement.

EC2 instance profile abuse is a common real-world escalation path. When an attacker gains code execution on an EC2 instance, through an SSRF vulnerability, a compromised web application, or stolen SSH credentials, they inherit the permissions of the instance's attached IAM role via the instance metadata service (IMDS). Many organizations attach overly permissive roles to instances for convenience, making this a frequent path to sensitive data or further escalation.

SSM RunCommand allows execution of commands on EC2 instances through the Systems Manager service. If a compromised principal has ssm:SendCommand permission and there are EC2 instances running the SSM agent with high-privilege instance profiles, the attacker can execute commands on those instances, effectively escalating to whatever permissions those instance roles hold, without needing SSH access or security group rules that allow direct connectivity.

Escalation Discovery Tools

Pacu, the open-source AWS exploitation framework maintained by Rhino Security Labs, includes modules specifically designed to enumerate and exploit privilege escalation paths. Its iam__privesc_scan module analyzes the calling principal's permissions and identifies exploitable escalation paths. Cloudfox, developed by Bishop Fox, takes a broader approach. It enumerates IAM roles, trust relationships, and resource policies across an AWS environment to identify privilege escalation and lateral movement opportunities, outputting results as loot files that map out attack paths. The enumerate-iam tool rapidly determines what API permissions an AWS credential has by making API calls across all services and recording which succeed.

PMapper (Principal Mapper) takes a graph-based approach, building a directed graph of IAM principals and their relationships, then identifying paths from any principal to administrative access. This is valuable for both attackers mapping escalation routes and defenders identifying which principals are one step away from admin.

Real-World AWS Privilege Escalation

Most real AWS escalation begins with a foothold: a leaked long-term access key found in a public repository, a server-side request forgery bug that reaches the instance metadata service, or a compromised CI/CD pipeline. From there, the API-level techniques above turn limited access into broad control. The 2019 Capital One breach is the canonical example. Server-side request forgery reached an EC2 instance role, and that role's permissions were broad enough to read more than 100 million records from S3. The escalation was not a software exploit but a chain of identity and permission mistakes, which is why AWS privilege escalation is fundamentally an IAM problem rather than a patching one. The practical lesson for defenders is that the dangerous condition is rarely a single permission; it is a combination, such as iam:PassRole paired with the ability to create a Lambda function or launch an EC2 instance.

Detection with CloudTrail and GuardDuty

CloudTrail records every IAM API call, making privilege escalation attempts visible, if you know what to look for. Key CloudTrail events to monitor include CreatePolicyVersion, AttachUserPolicy, AttachRolePolicy, PutUserPolicy, and PutRolePolicy where the policy document grants broad permissions. Correlating PassRole calls followed by service creation events (CreateFunction, RunInstances) by the same principal within a short time window is a strong indicator of escalation attempts.

GuardDuty provides managed detection for some privilege escalation patterns. The finding type PrivilegeEscalation:IAMUser/AdministrativePermissions fires when a principal attempts to assign a highly permissive policy to themselves. However, GuardDuty's coverage of the full spectrum of escalation paths is limited, making custom CloudTrail-based detections essential for comprehensive coverage.

Prevention: Least Privilege, SCPs, and Permission Boundaries

Prevention starts with least privilege, but in practice, achieving least privilege in AWS IAM is difficult because of the sheer number of actions (over 17,000 across all services) and the complexity of policy evaluation logic. AWS IAM Access Analyzer can identify unused permissions and generate least-privilege policies based on actual CloudTrail activity.

Service Control Policies (SCPs) applied at the AWS Organizations level provide guardrails that no principal in a member account can exceed, regardless of their IAM policies. An SCP that denies iam:CreatePolicyVersion, iam:AttachUserPolicy, and iam:PutUserPolicy except for designated administrative roles effectively blocks the most common escalation paths at the organizational level.

Permission boundaries are IAM policies that set the maximum permissions a principal can have, independent of their identity-based policies. When applied correctly, a permission boundary ensures that even if a user can modify their own policies, the resulting effective permissions cannot exceed the boundary. This is the most precise prevention control for delegated administration scenarios where users need some IAM management capability without full privilege escalation potential.

Related Labs

Practice discovering and exploiting real IAM escalation paths in live AWS environments. Pwned Labs scenarios such as Intro to AWS IAM Enumeration, Command Injection to EC2 User Data Privilege Escalation, and Hijack Orphaned S3 Buckets for Data Access walk through the exact techniques above. Browse the full set at pwnedlabs.io/explore.

Practice AWS Privilege Escalation with Pwned Labs

The ACRTP (AWS Cloud Red Team Professional) bootcamp deep-dives into AWS privilege escalation, with practitioners exploiting real IAM misconfigurations in live AWS environments: PassRole chains, cross-account pivots, instance profile abuse, and more. Each attack is followed by building CloudTrail-based detections and implementing preventive controls like SCPs and permission boundaries. Pwned Labs also offers free introductory labs covering AWS IAM fundamentals and basic escalation paths at pwnedlabs.io/labs.

Frequently Asked Questions

What is AWS privilege escalation?

Gaining permissions beyond those an identity was originally granted, typically by abusing IAM API permissions such as iam:PassRole, iam:CreatePolicyVersion, or role assumption to reach administrative access.

What are the most common escalation paths?

iam:CreateAccessKey on other users, iam:PassRole combined with service creation permissions such as lambda:CreateFunction or running an EC2 instance, iam:AttachUserPolicy or PutUserPolicy, and sts:AssumeRole into more privileged roles.

How do attackers discover escalation paths?

With tools like Pacu, which automates known escalation techniques, and PMapper, which graphs IAM relationships to reveal which combinations of permissions lead to admin access.

How is AWS privilege escalation detected?

By monitoring CloudTrail for sensitive IAM calls such as CreatePolicyVersion, AttachUserPolicy, and CreateAccessKey on other users, especially from principals that do not normally perform IAM administration, alongside GuardDuty for anomalous behavior.

How do you prevent it?

Apply least-privilege policies, use permission boundaries and service control policies, and avoid dangerous permission combinations, especially iam:PassRole paired with broad service creation permissions.