Cloud IAM Privilege Escalation: Attack Paths and Detection Across AWS, GCP, and Azure
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Cloud IAM privilege escalation is one of the most common post-compromise attack paths in cloud environments, and one of the least detected. An attacker who gains any foothold in your cloud environment (a leaked access key, a compromised EC2 instance, an over-privileged Lambda function) will immediately attempt to escalate privileges using legitimate IAM API calls. These calls do not look like attacks in your logs, they look like IAM administration. Understanding the specific escalation paths, the permissions that enable them, and the detection signatures for each is the foundation of effective cloud security.
AWS Privilege Escalation Paths
AWS has the most documented IAM privilege escalation paths. These five are the most commonly exploited.
iam:CreatePolicyVersion, direct policy backdoor
A principal with iam:CreatePolicyVersion can create a new version of any existing IAM policy and set it as the default, including a policy that grants AdministratorAccess. Attack: aws iam create-policy-version --policy-arn {POLICY_ARN} --policy-document '{"Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' --set-as-default. Fix: never grant iam:CreatePolicyVersion without also requiring iam:SetDefaultPolicyVersion to be scoped to specific policy ARNs. Detection (CloudTrail): alert on CreatePolicyVersion where requestParameters.setAsDefault is true.
iam:PassRole + ec2:RunInstances, launch with higher-privilege profile
A principal with iam:PassRole and ec2:RunInstances can launch a new EC2 instance with an instance profile that has more privileges than the attacker's own role. Attack: launch an EC2 instance with an AdministratorAccess instance profile, SSH in, and use the instance's credentials. Fix: scope iam:PassRole with Condition: StringEquals: iam:PassedToService: ec2.amazonaws.com and restrict the Resource to specific non-admin role ARNs. Detection (CloudTrail): alert on RunInstances where the iamInstanceProfile.arn contains roles you consider sensitive.
iam:AttachUserPolicy or iam:PutUserPolicy, direct privilege grant
A principal with iam:AttachUserPolicy can attach AdministratorAccess to their own IAM user. Attack: aws iam attach-user-policy --user-name {SELF} --policy-arn arn:aws:iam::aws:policy/AdministratorAccess. Fix: never grant iam:AttachUserPolicy, iam:PutUserPolicy, iam:AttachRolePolicy, or iam:PutRolePolicy without resource-level restrictions excluding administrative roles and policies. Detection: alert on any of these API calls where the targetUser is the same as the calling principal.
lambda:UpdateFunctionCode, code injection into privileged function
If a Lambda function has an execution role with high privileges, a principal with lambda:UpdateFunctionCode can replace the function's code with malicious code that exfiltrates credentials or performs privilege escalation actions. Attack: aws lambda update-function-code --function-name {HIGH_PRIVILEGE_FUNCTION} --zip-file fileb://malicious.zip. Fix: restrict lambda:UpdateFunctionCode to CI/CD service accounts only, and scope it to specific function ARNs. Detection: alert on UpdateFunctionCode from any principal other than your designated deployment role.
iam:CreateAccessKey, generate credentials for another user
A principal with iam:CreateAccessKey can generate new access keys for any IAM user, including admin users. Attack: aws iam create-access-key --user-name {ADMIN_USER}. This gives the attacker credentials equivalent to that user. Fix: never grant iam:CreateAccessKey with Resource: *, scope it to the principal's own user at most. Detection: alert on CreateAccessKey where the target username is different from the calling principal's username.
GCP Privilege Escalation Paths
GCP IAM privilege escalation frequently revolves around service account impersonation and IAM policy modification.
iam.serviceAccounts.actAs, impersonate a high-privilege service account
The iam.serviceAccounts.actAs permission allows a principal to act as a service account, to generate tokens for it, attach it to resources, or use it to authenticate. Attack: if a developer has iam.serviceAccounts.actAs on a service account that has Editor or Owner, they can attach that service account to a Compute Engine instance and access its credentials. Fix: grant iam.serviceAccounts.actAs only on specific service account resource paths, never at the project level. Detection (Cloud Audit Logs): alert on iam.serviceAccounts.actAs grants at the project level.
resourcemanager.projects.setIamPolicy, direct policy modification
Any principal with this permission can modify the project IAM policy, including granting themselves Owner or granting a service account they control any role. Attack: gcloud projects add-iam-policy-binding {PROJECT} --member=serviceAccount:{ATTACKER_SA} --role=roles/owner. Fix: restrict setIamPolicy to a single break-glass administrative identity and enforce MFA/approval for its use. Detection: alert on any setIamPolicy call that adds roles/owner, roles/editor, or roles/iam.securityAdmin.
cloudfunctions.functions.update, code injection into Cloud Function
Similar to the Lambda vector in AWS: a principal with permission to update a Cloud Function's code can inject malicious code into a function that runs with a high-privilege service account. Attack: gcloud functions deploy {HIGH_PRIVILEGE_FUNCTION} --source {MALICIOUS_SOURCE}. Fix: restrict Cloud Function deployments to CI/CD service accounts with narrow scope; alert on deployments from any other identity.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Azure Privilege Escalation Paths
Azure RBAC escalation commonly runs through role assignment permissions, managed identity abuse, and subscription-level control plane access.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Detection: Cross-Cloud SIEM Rules
These detection rules apply across cloud providers for the highest-signal privilege escalation indicators.
IAM permission grant to self
AWS (CloudTrail): alert where eventName in (AttachUserPolicy, PutUserPolicy, CreatePolicyVersion) and requestParameters.userName equals userIdentity.userName, or requestParameters.roleName is a role the calling identity can assume. GCP (Cloud Audit Logs): alert on setIamPolicy calls where the new binding's member matches the caller's identity. Azure (Activity Logs): alert on roleAssignments/write where the assignment principalId matches the caller's objectId.
Access key or service account key creation for another identity
AWS: CloudTrail CreateAccessKey where requestParameters.userName != userIdentity.userName. GCP: Cloud Audit Logs iam.serviceAccountKeys.create where the target service account is different from the caller's service account. Azure: Create application password or secret event where the target application is not owned by the calling user.
High-privilege resource creation from unusual identity
Alert on: EC2 RunInstances with an admin instance profile from an identity that is not your standard infrastructure automation role. Cloud Function or Lambda deploy events from any identity other than your designated CI/CD service account. Alert on these in real time, the window between when an attacker escalates and when they begin exfiltration is often less than 10 minutes.
The bottom line
Cloud IAM privilege escalation uses legitimate API calls, generates minimal noise, and moves fast. The defenses are IAM policy scoping (never iam:PassRole on *, never setIamPolicy without conditions, never role assignment write on subscription scope), automated permission auditing with PMapper and Prowler, and real-time CloudTrail/Cloud Audit Log alerts for the specific API calls that indicate escalation. Build those detections this week, the escalation paths are documented, the detection logic is straightforward, and the blast radius of not having them is full cloud account compromise.
Frequently asked questions
What makes cloud IAM privilege escalation different from traditional privilege escalation?
Traditional privilege escalation exploits vulnerabilities, buffer overflows, kernel bugs, weak file permissions. Cloud IAM privilege escalation exploits policy misconfigurations using only legitimate API calls. No CVE, no exploit code, no malware. An attacker with iam:CreatePolicyVersion in AWS can create a new version of an existing policy that grants themselves AdministratorAccess, entirely through the AWS API, generating API calls that look like normal IAM administration.
Does enabling MFA prevent cloud IAM privilege escalation?
MFA prevents unauthorized access using stolen passwords but does not prevent escalation once access is established. If an attacker phishes or steals a valid AWS access key (which does not require MFA for API calls), or compromises an EC2 instance and reads its instance profile credentials, they can attempt privilege escalation regardless of whether the original user account had MFA enabled. Preventing escalation requires IAM policy controls, not authentication controls.
How do I find privilege escalation paths in my current IAM setup?
Tools that enumerate escalation paths: PMapper (AWS-specific, maps IAM relationships as a graph and finds escalation paths): python3 -m principalmapper graph --create; python3 -m principalmapper analysis. Cloudsploit and Prowler also flag high-risk permissions. For Azure: Bloodhound for Azure (AzureHound) maps escalation paths in Entra ID. For GCP: ScoutSuite includes GCP IAM analysis. Run these tools against your environment and remediate the findings before an attacker maps them first.
Is it safe to grant iam:PassRole for CI/CD pipelines?
iam:PassRole scoped to specific roles is acceptable. The dangerous pattern is granting iam:PassRole with Resource: *, this allows the principal to pass any role to any service, including roles more powerful than the principal's own permissions. Scope iam:PassRole to the specific role ARNs that the CI/CD pipeline legitimately needs to pass: Condition: StringEquals: iam:PassedToService: ec2.amazonaws.com and Resource: arn:aws:iam::ACCOUNT:role/specific-ec2-role.
How do I find privilege escalation paths in my AWS IAM configuration without running an exploit?
Use PMapper (Principal Mapper) -- a free open-source tool that builds a graph of all AWS IAM relationships in your account and identifies which principals can reach which other principals through privilege escalation paths. Run: pmapper graph create --profile your-profile; pmapper analysis --accounts YOUR_ACCOUNT_ID. PMapper will list paths like 'LowPrivUser can escalate to AdministratorAccess via iam:PassRole on EC2'. Alternatively, use Cloudsplaining (open-source by Salesforce) to generate an HTML report of IAM policies with dangerous permissions. Both tools are read-only and require only iam:List* and iam:Get* permissions to analyze your IAM configuration.
How do I prevent CI/CD pipeline credentials from becoming a cloud privilege escalation path?
CI/CD service accounts are among the highest-risk identities in a cloud environment because they frequently hold deployment permissions -- iam:PassRole, lambda:UpdateFunctionCode, ec2:RunInstances -- that create escalation paths if the pipeline itself is compromised. Replace long-lived access keys with OIDC-based short-lived credentials for every CI/CD platform that supports it: GitHub Actions with AWS OIDC federation, GitLab CI with GCP Workload Identity Federation, and Azure Pipelines with federated credentials. Short-lived tokens expire after the job, eliminating the key-theft escalation path entirely. For permissions the pipeline legitimately needs, scope them to specific resource ARNs (specific Lambda function names, specific S3 buckets) rather than wildcards. Audit pipeline permissions quarterly using Cloudsplaining or PMapper and enforce a review gate: any PR that modifies pipeline IAM policy files requires security team approval before merge.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.