Cloud Privilege Escalation Paths in AWS IAM

AWS IAM privilege escalation almost never comes from one bad permission sitting alone. It comes from chains: small, ordinary-looking actions like iam:PassRole or iam:CreatePolicyVersion that, stacked together, hand a low-privilege identity the keys to the entire account. Understanding how those chains form isn't just academic. It's the only way to actually find them before someone else does, and the only way to break them for good.

The highest-value target in any AWS account

IAM is the permission layer that every single AWS action depends on. That's what makes it the crown jewel, and also what makes it the most dangerous thing to get wrong.

The numbers back this up. Wiz Research found that 82% of organizations unknowingly give third parties access to all their cloud data, and the average cost of a cloud breach hit $4.4 million in 2025. CrowdStrike's 2025 Global Threat Report found valid-account abuse accounted for 35% of cloud incidents in the first half of 2024, with new and unattributed cloud intrusions rising 26% year over year. That second stat matters a lot: it means IAM-path attacks aren't some theoretical edge case security teams worry about for the sake of thoroughness. They're the dominant pattern behind real incidents, right now.

And the way in is almost never exotic. Forget zero-days. The most common initial access sources are access keys hardcoded in GitHub repos, CI/CD pipelines, and Docker images, Hive Security found. Palo Alto Networks' Unit 42 analyzed 210,000 cloud accounts and found 76% weren't enforcing MFA for console users, while 83% had hard-coded credentials sitting in source control Rhino Security Labs. Those are the starting conditions. An attacker doesn't need to be clever to get a foothold. They just need someone to have committed a key to a public repo, which happens constantly.

How IAM privilege escalation works: the chain logic

Escalation, defined precisely, is a low-privilege identity using only the permissions it already has to reach a stronger identity, or to rewrite its own permissions into something stronger. No exploit code. No vulnerability scanner popping a shell. Just permissions, used exactly as AWS designed them to be used, in a sequence nobody anticipated.

The core mechanic is simple once you see it: some IAM actions change who can do what, and some let an identity run code as a more privileged identity. If an attacker can do either of those things, they can usually reach administrator in one or two steps.

The dangerous permissions rarely look dangerous during audits. Nobody flags iam:PassRole in a review because on its own, it does nothing. Nobody flags iam:CreatePolicyVersion either, because on its own, it just writes a new policy version. Risk here is entirely contextual. iam:PassRole is harmless until it's paired with a service that runs code somewhere, and iam:CreatePolicyVersion is benign until the principal holding it can point that permission at a policy attached to itself. Take a policy with exactly two actions, neither one a wildcard: iam:PassRole plus ec2:RunInstances on Resource: *. Nothing in that pairing screams "admin access." Together, it's a direct, working path to full administrator control.

Hive Security's full chain model lays out the generic version of this chain. Phase one is the foothold: a valid credential lands in the attacker's hands. Phase two is enumeration, mapping out exactly what that identity can do, using calls like list-attached-user-policies and get-policy-version, or brute-force tools like Pacu's iam__bruteforce_permissions module. Phase three is the escalation itself, where one of the documented paths converts a low-privilege identity into an administrator. Phase four is the actual objective: data exfiltration, planting persistence, or moving laterally into other accounts.

Every single step in that chain uses legitimate AWS API calls. No exploit, no CVE, just permissions functioning exactly as intended. That's the uncomfortable truth about this entire category of attack: it's indistinguishable from normal administrative work, right up until it isn't. And once the initial access is established, most of these escalations are exploitable within minutes. The slow part, in accounts with a lot of roles, is the enumeration, not the escalation itself.

The structural forces that keep overpermissioned identities in place

None of this persists because people are careless. It persists because the structure of how cloud teams operate pushes against least-privilege every single day. SecureLayer7's analysis names three forces driving this, and none of them are personal failings.

First, default policies are broad. AWS-managed policies like IAMFullAccess grant far more than most jobs actually need, and teams attach them to ship something on a deadline, fully intending to trim them down later. That trim almost never happens. Second, CI/CD identities accumulate permissions over time. Third, speed just beats caution, every time there's a deadline involved. A developer attaches *:* on a Friday afternoon to unblock a feature, plans to narrow the scope the following week, and never circles back.

Policy authoring itself is treated as a low-skill task when it's actually a high-skill one. Developers write policies to unblock features, not to model threat boundaries, which is a completely different exercise requiring a completely different mindset. Permissions pile up across incident response, debugging sessions, one-off migrations, with no working process anywhere to claw them back afterward.

