Skip to content
Service 10

Cloud Penetration Testing

Hands-on testing of AWS, Azure, and GCP — identity, misconfiguration, and the paths that turn one foothold into a tenant-wide problem.

What we test

A cloud estate is not a network with a different logo. The attack surface is identity, trust relationships, and the APIs that glue them together — a role that can assume another role, a storage account that is public because a flag was left on, a CI identity that can reach production because nobody scoped it.

We test that surface the way an attacker would: start from what is exposed or what a typical identity can do, then follow it until we hit a control that actually stops us, or until we reach something you would not want us to reach.

This is a different engagement from network penetration testing. Network work answers how far someone gets on the wire. Cloud work answers how far a principal gets once it can call your APIs.

AWS, Azure, and GCP

The methods differ by provider. The question does not.

Identity. Users, roles, service principals, managed identities, and the trust between them. Over-permissioned roles and forgotten federation are the usual path to a tenant-wide problem.

Storage and data. Buckets, blobs, and databases that are reachable because of a policy, a snapshot, or a replica nobody remembered.

Compute and runtime. Instances, functions, containers, and the metadata services they expose to anything that lands on them.

Control plane. The APIs and consoles an attacker uses once they have a foothold — often more valuable than the workload they landed on.

Where configuration review stops

A configuration review reads the tenant and tells you what is wrong. This engagement tries to use it. If you already know the settings are messy and want proof of impact, start here. If you want a read-only pass first, start there.

What you receive

A report ranked by what an attacker actually reached, with the principal, the path, and the change that closes it. We retest once you have remediated, the same as any other penetration test.

Common questions

Cloud Penetration Testing — what clients ask

Is this just a CIS benchmark against our tenant?
No. Benchmarks are useful homework; they are not a test. We use them as a map, then prove which findings an attacker can actually chain — a public bucket is a finding, a public bucket that leads to a role that can read production data is the engagement. You get the exploitable path, not a spreadsheet of should-fix items.
Do you need admin access, or do you test as an outsider?
Usually both, and they answer different questions. Unauthenticated and low-privilege testing shows what is reachable from the internet or a stolen user. Authenticated testing from a typical developer or operator role shows how far that identity can go once it is inside. We agree the starting identities in writing before anything is touched.
Will you change anything in our cloud accounts?
No. The engagement is read-and-prove, not remediate-as-we-go. We do not create lasting resources, weaken controls, or leave backdoors. Where a check carries real operational risk — for example a destructive IAM change — we tell you first and let you decide.

Strengthen your defenses.

Tell us what you need tested. We’ll come back with scope, timeline, and a fixed price.

Request a quote