Cloud iam deep
/SKILLCloud IAM red-team attack chain across AWS, Azure, GCP - focused on EXTERNAL exploitation paths and post-credential-discovery privilege analysis.
--- name: cloud-iam-deep description: Cloud IAM red-team attack chain across AWS, Azure, and GCP : focused on EXTERNAL exploitation paths and privilege analysis following credential discovery. Covers IAM enumeration (aws iam, az role, gcloud iam), STS/AssumeRole chaining, Azure Managed Identity abuse (via SSRF/leak), GCP service accountJSON abuse, IMDSv1/v2 attacks via SSRF, K8s ServiceAccount token privilege analysis once obtained (token discovery and cluster exposure are covered 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). Designed for scenarios where reconnaissance reveals a credential (key,JSON , token) and you need to determine what privileges it grants and how to escalate them. Use this when an AWS key, Azure secret, or GCP service account:JSON , or K8s SA token:is exposed via a code-repo file, JS bundle, APK, breach corpus, or SSRF chain. sources: aws-iam-docs, azure-rbac-docs, gcp-iam-docs, hackingthe.cloud, pacu, peirates, prowler,rhinosecuritylabsresearch ,hackeronepublic report_count : 6 --- ## When to Use Trigger when: - A cloud credential is exposed (key, secret, token,JSON file) - An SSRF chain reaches an IMDS or metadata endpoint - An APK or Git leak reveals an embedded cloud key - Reconnaissance reveals a 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 the cloud control plane Do NOT use for: - On-premises-only environments (use AD attackskills : but those are out of scope due to the “external-only” boundary) - Web2 vulnerabilities that happen to be on AWS:use the relevanthunt-* 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 | | i