AWS Access Analyzer exists and does its job, surfacing findings about unused or overly broad permissions. But those findings sit unactioned for months, because the tooling exists while the workflow to act on it does not. Unit 42's review of those 210,000 cloud accounts found 60% took over four days to fix known issues once they were identified Rhino Security Labs. That gap between detection and remediation is exactly where exploitation happens. It's not a hypothetical window. It's a four-day-plus window, on average, sitting wide open.

The most exploited IAM escalation paths in current assessments

At least 21 documented IAM escalation techniques exist in the Rhino Security Labs catalog, and that count has only grown. Datadog Security Labs' pathfinding.cloud research added 10 more paths to the IAM Vulnerable sandbox, bringing the total supported count to 31 Rhino Security Labs. The attack surface is bigger than most teams assume, and it keeps growing as AWS adds services.

The --set-as-default flag doesn't require a separate iam:SetDefaultPolicyVersion permission, which is the trap: most audits check which policy is attached, not every version, leaving a quiet, rollback-capable path that survives review after review.

iam:AttachUserPolicy and iam:AttachRolePolicy are even blunter. One API call attaches AdministratorAccess straight to the compromised identity. It's the simplest path there is, and ironically the one most likely to survive a policy review, because the permission name sounds administrative rather than escalatory.

Then there's the iam:PassRole plus ec2:RunInstances combination. Launch an EC2 instance with an administrator instance profile attached, connect to it, then hit the instance metadata service to pull the privileged role's temporary credentials. Hive Security frames iam:PassRole as a badge handoff: the permission itself hands a badge to a service, and whoever controls that handoff controls what the badge can open. A close cousin runs through Lambda: iam:PassRole combined with lambda:CreateFunction and lambda:InvokeFunction lets an attacker create a function that executes as a privileged role, then invoke it to run arbitrary AWS API calls. The function itself becomes the attack surface.

iam:PutUserPolicy and iam:PutRolePolicy write inline policies granting whatever permission the attacker wants, directly. The blind spot here is specific and well documented: inline policies don't show up in the IAM console summary view, so reviewers scanning the console never see them. And lambda:UpdateFunctionCode skips the need for iam:PassRole entirely, by swapping the code inside an already-existing privileged Lambda function for attacker code. No new function required.

The same shape repeats across other services. glue:CreateJob runs arbitrary Python or Spark workloads, and ecs:RunTask deploys containers carrying privileged roles. Any action that lets an attacker execute code under a privileged identity is, structurally, an escalation path. The good news is that every one of these steps leaves a CloudTrail event behind. CreatePolicyVersionAttachUserPolicy, and the rest all appear in the logs by name, which means defenders who know what to look for can pattern-match against them.

The emerging escalation surface in AI and orchestration services

This entire category has evolved in three distinct eras, according to research from Software Secured working with Sonrai Security. Era one is the classic IAM mutations: iam:AttachUserPolicy, iam:CreatePolicyVersion, trust-policy rewrites. All of it still fully relevant. Era two shifts toward service-centric execution: Lambda code updates, EventBridge routing tricks, ECR supply-chain poisoning, Step Functions chaining AssumeRole calls. Across most of these, iam:PassRole is the common thread enabling the whole thing.

Phase 3, escalation, is where one of the documented paths converts low privilege to admin. Bedrock Agents and Bedrock AgentCore can run code through a Code Interpreter, make AWS API calls on their own, chain actions across multiple services, and execute logic on behalf of whatever role they're assigned. Specific permissions like bedrock-agentcore:CreateCodeInterpreter, bedrock:InvokeModel, and lambda:UpdateFunctionCode used as a pivot from AgentCore all open fresh escalation paths that didn't exist a couple of years ago.

The structural problem underneath this is bigger than any single permission. Privilege escalation isn't just about identity anymore. It now lives at the intersection of service logic, orchestration, and AI, and a traditional IAM-only review misses this category of risk entirely. Training platforms like CloudGoat, IAM-Vulnerable, and CloudFoxable are still genuinely useful for learning the classic paths, but they don't capture the full modern surface. Practitioners need to extend their mental models here, not just download another tool.

Some of these paths simply can't be blocked cleanly. Not every AWS service participates equally in resource-policy enforcement, and Bedrock's Code Interpreter along with other execution-related actions can't be fully constrained with resource policies, at least as of current research. That means some escalation routes don't have a clean policy-layer fix waiting on the other side. Teams have to compensate somewhere else.

