Cloud Configuration Analysis in Modern Penetration Testing

Cloud adoption has moved the main attack surface away from network perimeters and open ports. It now sits in identity policies, IAM roles, storage permissions, and the trust relationships that connect one cloud service to another. Most penetration testing practice still hasn't caught up to that shift.

Older infrastructure testing grew up around a fixed perimeter. A tester would scan ports, find unpatched software, and check whether a firewall held. That picture doesn't fit cloud environments, because there's often no perimeter firewall standing between an attacker and the thing worth stealing. The wall itself is gone from the picture.

What decides how bad a breach gets in a cloud account is the configuration layer: the IAM role attached to a service, the bucket policy sitting next to it, the security group rule that lets it talk to something it shouldn't, whether the metadata service is reachable from a place it shouldn't be, rather than whether that service is running an old, vulnerable version. Two accounts can run the exact same vulnerable software and end up with wildly different blast radii, purely because one has tight IAM boundaries and the other doesn't.

Part of this comes from how cloud providers split up responsibility. The provider secures the physical infrastructure, the hypervisor, the data centers. The customer is on the hook for configuring identity, storage, and network controls correctly on top of that.

Cloud environments also behave differently in ways that change what "attack surface" even means. Resources come and go constantly: EC2 instances, Lambda functions, and Kubernetes pods spin up and shut down on their own schedules, so a weakness that exists at 2pm might simply not exist by 3pm. Multi-account and multi-region setups create paths between accounts and regions that never existed inside a single data center. Infrastructure-as-Code tools like Terraform and AWS CloudFormation turn templates into attack surface themselves: bake a misconfiguration into a template, and it gets copied into every environment that template provisions. And the thing standing in for a firewall now is identity: IAM roles, temporary tokens issued through AWS STS, federated identity through OAuth and OpenID Connect, and role-based access enforced through IAM policy documents. Authentication and authorization have become the real perimeter.

What a cloud penetration test covers, versus what most teams assume it does

A cloud penetration test and a web application penetration test overlap at the edges but test two different things entirely, and treating them as interchangeable leaves real gaps. A web app test checks what a logged-in user, or an attacker pretending to be one, can do inside an application. A cloud test checks what an attacker can do once they've gotten a foothold, a single compromised service, instance, or stolen credential, inside the broader cloud environment, and how far that foothold carries them.

IAM privilege escalation, credential theft from the metadata service, and cross-account access abuse live entirely outside the boundaries a web app test usually draws.

A proper cloud test covers ground a web app test never touches. It looks at IAM and privilege escalation: roles with too much permission, policies written with wildcards, escalation paths built from one role chaining into another, stale credentials nobody revoked, privileged accounts with no MFA. It checks storage: S3 buckets, Azure Blob containers, or GCS buckets that are publicly readable or writable, bucket policies that let another account reach in, data sitting unencrypted at rest. It tests the metadata service directly, checking whether a server-side request forgery flaw in an application can reach the instance metadata endpoint and pull out IAM role credentials, with every step backed by the actual commands run, the API calls made, and screenshots showing the lateral movement happened. It examines serverless and container risk: Lambda or Azure Function roles with too much reach, secrets hardcoded into environment variables, container registries set up loosely, Kubernetes RBAC rules that grant more than they should. It looks at how services trust each other, since lateral movement often has little to do with the application layer. And it checks whether logging would even catch any of this, confirming that CloudTrail, Azure's Activity Log inside Azure Monitor, and GCP's Cloud Audit Logs are actually capturing API calls coming from workloads that exist for minutes at a time.

Each cloud provider sets its own rules for what you can test without giving notice first. Azure permits testing of a customer's own resources without advance notification for most test types, and Microsoft's Penetration Testing Rules of Engagement block anything that generates excessive network traffic, like aggressive fuzzing, regardless of notification status. A testing provider worth hiring scopes every engagement against these rules as a matter of course, and if Terms of Service compliance hasn't come up by the time scoping conversations start, that's a fair thing to ask about directly.

