Cloud Penetration Testing Requires a Different Playbook
The testers arrive with the standard toolkit. They run network scans. They look for open ports on EC2 instances. They find a few, probe the services, and hand back a report that looks like what they would have produced for an on-premises engagement.
They missed most of the attack surface. And so did you, because the scope was defined the same way it would be for a traditional network test.
Cloud penetration testing is a meaningfully different discipline from what most organizations buy when they commission an assessment that happens to include cloud systems. The attack surface is API-driven, not network-driven. The path to the equivalent of domain admin runs through IAM, not Kerberos. The most interesting credentials do not live on a domain controller. And the most impactful findings are almost never the ones a port scanner surfaces.
Why Port Scanning Misses the Point
In a traditional network environment, the attacker gets a foothold, runs credential attacks, moves laterally through SMB and Kerberos, and eventually reaches a privileged position. Network topology shapes everything. Control over systems comes from controlling network identity.
Cloud environments are API-driven. Every action - provisioning a server, reading from storage, creating a new identity - gets executed through API calls authenticated by IAM credentials. Whoever holds the right credentials controls the environment. The network is almost irrelevant compared to that.
This means finding an open port is far less interesting than finding a path to IAM credentials and understanding what those credentials can do. An instance metadata service endpoint does not show up on a port scan. An overpermissioned Lambda execution role does not have a CVE. But either one can be the start of a path to full administrative access over your cloud account.
The Metadata Service Attack Chain
The most reliable attack chain in cloud environments runs through SSRF to the instance metadata service. Here is how it works.
A web application running on an EC2 instance has a server-side request forgery vulnerability: it will fetch arbitrary URLs when told to. The attacker points it at 169.254.169.254, the AWS instance metadata endpoint. That service returns, among other things, the temporary IAM credentials associated with the instance's execution role.
The attacker now has IAM credentials. What those credentials can do determines everything that follows. In well-configured environments, an EC2 instance role has only the permissions the instance needs to function. In practice, instance roles accumulate permissions over their lifetimes, the same way service accounts in Active Directory do. A role that started as "read from this specific S3 bucket" has, through operational convenience and missed cleanup, grown into something considerably more permissive.
From IAM credentials, the next step is enumeration: what can these credentials actually do? Tools like Pacu (the AWS exploitation framework) and manual API calls replace the BloodHound phase of a traditional internal assessment. The questions are different, but the structure is familiar: start from a known position, find the paths that lead somewhere more valuable.
IAM Is the New Kerberos
In Active Directory, the path to domain admin runs through service accounts and delegation settings. In cloud environments, the equivalent path runs through IAM policy combinations.
The privilege escalation techniques are well-documented and appear in most cloud penetration testing engagements. An IAM user or role that can create new IAM policies can grant itself administrative access. A role that can pass roles to EC2 instances can spin up a new instance with an administrative role attached and use it as a stepping stone. A role that can update Lambda function configurations can redirect a function at attacker-controlled code and inherit the function's execution role, which may be considerably more permissive than the attacker's starting position.
None of these exploit software vulnerabilities. They are logical consequences of specific IAM permission combinations that nobody reviewed carefully enough. Cloud IAM policy analysis is now a standard component of any serious cloud penetration test for exactly this reason.
What Good Scope Actually Covers
The most common failure in cloud assessment scoping is treating it like a network test with cloud-flavored systems. Traditional scope conversations cover IP ranges and specific applications. That framing misses most of what matters.
Useful cloud scoping addresses which AWS accounts (or Azure subscriptions, or GCP projects) are in scope, what starting access level the test assumes (unauthenticated, with a standard IAM user, with a compromised developer credential), whether the external attack surface is included, and whether cross-account trust relationships are in scope.
That last point matters more than most buyers realize. Cloud environments commonly have trust relationships between accounts: a production account that trusts a development account for deployment pipelines, a centralized logging account, a security tooling account with read access across the organization. These relationships are intentional. They are also attack paths, and they frequently have weaker security posture on the trusted side than on the account holding the most sensitive assets.
What the Findings List Actually Looks Like
Unpatched CVEs are rare in cloud assessment reports because managed cloud services reduce the footprint of self-hosted software. What appears instead is configuration debt.
Wildcard IAM policies are common and dangerous. A policy granting "s3:*" on "*" means the attached identity can perform any S3 operation on any bucket in the account, including deleting the bucket holding backup data. These policies exist because they were faster to write and nobody has reviewed them since.
Secrets in EC2 user data and Lambda environment variables appear on nearly every engagement. These configuration fields are readable by anyone with the right IAM permissions, and those permissions are frequently broader than intended. It is the same problem as credentials in version control, just one layer further in.
Overpermissioned cross-account roles without external ID requirements are a consistent finding. A role trusting an external account ID should require an external ID in the trust policy. Without it, confused deputy attacks become straightforward and well-documented.
The Question to Ask Before You Sign Anything
Ask your testing firm how they scope cloud assessments and what cloud-specific methodology they use. If the answer is "we include cloud systems in our network test," you are getting a surface-level look at the wrong attack surface.
The most impactful findings come from following the IAM path, not the port scan. A methodology that treats cloud as network-plus-some-extra-steps will find network things. The IAM privilege escalation chain that could hand someone your entire account will still be there when the report is filed.
The playbook is different. Buy an engagement designed for the actual environment.