/cloud-iam-deep

name: cloud-iam-deep
description: Cloud IAM red-team attack chain across AWS, Azure, GCP — focused on EXTERNAL exploitation paths and post-credential-discovery privilege analysis. Covers IAM enumeration (aws iam, az role, gcloud iam), STS/AssumeRole chaining, Azure Managed Identity abuse (via SSRF/leak), GCP service account JSON abuse, IMDSv1/v2 attacks via SSRF, K8s ServiceAccount token privilege analysis once held (token discovery / cluster exposure is owned by hunt-k8s), role-trust-policy confused-deputy, cross-account assume-role enumeration, IAM privilege escalation patterns (24+ AWS, 8+ Azure, 6+ GCP), and AWS Cognito Identity Pool unauthenticated-role attack chain (GetId → GetCredentialsForIdentity → IAM role abuse). Built for the case where recon yields a credential (key, JSON, token) and you need to know what it grants and how to escalate. Use when an AWS key / Azure secret / GCP service account JSON / K8s SA token surfaces from a code repo, JS bundle, APK, breach corpus, or SSRF chain.
sources: aws-iam-docs, azure-rbac-docs, gcp-iam-docs, hackingthe.cloud, pacu, peirates, prowler, rhinosecuritylabs_research, hackerone_public
report_count: 6

When to use

Trigger when:

• A cloud credential surfaces (key, secret, token, JSON file)
• SSRF chain reaches IMDS / metadata endpoint
• APK / git-leak reveals embedded cloud key
• Recon shows public S3/GCS/Azure-blob with permissions you can verify
• A Kubernetes API or service-account token is exposed
• Post-RCE on a cloud-hosted instance — pivot to cloud control plane

Do NOT use for:

• On-prem-only environments (use AD attack skills — but those are out of scope per external-only boundary)
• Web2 vulns that happen to be on AWS — use the relevant `hunt-*` skill

---

Credential identification (first 60 seconds)

# AWS access key patterns
AKIA[0-9A-Z]{16}                # IAM user access key (long-term)
ASIA[0-9A-Z]{16}                # STS temporary credential
AGPA[0-9A-Z]{16}                # IAM group
AIDA[0-9A-Z]{16}                # IAM user (user-id)
AROA[0-9A-Z]{16}                # IAM role
ANPA[0-9A-Z]{16}                # Managed policy

# AWS secret pattern (40-char base64-ish — context required)
[A-Za-z0-9/+=]{40}              # AWS secret access key

# Azure
AccountKey=[A-Za-z0-9+/=]{86}   # Storage account key
client_secret pattern + UUID    # Azure AD app credential

# GCP service account JSON
{
  "type": "service_account",
  "project_id": "...",
  "private_key_id": "...",
  "private_key": "-----BEGIN PRIVATE KEY-----..."
}

# K8s SA token (JWT format — decode to confirm)
eyJhbGciOiJSUzI1...     # decode kid claim to see issuer

---

AWS — read-only validation (the safe first step)

# Set credential
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."

# 1. WHO am I?
aws sts get-caller-identity
# Returns: UserId, Account, Arn
# Arn tells you: IAM user vs role, account ID, name

# 2. WHAT can I do? (the privesc question)
# Try common read-only first — failures still inform you
aws iam list-users 2>&1 | head -5
aws iam list-roles 2>&1 | head -5
aws iam list-policies 2>&1 | head -5
aws iam list-groups 2>&1 | head -5

# 3. WHAT policies are attached to me?
aws iam list-attached-user-policies --user-name <self>
aws iam list-user-policies --user-name <self>          # inline policies
aws iam list-groups-for-user --user-name <self>

# 4. Service-by-service surface
aws ec2 describe-instances --max-items 1 2>&1 | head
aws s3 ls 2>&1 | head -10
aws lambda list-functions --max-items 5 2>&1 | head
aws rds describe-db-instances --max-items 5 2>&1 | head
aws secretsmanager list-secrets --max-results 5 2>&1 | head
aws ssm describe-parameters --max-results 5 2>&1 | head

# 5. Audit any cross-account / external trust
aws iam list-roles --query 'Roles[?contains(AssumeRolePolicyDocument.Statement[0].Principal.AWS, `arn:aws:iam::`)]' 2>&1 | head -20

---

AWS privesc patterns (24+ documented — `iam_privesc` techniques)

Quick lookup — if you have any of these IAM actions, escalate via the listed technique:

| You have | Escalate via | |---|---| | `iam:CreateAccessKey` | Create access key on any user → impersonate | | `iam:CreateLoginProfile` | Set a console password on a user → login | | `iam:UpdateLoginProfile` | Reset console password on a user | | `iam:AttachUserPolicy` | Attach AdministratorAccess to self | | `iam:AttachGroupPolicy` | Attach AdministratorAccess to a group you're in | | `iam:AttachRolePolicy` + sts:AssumeRole | Attach to a role you can assume | | `iam:PutUserPolicy` | Inline AdministratorAccess to self | | `iam:PutGroupPolicy` | Inline policy on a group | | `iam:PutRolePolicy` | Inline on a role you can assume | | `iam:AddUserToGroup` | Add self to admin group | | `iam:UpdateAssumeRolePolicy` + sts:AssumeRole | Modify trust to allow self | | `iam:CreatePolicyVersion` | Create v2 of an attached policy with admin | | `iam:SetDefaultPolicyVersion` | Switch attached policy to admin version | | `iam:PassRole` + ec2:RunInstances | Launch EC2 as admin role → use instance creds | | `iam:PassRole` + lambda:CreateFunction/InvokeFunction | Run code as admin role | | `iam:PassRole` + cloudformation:CreateStack | CF stack creates resources as admin | | `iam:PassRole` + glue:CreateDevEndpoint | Notebook runs as admin role | | `iam:PassRole` + datapipeline | Pipeline runs as admin role | | `iam:PassRole` + codestar:CreateProject | New project gets admin role | | `ec2:RunInstances` (with admin instance profile already on the AMI) | Spin instance, exfil creds from IMDS | | `lambda:UpdateFunctionCode` (function has admin role) | Replace code → exfil creds | | `lambda:UpdateFunctionConfiguration` | Add layer / env var that exfils | | `cloudformation:UpdateStack` | Modify stack to grant self admin | | `sts:AssumeRole` (where trust allows you) | Direct privilege jump |

Many of the destructive ones are out-of-scope for an external red-team; document the path, don't always execute.

---