Cloud Testing Is Not Network Testing
Cloud penetration testing follows the same goal as any other assessment — prove what an attacker could achieve — but the methodology is different. In the cloud, most compromise comes not from unpatched software but from misconfiguration and identity: an overly permissive role, a public storage bucket, an exposed secret. Effective cloud testing therefore blends configuration review with active exploitation. This article walks through the methodology behind a cloud penetration test across AWS, Azure, and GCP.
Phase 1: Scoping and the Shared Responsibility Model
Cloud scoping starts with a crucial distinction: the shared responsibility model. The provider secures the underlying infrastructure; the customer is responsible for configuration, identity, data, and access. A cloud penetration test focuses on the customer’s side of that line. Scoping defines which accounts, subscriptions, or projects are in scope, what level of access the tester is granted (from anonymous external through to an authenticated low-privilege identity), and which provider policies must be respected.
Phase 2: Configuration Review
The tester reviews the environment’s configuration against cloud security best practices and provider benchmarks (such as the CIS Benchmarks). This covers identity and access management policies, storage permissions, network controls such as security groups and firewall rules, logging and monitoring coverage, encryption settings, and exposed management surfaces. Misconfigurations identified here become the candidates for the active testing that follows.
Phase 3: Identity and Access Attacks
Identity is the new perimeter in the cloud, so this phase is central. The tester examines how identities are granted and used:
- Over-permissioned roles and policies — identities with far more access than they need.
- Exposed credentials and secrets — keys and tokens leaked in code, metadata, or storage.
- Weak or missing MFA on privileged identities.
- Trust and federation issues between accounts, tenants, or external providers.
These weaknesses are the cloud equivalent of weak passwords on an internal network — the most reliable route to escalation.
Phase 4: Privilege Escalation
Using an initial identity, the tester attempts to escalate privileges within the cloud environment — abusing permissive policies, role-assumption paths, and service misconfigurations to gain broader control. Cloud privilege escalation often follows non-obvious chains (one service granting access to another), and mapping these paths is where deep cloud expertise matters most.
Phase 5: Lateral Movement and Data Exposure
With elevated privileges, the tester demonstrates how an attacker would move through the environment and reach sensitive data — accessing storage, databases, secrets managers, and compute workloads. Where the environment includes serverless functions and containers, those are assessed too, since they frequently run with broad permissions and represent a fast path to escalation. The goal is to show, concretely, what data and systems a realistic attacker could reach.
Phase 6: Impact and Reporting
The tester documents the realistic impact — what was accessible, what could have been disrupted, and how the chain unfolded — within agreed limits. The report includes an executive summary, technical findings with severity and reproduction steps mapped back to specific cloud resources and IAM principals, evidence, and prioritized remediation. Because cloud findings are configuration-driven, remediation guidance is usually concrete and quick to apply once it is clearly identified.
From Methodology to Engagement
A strong cloud methodology turns a sprawling, configuration-heavy environment into a clear picture of real risk. Learn more about our cloud penetration testing service, or see how cloud testing fits alongside external and internal network testing for organizations running hybrid infrastructure. To scope an engagement, contact us.
Related Reading
- External network penetration testing methodology
- Internal network penetration testing methodology
- Cloud penetration testing methodology
- Thick client and desktop application penetration testing
- AI and LLM application penetration testing
- Our published CVE vulnerability research
DarkPoint Security publishes original vulnerability research. Every engagement is performed in-house in Canada by OSCP-certified consultants, and remediation retesting is included.
Frequently Asked Questions
Do we need permission from AWS, Azure or GCP before testing?
The major providers permit customer testing of your own resources without prior approval, subject to their published rules of engagement. Denial of service testing generally remains prohibited without separate arrangement. Always check the current policy for your provider and any managed services in scope.
What does the shared responsibility model mean for testing scope?
You can test what you configure and control: your identity configuration, storage permissions, compute instances, network rules and applications. You cannot test the provider's underlying platform. Most real cloud findings sit on the customer side of that line, in identity and misconfiguration rather than in provider vulnerabilities.
What are the most common findings in a cloud penetration test?
Over-permissioned identity roles and unused credentials, storage exposed more broadly than intended, missing or bypassable network restrictions, secrets committed into infrastructure code or environment variables, and privilege escalation paths that let a low-privilege role reach an administrative one.
How is cloud penetration testing different from a configuration review?
A configuration review compares your settings against a benchmark and reports drift. A penetration test chains the weaknesses together to prove what an attacker could actually reach. The review tells you a role is over-permissioned; the test shows what that role gets you.