External exposure
What an attacker can reach from the internet: exposed services, forgotten endpoints, and storage or databases left open to the world.
- Internet-facing services
- Open storage & databases
- Exposed management planes
- Forgotten assets
Cloud penetration testing
Test the cloud an attacker would actually reach.
Most cloud breaches are not clever exploits. They are a bucket someone made public, a role with too many permissions, or a key left where it should not be. We test your AWS, Azure and Google Cloud the way an attacker would, from the outside in and from a foothold out, across exposure, configuration and identity.
Configuration review
The settings an attacker abuses once inside: public buckets, over-permissive security groups, weak defaults and missing logging.
- Storage & bucket policy
- Network & security groups
- Logging & monitoring gaps
- Weak defaults
Identity & privilege
The identity model that decides how far a foothold goes: over-privileged users and roles, and the paths an attacker uses to reach full control.
- IAM users & roles
- Over-privileged access
- Privilege escalation paths
- Federation & keys
Beyond the console
Where cloud breaches actually start.
It is rarely a zero-day. Far more often it is a misconfiguration or an over-privileged identity, the kind of gap that hides in plain sight. We look for what a real attacker would find, then prove how far it goes.
- Public storage and databases exposed to the internet
- Over-permissive roles and identities that escalate to admin
- Leaked or long-lived keys and credentials
- Missing logging that lets an attacker move unseen
How we test
How a cloud test runs.
Every cloud engagement follows the same clear phases, so you always know what is happening and why.
- 01
Scope and access
We agree the accounts, services and providers in scope, arrange read-only access for the review, and sign off the rules of engagement.
- 02
External discovery
We map what your cloud exposes to the internet: services, endpoints, storage and management interfaces.
- 03
Configuration review
We work through the account configuration for the weaknesses attackers rely on: public storage, weak network rules and missing controls.
- 04
Identity and privilege
We map the identity model and find the paths from a low-privileged foothold to full control.
- 05
Exploitation
We safely prove impact, chaining the misconfigurations and identity flaws the way a real attacker would.
- 06
Report and retest
You get an executive and technical report within 48 hours, then a free retest of critical and high findings once you have fixed them.*
Deliverables
What you get.
Not a 500-page tool export. You get the handful of things that actually put you at risk, and how to fix them.
- A senior, CREST-certified tester on the work from start to finish
- Executive and technical report within 48 hours of testing finishing
- Every finding rated by CVSS and by real business impact
- Clear, prioritised remediation your team can act on
- Reproducible proof of concept for each issue, never a scanner dump
- A free retest of critical and high findings within 30 days*
* The free retest covers critical and high findings within 30 days, one retest per engagement, delivered remotely and excluding on-site costs. Applies to UK-based engagements only. See our terms for full details.
FAQ
Cloud testing, answered.
Straight answers to what clients ask most about cloud engagements.
Which cloud providers do you test?
AWS, Azure and Google Cloud, and the services most businesses run on top of them. We test the exposed surface, the configuration and the identity model in each, and agree the exact accounts and services in scope with you before we start.
What is the difference between a cloud configuration review and a penetration test?
A configuration review checks your cloud settings against good practice: public storage, over-permissive roles, missing logging and so on. A penetration test goes further and proves what an attacker could actually do by chaining those weaknesses together. We do both in one engagement, so you get the checklist and the proof of impact.
Do you need access to our cloud accounts?
For the configuration and identity work, yes: read-only access to the accounts in scope lets us see what an attacker would abuse after getting in. The external exposure testing needs nothing from you. We agree the access, the scope and the boundaries up front, and everything is logged.
Is cloud testing safe to run against production?
Yes. Most cloud testing is read-mostly and safe against production under agreed rules of engagement. Where an action carries any risk, we agree it with you first, and we never touch your data or availability without sign-off.
Do you test containers and Kubernetes?
Yes. Where they are in scope we test container images, registries and Kubernetes clusters, including the roles and network policies that decide how far a compromised container can reach.
How is this different from your infrastructure test?
An infrastructure test focuses on hosts, networks and services. Cloud testing adds what is unique to the cloud: the account configuration, the storage, and the identity and permissions model that a traditional network test does not cover. Many clients scope the two together.
Ready to test your cloud?
Tell us what you run and where, and what worries you. We will come back within one working day with a suggested approach and a fixed-price scope, with no sales theatre.