Why a misconfiguration scan is not a penetration test

Running a Cloud Security Posture Management tool against an account and handing over the resulting report is not the same thing as a penetration test. A CSPM scan is good at spotting known misconfiguration patterns across a large environment fast, but it doesn't test whether those patterns can actually be exploited, doesn't chain separate findings into a real attack path, and can't surface the trust relationships specific to an organization that only come from someone actually digging into how the environment is wired together.

A misconfiguration review tells an organization what's set up wrong. A penetration test tells that organization what an attacker could actually do with it once they found it.

The two sit apart structurally. A misconfiguration review runs through automated CSPM tooling and configuration analysis, flags policies that grant too much access, stops short of simulating any lateral movement, and ends up as a list of individual findings with no connective tissue between them. Some auditors accept this as compliance evidence. A cloud penetration test puts a human in the loop simulating an active attacker, actually exploiting IAM escalation paths up to root or admin access, testing SSRF against both IMDSv1 and IMDSv2 and proving credential extraction when it works, and chaining individual findings into a realistic path from first foothold to final impact. This kind of report gets accepted universally as compliance evidence, not just by some auditors.

The gap between the two is clearest in a specific failure pattern. A CSPM tool can flag a publicly accessible S3 bucket without any trouble. What it can't tell anyone is whether the data sitting in that bucket, combined with an over-permissioned IAM role attached to some Lambda function three services away, actually builds a path to exfiltrate data out of a production database. Seeing that chain takes a person who understands how the whole environment fits together, not a scanner running a rule set.

Both kinds of assessment have a place. A misconfiguration review makes a sensible baseline to run regularly. A penetration test is what's actually required for real compliance evidence and an honest picture of risk. The trouble starts when organizations blur the two together and walk away thinking they've done the harder, more valuable work when what they've actually done is the easier, automated version of it.

The Cloud Penetration Testing Methodology

A cloud penetration test done properly moves through a defined sequence: asset discovery, IAM analysis, exploit chaining, lateral movement, and finally documented proof that the exploit worked. Each phase builds on what came before it, and the end result is something an auditor can evaluate and an engineering team can actually fix.

Everything starts with scoping and authorization. The exact boundaries of the account, subscription, or project under test get nailed down first. Provider-specific authorization requirements get confirmed. The team decides up front whether testing covers only what the customer manages or extends into reviewing provider-managed settings too, and all of this gets locked into a signed statement of work with whoever actually owns the account.

From there, the work moves into inventory mapping and reconnaissance. Every cloud asset gets identified and cataloged: compute like EC2 instances and Lambda functions, storage like S3 buckets and EBS volumes, databases like RDS and DynamoDB, network components like VPCs and security groups, and every IAM entity, meaning users, roles, and policies. API endpoints get documented and the relationships between services get mapped, often with tools like CloudMapper, which generates visual diagrams of network topology. On Azure, this phase starts by authenticating and confirming the active subscription context before anything gets enumerated. On GCP, it starts by listing authenticated accounts and the projects they can reach, to establish the starting point.

Next comes the configuration review itself. IAM policies get examined for permissions that go further than they need to. Storage bucket permissions get checked line by line. Security group rules get reviewed. Serverless function execution roles get assessed for how much they can actually touch. Infrastructure-as-Code templates get audited too, since a misconfiguration baked into a Terraform or CloudFormation template doesn't stay contained, it propagates into every environment that template stands up.

IAM and privilege escalation analysis follows, usually with tools built for the job: Pacu for AWS-specific exploitation, ScoutSuite for auditing security posture across multiple cloud providers at once. This phase maps out escalation paths, tests whether one role can chain into another with more permission than it started with, flags stale credentials that still carry access nobody needs anymore, and checks whether MFA is actually enforced on the accounts that matter most.

