Cloud IAM privilege escalation happens when an attacker with limited permissions abuses misconfigured identity policies to grant themselves broader access, often reaching full administrative control without ever compromising a privileged account directly. In AWS alone, researcher Spencer Gietzen documented 21 distinct escalation methods in a widely cited 2018 study, and the list has only grown since as AWS, Azure, and GCP have added new services and permission types. The 2019 Capital One breach, where Paige Thompson exploited an SSRF flaw combined with an over-permissioned IAM role to exfiltrate data on 106 million customers, remains the canonical example of what happens when a single misassigned policy meets a determined attacker. These paths rarely require a zero-day; they exploit permission combinations that look harmless in isolation but become dangerous when chained together. This post breaks down how the most common escalation paths work across the three major cloud providers, using specific permissions and real incidents, so security and platform teams know exactly what to look for.
What Counts as an IAM Privilege Escalation Path?
An IAM privilege escalation path is any sequence of allowed actions that lets a principal grant itself permissions beyond what was originally intended, without an administrator explicitly approving that specific outcome. The key word is "sequence" — no single permission in the chain looks catastrophic on its own. For example, a user with iam:CreatePolicyVersion on their own IAM policy isn't obviously dangerous until you realize that action lets them attach a new policy version granting themselves AdministratorAccess, because AWS evaluates the most recently created version by default. Rhino Security Labs' original 2018 research and the open-source tool it spawned, PMapper, formalized this as a directed-graph problem: nodes are identities, edges are permission grants that let one identity act as another. Modern cloud environments routinely contain hundreds of these edges, most created by well-intentioned Terraform modules or CI/CD roles rather than malicious intent.
How Does the iam:PassRole Plus Lambda Escalation Work?
The iam:PassRole combined with lambda:CreateFunction and lambda:InvokeFunction path lets an attacker execute code with the permissions of any role they're allowed to pass, even if their own user account has no direct compute or data access. The attack works like this: a developer role is granted iam:PassRole on a broad set of roles (a common shortcut to avoid updating IAM policies every time a new Lambda is deployed), plus lambda:CreateFunction. The attacker creates a new Lambda function, passes it an execution role with S3 or Secrets Manager access, writes code that dumps environment variables or bucket contents, and invokes it. Because the Lambda runs with the passed role's permissions rather than the caller's, the resulting access can be dramatically wider than what the attacker's own identity was ever granted. AWS's own IAM documentation flags iam:PassRole as one of a small number of permissions that should almost never be granted with a wildcard resource ("Resource": "*"), yet it appears wildcarded in a large share of the misconfigured policies flagged by cloud security posture tools every year.
Why Is iam:CreatePolicyVersion Considered the Highest-Risk AWS Permission?
iam:CreatePolicyVersion is considered the highest-risk AWS IAM permission because it lets a principal rewrite the effective permissions of any policy it can target, including its own, turning a low-privilege identity into an administrator in a single API call. AWS policies support up to five versions, and unless an admin explicitly pins a non-default version, the newest version created becomes the one enforced immediately. An attacker who holds this permission on their own attached policy — or on a policy attached to a role they can assume — can call CreatePolicyVersion with a document granting "Action": "*" and "Resource": "*", set it as default, and have full account control within seconds. Related permissions carry the same risk profile: iam:SetDefaultPolicyVersion (switch to a previously created malicious version), iam:AttachUserPolicy / iam:AttachRolePolicy (attach an existing admin-equivalent managed policy), and iam:UpdateAssumeRolePolicy (rewrite a role's trust policy so an attacker-controlled principal can assume it). Any of these four permissions, held without tight resource scoping, is functionally equivalent to granting AdministratorAccess.
How Do GCP and Azure Privilege Escalation Paths Differ From AWS?
GCP and Azure privilege escalation paths differ from AWS mainly in mechanism — service account impersonation and role-assignment chaining, respectively — but the underlying logic of "permission A plus permission B equals unintended C" is identical. On GCP, the iam.serviceAccounts.actAs permission (bundled into the deceptively named roles/iam.serviceAccountUser role) lets a principal launch resources — a Compute Engine VM, a Cloud Function, a Cloud Run job — that run as a more privileged service account, mirroring the AWS PassRole pattern almost exactly. Google's own privilege escalation documentation lists at least seven distinct GCP paths built on combinations of actAs, iam.serviceAccountKeys.create, and deploymentmanager.deployments.create. On Azure, the classic path combines the built-in Contributor role (which can create and manage resources but not assign permissions) with User Access Administrator (which can assign roles but not manage resources); a principal holding both, often via two separate group memberships that looked reasonable when reviewed independently, can grant itself Owner on a subscription. Microsoft's Azure AD documentation specifically warns against combining these two roles on the same principal for exactly this reason.
Which Real Breaches Started With an IAM Privilege Escalation Path?
At least two well-documented breaches trace directly back to IAM privilege escalation rather than credential theft alone. The 2019 Capital One incident began with an SSRF exploit against a misconfigured WAF, but the damage scaled to 106 million records specifically because the compromised EC2 instance's IAM role carried s3:GetObject and list permissions across far more buckets than the WAF's function required — a case of excessive standing privilege rather than a multi-step escalation chain, and a reminder that over-broad roles amplify every other vulnerability in the stack. More directly relevant to escalation chains, the 2023 disclosures around GCP's "Bad.Build" class of flaws (Tenable, August 2024) showed how the Cloud Build default service account's implicit permissions could be chained through iam.serviceAccounts.actAs to reach nearly any resource in a project. Separately, multiple incident write-ups from cloud IR firms in 2022–2023 documented attackers using stolen developer laptops or leaked CI tokens purely as an entry point, then using iam:CreatePolicyVersion or equivalent GCP/Azure paths to escalate from a single scoped CI role to full account takeover within minutes of initial access — underscoring that the entry point is often mundane, but the escalation path is what turns a minor compromise into a full breach.
How Safeguard Helps
Safeguard's reachability analysis maps IAM policy graphs the same way it maps code call paths, distinguishing permissions that are merely attached from those an attacker could actually exercise given a real entry point, so security teams can prioritize the iam:PassRole, iam:CreatePolicyVersion, and actAs-style chains that are genuinely exploitable in their environment instead of chasing every wildcarded policy in isolation. Griffin AI, Safeguard's analysis engine, traces these multi-permission escalation graphs across AWS, GCP, and Azure automatically and flags the specific edge — a shared role, a chained trust policy, a dual role assignment — that turns a low-privilege identity into an admin path. Safeguard's SBOM generation and ingest capabilities extend this visibility to the infrastructure-as-code and CI/CD roles that provision cloud resources in the first place, since a Terraform pipeline's own service account is frequently the most over-privileged identity in the account. When Safeguard identifies an escalation path, it can open an auto-fix pull request that scopes the offending policy down to the specific resources and actions actually in use, closing the gap without breaking the deployment it was written to support.