Understanding cloud security for penetration testing

Traditional network testing starts with a range of addresses and works inward. Cloud testing starts with an identity and works outward, because in a cloud estate almost everything an attacker wants is reachable by anyone holding the right role, and roles are far easier to over grant than firewall rules.

That changes the first question of the engagement. Not what is exposed, but what can this principal become.

Privilege escalation is a graph problem

A role that can modify another role's trust policy can assume it. A role that can pass a more privileged role to a compute service can execute as it. A role that can update a function's code can run arbitrary code with that function's permissions. None of these is a vulnerability in the provider; each is a documented feature.

Chained together, a handful of individually reasonable grants become a path from a low privilege service account to full administrative control. Finding those paths is the core of a cloud assessment, and it requires enumerating the permission graph rather than scanning hosts.

The shared responsibility line

The provider secures the infrastructure. You secure the configuration, the identities, the data and the code. Almost every publicised cloud breach has been on the customer side of that line, and usually on the identity part of it.

Get authorisation to test in writing, respect the provider's rules of engagement, and scope carefully around managed services you do not own. Then test identity first, network second, and configuration continuously, because in a cloud estate, configuration drifts every day and an annual assessment is a photograph of a moving object.