What Is Cloud IAM Privilege Escalation?

How Cloud Privilege Escalation Differs from On-Premises

In traditional on-premises environments, privilege escalation usually means exploiting a kernel vulnerability, abusing a SUID binary, or leveraging credential reuse to move from a standard user to local admin to domain admin. The path is well-mapped by decades of offensive tooling (Mimikatz, Rubeus, PowerView) and defensive frameworks (the Windows privilege escalation kill chain is extensively documented in MITRE ATT&CK).

Cloud privilege escalation is fundamentally different. There is no kernel to exploit; the attacker operates within the cloud provider's control plane, where access is governed entirely by IAM policies. Escalation happens by finding combinations of permissions that, when chained together, grant access the identity was never intended to have. The permissions themselves are legitimate features; the vulnerability is in how they've been assigned.

This makes cloud privilege escalation harder to detect. There are no exploit payloads, no shellcode, no anomalous process execution. The attacker uses the same APIs that administrators use, often with calls that individually appear routine.

AWS Privilege Escalation Paths

Rhino Security Labs' research identified over 20 distinct AWS IAM privilege escalation methods. The most commonly exploited include:

iam:PassRole + Lambda/EC2/ECS: If a user can pass an existing high-privilege role to a Lambda function, EC2 instance, or ECS task, they can create a compute resource that runs with that role's permissions, effectively assuming those permissions indirectly. An attacker with iam:PassRole and lambda:CreateFunction + lambda:InvokeFunction can create a Lambda function running as an admin role and execute arbitrary API calls through it.

sts:AssumeRole across accounts: Cross-account role trust policies that use overly broad conditions (or no conditions at all) allow any principal in the trusted account to assume the role. Attackers who compromise a low-privilege identity in Account A can escalate by assuming a high-privilege role in Account B if the trust policy permits it.

iam:CreatePolicyVersion or iam:AttachUserPolicy: An identity with permission to create new policy versions or attach existing policies to itself can directly grant itself administrator access by writing or attaching an admin policy.

iam:CreateLoginProfile or iam:UpdateLoginProfile: Allows the attacker to set a console password for any IAM user, including admin users, gaining interactive access to the console.

Azure Privilege Escalation Paths

Azure's identity model introduces additional escalation surfaces through Azure AD (Entra ID), Managed Identities, and the RBAC hierarchy:

Managed Identity Abuse: If an attacker gains code execution on a VM or App Service with a system-assigned or user-assigned managed identity, they inherit that identity's RBAC permissions. Managed identities assigned Contributor or Owner at the subscription level are a direct path to environment takeover.

Azure AD Application Permissions: Applications with Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, or AppRoleAssignment.ReadWrite.All can escalate by granting themselves or other principals Global Administrator-equivalent permissions.

Privileged Identity Management (PIM) Exploitation: If an attacker compromises an identity eligible for (but not actively assigned) an elevated role through PIM, they can activate the role themselves if MFA and approval requirements are misconfigured or bypassed.

Automation Account Runbook Abuse: Azure Automation Accounts often run with high-privilege Run As accounts. An attacker with Contributor access to an Automation Account can modify runbooks to execute commands under the Run As identity's permissions.

GCP Privilege Escalation Paths

GCP's escalation paths center on service accounts and the project-level permission model:

Service Account Impersonation: The iam.serviceAccounts.getAccessToken permission allows an identity to generate access tokens for any service account it can impersonate. Chaining this through multiple service accounts can reach project-level Owner access.

Service Account Key Creation: An identity with iam.serviceAccountKeys.create can generate persistent keys for high-privilege service accounts, creating backdoor access that persists even after the original compromise is remediated.

setIamPolicy Abuse: Permission to set IAM policy on a resource (project, folder, organization) allows an attacker to grant themselves or another identity any role, including Owner.

Notable Cloud IAM Escalation Incidents

The 2019 Capital One breach remains the clearest public example. Server-side request forgery reached an EC2 instance role whose permissions were broad enough to read more than 100 million records from S3, a straight line from a web-layer bug to an over-permissioned identity. The recurring pattern across clouds is the same: an initial foothold from a leaked key, an exposed metadata service, or a compromised pipeline, followed by the abuse of a single dangerous permission or trust relationship to reach far broader access. In every case the escalation lived in identity configuration, not in unpatched software, which is why IAM is the first place a cloud assessment looks.

Detection Approaches

Detecting IAM privilege escalation requires monitoring the cloud control plane for anomalous permission changes. Key signals include new policy versions created outside of CI/CD pipelines, role assumptions from unexpected source identities, service account key creation events, and sudden spikes in API calls from an identity that historically had low activity. AWS CloudTrail, Azure Activity Logs, and GCP Cloud Audit Logs capture these events, but effective detection requires correlation rules that understand IAM escalation chains, using tools like CloudTrail Lake, Microsoft Sentinel, and Chronicle SIEM support this with custom analytics rules.

Related Labs

Practice real escalation paths across all three clouds in live environments. Pwned Labs scenarios such as Intro to AWS IAM Enumeration, Unmask Privileged Access in Azure, and Pivot Through Service Accounts Using Dangerous Permissions walk through provider-specific escalation end to end. Browse the full set at pwnedlabs.io/explore.

Master Cloud Privilege Escalation at Pwned Labs

IAM privilege escalation is a core focus across all three Pwned Labs cloud bootcamps. The ACRTP (AWS) bootcamp covers PassRole abuse, cross-account role assumption, and policy manipulation. The MCRTP and MCRTE (Azure) bootcamps walk through managed identity exploitation, Azure AD app permission abuse, and PIM attacks. The GCRTP (GCP) bootcamp covers service account impersonation and setIamPolicy exploitation. Every path is practiced in real cloud environments against live IAM configurations. Start at pwnedlabs.io/bootcamps.

Frequently Asked Questions

What is cloud IAM privilege escalation?

Abusing identity and access management configuration to gain permissions beyond those originally granted, typically by exploiting dangerous permissions, role assumption, service account impersonation, or over-broad trust relationships.

How does it differ from on-premises escalation?

There is no kernel or local exploit involved. The attacker works within the provider's control plane, chaining IAM permissions and trust relationships rather than exploiting software running on a host.

What is the most common AWS escalation primitive?

iam:PassRole combined with a service creation permission, which lets an attacker attach a high-privilege role to a resource they control and then act with that role's permissions.

How does escalation work in GCP?

Primarily through service account impersonation. A principal that can call iam.serviceAccounts.getAccessToken or actAs on a more privileged service account can borrow that identity's permissions.

How is IAM escalation detected?

By monitoring provider audit logs (CloudTrail, Azure Activity and Entra ID logs, GCP Cloud Audit Logs) for sensitive IAM changes and impersonation calls, ideally with correlation rules that understand full escalation chains rather than single events.