Cloud Pentesting: AWS, Azure, GCP — Lessons from Real Engagements

Cloud pentesting differs from network pentesting in scope and tooling. The "perimeter" is API endpoints and IAM. The blast radius is whatever the compromised role can do. Here is the methodology that consistently produces findings.

Engagement scoping

Cloud engagements need clear scope: which accounts, which regions, which assumed-breach starting point. The most common starting points are unauthenticated (find an open S3 bucket, find a public RDS instance), authenticated low-privilege user, or compromised CI/CD service principal.

Phase 1: Surface enumeration

• Public buckets, blobs, and storage accounts (S3, Azure Blob, GCS).
• Exposed serverless endpoints (Lambda function URLs, API Gateway with weak auth).
• Public-facing services on standard ports — RDS, ElastiCache, public ALBs with weak rules.
• Subdomain enumeration finds CloudFront distributions, S3 website endpoints, App Runner services.

Phase 2: Identity attack paths

Once a low-privilege identity is in hand, map what it can do. Tools: Pacu (AWS), MicroBurst (Azure), GCPBucketBrute (GCP). Look for over-permissioned policies, hidden role-chaining, and the classic "PassRole + iam:UpdateAssumeRolePolicy" privilege escalation paths. AWS IAM Access Analyzer is your friend.

Phase 3: Data and secrets

• SSM Parameter Store and Secrets Manager — readable to over-broad roles in many environments.
• S3 metadata — even when bucket contents are restricted, ACLs and policies often leak object existence.
• EC2 instance metadata service (IMDSv1 still found) — credential theft via SSRF.
• Cross-region forgotten resources — old Azure storage accounts, GCP projects from a 2020 PoC.

Phase 4: Lateral movement

• Cross-account trust chains (assume-role into linked accounts).
• Service-to-service via service identity (EC2 role → S3 → SSM → another EC2).
• CI/CD as a pivot — many orgs grant CI roles broad permissions.

Findings that always appear

• Public S3 buckets (or near-public — readable to "any AWS account").
• Over-permissioned default IAM roles.
• Long-lived access keys for human users.
• Logging gaps: CloudTrail not enabled in all regions, or sent to a bucket that is itself attackable.
• Forgotten test resources with elevated trust to production.

Reporting that lands

Cloud findings need clear "if this is exploited, here is what an attacker can do" narratives. CSPM tool output dumped to PDF is not a pentest report. A real cloud pentest documents the attack chain, the affected resources, and a prioritized remediation backlog with IaC examples where possible.

If you want a cloud pentest scoped for an SMB budget, our team runs them in 1-2 weeks across AWS, Azure, or GCP.

Cloud Pentesting: where to start this week

If you are just starting on cloud pentesting, pick one application or one business unit and run the playbook above end-to-end. A focused cloud pentesting pilot beats a sprawling rollout every time — and the artefacts you produce (asset inventory, threat model, remediation tracker) seed every future engagement.

Further reading

• Vexta — vulnerability scanning & pentest platform
• Network Pentesting: Tools, Workflow, and Reporting
• OWASP Top 10
• OWASP ASVS

Key takeaways on cloud pentesting

• Threat model first. Map the assets in scope for cloud pentesting, the attackers who would target them, and the controls already in place — before buying any tool.
• Detection beats prevention alone. Pair every preventive control with telemetry; assume one layer of cloud pentesting defence will fail and design for visibility on the second.
• Document the decisions, not just the configs. Auditors and incoming team members read the why, not the YAML. A short cloud pentesting architecture brief saves dozens of hours later.
• Test against real adversary patterns. Tabletop exercises and red-team drills tell you whether the cloud pentesting plan survives contact with reality.
• Iterate quarterly. Reassess the cloud pentesting posture every quarter; the threat surface changes faster than annual reviews can keep up with.

Cloud pentesting: frequently asked questions

What is the fastest first step in cloud pentesting?

Inventory. Until you know what is in scope, every other cloud pentesting decision is theoretical. A two-day inventory exercise typically uncovers more risk than a quarter of policy work.

How much should a small team spend on cloud pentesting each year?

Plan for 5–10% of IT budget on cloud pentesting controls and an additional 2–3% on assurance (audits, pentests, training). Mid-market teams often under-spend on assurance and over-spend on tooling.

Who owns cloud pentesting when there is no CISO?

The CTO or VP Engineering — accountability without ambiguity. Bring in a fractional CISO when cloud pentesting obligations cross regulatory boundaries (DPDP, HIPAA, PCI, RBI).

How do we measure whether cloud pentesting is working?

Three numbers: mean time to detect, mean time to recover, and the count of unpatched critical-severity vulnerabilities older than 30 days. Trend matters more than absolute value.