This guide explains how cloud penetration testing is actually performed — the phases, the techniques used at each stage, and what a rigorous assessment looks like across AWS, Azure and GCP.
It is written for security engineers, cloud architects, and technical leaders who want to understand the process, prepare their environment for testing, or evaluate whether a provider’s methodology is deep enough to trust.
Looking to engage a provider rather than understand the process? See our cloud penetration testing services.
Why Cloud Penetration Testing Requires a Different Methodology
Traditional network penetration testing assumes a defined perimeter, IP ranges you can scan, and infrastructure you fully control. Cloud environments break all three assumptions.
Four differences shape the methodology:
Identity is the new perimeter. In cloud environments, most successful attacks are not exploits against software — they are the abuse of over-permissioned identities. An IAM role with an unintended permission is more dangerous than an unpatched server.
The infrastructure is API-driven. Every resource is created, modified and destroyed through APIs. That means the control plane itself is attack surface, and misconfigurations propagate at machine speed.
Responsibility is shared. The provider secures the underlying platform; you secure everything you configure within it. Testing must target the customer side of that boundary — and only that side.
The environment is ephemeral. Assets scale up and disappear. A point-in-time asset list is stale almost immediately, so discovery must be continuous throughout the engagement.
The Five Phases of a Cloud Penetration Test
Phase 1: Scoping and Authorisation
Everything begins with defining exactly what will be tested and confirming you are permitted to test it.
What happens in this phase:
- Environment definition — which cloud accounts, subscriptions, projects, regions and services are in scope
- Access model decision — black box (no credentials), grey box (limited credentials simulating a compromised user), or white box (full read access plus architecture documentation)
- Provider policy review — confirming which services can be tested without prior approval, and excluding prohibited techniques such as simulated DDoS, port flooding, and DNS zone walking
- Rules of engagement — testing windows, escalation contacts, prohibited actions, and stop conditions
- Written authorisation — signed permission from an authorised owner of the environment
Why it matters: an unscoped cloud test can breach your provider agreement or disrupt production. Grey-box access almost always produces better results per unit of effort, because it mirrors the realistic scenario of an attacker who has already phished one set of credentials.
Phase 2: Reconnaissance and Asset Discovery
The objective is to build an accurate picture of the cloud estate — including the assets the organisation has forgotten about.
External reconnaissance:
- Subdomain enumeration and DNS analysis to reveal cloud-hosted assets
- Identification of publicly accessible storage (S3 buckets, Azure Blob containers, GCS buckets)
- Discovery of exposed management interfaces, dashboards and APIs
- Certificate transparency log analysis to surface hostnames
- Public code repository and paste-site searches for leaked keys and credentials
Internal / authenticated discovery:
- Full resource inventory across accounts, subscriptions and projects
- Identity inventory — users, groups, roles, service accounts, service principals
- Network topology: VPCs, subnets, peering, transit gateways, security groups
- Data store identification: databases, storage, secrets managers, key vaults
- Serverless and container workload enumeration
Why it matters: most cloud breaches involve an asset nobody knew was exposed — a forgotten development account, a public bucket from a migration, or an orphaned test environment with production credentials.
Phase 3: Identity and Privilege Analysis
This is the heart of cloud penetration testing and where the highest-severity findings almost always emerge.
What is analysed:
- Permission mapping — the effective permissions of every identity, which is often far broader than intended
- Wildcard and overly permissive policies —
Action: *,Resource: *, and their Azure and GCP equivalents - Privilege escalation paths — permissions that allow an identity to grant itself more permissions (for example
iam:PassRolecombined with a compute service, policy-version manipulation, orlambda:UpdateFunctionCodeon a privileged function) - Role assumption chains — where role A can assume role B, which can assume role C, ending at administrative access
- Cross-account and cross-tenant trust — trust relationships that unintentionally allow external principals in
- Service account and managed identity abuse — including token theft from compute metadata endpoints
- Federation and SSO configuration — identity provider trust, conditional access gaps, and MFA coverage
- Credential hygiene — long-lived access keys, unrotated secrets, and credentials committed to code
Why it matters: a single over-permissioned role can convert a low-privilege foothold into full environment compromise without exploiting a single software vulnerability. This phase is what separates genuine cloud penetration testing from configuration scanning.
Phase 4: Exploitation and Lateral Movement
Findings are validated by demonstrating real, controlled exploitation — proving what an attacker could actually achieve.
Typical activity:
- Initial access simulation — exploiting an exposed service, a leaked credential, or a vulnerable application to gain the first foothold
- Metadata service abuse — retrieving instance credentials via the metadata endpoint (a leading cause of major cloud breaches)
- Privilege escalation — executing the paths identified in Phase 3 to confirm they are exploitable, not theoretical
- Lateral movement — pivoting across accounts, subscriptions, VPCs and trust boundaries
- Container and workload testing — Kubernetes RBAC abuse, service account token theft, privileged container breakout to the host node
- Data access validation — demonstrating reachability of sensitive data stores without exfiltrating live data
- Persistence simulation — showing how an attacker would maintain access through backdoor identities, modified trust policies, or scheduled functions
- Detection testing — establishing whether CloudTrail, Azure Activity, GCP Audit Logs and your SOC actually generated alerts
Boundaries observed throughout: no destructive actions, no customer data exfiltration, no impact on availability, and no techniques prohibited by the provider. Proof of concept, not proof of damage.
Phase 5: Reporting and Remediation
The engagement is only valuable if the output can be acted on.
A complete report contains:
- Executive summary — business risk in plain language for leadership
- Attack narrative — the full chain from initial access to impact, showing how individually low-severity issues combined into a critical outcome
- Technical findings — each with evidence, reproduction steps, and affected resources
- Risk ratings based on exploitability, not raw CVSS — a “medium” misconfiguration that enables administrative access is a critical finding in practice
- Remediation guidance — specific configuration changes, not generic advice
- Detection gap analysis — what your logging and monitoring failed to catch
- Strategic recommendations — systemic fixes such as permission-boundary design or guardrail policies
Retesting should follow remediation to confirm fixes are effective and have not introduced new issues.
Cloud Penetration Testing Checklist
Use this to assess coverage — whether you are testing internally or evaluating a provider’s scope.
Identity and access
- [ ] Effective permissions mapped for all identities
- [ ] Privilege escalation paths identified and validated
- [ ] Cross-account and cross-tenant trust relationships reviewed
- [ ] Service accounts and managed identities assessed
- [ ] Federation, SSO and MFA coverage verified
- [ ] Long-lived and unrotated credentials identified
Storage and data
- [ ] All storage services enumerated for public exposure
- [ ] Bucket and container policies and ACLs reviewed
- [ ] Encryption at rest and key management assessed
- [ ] Database exposure and authentication tested
- [ ] Secrets management and hardcoded credential review
Network
- [ ] VPC / VNet segmentation validated
- [ ] Security groups and firewall rules reviewed
- [ ] Peering and transit connections assessed
- [ ] Internet-facing services inventoried
- [ ] Hybrid connectivity to on-premises reviewed
Compute and workloads
- [ ] Instance metadata service configuration tested
- [ ] Container and Kubernetes RBAC assessed
- [ ] Container breakout paths evaluated
- [ ] Serverless function permissions and code reviewed
- [ ] Image supply chain and registry trust reviewed
Logging and detection
- [ ] Audit logging enabled across all accounts and regions
- [ ] Log integrity and retention verified
- [ ] Alerting coverage tested against real attack activity
- [ ] Incident response process validated
Common Cloud Misconfigurations Found During Testing
Ranked by how often they lead to serious compromise:
- Over-permissioned IAM roles — wildcard permissions granted for convenience during a project and never tightened
- Publicly accessible storage — buckets and containers exposed through ACLs or policy, often during migration
- Exposed metadata services — allowing credential theft from a compromised workload through SSRF or code execution
- Hardcoded credentials — access keys in code repositories, container images, environment variables and CI/CD configuration
- Unrestricted security groups — management ports open to
0.0.0.0/0 - Missing or incomplete audit logging — attacker activity that leaves no usable trace
- Weak cross-account trust — external principals permitted by an overly broad trust policy
- Unprotected Kubernetes API servers — anonymous or weakly authenticated cluster access
- Absent MFA on privileged accounts — particularly on break-glass and root accounts
- Orphaned development and test environments — running with production data or production credentials
How to Prepare Your Environment for a Cloud Penetration Test
Preparation directly determines how much value you get from the engagement.
Before testing begins:
- Inventory your accounts — including the ones outside your main organisation structure
- Confirm authorisation — ensure the person approving is authorised to approve
- Enable comprehensive logging — CloudTrail, Azure Activity Logs, GCP Audit Logs across all regions, so testing activity is visible
- Notify your SOC selectively — for a pure detection test, do not notify them; otherwise pre-brief a named contact to prevent a real incident response being triggered
- Prepare read-only access — provisioning a scoped role in advance saves days of engagement time
- Define what is off-limits — production databases, customer data, or availability-critical systems
- Identify your crown jewels — testing should be objective-driven, so name what actually matters
What not to do: do not harden the environment specifically for the test. Testing a temporarily hardened environment produces a report describing a system you do not actually operate.
Tools and Techniques Used in Cloud Penetration Testing
Tooling supports the methodology; it does not replace analyst judgement.
Discovery and enumeration — cloud provider CLIs, ScoutSuite, Prowler, CloudMapper, and custom API-driven enumeration
Identity and privilege analysis — PMapper, Cloudsplaining, IAM policy simulators, and graph-based permission analysis
Exploitation frameworks — Pacu (AWS), MicroBurst and ROADtools (Azure), and purpose-built exploitation scripts
Container and Kubernetes — kube-hunter, kubeaudit, Trivy, and manual RBAC analysis
Secrets discovery — TruffleHog, Gitleaks, and repository and image scanning
The critical caveat: automated tools reliably surface misconfigurations, but they do not chain findings together. Recognising that three individually low-severity issues combine into a full compromise path is manual analysis — and it is where the real value of a penetration test lies.
FAQ - Cloud Pentesting
- How long does a cloud penetration test take?Most engagements run one to three weeks depending on the number of accounts, deployed services, and whether container and application layers are included.
- Should we do black box or grey box testing?Grey box is usually the better investment. Black box spends significant time on discovery that credentialed access provides immediately, and it mirrors the most realistic scenario — an attacker who has already obtained one set of credentials.
- Is cloud penetration testing permitted by AWS, Azure and GCP?Yes, within each provider's stated policy. Customer-initiated testing of your own resources is permitted; techniques affecting shared infrastructure or other tenants are prohibited and require separate authorisation.
- How is this different from a cloud security posture assessment?A posture assessment (CSPM) identifies misconfigurations against a benchmark. A penetration test validates which of those misconfigurations are actually exploitable and chains them into realistic attack paths.
- How often should cloud environments be tested?At least annually, and after any significant architectural change, new account onboarding, or migration. Cloud environments change far faster than on-premises networks.
- Can testing be performed without affecting production?Yes. Testing is rate-limited, destructive techniques are excluded by default, and anything potentially disruptive requires explicit approval and a scheduled window.
Next Steps
Understanding the methodology is the first step. If you are ready to assess your own environment, our team performs cloud penetration testing across AWS, Azure and GCP — scoped to your architecture and aligned to provider testing policies.