Cloud Penetration Testing

Cloud penetration testing is a scoped, authorised assessment of the identities, control planes, workloads, data stores and exposed services inside a cloud environment. It attempts agreed attack paths, under the provider’s current testing policy, and records what those paths reached.

This guide is written for UK teams buying that work: what the service covers, where the shared responsibility boundary falls, what the report should contain, and what a test cannot tell you afterwards.

In brief: A cloud penetration test should state the accounts and environments in scope, the attack paths attempted, the evidence behind each finding and the exclusions that limit it, with a named owner for every remediation action. It is a point-in-time assessment, not a certification and not a substitute for continuous monitoring.

What cloud penetration testing covers

A cloud penetration test is a scoped, authorised attempt to reach something that matters, through the identities, control planes, workloads and data stores of a live cloud environment. An automated scan lists known weaknesses. A penetration test establishes what an attacker could reach with them. The value sits in the attack paths that were tried, the evidence recorded, and the plain statement of what was left alone.

Coverage is never automatic. Anything not written into the rules of engagement did not happen, whatever the summary implies. On a typical engagement the named coverage includes:

• human users, service identities, workload roles and federation to an external identity provider;
• privileged access, permission boundaries and the routes between low-privilege and high-privilege roles;
• internet-facing services, APIs and management interfaces;
• network paths, segmentation and security group rules;
• storage exposure, secrets handling and key management;
• virtual machines, containers, functions and the images behind them;
• deployment pipelines and the infrastructure code that builds the estate;
• logging, alerting and the response path, where the buyer wants detection measured.

Where the boundary is drawn

A boundary is a list of accounts, subscriptions or projects, a list of environments, a list of permitted techniques, and a date range. It is agreed in writing by someone who can authorise testing against each of them. Where a shared platform hosts other tenants, that constraint belongs in the boundary too, not in a footnote.

We write the excluded items down with as much care as the included ones, because the exclusions are what a reader will misread six months later. An estate with three production subscriptions and one tested subscription has been tested once, not three times.

Shared responsibility and provider testing rules

The provider secures the parts of the platform you cannot reach. You keep the identities, configurations, workloads and data you control. Where that line falls changes with the service model: a managed database moves patching to the provider and leaves access control with you.

That split decides what a tester may touch. Testing your own application on a virtual machine you own is a different proposition from testing the provider’s hypervisor, and only one of them is yours to authorise.

AWS, Azure and Google Cloud policies

Each major provider publishes its own customer testing policy, and they do not say the same thing. AWS lists the services you may test without prior approval and names prohibited activities, denial of service testing among them. Microsoft’s rules of engagement also rule out denial of service testing and post-exploitation activity such as lateral movement. Google Cloud’s guidance takes a different shape again: it says advance notice is not required and that your testing must not affect other customers, and points to its Acceptable Use Policy for the limits. Read the current version of each at the point of scoping: these documents change, and a policy quoted from memory is a liability.

Rules of engagement before any packet is sent

Before the first request leaves a tester’s machine, both sides should hold the same document: the boundary, the permitted techniques, the test windows, the source addresses, the emergency contacts on each side, and the stop procedure with the name of the person who can invoke it.

A permitted test can still disrupt a system nobody fully understood. That is an argument for a working stop procedure, not for a weaker test.

Identity and control-plane testing

Most cloud compromises we are asked to reconstruct did not begin with an exotic exploit. They began with a credential, a token or a role that could be assumed by something that should not have been able to assume it.

Why identity is the shortest path

Identity is where a small foothold becomes a large one. A test should look at over-broad permissions, trust policies that accept more than intended, credentials left in code, images or metadata services, weak federation conditions, and any path that ends at a role with administrative rights.

The finding that matters is rarely “this policy is too permissive”. It is “this build agent could assume this role, and from there read this bucket”, with the commands and the timestamps attached.

Control plane against workload

Control-plane testing examines the APIs and management paths used to create, change and read resources. Workload testing examines what runs inside them: the application, the container, the function, the database. The two fail independently. A well-written application can sit inside an account whose identity policy hands it away, and a hardened account can host an application with an unauthenticated administrative endpoint.

Test identities should be documented with an owner and a starting permission set, and the report should distinguish access that was granted for the assessment from access that was earned through a finding. Without that line, a reader cannot tell a serious result from a supplied one.

What a cloud penetration test report should contain

The report is the product. Everything else is process. For each finding, expect:

1. the affected resource, account or subscription, and the environment it sits in;
2. the identity and the attack path used to reach it;
3. evidence that supports the conclusion, including commands, timestamps and resource identifiers;
4. the technical consequence and the business consequence, stated separately;
5. the remediation owner, named by role;
6. corrective action that a platform engineer can act on without a second meeting;
7. the terms under which a fix will be verified, and by whom.

Expect the closing discussion to say where the testers looked and found nothing exploitable. A report that lists only successes tells you what was found, never what was covered. Expect the limitations and assumptions to be written plainly: time constraints, environments excluded, features that could not be exercised, and any point at which the test was paused.

What a cloud penetration test cannot tell you

A test describes one estate, on agreed dates, under agreed rules. It cannot tell you that the deployment you ship next Tuesday is secure, because that deployment did not exist when the work was done. Cloud estates change daily, and identity assignments change fastest of all.

It cannot certify you. A penetration test is evidence that certain attack paths were attempted and what came of them. It is not an audit opinion, and no report should be presented as one.

It cannot replace the controls that run continuously: configuration monitoring, vulnerability management, logging, and the person who reads the alerts.

Say that out loud to your board before somebody else says it for you.

A structural engineer signs off the building as designed and built, not the extension added two years later. The same limit applies here, and buyers are entitled to hear it before the invoice rather than after it.

AWS, Azure and Google Cloud scope compared

The three major platforms use different names, different permission models and different control-plane services. Experience on one is useful on another, and it is not a substitute. When a proposal says “cloud”, ask which cloud, and which services within it.

A multi-cloud estate needs one boundary per provider. One account list and one method rarely survive contact with a second platform.

How to compare cloud penetration testing providers

Compare proposals against the same written scope and the same required outputs. Until the scope is fixed, a price comparison compares nothing.

Questions that separate proposals

• Who will do the work, and what have they tested on this platform?
• Does the method cover identity, control plane and workloads, or only the workloads?
• How will production risk and the provider’s testing rules be handled?
• Can we see a redacted example report before we sign?
• How are credentials, screenshots and evidence stored, transferred and destroyed?
• Are subcontractors involved, and are they named?
• Is retesting of remediated findings included, and for how long?
• Which exclusions could change the conclusion materially?

Define the boundary before you ask for prices

Write down the cloud environments in scope, the data that would hurt to lose, the identities involved, the techniques you will permit, and the decisions the evidence must support. Send that same document to every provider you are considering. You will get proposals you can actually compare, and a test that answers your question rather than theirs.

Ask LEVERAGE CYBER to review your cloud testing scope.