cloud-pentest
GitHub云环境后渗透利用技能，涵盖AWS/GCP/Azure的IAM枚举、权限提升及凭证窃取。用于在获取凭据或元数据访问权后，验证实际影响并证明风险，仅限授权范围。
Trigger Scenarios
Install
npx skills add awarexone/Agentic-Bug-Hunter --skill cloud-pentest -g -y
SKILL.md
Frontmatter
{
"name": "cloud-pentest",
"description": "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):
| Permission held | Escalation |
|---|---|
iam:CreatePolicyVersion |
Write a new default *:* version onto an attached policy |
iam:PassRole + ec2:RunInstances / lambda:CreateFunction |
Launch compute AS an admin role |
iam:AttachUserPolicy / PutUserPolicy |
Attach AdministratorAccess to yourself |
sts:AssumeRole (over-broad trust) |
Assume a more privileged role |
iam:CreateAccessKey on another user |
Mint keys for a privileged user |
lambda:UpdateFunctionCode on privileged fn |
Run code with the function's role |
iam:UpdateAssumeRolePolicy |
Rewrite trust policy to let you assume it |
Impact proof (benign): list a bucket you were told is in scope, sts assume-role into the admin role and get-caller-identity to show the new ARN, or read a canary object. Don't touch real PII.
2. METADATA (IMDS) — SSRF LANDS HERE
IMDSv1 (no token): GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>
IMDSv2 (token): PUT .../latest/api/token (X-aws-ec2-metadata-token-ttl-seconds: 21600)
then GET with X-aws-ec2-metadata-token: <token>
GCP: GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
header: Metadata-Flavor: Google
Azure: GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/
header: Metadata: true
Got temp creds → jump to section 1 (AWS) / 3 (GCP) / 4 (Azure) and enumerate what THAT role can do. SSRF alone is Medium; SSRF → metadata creds → data/admin is Critical.
3. GCP — IMPERSONATION IS THE PIVOT
gcloud auth activate-service-account --key-file=sa.json # or use the token
gcloud projects get-iam-policy <project>
gcloud iam service-accounts list
| Permission | Escalation |
|---|---|
iam.serviceAccounts.getAccessToken / actAs |
Impersonate a higher-priv SA (--impersonate-service-account) |
iam.serviceAccountKeys.create |
Mint a key for a privileged SA |
iam.roles.update on a custom role you hold |
Add permissions to yourself |
cloudfunctions.functions.update / deploy |
Run code as the function's SA |
storage.objects.get on a sensitive bucket |
Read secrets/state |
Owner/Editor at project level = effectively admin. Check for the default Compute SA having Editor — extremely common.
4. AZURE — MANAGED IDENTITY & RBAC
az account show
az role assignment list --assignee <objectId> --all
az resource list
| Path | Escalation |
|---|---|
| Managed identity with Contributor | Deploy/modify resources, run commands on VMs (az vm run-command) |
Microsoft.Authorization/*/write |
Assign yourself Owner |
| Key Vault access policy / RBAC | Read secrets, certs, keys |
| Automation Account / Runbook | Execute as the automation identity |
| Storage account key read | Full blob access |
5. STORAGE — S3 / GCS / BLOB
[ ] List: aws s3 ls s3://<bucket> --no-sign-request (public?)
[ ] Read/Write ACL: get-bucket-acl / put-object test (own canary file only)
[ ] Bucket policy allows *? cross-account?
[ ] Versioning / logging exposes old secrets?
[ ] Website / static hosting → subdomain takeover angle (see web2-vuln-classes)
Writable public bucket serving a live site = Critical (content injection / takeover). Readable bucket with secrets/PII = High/Critical.
6. SECRETS HARVEST (post-access)
[ ] Lambda/Cloud Function/App env vars (often hold API keys, DB creds)
[ ] SSM Parameter Store / Secrets Manager (if perms allow)
[ ] EC2 user-data / instance tags
[ ] Terraform state in the bucket you just read
[ ] CI/CD variables reachable from the identity
Each secret → re-run "identify the identity" for the NEW credential. Chain until you hit admin or crown-jewel data, then stop and write it up.
7. REPORT LINE (per finding)
Entry: <leaked key | SSRF→metadata | public bucket | SA JSON>
Identity: <ARN / SA / object id> — <what it could do>
Escalation: <exact permission → action that raised privilege>
Impact proven: <assumed admin ARN | read canary | listed in-scope resource>
Blast radius: <accounts/services/data reachable>
Fix: <least-privilege policy | IMDSv2 enforce | block-public-access | rotate>
Impact must be demonstrated with a concrete call, using benign/own-account objects. "The key might allow…" is not a finding — show get-caller-identity after the escalation.
Version History
- 40b03ee Current 2026-10-19 11:27
