Cloud IAM Privilege Escalation: Common Misconfigurations and How to Find Them

The 2024 Verizon DBIR found that misconfiguration remains the leading cause of cloud data breaches, with IAM errors accounting for the majority of those misconfigurations. After several years of running cloud security assessments, the pattern is remarkably consistent: environments that look secure from the outside have IAM configurations that an attacker with initial access can exploit to reach administrator-level permissions within minutes.

AWS: The Most Common Escalation Patterns

iam:PassRole with ec2:RunInstances

If a principal has iam:PassRole on a high-privilege IAM role and ec2:RunInstances, they can launch a new EC2 instance with that high-privilege role attached, then retrieve credentials from the instance metadata service. This is a privilege escalation even if the principal has no direct IAM write permissions.

# Check if current credentials can pass roles
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789:user/low-priv-user \
  --action-names iam:PassRole ec2:RunInstances \
  --resource-arns arn:aws:iam::123456789:role/AdminRole

# If allowed, launch instance with admin role
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --iam-instance-profile Name=AdminInstanceProfile

# Retrieve credentials from metadata (from within the instance)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/AdminRole

Lambda:CreateFunction with iam:PassRole

The same escalation pattern applies to Lambda functions. A principal that can create Lambda functions and pass a high-privilege role can deploy a function that extracts credentials or performs arbitrary actions with the permissions of that role.

iam:CreateLoginProfile on Another User

The ability to create or update a console login profile for another IAM user effectively means the ability to take over that user's console access. Combined with knowledge of an existing high-privilege user account, this is a direct privilege escalation without touching the IAM policy layer.

GCP: Service Account Key Abuse

GCP service account keys are long-lived credentials that can be created by any principal with iam.serviceAccountKeys.create on a service account. If you can create keys for a high-privilege service account, you have persistent access at that privilege level. We find exported service account keys in source code repositories, CI/CD environment variables, and developer laptops far more often than should be possible.

# Find principals with dangerous service account permissions
gcloud iam roles list --format json | jq '.[] | select(.includedPermissions[] |
  test("iam.serviceAccountKeys.create|iam.serviceAccounts.actAs"))'

# Check who can actAs a specific service account
gcloud iam service-accounts get-iam-policy [email protected]

# List all user-managed service account keys (look for long-lived keys)
gcloud iam service-accounts keys list \
  --iam-account [email protected] \
  --filter "keyType=USER_MANAGED"

Systematic Detection with IAM Assessment Tools

# AWS: Use Cloudsplaining to identify privilege escalation paths
pip install cloudsplaining
cloudsplaining download --profile default
cloudsplaining analyze --input-file path/to/account-authorization-details.json

# AWS: Use Pacu for automated IAM enumeration (authorised testing only)
pacu
> run iam__enum_permissions
> run iam__privesc_scan

# GCP: Use Forseti Security or gcp-iam-privilege-escalation for path analysis
# Check for any principal with owner/editor on project
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)" \
  --filter="bindings.role:roles/owner OR bindings.role:roles/editor"

Remediation Priorities

1. 01Audit all IAM roles for iam:PassRole without scope restrictions. Add resource-level conditions to limit which roles can be passed.
2. 02Enable IAM Access Analyser (AWS) or Policy Analyser (GCP) and review findings weekly.
3. 03Eliminate user-managed service account key files. Migrate to Workload Identity Federation or instance metadata credentials.
4. 04Implement Service Control Policies (AWS) or Organisation Policy constraints (GCP) that hard-block the highest-risk permissions at the organisation level.
5. 05Review all roles with administrator-equivalent permissions and enforce time-bound, just-in-time access for privileged operations.