domains / families / security / cloud-iam-deep

cloud-iam-deep

combined

Cloud IAM red-team attack chain across AWS, Azure, GCP GCP/AWS/Azure cloud exploitation -- Cloud Functions, Firestore, Cloud Run, S3, MinIO, Blob Storage, SA keys

When to use

• 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

When not to use

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.

Skill page

Conflict

The two copies overlap in scope (cloud IAM red teaming across AWS, GCP, and Azure) but each contains material steps the other lacks. The uphiago copy is GCP-heavy with concrete Cloud Functions URL enumeration, gcf-sources bucket access, SA-key-to-token generation, and Firebase/Firestore open-access tests. The sickn33 copy is AWS-heavy with credential identification patterns, read-only validation commands, and a detailed IAM privilege-escalation matrix, plus a mandatory authorization gate. Neither is a reproduction of the other; crowning one would hide a real alternative procedure.