domains / security / cloud-iam-redteam / cloud-iam-deep

cloud-iam-deep

Skill card

combined

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.

Repositories

RepositoryPath
uphiago/recon-skillsredteam/cloud-iam-deep/SKILL.md
sickn33/agentic-awesome-skillsplugins/agentic-awesome-skills-claude/skills/cloud-iam-deep/SKILL.md

Other copies

RoleRepositoryPath
peeruphiago/recon-skillsredteam/cloud-iam-deep/SKILL.md
peersickn33/agentic-awesome-skillsplugins/agentic-awesome-skills-claude/skills/cloud-iam-deep/SKILL.md
adaptersickn33/agentic-awesome-skillsplugins/agentic-awesome-skills/skills/cloud-iam-deep/SKILL.md
adaptersickn33/agentic-awesome-skillsskills/cloud-iam-deep/SKILL.md

Combined skill

---
name: cloud-iam-deep
description: Cloud IAM red-team attack chain across AWS, GCP, and Azure
---

## Authorization Gate
Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.
Without that confirmation, remain read-only and provide defensive guidance only.

## When to Use
- After finding Firebase API keys, Supabase keys, or GCP SA keys
- When a target uses serverless (Cloud Functions, Cloud Run)
- After finding S3 bucket names or MinIO instances
- 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

## Credential Identification
Identify credential types using patterns:
- AWS: AKIA[0-9A-Z]{16}, ASIA[0-9A-Z]{16}, AGPA[0-9A-Z]{16}, AIDA[0-9A-Z]{16}, AROA[0-9A-Z]{16}, ANPA[0-9A-Z]{16}, 40-char secret
- Azure: AccountKey=[A-Za-z0-9+/=]{86}, client_secret + UUID
- GCP: service_account JSON with private_key
- K8s: JWT SA token (decode kid claim)

## AWS — Read-Only Validation
1. Set credentials: export AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
2. Identify identity: aws sts get-caller-identity
3. Enumerate permissions: aws iam list-users, list-roles, list-policies, list-groups
4. Check attached policies: aws iam list-attached-user-policies, list-user-policies, list-groups-for-user
5. Service surface: aws ec2 describe-instances, aws s3 ls, aws lambda list-functions, aws rds describe-db-instances, aws secretsmanager list-secrets, aws ssm describe-parameters
6. Audit cross-account trust: aws iam list-roles with AssumeRolePolicyDocument query

## AWS Privilege Escalation Patterns
If you have any of these IAM actions, escalate via the listed technique:
- iam:CreateAccessKey → Create access key on any user → impersonate
- iam:CreateLoginProfile / iam:UpdateLoginProfile → Set/reset console password
- iam:AttachUserPolicy / iam:AttachGroupPolicy / iam:AttachRolePolicy → Attach AdministratorAccess
- iam:PutUserPolicy / iam:PutGroupPolicy / iam:PutRolePolicy → Inline admin policy
- iam:AddUserToGroup → Add self to admin group
- iam:UpdateAssumeRolePolicy + sts:AssumeRole → Modify trust to allow self
- iam:CreatePolicyVersion / iam:SetDefaultPolicyVersion → Switch to admin version
- iam:PassRole + ec2:RunInstances / lambda:CreateFunction / cloudformation:CreateStack / glue:CreateDevEndpoint / datapipeline / codestar:CreateProject → Run code as admin role
- ec2:RunInstances with admin instance profile → Spin instance, exfil creds from IMDS

## GCP — Cloud Functions Enumeration
1. Enumerate project IDs and regions using patterns: empresa, empresa-app, empresa-prod, empresa-dev, empresa-1, empresa-12345, app-empresa, admin-1a2b3
2. Test Cloud Functions URLs: https://{REGION}-{PROJECT_ID}.cloudfunctions.net/{FUNCTION_NAME}
3. Test HTTP methods without auth: GET, POST, PUT, DELETE
4. Check for reflected CORS on all functions

## GCP — Source Code Buckets
Access gcf-sources-{PROJECT_NUMBER}-{REGION} and gcf-v2-sources-{PROJECT_NUMBER}-{REGION} with SA key read permission to download function source zips.

## GCP — SA Key to Token Generation
1. Generate JWT from SA key using RS256 signature
2. Exchange JWT for access token via token_uri
3. List IAM policy: cloudresourcemanager.googleapis.com/v1/projects/{project_id}:getIamPolicy
4. List Storage buckets: storage.googleapis.com/storage/v1/b?project={project_id}
5. Test Firestore access: firestore.googleapis.com/v1/projects/{project_id}/databases/(default)/documents

## GCP — Firebase Open SignUp
Test open sign-up: curl identitytoolkit.googleapis.com/v1/accounts:signUp?key=$API_KEY

## GCP — Firestore Public Access Test
1. Test read: curl firestore.googleapis.com/v1/projects/$PROJECT_ID/databases/(default)/documents/{collection}?key=$API_KEY
2. Test write: curl PATCH with updateMask.fieldPaths

## Azure
- Identify storage account keys and Azure AD app credentials
- Test blob storage access with identified credentials
- Enumerate RBAC roles and assignments

## Reporting
Document all findings with evidence, severity, and remediation guidance.