Cloud Penetration Testing Methodology

How Cloud Pentesting Differs from Traditional Pentesting

On-premises penetration testing starts with network scanning and lateral movement through the LAN. Cloud pentesting starts from the outside — with API calls, IAM enumeration, and metadata service probing. The attack surface is fundamentally different:

Dimension	Traditional Pentest	Cloud Pentest
Entry point	Network perimeter, VPN, web apps	APIs, web apps, compromised credentials, supply chain
Privilege escalation	OS vulnerabilities, service accounts	IAM iam:PassRole, assume-role chains, overprivileged lambdas
Lateral movement	SMB, PtH, Kerberoasting	Cross-account role assumption, service-linked roles
Evidence	Network captures, log files	CloudTrail, VPC Flow Logs, API call history
Scope limitation	IP ranges, hostnames	AWS accounts, GCP projects, Azure subscriptions
Rules of engagement	Written authorisation	AWS/Azure/GCP pentest authorisation forms required

Critical: Cloud providers require advance notification or prior authorisation for certain test activities. AWS permits security testing of your own resources without prior notification for most services, but DDoS simulation and DNS zone walking require prior approval. Always check provider-specific policies.

The Six-Phase Cloud Pentest Methodology

Phase 1 — Scoping and Authorisation

• Identify target accounts, projects, subscriptions
• Obtain written authorisation from the resource owner
• Submit cloud provider notification forms where required
• Define out-of-scope services (production databases, payment systems)

Phase 2 — Reconnaissance and Enumeration

Passive reconnaissance identifies exposed cloud assets without touching the target environment:

• Certificate transparency logs (crt.sh) reveal subdomains and cloud service endpoints
• OSINT on S3 bucket naming conventions (company-dev, company-backup, company-logs)
• GitHub and code repositories for hardcoded credentials
• LinkedIn for technology stack hints

Active enumeration (with authorisation):

• aws sts get-caller-identity — confirms credential validity and reveals account ID
• aws iam list-users, aws iam list-roles — enumerate identity inventory
• aws s3 ls — list accessible buckets

Phase 3 — Vulnerability Identification

• Run Prowler or ScoutSuite for automated misconfiguration discovery
• Check for IMDSv1 exposure (SSRF targets)
• Identify overprivileged IAM entities using Cloudsplaining
• Look for public RDS snapshots, public AMIs, public S3 buckets
• Check for disabled CloudTrail logging and Config rules

Phase 4 — Exploitation

• Credential-based attacks: Use found credentials to enumerate permissions
• SSRF-to-IMDS: Exploit SSRF vulnerabilities to reach instance metadata
• IAM privilege escalation: Exploit iam:PassRole, iam:CreatePolicyVersion, etc.
• Serverless exploitation: Trigger Lambda functions with malicious payloads

Phase 5 — Post-Exploitation

• Enumerate accessible S3 data
• Attempt cross-account role assumption
• Check for data exfiltration paths (S3 replication, SNS, SQS)
• Pivot to non-cloud services (RDS, ElastiCache) accessible from compromised EC2

Phase 6 — Reporting

Document findings with business impact, technical evidence, and remediation steps.

The Five Cloud Pentest Patterns

These five patterns appear in almost every cloud engagement:

1. Overprivileged IAM role on EC2: The instance role has s3:* or iam:* permissions. Combined with SSRF or RCE, this becomes critical.

2. Public S3 bucket with sensitive data: Development or backup buckets left public. Often contains database dumps, source code, or API keys.

3. Cross-account trust misconfiguration: A role trust policy allows assumption from * or an entire AWS account rather than a specific role or service.

4. Disabled or misconfigured logging: CloudTrail not enabled in all regions, S3 bucket for logs is publicly writable, or GuardDuty is disabled.

5. Secrets in environment variables: API keys, database passwords, and tokens stored in Lambda environment variables or EC2 user data, visible in plaintext to anyone with read access to the configuration.

Recon Tools

Tool	Purpose	Cloud
CloudSploit	Automated misconfiguration scanning	AWS, Azure, GCP
Pacu	AWS exploitation framework	AWS
ScoutSuite	Multi-cloud security auditing	AWS, Azure, GCP, Alibaba
Enumerate-IAM	Brute-force IAM permission enumeration	AWS
ROADtools	Azure AD enumeration and attack	Azure
Gitleaks	Secret scanning in repositories	Any

Cloud Pentest Report Structure

1. Executive summary (business risk, key findings)
2. Scope and methodology
3. Findings (Critical → High → Medium → Low → Informational)
   • Per finding: description, evidence (screenshots, API calls), CVSS score, remediation steps
4. Attack chain narrative (how findings chain together)
5. Remediation roadmap (prioritised by risk and effort)
6. Appendix (raw tool output, raw API responses)

Key Takeaway

Cloud penetration testing is a specialised discipline that requires cloud-native thinking. The most impactful findings — overprivileged IAM, public data exposure, disabled logging — are not found with Metasploit but with careful API enumeration and configuration review. Mastery of IAM, CloudTrail, and the five common patterns gives you the foundation for any cloud security assessment.