Why automated tools alone cannot find these paths

That's a serious gap, even in tools built specifically for this job.

Rule-based linters run into a structural limit: they evaluate permissions in isolation. They're good at flagging wildcards, iam:*, known-bad action names. But an escalation path is an interaction between individually benign permissions, and one of the documented paths converts low privilege to admin, so catching that requires reasoning about a full chain, not scoring a single line item.

GuardDuty runs into a related wall. It surfaces some suspicious patterns, but it doesn't detect intentional privilege escalation carried out through legitimate API calls fired in the expected order. That's the whole problem in one sentence: the most dangerous escalation looks exactly like normal usage, until the moment it isn't.

Enumeration tools like Pacu, PMapper, ScoutSuite, and CloudFox help practitioners find paths as new services arrive, but require a skilled operator to interpret and chain findings. They're genuinely useful for offense-informed defense. But they still require a skilled operator sitting behind the keyboard, interpreting output and chaining findings together into something that actually means something.

Inline policies are invisible in the IAM console summary view, and finding them requires explicitly running aws iam list-role-policies --role-name against every role in question. On top of that, escalation paths can run straight through cross-account trust relationships that show up in neither the policy view nor the identity view, unless someone maps the full authorization detail by hand. Automated tools give coverage at scale. They're not built to find chain-based paths on their own, and that gap is exactly where human reasoning, thinking like an attacker, becomes irreplaceable. Datadog Security Labs' pathfinding.cloud research found that open-source IAM privilege escalation assessment tools ranged from detecting between 14–22 of the 31 supported paths, revealing significant blind spots even in purpose-built tooling.

IAM privilege escalation assessment coverage beyond a scan

A manual tester doesn't stop at "detected." Finding an overprivileged Lambda execution role is the start of the work, not the end of it. A real assessment tests whether that role can read entries out of Secrets Manager, can call STS to assume a cross-account role, and can persist access through a backdoored CloudFormation stack. That's the actual difference between a compliance checkbox and a real security finding: one describes a risk, the other proves it.

A proper IAM assessment, following SecureLayer7's methodology, maps every user, role, and policy attachment in the account, including cross-account trust paths that a casual review rarely catches. For each identity, it checks which escalation-capable actions it holds and whether a path to administrator actually exists from there. For each high-value path found, the tester proves it, running the escalation in a controlled way rather than describing it hypothetically. For every high-privilege role uncovered, the assessment documents exactly what an attacker holding that role could reach.

None of this works blackbox. Assessing IAM properly means seeing source code repositories for hardcoded credentials, CI/CD pipeline configurations for over-permissioned pipeline roles, and cloud configurations, all together, at the same time. Blackbox testing of IAM is inherently incomplete, because the attack surface here lives in configuration, not in a network perimeter somewhere.

Ask any provider directly what percentage of an engagement is manual testing versus automated scanning. Vague answers, or answers that lean on tool names instead of describing methodology, are a signal. Credentials matter too: OSCP (now formally OSCP+, OffSec's 24-hour proctored hands-on exam) and GPEN represent credible, hands-on validation of exploitation skill. CEH, a multiple-choice exam, doesn't validate the same thing. That distinction matters specifically here, because the finding being attested to is an exploited chain, not a checklist item.

An assessment that comes back clean, with zero escalation paths found in a real AWS account, is almost certainly incomplete rather than genuinely secure. The structural forces covered earlier guarantee that paths exist somewhere. The tester either found them or didn't.

Defensive controls that break escalation chains

Start with the single highest-yield action available right now: audit iam:PassRole across the account. Run aws iam get-account-authorization-details and search the output for every principal holding PassRole on *. Every single one of those is a potential escalation path waiting to be paired with a service that runs code.

From there, check for inline policies explicitly, since they're invisible in the console summary view and require a direct command to surface. Review every managed policy's full version history, not just its currently attached version, since iam:CreatePolicyVersion leaves old, forgotten versions sitting around as quiet rollback paths. Trim the CI/CD roles that have accumulated permissions release after release, and treat Access Analyzer findings as work items with a deadline, not as a dashboard to glance at occasionally.

None of these controls are exotic. They're follow-through on things AWS already tells account owners, sitting in a report somewhere. The chains only work because that follow-through keeps getting deferred.