Cloud Privilege Escalation Attacks: Azure, AWS, and GCP Patterns Every Defender Should Know

IAM Is the New Kernel

There is no exploit chain in most cloud breaches. There is only permission misuse.

Cloud privilege escalation does not exploit bugs. It exploits design assumptions - trust policies that assume identity equals intent, metadata services that hand credentials to anyone who asks, and role boundaries that exist in documentation but not in enforcement.

Identity-based attacks account for 68% of cloud breaches (Thales 2025). Rhino Security Labs documented 21 distinct IAM escalation paths in AWS alone. CrowdStrike's fastest observed breakout time is 50 seconds. These are not exotic attacks. They are the primary post-compromise vector.

Cloud APIs are both the management interface and the attack surface. Every legitimate administrative action - assuming roles, passing permissions, creating applications, binding tags - is also an escalation technique when performed by the wrong identity. The control plane is the attack surface.

Figure 1: Five cloud privilege escalation patterns across AWS, Azure, and GCP. Root cause: IAM misconfiguration.

All cloud privilege escalation follows the same pattern: identity, assumption, reuse, escalation. These are the five most common instantiations.

The Detection Asymmetry

Every cloud attack looks like legitimate behavior. Detection is distinguishing intent, not action.

An attacker assuming a role uses the same sts:AssumeRole call that every Lambda function uses. An attacker adding credentials to an Azure application uses the same API that every developer uses. An attacker binding a tag in GCP uses the same endpoint that every infrastructure team uses.

The signal is not in the API call. It is in the context: who made the call, from where, at what time, targeting what resource, following what sequence of prior actions. This is why raw CloudTrail monitoring produces overwhelming noise, and why behavioral detection - anomalous identity behavior, unusual API sequences, cross-account activity from new sources - is where cloud detection engineering must focus.

Figure 2: Detection strategies per cloud - the signal is in the context, not the API call.

The organizations that detect cloud escalation are not the ones with the most rules. They are the ones whose rules distinguish a deployment pipeline assuming a role at 2pm on Tuesday from an attacker assuming the same role at 3am on Saturday from an IP in a country where the organization has no employees.

AWS: Three Escalation Paths, One Weakness

All three AWS escalation paths exploit the same weakness: trust boundaries that assume identity equals intent.

AssumeRole Misconfiguration

An adversary obtains leaked access keys for a low-privilege IAM user. They discover a role with an overly permissive trust policy:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111111111111:root"},
  "Action": "sts:AssumeRole"
}

This allows any IAM entity in the account to assume the role. The worst variant: "AWS": "*" - any authenticated identity in any AWS account.

Detection: CloudTrail sts:AssumeRole from unexpected accounts, unusual users, or unusual times. Brute-force enumeration produces a distinct pattern of failed calls.

Defense: Specific role ARNs in trust policies, never wildcards. Do not expose your Account ID.

IMDS Credential Theft

Figure 3: IMDSv1 vs IMDSv2 - simple GET with no auth (vulnerable to SSRF) vs session token via PUT (blocks SSRF).

The Instance Metadata Service provides EC2 instances with temporary IAM credentials at http://169.254.169.254. IMDSv1 requires a simple GET - no authentication. Any SSRF vulnerability becomes a credential theft vulnerability.

Capital One, 2019: SSRF in a web application, IMDS query, IAM credentials, 100 million customer records from S3.

# IMDSv1 (vulnerable) - one unauthenticated GET
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>

# IMDSv2 (mitigated) - PUT for token, then GET with token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>

IMDSv2 blocks SSRF because PUT cannot be made via redirect. The TTL header prevents token extraction through network pivots.

Detection: GuardDuty anomalous IMDS patterns. CloudTrail flags IMDS-sourced credentials used from outside the VPC.

Defense: aws ec2 modify-instance-metadata-options --instance-id <id> --http-tokens required. Enforce via SCP organization-wide.

PassRole Escalation

A user with iam:PassRole + ec2:RunInstances can attach any role to a new instance - including admin roles - then SSH in and retrieve the credentials from IMDS.

