Cloud Pentesting Methodology

Cloud penetration testing requires a different approach than traditional infrastructure testing. Understanding the shared responsibility model, API-centric attack surface, and cloud-specific techniques is essential for effective security assessments.

Cloud vs Traditional Pentesting

Key Differences

Aspect	Traditional	Cloud
Scope	Network perimeter	APIs, IAM, services
Attack surface	Servers, ports	Metadata, credentials
Lateral movement	Network pivoting	Cross-account access
Data exfiltration	File transfers	Cloud storage APIs
Privilege escalation	OS-level	IAM policy abuse
Authorization	Written scope	Cloud provider approval

Cloud Pentesting Prerequisites

Before testing cloud environments:

Written authorization from cloud account owner
Cloud provider notification (AWS Pentest Policy, Azure ROE, GCP Acceptable Use)
Defined scope - specific accounts, regions, services
Emergency contacts for incident response
Data handling agreement for discovered credentials

Cloud Pentesting Framework

MITRE ATT&CK Cloud Matrix

┌─────────────────────────────────────────────────────────────┐
│                    ATT&CK for Cloud                          │
├─────────────────────────────────────────────────────────────┤
│  Initial Access → Execution → Persistence → Priv Esc       │
│       │               │            │            │           │
│  Valid accounts   Cloud API    IAM roles    Policy abuse   │
│  Phishing         Lambda       Access keys  Cross-account  │
│  Public apps      Functions    Trust        Service roles  │
├─────────────────────────────────────────────────────────────┤
│  Defense Evasion → Credential Access → Discovery           │
│       │                  │                │                 │
│  Disable logging    Metadata API     Cloud APIs            │
│  Modify policies    Secret stores    Account enumeration   │
│  Region switching   Token theft      Resource discovery    │
├─────────────────────────────────────────────────────────────┤
│  Lateral Movement → Collection → Exfiltration              │
│       │                │              │                     │
│  Assume roles      S3 buckets    Cloud storage             │
│  Service accounts  Databases     Transfer out              │
│  Trust abuse       Backups       Shadow copy               │
└─────────────────────────────────────────────────────────────┘

Phase 1: Reconnaissance

External reconnaissance:

# Discover cloud assets
# Subdomain enumeration for cloud services
subfinder -d target.com | grep -E '(aws|azure|gcp|s3|blob|cloud)'

# DNS records indicating cloud usage
dig +short txt target.com | grep -E '(spf|dkim|amazonses)'

# Certificate transparency logs
curl "https://crt.sh/?q=%.target.com&output=json" | jq -r '.[].name_value' | sort -u

# GitHub/GitLab dorking for credentials
# Search: "target.com" aws_access_key OR aws_secret

Service-specific discovery:

# S3 bucket naming patterns
# company-name, company-backups, company-logs
aws s3 ls s3://target-company --no-sign-request

# Azure blob patterns
curl -s "https://targetcompany.blob.core.windows.net/public?restype=container&comp=list"

# GCP storage
gsutil ls gs://target-company-bucket

Phase 2: Enumeration

Once you have credentials:

# AWS - Who am I?
aws sts get-caller-identity

# What can I do?
aws iam list-attached-user-policies --user-name compromised-user
aws iam list-user-policies --user-name compromised-user

# Azure - Current context
az account show
az ad signed-in-user show

# GCP - Current identity
gcloud auth list
gcloud config list

Phase 3: Privilege Escalation

Identify escalation paths:

# AWS - Common escalation vectors
# iam:PassRole + lambda/ec2 - create role-assuming resource
# iam:CreatePolicyVersion - modify existing policy
# iam:AttachUserPolicy - attach admin policy
# sts:AssumeRole - assume more privileged role

# Check for assumable roles
aws iam list-roles --query 'Roles[*].{Name:RoleName,Trust:AssumeRolePolicyDocument}'

Phase 4: Lateral Movement

# AWS cross-account
aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/CrossAccountRole \
    --role-session-name pentester

# Service account token (Kubernetes)
kubectl auth can-i --list
kubectl get secrets -A

Phase 5: Impact Assessment

Document findings:

Data exposure risk
Privilege escalation paths
Persistence mechanisms
Compliance violations

Testing Boundaries

In-Scope Activities

Activity	Typically Allowed	Requires Approval
API enumeration	Yes	-
IAM policy analysis	Yes	-
Storage permission testing	Yes	-
Network scanning	Limited	Yes
DoS testing	No	Special approval
Production data access	Case-by-case	Yes

Cloud Provider Policies

AWS:

No pre-approval needed for most tests
Prohibited: DoS, DNS zone walking, port flooding
Report vulnerabilities via HackerOne

Azure:

Follow Rules of Engagement
No testing of Microsoft infrastructure
24-hour notification for certain tests

GCP:

Standard Acceptable Use Policy
No testing of Google infrastructure
Automated scanning requires notification

Assessment Types

Type	Focus	Duration
Configuration review	CIS benchmarks, misconfigurations	1-2 weeks
Pentest (limited)	Specific service/application	1-2 weeks
Pentest (comprehensive)	Full account assessment	3-4 weeks
Red team	Full attack simulation	4-8 weeks
Continuous testing	Ongoing assessment	Continuous

Next, we'll cover enumeration and reconnaissance techniques for cloud environments. :::