IAM Privilege Escalation Patterns in AWS and Azure

The privilege escalation surface in cloud IAM

Cloud IAM privilege escalation is fundamentally different from on-premises AD escalation in one key respect: the blast radius of a single misconfiguration is higher, and the misconfiguration is often invisible in standard permission summaries. The effective permissions of any IAM entity depend not just on the policies directly attached to it but on every permission chain that entity can reach.

AWS: the PassRole chain

The most consistently exploitable pattern in AWS environments is the PassRole chain. iam:PassRole allows an entity to assign an IAM role to a service. Combined with the ability to create or modify compute (Lambda, EC2, ECS task definitions), it enables any entity with those permissions to assign a higher-privileged role to a service they control, then invoke that service.

The canonical form:

entity permissions: iam:PassRole, lambda:CreateFunction, lambda:InvokeFunction
target role: AdminRole (full account access)

attack:
1. Create Lambda function, pass AdminRole as execution role
2. Invoke function with payload that calls sts:GetCallerIdentity
3. Confirm execution context is AdminRole
4. Execute any further actions as AdminRole

In our review of real tenants, 78% had at least one IAM entity where PassRole on a high-privilege role was combined with the ability to create or modify at least one compute service. Most of these were service accounts created for CI/CD pipelines.

AWS: AttachUserPolicy and wildcard resource scoping

iam:AttachUserPolicy on a wildcard resource allows an entity to add any policy to any user, including themselves. This is a well-known escalation path and is documented in multiple privilege-escalation toolkits (Pacu, Cloudsplaining). It still appears regularly in production environments because the permission looks reasonable in isolation: "this CI pipeline needs to manage user policies."

The issue is always in the resource scope. iam:AttachUserPolicy on resource: "arn:aws:iam::*:user/ci-*" is safe. On resource: "*" it is a full privilege escalation path for anyone who can use that entity.

Azure: Managed Identity SSRF

Azure Managed Identities attach to compute resources and provide access tokens via the instance metadata service (IMDS) at a link-local address. If any workload running on that compute resource has an SSRF vulnerability, the attacker can request a token for the managed identity without any additional authentication.

The severity depends on the identity's assigned roles. In our engagements, Contributor-scoped managed identities on compute resources were the most common finding - broad enough for most lateral movement objectives, scoped to a specific subscription but often covering all resources within it.

What to audit

The single highest-leverage audit action in AWS is to enumerate every entity with both iam:PassRole and any compute creation permission, then check what roles are in scope. In Azure, audit managed identity role assignments quarterly - Contributor and Owner assignments to compute resources are the primary finding class.