Module 2 · Cloud IAM — Where Most Breaches Live 🔒

• Implicit permissions. Action requires permissions X, Y, Z — you grant X and Y, not Z; action fails; developer adds * permission. Problem solved; exposure increased.
• Resource-based policies + identity-based policies + SCPs + permission boundaries: multiple layers of evaluation. Effective permission = union minus denials. Hard to reason about.
• Assume-role chains (AWS): role A assumes role B which can assume role C. Effective power not captured by any single role’s policies.
• Service-linked roles: pre-configured by cloud provider; varying levels of documentation.
• Organizational policies (AWS SCPs, Azure Policy, GCP Org Policies) add guardrails but also confusion.

Dangerous IAM patterns

Wildcard permissions

# AWS: classic bad policy
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

# "But we're just developers, we need flexibility" — famous last words
# Found regularly in real AWS audits, often on long-standing roles

iam:PassRole + ec2:RunInstances = privilege escalation

# If a user has:
# - iam:PassRole (can assign a role to a new resource)
# - ec2:RunInstances (can create EC2)

# They can:
# 1. Launch EC2 with admin role attached
# 2. SSH/SSM into that EC2
# 3. Use IMDS to get admin role's temporary credentials
# 4. Become admin of the account

# Many "developer" permissions include these indirectly via managed policies
# Pacu (AWS exploitation framework) automates privesc path discovery
pacu > run iam__privesc_scan

CodeBuild / Lambda → role assumption chain

# Developer has permission to update a CodeBuild project
# CodeBuild project runs with a privileged IAM role
# Developer updates project's buildspec to exfil credentials
# On next build: execute buildspec as CodeBuild role

# Similar: update Lambda function code; Lambda runs as its assigned role
# If that role has broad permissions, Lambda execution = privilege use

Cross-account trust with overly broad Principal

# Bad trust policy
{
  "Effect": "Allow",
  "Principal": {"AWS": "*"},      # Any AWS account can assume!
  "Action": "sts:AssumeRole"
}

# Found in the wild. Usually deployed by a dev testing and never tightened
# Anyone with an AWS account (literally anyone) can assume that role

MFA not enforced for IAM users

IAM users with console access + programmatic keys but no MFA. Credential leak = instant compromise. Modern best practice: federated access (SAML or OIDC) with MFA at IdP; avoid long-lived IAM users entirely.

GCP IAM specifics

• Basic roles (Owner, Editor, Viewer) are too broad. Use predefined or custom roles.
• Default service accounts are created per service with broad permissions. Disable or restrict.
• Service account keys (JSON files) are long-lived; avoid with Workload Identity Federation.
• Hierarchical IAM (Org → Folder → Project → Resource) with inheritance — grant at narrowest scope.

Azure IAM specifics

• RBAC on ARM (management plane) separate from data plane (e.g., Storage Blob Data Reader vs Owner).
• Entra ID roles (Global Administrator, etc.) separate from Azure RBAC.
• Subscription Owner = root of that subscription. 2-5 people maximum.
• User Access Administrator + Contributor = effective Owner. Watch the combination.
• Management Groups add another layer.

Tools for IAM analysis

• Pacu (AWS): offensive framework, privilege escalation path discovery.
• CloudSplaining: static analysis of IAM policies for risky patterns.
• IAMSpy / PMapper: graph-based IAM analysis (BloodHound for AWS).
• Cloudmapper: AWS environment visualization.
• Steampipe: query cloud config via SQL.
• Prowler: comprehensive AWS/Azure/GCP auditor.
• ROADtools (Entra): enumerate + visualize Entra environment.
• AzureHound / BloodHound AD Azure: attack path visualization for Entra.

What we find

• Wildcard IAM permissions on human users
• Service accounts with admin-level roles
• Cross-account trust policies allowing any account
• IAM users with programmatic keys + no MFA
• Keys older than 90 days never rotated
• Service accounts without any review process
• Over-granted “Owner” or “Contributor” roles at subscription level
• Entra Global Admins count > 10
• Service principals with Directory.Read.All or similar broad permissions
• PIM not enabled; standing admin access

Mindset takeaway

IAM is the hardest part of cloud security. It’s also the most important — most cloud breaches are ultimately IAM misconfigurations. Invest disproportionately here. Tools help; they don’t replace the review process. Every permission granted should have an owner, a justification, and a review date.

For pentesters: Pacu + CloudSplaining + PMapper on every AWS engagement. ROADtools/AzureHound on every Entra engagement. Privilege escalation paths are always there if you look. For defenders: continuous IAM analysis (via CSPM or custom queries) is table stakes. Permissions sprawl grows; you must prune continuously.