What is cloud penetration testing?
Cloud penetration testing is an authorized security assessment of the cloud resources, identities, workloads, and trust relationships you have deployed. It differs from a compliance review, which checks alignment to controls, and from a vulnerability assessment, which mainly enumerates known issues. It also differs from a traditional network penetration test because the highest-value attack paths in cloud environments often stem from IAM, federation, storage access, and workload identity rather than from directly reachable services.
The shared responsibility model is what defines the testing boundary. The provider is responsible for the security of the underlying cloud infrastructure. You’re responsible for the resources, configurations, identities, access rules, and workloads you deploy on top of it. (That includes IAM policies, trust relationships, bucket permissions, service account bindings, CI/CD federation, Kubernetes RBAC, and infrastructure-as-code templates.)
That’s why cloud penetration testing is ultimately a test of your configuration decisions. If a role trust policy, an OIDC condition, or a workload identity mapping creates a path to broader access, that path exists regardless of how well the provider secures its own platform.
Vulnerability Management Buyer's Guide
This buyers guide will not only help you objectively choose or replace a vulnerability management solution, but also provide insights on how your organization can work together to own the responsibility of security as one team.
How cloud pen testing differs from network pen testing
Cloud pen testing is different from network pen testing because the main attack surface is identities and access, not just hosts and ports.
In a traditional network assessment, scope is usually bounded by addresses, subnets, and reachable services. As we’ve seen, in a cloud assessment, scope is more often bounded by accounts, subscriptions, projects, identities, and the trust relationships connecting them.
A single cloud environment can contain hundreds of roles, workload identities, CI/CD integrations, and cross-account or cross-project relationships. As a result, a cloud pen test often starts by mapping identity and access paths rather than by building a port inventory.
Recon (short for reconnaissance) also changes in cloud pen testing because the tester is usually looking for exposed cloud resources, leaked identifiers, weak metadata access, or externally reachable control planes instead of just scanning for open ports. Enumeration then focuses on who can access what, who can assume what, and which identity relationships can be chained.
The result is a different kind of finding. In a network pen test, the finding is usually a reachable service with a specific exploitable weakness. In a cloud pen test, the finding is usually an access path: one identity can assume another, a workload can exchange a service account token for cloud credentials, or an automation role can reach data or admin scope it was never meant to touch.
How a cloud pen test actually works
A cloud pen test works by finding exposed resources, mapping identities and permissions, testing access paths, and then measuring what that access actually allows.
Recon
Cloud recon starts with what’s exposed before privileged access is obtained. That can include public buckets, overly exposed storage endpoints, leaked project or account identifiers in repositories, weakly protected web workloads, and externally reachable Kubernetes or application control planes.
It can also include workload metadata exposure when an application vulnerability such as server-side request forgery (SSRF) allows a request to reach a metadata endpoint. In AWS, for example, the EC2 metadata service at 169.254.169.254 can become the bridge from an application-layer issue to temporary cloud credentials if the instance metadata configuration still permits that path.
Enumeration
Enumeration is where cloud testing becomes explicitly identity-centric. On AWS, that means reviewing roles, policies, trust relationships, and federation conditions. On Azure, it means understanding service principals, managed identities, and federated access rules. On Google Cloud, it involves understanding IAM bindings, service accounts, and workload identity relationships.
In Kubernetes environments, enumeration also includes RBAC, service accounts, projected tokens, and workload identity mappings into the cloud provider. The goal is not just to list objects. It’s to understand which identities can reach which resources, and how one set of permissions could become another.
Exploitation
In cloud environments, the exploitation phase of pen testing validates that a permission chain is actually traversable. An identity may be able to assume a second role. That second role could have broader data access, or may be able to create or reconfigure a service. A workload identity might allow a pod or pipeline to exchange its identity token for cloud credentials.
This is also where federation paths matter. In AWS, OIDC trust policies evaluate claims such as aud and sub before issuing temporary credentials. If those trust conditions are too broad, workflows can receive cloud credentials they were never meant to have.
Post-exploitation
The post-exploitation step of cloud pen testing confirms blast radius. Testers check what a newly reached identity can actually do: read data; assume more roles; create new credentials; modify permissions; or move into sibling accounts, subscriptions, or projects.
The important point is that this activity typically uses legitimate cloud APIs. That’s why defenders need to watch for anomalous identity behavior, unusual role assumption, unexpected token exchange, or sudden bulk access to resources that an identity doesn’t normally touch.
What attack paths do cloud pen tests uncover?
IAM role chaining
IAM role chaining is an access path in which one identity can assume a second role, then use that new session to assume a third role, and continue until the chain reaches high-value data or administrative scope.
The mechanics are straightforward: The current identity needs the ability to call the provider’s role-assumption mechanism, and the target role’s trust configuration must allow that access. On AWS, this usually means a trust-policy relationship plus permission to call sts:AssumeRole on the target role.
By itself, a single role may not look risky, while the full chain is highly exploitable. A low-privilege engineering credential may not be dangerous in isolation. But if it can assume a build role, and that build role can assume a deployment or operations role, the result may still be a path to broad privilege.
OIDC federation abuse
OIDC federation abuse happens when a cloud role trusts an external identity provider too broadly and ends up issuing credentials to workflows or identities that were not meant to receive them.
The mechanics depend on the trust conditions. In AWS, OIDC federation typically uses sts:AssumeRoleWithWebIdentity and evaluates token claims such as audience and subject before issuing temporary credentials. The critical point is that those conditions must be narrowly scoped so that only the intended external identities can request tokens.
Otherwise, there’s risk from overly broad claim matching. If the trust condition is scoped too loosely, a wider set of workflows can receive temporary cloud credentials. And because no long-lived secret is leaked, this path can be missed by secret-scanning assumptions.
Kubernetes workload identity abuse
Kubernetes workload identity abuse happens when a compromised workload uses its service account identity to obtain broader cloud permissions than the application should have.
The mechanics vary by provider, but the pattern is consistent. On Amazon EKS, IAM roles for service accounts (IRSA) associate an IAM role with a Kubernetes service account so pods can make AWS API requests under that role. On GKE, Workload Identity Federation for GKE allows Kubernetes ServiceAccounts to exchange tokens for Google Cloud service account access. On AKS, Microsoft Entra Workload ID uses a projected service account token and webhook mutation so workloads can authenticate to Azure resources without embedded secrets.
The risk is that workload compromise can become cloud compromise if the bound identity is too broad. There is nuance to keep in mind here: Not every pod always has a universally useful token, and not every service account is bridged into cloud IAM. Your focus should be on exploitable attack paths formed from the combination of workload compromise plus an over-permissioned or overly trusted workload identity.
Watch 12-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
What tools do cloud pen tests use?
| Tool | Best fit | What it helps with | What still requires human analysis |
|---|---|---|---|
| Pacu | AWS exploitation-assisted testing | Offensive AWS modules for enumeration, privilege escalation, and credential abuse | Confirming realistic attack paths and their business impact |
| ScoutSuite | Multi-cloud security auditing | Point-in-time posture review and attack-surface visibility across supported clouds | Determining whether findings connect into a real chain |
| Prowler | Broad cloud security assessment | Large check library, security and compliance coverage, reporting | Distinguishing control failures from exploitable paths |
| Peirates | Kubernetes-focused offensive testing | Service account abuse, RBAC exploitation, Kubernetes-to-cloud pivoting | Scoping, validation, and safe execution in real environments |
The larger point remains the same across all of these tools: They can identify promising paths or misconfigurations, but they don’t replace the tester’s job of showing how one issue leads to another.
Do you need permission from AWS, Azure, or Google Cloud for pen testing?
It depends on the scope. In many cases, you don’t need routine pre-approval from the cloud provider, but some providers or testing activities still have service-specific restrictions or additional rules.
AWS’s penetration testing policy says customers may conduct security assessments of permitted services without prior approval, while command-and-control testing requires prior approval and certain activities remain prohibited. AWS publishes a permitted-services list and a prohibited-activities list, including DNS zone walking through Route 53 hosted zones, flooding, S3 bucket takeover, and simulated DoS and DDoS activity.
Microsoft’s Azure penetration testing guidance states that customers don’t need Microsoft’s pre-approval but must follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Microsoft explicitly prohibits activities such as DoS testing, testing tenants or data you do not own, using other people’s credentials, network-intensive traffic generation, phishing, and certain post-exploit actions against Microsoft online services.
Google Cloud’s Cloud Security FAQ states that customers aren’t required to contact Google before penetration testing their projects, provided the testing affects only their own projects and complies with the platform’s acceptable use and terms.
So the practical rule is consistent across providers: Test only what you own and are explicitly authorized to test, stay within provider terms, and don’t assume that “my cloud account” gives you permission to test shared or provider-managed infrastructure however you want.
External penetration testing: A practitioner's guide
External penetration testing assesses the exploitability of public-facing assets. It doesn’t just determine whether vulnerabilities exist; it also indicates whether attackers can actually reach and leverage them.
Leia mais
How long does a cloud pen test stay valid?
A cloud pen test stays valid only for a limited time because the environment can change soon after the test ends.
Simply put, a cloud pen test is a snapshot of an environment that keeps changing. New Terraform modules, new trust policies, new workload identities, new service accounts, and new federation bindings can all create attack paths that didn’t exist during the last engagement. The output should be treated as validated evidence for a moment in time, not as a permanent certification that the environment is safe.
Still, triggered reassessments provide more coverage than a calendar-only mindset. Large IAM changes, new account or project onboarding, major CI/CD federation changes, and new Kubernetes clusters or identity bridges are all good reasons to revisit cloud-specific testing.
What is a penetration testing report? Components and examples
Penetration testing report is a formal document that details vulnerabilities found during a simulated attack, with evidence, risk ratings, and fixes.
Leia mais
What cloud pen tests can’t fully solve
As we’ve seen, manual cloud pen tests provide a necessary baseline, but they are point-in-time snapshots of environments that change daily.
A manual test can’t track new trust relationships after the engagement ends. A developer deploying a new Terraform module the day after the pen tester logs off could introduce an overly permissive IAM role or a dangerous OIDC binding, creating a critical attack path that goes unnoticed until next year's assessment.
This is where continuous, graph-based analysis and automated validation bridge the gap.
The Wiz Security Graph continuously analyzes relationships across your cloud infrastructure, identity, data, code, and runtime context to uncover theoretical attack paths. To move beyond theory, Wiz Red Agent uses automated penetration testing to safely validate those pathways. Instead of waiting for an annual assessment to test an IAM role chain, Red Agent acts as an autonomous attacker. It validates exploitability in real time and provides concrete reproduction steps to prove whether a misconfiguration leads to a breach.
When paired with the Wiz Runtime Sensor for deep threat detection, teams gain continuous visibility into what is exposed, what is actually exploitable, and what is actively under attack.
Wiz doesn’t replace the creative logic of a human penetration test. It automates the discovery and validation of known attack paths. This allows your testing teams to spend their billed hours hunting complex, business-logic vulnerabilities rather than manually tracing standard IAM misconfigurations.
Ready to turn point-in-time penetration testing into continuous cloud exposure management? Book a demo to see how the Wiz Security Graph and Red Agent unify context across infrastructure, identity, and workloads to reveal your true blast radius at machine speed.
Uncover Vulnerabilities Across Your Cloud
Stop chasing alerts—Wiz maps your entire cloud to find and prioritize real risks immediately.
