AWS IAM Privilege Escalation: 7 Paths We Find in Every Assessment

In the past eighteen months, AWS IAM misconfiguration has overtaken every other finding category in our cloud security assessments. IAM policies are complex, least privilege is hard to maintain at scale, and the blast radius of a single over-privileged account is enormous. Here are the seven escalation paths we find most frequently.

1. iam:CreatePolicyVersion

An account with iam:CreatePolicyVersion can create a new version of any existing IAM policy — including policies attached to more privileged roles. By setting a new default version that includes *:*, the attacker grants themselves administrator access.

aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789:policy/TargetPolicy \
  --policy-document file://admin-policy.json \
  --set-as-default

2. iam:AttachRolePolicy

The ability to attach managed policies to roles allows an attacker to attach the AWS-managed AdministratorAccess policy to a role they can assume — or to their own user if they also have iam:AttachUserPolicy.

3. iam:PassRole + ec2:RunInstances

The most commonly missed escalation path. iam:PassRole alone looks harmless. Combined with any service that accepts a role at launch — EC2, Lambda, ECS — an attacker can launch a resource with a high-privilege instance profile, then exfiltrate credentials from the metadata service.

aws ec2 run-instances \
  --image-id ami-xxxxxxxx --instance-type t2.micro \
  --iam-instance-profile Name=AdminRole \
  --user-data file://steal-creds.sh

4. lambda:UpdateFunctionCode

If a Lambda function has an elevated role and an attacker can update the function code, they can inject a payload that exfiltrates the role credentials via an outbound HTTP request — no console access required.

5. sts:AssumeRole Misconfigurations

Trust policies that use wildcards or rely on aws:PrincipalAccount alone without additional conditions can allow cross-account role assumption from attacker-controlled accounts.

6. Inline Policy Abuse via iam:PutUserPolicy

Unlike managed policies, inline policies have no version history and don't appear in default IAM policy lists. An attacker with iam:PutUserPolicy can silently attach a policy granting any permission — significantly harder to detect.

7. secrets:GetSecretValue on Privileged Credentials

Access to Secrets Manager combined with poorly scoped resource policies allows retrieval of database credentials, API keys, and service account passwords that grant privilege equal to or exceeding the credentials they protect.