Cloud penetration testing: AWS, Azure & GCP — misconfigurations, IAM, and the app on top
Most cloud breaches aren't exotic zero-days — they're misconfigurations: a public S3 bucket, an over-permissioned IAM role, a security group open to the world, an exposed metadata endpoint. Cloud penetration testing finds the configuration and identity weaknesses that scanners miss and chains them with application flaws to show real impact. Matproof Sentinel combines cloud configuration testing (Prowler-based) with full web, API, and authenticated testing — audit-ready, with proof-of-exploit, from €149 and a free scan to start.
Why cloud penetration testing is different from a traditional pentest
Traditional penetration testing assumes a network perimeter you can scan. The cloud doesn't work that way: your attack surface is defined by identity (IAM), configuration (security groups, bucket policies, service settings), and the managed services you compose — and the most damaging attacks chain a small misconfiguration into full account compromise. A single over-permissioned role, a publicly readable storage bucket, an exposed instance metadata service (the SSRF-to-credentials path behind several headline breaches), or a misconfigured serverless function can take an attacker from 'foothold' to 'read the whole environment'. Cloud penetration testing therefore tests two layers together: the cloud control plane (IAM, configuration, exposed services across AWS, Azure, and GCP) and the application data plane (the web apps, APIs, and authenticated surface running on top). Testing them in isolation misses the chains — e.g. an app SSRF that reaches the metadata endpoint and harvests cloud credentials. It's also increasingly expected evidence: SOC 2, ISO 27001, PCI-DSS, and cyber insurers all want assurance that your cloud environment resists attack, not just that a CSPM tool flagged some findings.
- Identity-first: IAM privilege escalation and over-permissioned roles are the cloud's primary attack path — not open ports.
- Misconfiguration, not zero-days: public buckets, open security groups, and exposed services cause most cloud breaches.
- The chains matter: an app SSRF → instance metadata → cloud credentials is invisible if you test config and app separately.
- Expected as evidence: SOC 2, ISO 27001, PCI-DSS, and cyber insurers want proof your cloud resists attack, beyond a CSPM report.
What a cloud penetration test should cover
- IAM & privilege escalation: over-permissioned roles and users, dangerous policy combinations, assumable roles, and paths from a low-privilege identity to admin (across AWS, Azure, GCP).
- Exposed storage & data: public or misconfigured S3 / Azure Blob / GCS buckets, overly broad ACLs, and unencrypted sensitive data at rest.
- Network & service exposure: security groups / NSGs open to the internet, exposed databases and management ports, and public-facing services that should be private.
- Instance metadata & SSRF chains: testing whether an application SSRF can reach the cloud metadata endpoint (IMDSv1) and harvest temporary credentials — a leading cloud-breach vector.
- Serverless & container security: misconfigured Lambda/Functions, over-broad execution roles, exposed container registries, and Kubernetes RBAC weaknesses.
- Cloud configuration baseline (Prowler): hundreds of CIS-benchmark and provider-best-practice checks across the account, correlated with the exploit findings.
- The application on top: full OWASP Top 10 and OWASP API Security Top 10 testing of the web apps and APIs running in the cloud, including authenticated (grey-box) testing.
Sample finding
App SSRF reaches the instance metadata service and harvests cloud credentials (full-account-compromise chain)
A server-side request forgery in an image-fetch feature allowed an attacker to make the application request arbitrary internal URLs. The instance was running IMDSv1, so the tester pointed the SSRF at the cloud metadata endpoint and retrieved the temporary IAM credentials attached to the instance role. Because that role was over-permissioned (it had broad read access 'for convenience'), those credentials granted read access to storage buckets containing customer data across the account. A single application-layer bug therefore chained, through a cloud misconfiguration, into an environment-wide data exposure — the exact pattern behind several well-known cloud breaches, and one that a config-only or app-only test would have missed.
Fix: Enforce IMDSv2 (token-based) on all instances and disable IMDSv1; fix the SSRF by all-listing outbound destinations and blocking link-local/metadata addresses (169.254.169.254). Apply least privilege to the instance role so it can only access what the workload needs. Re-test the SSRF and the credential path to confirm the chain is broken.
Reference: OWASP A10:2021 Server-Side Request Forgery · CWE-918 SSRF · CWE-269 Improper Privilege Management · MITRE ATT&CK T1552.005 (Cloud Instance Metadata API)
Cloud penetration testing vs. CSPM scanning
| — | Free scan | Matproof Sentinel | Traditional consultancy |
|---|---|---|---|
| Automated scan engine | ✓ (3-min preview) | ✓ Full scan | ✗ Manual only |
| OWASP Top 10 coverage | Partial | ✓ Complete | ✓ Complete |
| Proof-of-exploit evidence | ✗ | ✓ Per finding | ✓ Per finding |
| Regulatory mapping (DORA/NIS2/ISO 27001) | ✗ | ✓ Automated | ✓ Manual |
| Audit-ready PDF report | ✗ | ✓ Instant | ✓ 2–4 weeks delivery |
| Continuous / recurring scans | ✗ | ✓ Per deploy | ✗ Annual engagement |
| Time to first result | ~3 min | ~30 min full scan | 2–4 weeks |
| Price | €0 | From €149 | €8,000–€25,000 |
| Source code review (SAST) | ✗ | ✓ On Growth plan | ✓ Scoped engagement |
| API testing (REST/GraphQL) | ✗ | ✓ Automated | ✓ Manual |
Matproof Sentinel for cloud penetration testing
- 1 full pentest scan
- AI-prioritized findings with CVSS 3.1
- Proof-of-exploit per finding
- Audit-ready PDF report
- Regulatory mapping (DORA, NIS2, ISO 27001)
- Unlimited scans (up to 3 domains)
- Continuous monitoring
- CI/CD integration (GitHub, GitLab)
- All regulatory mappings
- Priority support
- Unlimited scans + domains
- Authenticated / White-Box testing
- API & cloud infrastructure tests
- Dedicated security account manager
- 24h SLA response time
Frequently asked questions about cloud penetration testing
What is cloud penetration testing?
Cloud penetration testing is the active assessment of your cloud environment (AWS, Azure, GCP) for exploitable weaknesses — focusing on identity (IAM), configuration (storage, network, services), and the chains that turn a small misconfiguration into account-wide compromise — together with the web apps and APIs running on top. Unlike a CSPM/posture tool that lists misconfigurations by signature, a penetration test exploits and chains them to demonstrate real impact.
How is cloud penetration testing different from CSPM or a vulnerability scan?
A CSPM or scanner identifies misconfigurations and known issues by checking settings against benchmarks — useful, but it produces a long list without proving impact, and it can't see attack chains (e.g. app SSRF → metadata → credentials). A penetration test exploits the findings, chains them across the config and application layers, and shows what an attacker could actually achieve. Matproof Sentinel does both: a Prowler-based configuration baseline plus exploit-validated penetration testing.
Do I need cloud provider permission to run a penetration test?
The major providers (AWS, Azure, GCP) permit customer-initiated penetration testing of your own resources without prior approval for most services, subject to their testing policies (certain activities like denial-of-service remain prohibited). You should still confirm scope against the current provider policy and ensure you own or are authorised to test the target environment. Matproof Sentinel's testing stays within these non-destructive bounds by default (read-only authenticated mode).
Which clouds does Matproof Sentinel cover?
AWS, Azure, and GCP for the configuration and identity baseline (Prowler-based), plus full web-application and API testing of whatever runs on top, regardless of provider. The most damaging findings usually come from correlating the two — an application flaw that reaches a cloud misconfiguration — which is why Sentinel tests them together rather than in isolation.
Does cloud penetration testing help with SOC 2, ISO 27001, or cyber insurance?
Yes. Auditors and insurers increasingly want assurance that your cloud environment resists attack, not just that a posture tool flagged findings. Sentinel's report maps cloud findings to recognised frameworks (CIS Benchmarks, OWASP, SOC 2, ISO 27001) with CVSS ratings, proof-of-exploit, and remediation tracking — usable directly as audit and insurance-application evidence.
Go deeper — related blog articles
Start your cloud penetration test
Find the IAM, configuration, and SSRF-to-credentials chains that scanners miss — across AWS, Azure, and GCP, plus the app on top. Matproof Sentinel delivers proof-of-exploit findings and audit-ready reports, from €149, with a free scan to start.
Run a free pentest scan