Cloud Pentest
Post-access cloud exploitation for AWS, GCP, and Azure, what to do AFTER you obtain...
Install
npx skills add awarexone/Agentic-Bug-Hunter --skill cloud-pentest -g -a claude-code -y- Repository
- awarexone/Agentic-Bug-Hunter5.5k
- Category
- Security
- Updated
- 7d ago
- License
- MIT
- Context cost
- Mediumabout 1,559 tokens
- Runs scripts
- No, instructions only
What it does
Post-access cloud exploitation for AWS, GCP, and Azure, what to do AFTER you obtain credentials or reach a metadata endpoint. Covers IAM enumeration and privilege escalation (iam:PassRole, CreatePolicyVersion, AssumeRole chains, GCP service-account impersonation, Azure managed-identity abuse), IMDSv1/v2 metadata credential theft, STS token abuse, S3/GCS/Blob bucket takeover and object exfil, Lambda/Cloud Functions env-var secrets, cross-account and cross-service pivoting, and turning leaked keys into demonstrated impact (read PII, assume admin, exfil data). Assumes authorized scope only. Use when you have AWS/GCP/Azure keys, an SSRF hitting 169.254.169.254 / metadata.google.internal, a leaked service-account JSON, or a token, and need to escalate and prove impact. For finding buckets/origins first, use cloud-recon; for the SSRF entry point, see web2-vuln-classes. 中文触发词：云渗透、AWS提权、IAM枚举、元数据凭证、云安全审计
CLOUD PENTEST, Post-Access Exploitation
Recon finds the door; this is what you do inside. A leaked
AKIA...key or a metadata token is not a finding on its own, the finding is what that identity can DO. Enumerate the identity, find the privesc path, prove real impact. Never touch data you're not authorized to.
AUTHORIZATION FIRST
[ ] Target cloud account/subscription is explicitly in scope
[ ] You have written authorization (program scope, engagement doc)
[ ] Read-only enumeration before ANY state change
[ ] No exfil of real customer data, prove access with a benign canary/own-account object
[ ] Discovered accounts/roles you can pivot to are NOT auto-authorized, confirm scope
Stop here if any box is unchecked.
0. IDENTIFY THE IDENTITY (do this first, always)
| You have | First call | Tells you |
|---|---|---|
| AWS keys | aws sts get-caller-identity | account id, principal ARN, user vs role |
| AWS metadata | curl .../iam/security-credentials/<role> | temp creds + role name |
| GCP SA JSON / token | gcloud auth ... / curl metadata ...token | project, service account, scopes |
| Azure token / MI | IMDS .../identity/oauth2/token | tenant, object id, resource access |
Never assume privilege. Enumerate what this identity actually has before planning.
1. AWS, ENUMERATE THEN ESCALATE
Enumerate (read-only):
aws sts get-caller-identity
aws iam get-account-authorization-details 2>/dev/null # full policy dump if allowed
aws iam list-attached-user-policies --user-name <u>
aws iam list-role-policies / list-attached-role-policies
# No IAM read? Brute the effective perms with enumerate-iam / then map with a policy tool
Classic privesc paths (need the matching permission):
