Cloud Penetration Testing — Find the Attack Paths Your Cloud Configuration Creates
Penetration testing of AWS, Microsoft Azure, Google Cloud and Alibaba Cloud environments by CREST-certified testers. We start where real cloud breaches start — a leaked key, an over-permissive role, a public bucket — and show exactly how far an attacker could get, and what to fix first.
At a Glance
What Is Cloud Penetration Testing — and How Is It Different?
Cloud penetration testing is an authorised, controlled attempt to compromise the workloads, identities and data you run on a public cloud platform — exactly as an attacker would. It differs from a traditional network penetration test in one fundamental way: in the cloud, identity is the perimeter. Most cloud breaches do not begin with an exploited CVE. They begin with a leaked access key, a role that trusts too much, a service account with a basic role, or a storage bucket that was public for a week nobody noticed.
It also differs from a configuration review. Cloud security posture tools — AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center, Alibaba Cloud Security Center — compare your settings to a benchmark and produce a list of deviations. That list is useful, but it does not tell you which deviations an attacker can actually chain together. A penetration test does: it takes the low-privilege identity, finds the path to the sensitive data, and documents each step with evidence.
The result is a prioritised view of real risk. Ten medium-severity misconfigurations that together give an attacker administrative control of your production account matter more than one critical finding that leads nowhere. Only testing reveals that difference.
What We Test on Each Cloud Platform
The service names change between providers; the attack paths do not. Each engagement is scoped to the platform's native services, identity model and management plane.
Amazon Web Services
- IAM privilege-escalation paths (iam:PassRole, policy versioning, AssumeRole chains)
- Over-permissive roles and EC2 instance profiles
- Public S3 buckets and shared EBS or RDS snapshots
- Lambda and API Gateway abuse, function environment secrets
- Instance metadata service exposure (IMDSv1, SSRF to credentials)
- Cross-account trust policies and external IDs
- Security Group and NACL exposure across VPCs and peering
Microsoft Azure
- Entra ID privilege escalation via directory roles and PIM gaps
- App registrations and service principals with Owner rights
- Managed identity abuse from compromised compute
- Storage accounts with anonymous blob or SAS exposure
- Key Vault access policies and RBAC misconfiguration
- NSG, peering and private-endpoint exposure
- Conditional Access gaps for service and break-glass accounts
Google Cloud
- IAM basic roles (Owner, Editor) and default service accounts
- Service-account key leakage and impersonation chains
- Public Cloud Storage buckets and object ACLs
- Compute metadata and instance takeover via startup scripts
- GKE control plane exposure and Workload Identity bindings
- VPC firewall rules open to 0.0.0.0/0
- Organisation policy and project-boundary weaknesses
Alibaba Cloud
- RAM users, policies and AccessKey exposure
- STS role assumption and cross-account trust
- Security groups open to 0.0.0.0/0 on ECS
- Public OSS buckets and bucket policies
- ECS metadata abuse and instance RAM roles
- ActionTrail blind spots and missing SLS retention
- Same CREST methodology; testing follows Alibaba Cloud's authorisation process
EKS, AKS, GKE and ACK Cluster Testing
Managed Kubernetes moves the control plane to the provider but leaves the cluster's identity, network and workload security to you. Cluster testing is scoped alongside the surrounding cloud account so that the paths between them — a pod's node role, a workload identity binding, a registry credential — are tested, not assumed.
Cluster RBAC & Identity
Over-broad ClusterRoleBindings, default service-account tokens, and IAM or Entra ID bindings that let a pod act as the node or the cloud account.
Exposed APIs & Dashboards
Public API servers, anonymous-auth endpoints, kubelet read-only ports, and dashboards reachable from outside the cluster network.
Pod Escape & Node Access
Privileged containers, host-path mounts, hostPID and hostNetwork, and reaching the node's instance metadata from inside a pod.
Secrets Handling
Credentials in environment variables, ConfigMaps and image layers; unencrypted etcd secrets; Secrets Manager or Key Vault access from workloads.
Image Supply Chain
Registry permissions, unsigned or unscanned images, admission-control bypass, and CI/CD runners with cluster-admin credentials.
Network Policy & Segmentation
Missing NetworkPolicies, flat namespaces, and east-west reachability between cardholder-data workloads and everything else.
A 6-Phase Cloud Testing Methodology
Structured around how cloud environments are actually compromised, and delivered within each provider's published testing rules — AWS's permitted-services policy, the Microsoft Cloud Unified Penetration Testing Rules of Engagement, the Google Cloud Acceptable Use Policy, and Alibaba Cloud's authorisation process. Denial-of-service and destructive testing are excluded on every platform.
Phase 1: Scoping and Provider Rules of Engagement
We define the in-scope accounts, subscriptions or projects, the clusters and workloads, and the approach: black box from the internet, grey box with realistic user roles, or assumed breach from a deliberately low-privilege identity. Rules of engagement are documented and signed, and any provider-specific paperwork — AWS approval for activities outside the permitted list, Microsoft's optional notification form, Alibaba Cloud's authorisation request — is completed before testing begins. For PCI DSS environments, scope is aligned with the cardholder data environment your QSA will assess.
Phase 2: Reconnaissance — Outside and Inside
From outside, we map what the internet can see: public IPs, load balancers, storage endpoints, exposed management consoles, DNS records and leaked credentials in code repositories and build logs. From the assumed-breach position, we enumerate what the starting identity can list, read and assume. EIC's AI-assisted platform, Infiltra, accelerates enumeration across large multi-account estates so that testers spend their time on the paths that matter.
Phase 3: Identity and Configuration Analysis
This is where cloud testing differs most from network testing. We build the identity graph — who can assume what, which policies allow privilege escalation, which service accounts have keys, which trust relationships cross account or tenant boundaries — and analyse storage exposure, network segmentation, secrets management and logging coverage. Every finding is validated by hand.
Phase 4: Controlled Exploitation and Privilege Escalation
We attempt to chain findings into complete attack paths: from a leaked key to an assumed role, from the role to a snapshot, from the snapshot to database credentials, from the database to cardholder data. Each step is documented with proof-of-concept evidence. Exploitation is performed against non-production copies where data or configuration could be altered, and nothing is left behind.
Phase 5: Reporting
You receive an Executive Summary for boards, regulators and your QSA, and a Technical Report for the platform and security teams: every finding with CVSS v3.1 scoring, the attack path it belongs to, and the specific fix — a policy statement, a firewall rule, a Conditional Access change — rather than a generic recommendation.
Phase 6: Retest
Within 30 days of report delivery, EIC retests remediated findings at no additional cost and issues an updated report showing the before-and-after state — the evidence your assessor, auditor or acquirer needs.
Cloud Penetration Testing for PCI DSS
A cardholder data environment hosted in the cloud is still a cardholder data environment. PCI DSS Requirement 11.4 requires external and internal penetration testing at least annually and after significant change, and Requirement 11.4.5 requires the segmentation controls that keep out-of-scope systems away from the CDE to be tested. The provider's own Attestation of Compliance covers the provider's infrastructure — it does not cover your VPCs, your roles, or your Kubernetes clusters.
In the cloud, segmentation is built from VPCs and VNets, peering, transit gateways, private endpoints, security groups and network policies — and in practice it is also built from identity, because a role that can reach the CDE is a path into it regardless of network design. EIC's testers hold both CREST certifications and PCI QSA experience, so the test is scoped to the CDE your assessor will validate and the report is written in the language your QSA needs.
For the requirement-by-requirement detail, see PCI DSS penetration testing, and for how each platform maps to the standard, our QSA guides to PCI DSS on AWS, Azure, Google Cloud and Alibaba Cloud, brought together in the PCI DSS in the Cloud hub.
Requirement 11.4 Coverage
External and internal testing of the cloud CDE, application-layer and network-layer, with the methodology documented for your QSA.
Segmentation Testing (11.4.5)
Reachability testing across VPCs, VNets, peering, shared services and identity paths to prove out-of-scope systems cannot reach the CDE.
Evidence Your Assessor Accepts
Findings, remediation and retest results tracked in Complium alongside every other PCI DSS v4.0.1 requirement for Azure- and AWS-hosted environments.
Your Cloud Penetration Test Report
Written for two audiences: executives and assessors who need to understand risk, and platform teams who need to fix it.
Report Structure
Executive Summary
Overall risk rating, the attack paths that matter, business impact and strategic recommendations — for boards, regulators and your QSA.
Attack Path Narratives
Each chain from starting position to impact, step by step, with the identity, permission or misconfiguration that enabled every hop.
Technical Findings
Every vulnerability with CVSS v3.1 score, affected resource identifiers, proof-of-concept evidence and the exact remediation.
Remediation Roadmap
Risk-prioritised plan that fixes the paths first, then the individual findings, with effort estimates for platform teams.
Methodology & Rules of Engagement
Scope, approach, provider authorisations, dates, tools and frameworks — the appendix your auditor will ask for.
Retest Results
Before-and-after status for every remediated finding, issued as an updated report.
Infiltra and Complium
Infiltra
EIC's AI-assisted testing platform handles enumeration across large multi-account cloud estates and surfaces candidate attack paths for testers to validate. Every finding in your report has been confirmed and exploited by a person; Infiltra makes the coverage broader and the engagement faster.
About Infiltra →Complium
For PCI DSS engagements, penetration-test findings, remediation status and retest evidence are tracked in Complium against Requirement 11.4 alongside every other PCI DSS v4.0.1 requirement. Complium's read-only integrations with Microsoft Azure and AWS collect the identity, logging and configuration evidence the same assessment needs.
About Complium →Why Choose EIC for Cloud Penetration Testing?
CREST Accredited and PCI QSA
Testers who hold CREST certifications and work alongside EIC's PCI QSAs. Your cloud test is scoped to the CDE your assessor will validate, and the report satisfies PCI DSS Requirement 11.4 without a second engagement.
Payment System Specialists
Cloud-hosted payment gateways, core banking, wallets and card-processing platforms. We understand where cardholder data flows in a cloud architecture and test the paths to it.
AI-Assisted Coverage
Infiltra accelerates enumeration and attack-path discovery across large estates, so human testers spend their time on exploitation and validation rather than inventory.
Reports That Drive Action
Attack narratives for executives, resource-level fixes for engineers. Every finding names the policy, rule or setting to change — and the retest is included.
Provider Rules, Handled
AWS permitted-services policy, Microsoft Rules of Engagement, Google Cloud Acceptable Use Policy, Alibaba Cloud authorisation — the paperwork and the boundaries are part of scoping, not an afterthought.
Zero Client Breaches Since 2016
No organisation secured by EIC has suffered a breach. Cloud testing is one part of a broader engagement that helps you build a posture that prevents compromise.
Cloud Penetration Testing FAQs
Ready to Test Your Cloud Environment?
Schedule a free scoping call with a CREST-certified tester. We'll map your accounts, subscriptions and clusters, recommend the right approach, and send a fixed-price proposal within 24 hours.
Explore More
Penetration Testing
Web application, network, mobile and red team testing — the full CREST-accredited service.
PCI DSS Penetration Testing
Requirement 11.4 explained — annual and post-change testing, segmentation testing, and what your QSA expects to see.
PCI DSS in the Cloud
AWS, Azure, Google Cloud and Alibaba Cloud compared — shared responsibility, scoping, and the findings QSAs see most.
PCI DSS on Kubernetes
Cluster scoping, NetworkPolicy and service-mesh segmentation, RBAC, secrets, images and audit logs for EKS, AKS, GKE and ACK.
Infiltra
The AI-assisted testing platform behind every EIC engagement — broader coverage between annual tests.
Complium
Track pen test findings and retest evidence alongside every other PCI DSS v4.0.1 requirement.