Cloud Penetration Testing (AWS, Azure, GCP)

We map the tenant: accounts and subscriptions, identities and roles, exposed services and public assets. Configuration data is invaluable here, so we work from read access where you can grant it, enumerate permissions carefully, and build a picture of the trust relationships that hold the environment together.

This is the core of the work. From the starting identity we look for a path upward: a role that can be assumed, a policy that grants more than intended, a function whose execution role is over-scoped, a secret that grants access to a more powerful principal. We chain these steps the way an attacker would and see how close we get to administrative control or to your most sensitive data.

Access only matters for what it reaches. We test whether the paths we found lead to customer data, backups, secrets or the ability to alter infrastructure, and we confirm exactly what a real attacker could read, change or destroy. Where logging and detection should have caught our activity, we note whether it did.

You get an executive summary and a technical report where each finding carries impact, a CVSS score where it maps, reproduction steps and a specific remediation, whether that is a tightened policy, a blocked metadata path or a rotated key. After you fix, we retest for free to confirm the escalation path is genuinely closed.

Wildcard permissions, roles that can escalate to admin, and trust policies that let the wrong principal assume a powerful role are the most common critical findings by a wide margin. A single identity with one policy too many often collapses the whole security model. We find the exact chain and show you the least-privilege fix.

Buckets and blobs left readable, snapshots shared too widely, and databases exposed to the internet still leak data every week somewhere. We check every storage service and its access policy, including the subtle cases where a bucket is private but a policy or ACL quietly opens it.

A server-side request forgery in an application becomes account compromise when it can reach the instance metadata service and pull temporary credentials. We test whether IMDS is exposed, whether IMDSv2 is enforced, and whether any application in scope can be coaxed into reaching it.

Access keys in a public repository, tokens baked into a container image, credentials in an environment variable readable by the wrong role. These are the seeds of most breaches. We hunt them across the assets in scope and trace what each one would give an attacker.

We frame configuration findings against the CIS Benchmarks for AWS, Azure and GCP and each provider’s security best-practice guidance, so your team has a recognised standard to remediate against and to measure future drift. A benchmark score on its own is not security, but paired with the exploited attack paths it gives you both the what and the why behind each fix.

The report and an attestation letter support ISO 27001, SOC 2 and PCI DSS obligations, including the external and internal testing expectations those frameworks carry. Tell us your framework and we align the deliverables to it.

A penetration test proves what an attacker can do; a configuration review checks every setting against a baseline. They complement each other, and where you need the exhaustive audit rather than the adversarial test, our cloud security configuration review covers that ground.

On AWS the action is in IAM: assumable roles, policy conditions, the instance metadata service, and cross-account trust between the many accounts a mature organisation ends up with. We map the role graph and look for the assume-role chain that reaches an administrator or a sensitive account.

Azure blends Entra ID identities with subscription-level RBAC, and the interesting gaps often sit between the two, such as a managed identity with more rights than anyone tracked, or a service principal with a stale, over-privileged credential. We test both planes and how a foothold in one reaches the other.

On GCP service accounts and their impersonation are the recurring theme, alongside project and organisation-level IAM inheritance that quietly grants more than a single project’s view suggests. We trace impersonation chains and inherited permissions to their real endpoint.