{
  "Effect": "Allow",
  "Action": ["iam:GetRole", "iam:PassRole"],
  "Resource": "*"
}

"Resource": "*" means the user can launder any role's permissions through an instance they control.

Detection: CloudTrail iam:PassRole to admin roles, especially followed by RunInstances from the same identity.

Defense: Restrict Resource to specific role ARNs. Never wildcard PassRole.

Azure: The Service Principal Backdoor

Figure 4: Azure Application Administrator escalation flow - actions are attributed to the app, not the attacker.

The Application Administrator role can create and manage Enterprise Applications. This is a privilege escalation vector most organizations do not monitor.

The attack: Compromise an Application Administrator (or any user - all users can create applications by default). Add credentials to a high-privilege Enterprise Application. Authenticate as the application's service principal. Inherit whatever permissions the application was granted. Actions in logs show the application identity, not the attacker.

Service principals are the ideal persistence mechanism because they bypass user-centric controls. No MFA can be enforced on service principals. No session monitoring applies. No conditional access policies trigger. Once an attacker has a client secret for a privileged service principal, there is no second factor.

The subtler variant: phish an administrator into granting consent for elevated API permissions on an application the attacker controls. One click on "approve" and the application has Directory.ReadWrite.All.

Detection: Entra ID audit logs - new credential additions to applications, admin consent grants for high-privilege permissions, new registrations from unexpected users. Sentinel: AuditLogs | where OperationName == "Add service principal credentials".

Defense: Disable default user application creation. Require admin consent workflow. Monitor service principal sign-ins. Treat Application Administrator as highly privileged.

GCP: When Control Planes Interact

This technique, "Tag Your Way In" (Mitiga, Ariel Kalman), is the most conceptually interesting escalation in this article. The vulnerability is not in IAM or tagging individually - it is in how they interact.

GCP organizations use IAM conditions to gate role assignments based on resource tags:

binding condition: resource.matchTag('env', 'production')

An attacker with roles/resourcemanager.tagUser + roles/viewer - seemingly low-privilege - can:

1. Enumerate IAM policies to find roles gated by tag conditions
2. Bind the required tag to a target resource
3. Satisfy the IAM condition, gaining the elevated role
4. Perform privileged actions on the resource
5. Extract service account tokens from VM metadata for lateral movement

This is not a vulnerability. GCP does not prevent tagUser identities from manipulating tags that IAM conditions depend on. The tag management plane and the IAM enforcement plane are coupled, not isolated.

Detection: Cloud Audit Logs - tag binding creation followed by privileged API calls on the same resource. CreateTagBinding from identities that do not normally manage tags.

Defense: Restrict tagUser as security-sensitive when IAM conditions depend on tags. Separate tag roles from resource roles. Apply Deny Policies on sensitive resources.

Continuous Validation

If escalation is configuration-driven, it must be continuously tested - not assumed.

Stratus Red Team (DataDog) emulates cloud attack techniques across AWS, Azure, GCP, and Kubernetes, each mapped to MITRE ATT&CK Cloud tactics:

stratus warmup aws.credential-access.ec2-steal-instance-credentials
stratus detonate aws.credential-access.ec2-steal-instance-credentials
stratus cleanup aws.credential-access.ec2-steal-instance-credentials

Execute the technique. Wait for telemetry. Query for detections. Classify. Act on gaps. The same workflow from Articles 1-3 in this series, targeting cloud control planes instead of endpoints.

The patterns in this article have not changed in five years. What has changed is the speed at which adversaries find and exploit them. The Snowflake breach of 2024 - 165 customer accounts compromised through stolen credentials with no MFA - required no zero-day. The Microsoft/Midnight Blizzard breach started with a legacy test account with overprivileged access. Neither was sophisticated. Both were configuration failures.

If your IAM is misconfigured, you do not have a vulnerability. You have an exposed control plane. And the only way to know whether your configurations have drifted since the last audit is to test them continuously - not annually.