Cloud Penetration Testing
AWS, Azure and GCP — IAM misconfiguration, exposed services, container and Kubernetes flaws, and SSRF to metadata, mapped to your cloud estate.
Cloud penetration testing is an assessment of an AWS, Azure or GCP environment — identity, network exposure, storage, compute and container workloads — to find exploitable misconfigurations. Passeca tests IAM privilege-escalation paths, exposed services and buckets, SSRF to metadata, and Kubernetes and container escape routes, then chains them into the realistic path an attacker takes to reach data or take over an account.
What concrete vulnerabilities do we test for?
Cloud risk is identity-centric. These are the misconfiguration classes that lead to data exposure and account takeover.
IAM misconfiguration
Over-privileged roles, wildcard actions, long-lived access keys, missing MFA on privileged users, and trust policies that allow assumed roles from any account.
Exposed services & storage
Public S3 buckets and blob containers, management ports (SSH, RDP, databases) open to the internet, and snapshots left world-readable.
Container & Kubernetes
RBAC over-privilege, privileged containers, exposed kube-apiserver, hostPath mounts, and service-account token abuse for cluster takeover.
SSRF to cloud metadata
Application flaws that let an attacker reach the cloud metadata endpoint (169.254.169.254) and steal instance credentials to pivot.
Network & segmentation
Security groups and firewall rules allowing unintended east-west movement, public subnets hosting private services, and VPC peering exposure.
Secrets management
Secrets in environment variables, images or code; secrets managers with over-broad access; and leaked credentials harvested from CI logs.
Methodology for cloud estates
A hybrid of external attacker simulation and identity-centric configuration review, within each provider's permitted-testing rules.
We combine external attack-surface enumeration (exposed services, storage, management ports) with an authenticated configuration review of IAM, network, storage and compute. Identity paths — over-privilege, trust-policy abuse, credential exposure — are mapped and walked to determine how far an attacker can move.
For container and Kubernetes estates we assess RBAC, pod security, admission control, service-account token use and the kube-apiserver exposure. Application-layer SSRF is tested for its potential to reach the cloud metadata service. Every engagement respects the cloud provider's terms of service and agreed rules of engagement.
Example findings from real (anonymised) cloud tests
Cloud findings are typically chained attack paths — one misconfig enabling the next.
Public S3 bucket exposed customer documents
A storage bucket configured for public read allowed anyone with the URL to enumerate and download customer files stored in the cloud.
Over-privileged role allowed privilege escalation to account takeover
An IAM role with permission to create access keys for any user was assumed by a compromised low-privilege identity, enabling full account takeover.
SSRF reached instance metadata, yielding cloud credentials
An application SSRF fetched the cloud metadata service and returned temporary credentials, which were used to access other resources in the account.
Privileged container escaped to the host on an EKS cluster
A container running privileged with a hostPath mount allowed an attacker to break out to the node and access the cluster's node credentials.
Findings are anonymised and paraphrased. Specific reproduction steps are reserved for the engagement report.
How long does a cloud pentest take, and what does it cost?
Driven by account and region count, workload diversity, Kubernetes scope, and whether the test is black-box or authenticated.
| Engagement size | Typical duration | Price band |
|---|---|---|
| Focused — single account / region | 1 week | Price on request |
| Standard — multi-account + K8s | 1–2 weeks | Price on request |
| Complex — multi-cloud estate | 2+ weeks | Price on request |
Use the free pentest scoping tool for a precise estimate.
What's in the report?
- Executive summary — cloud risk in business terms.
- Chained attack paths — the route from initial foothold to data or account takeover.
- Graded findings — per-resource, with CVSS and business impact.
- Remediation guidance — least-privilege IAM, SCPs, network hardening, pod security.
- Compliance mapping — PCI DSS, ISO 27001, SOC 2, DORA, NIS2, BSI C5.
- Remediation retest — fixes retested within the engagement window.
Which compliance requirements does this satisfy?
| Framework | Relevant requirement | How the pentest maps |
|---|---|---|
| PCI DSS | Req. 11.4 | Penetration testing of cloud-hosted cardholder-data environments |
| ISO 27001:2022 | A.8.20 / A.8.29 | Network security & security testing in development and acceptance |
| SOC 2 | CC4.1 / CC6 | Monitoring & logical access |
| DORA | Art. 24–25 | Digital operational resilience testing |
| NIS2 | Art. 21 | Risk-based security measures, evidenced |
Cloud pentest, answered
Legality, access models, Kubernetes, and compliance for cloud testing.
What is cloud penetration testing?
Can you legally penetration test AWS, Azure and GCP?
How is cloud testing different from network or web testing?
What access do you need for a cloud pentest?
Do you test Kubernetes and containers?
Which compliance requirements does cloud pentest satisfy?
How long does a cloud pentest take?
Tell us your accounts and regions — get a day estimate
The free pentest scoping tool converts your cloud estate into a day estimate and price band, then hands to Passeca's offensive-security team for a precise quote.
Related