Then comes active exploitation and lateral movement, the phase where findings turn into proof. If an application shows signs of SSRF, the test checks whether that flaw can reach the instance metadata endpoint, pull IAM role credentials out of it, and use those credentials to touch production resources, with every step backed by the actual commands, API calls, and screenshots that show it happened. AWS's IMDSv2 closes off the most direct version of this attack by requiring a session token before the metadata service responds, but plenty of environments are still running the older IMDSv1, so part of this phase is simply confirming which version is active and whether it's enforced. From there, testing simulates what an attacker holding that initial foothold can reach next: other accounts, exfiltration paths, ways to maintain access.

Reporting closes the engagement. Findings get presented as chained attack paths rather than a stack of disconnected configuration flags, every critical finding comes with working exploit evidence attached, and the final report is structured so it can serve directly as evidence for SOC 2 and ISO 27001 audits.

The Need for Whitebox Access to Map the Full Attack Chain

Without direct access to cloud configurations, IAM policy documents, Infrastructure-as-Code templates, and source code, a tester only sees the attack surface from outside looking in. That outside view misses the trust relationships specific to the organization, the particular combinations of permissions, and the logic-level paths that turn one misconfiguration into an actual breach.

An external tester working without inside access can find what's publicly exposed well enough, like an open storage bucket or an endpoint reachable from the internet. That chain only becomes visible with access to the code and configuration that actually ties the services together.

IAM complexity is where this limitation bites hardest. Privilege escalation through role-chaining is invisible from the outside, since a tester has to read the actual policy documents to see that Role A can assume Role B, and that Role B carries permissions Role A never had on its own, which is the escalation path itself. Wildcard policies and overly loose conditions are written into the configuration, so finding them means reading the policy itself. The same holds for Infrastructure-as-Code: a misconfigured Terraform or CloudFormation template is part of the attack surface because it propagates into every environment it provisions, but that template only becomes visible with access to the repository itself.

Source code access also settles whether an SSRF flaw can reach the metadata service. Whether an application can be tricked into reaching the metadata service depends on how that application builds its outbound requests, something visible directly in the code and invisible to a black-box scanner that can only watch how the application responds from outside.

Hardcoded secrets sitting in environment variables and CI/CD pipelines are a leading cause of cloud credential exposure, so you have to access the codebase and pipeline configuration directly to find them; probing whatever happens to be internet-facing won't do it.

A middle path exists too: partial access, some credentials, limited architecture diagrams, can surface attack chains that a fully external test would miss entirely, including cases where a flaw in application logic chains into access on the cloud control plane. That greybox approach is a genuine improvement over black-box testing, but it's still a compromise. Full whitebox access to configuration and code is what closes the remaining blind spots.

Configuration-level access and the most consequential cloud attack chains

The attack chains that cause the worst breaches almost never come from a single glaring flaw. They come from two or three ordinary-looking pieces fitting together in a way nobody intended. A storage bucket with slightly too generous a policy means little on its own. An IAM role attached to a Lambda function with slightly too much reach means little on its own. Put them together, and a path opens from an internet-facing service straight into a production database, and that path only exists because of how the specific pieces were configured in that specific account.

Finding that kind of chain takes reading the IAM policy documents directly, since role-chaining escalation paths, where Role A can assume Role B and inherit permissions Role A never had, are written into the policy JSON itself and invisible to anything scanning from outside. You also have to read the Infrastructure-as-Code templates, because a single flawed Terraform module can quietly reproduce the same weakness across every environment the organization runs. It takes reading the application's source code, since whether an SSRF flaw can reach the instance metadata endpoint and pull IAM credentials depends on how outbound requests are built in the code, not on anything visible from a response. And you have to check the CI/CD pipeline and environment variables directly, since hardcoded secrets sitting there are among the most common ways cloud credentials end up exposed.

None of this is visible from the outside, no matter how long an external tester spends probing. It's only visible to someone with the configuration and the code in front of them, tracing how the pieces actually connect, one role, one policy, one template at a time.