Cloud penetration testing
We attack your AWS and Google Cloud environments the way a motivated adversary would — chaining real misconfigurations into proven impact, not listing theoretical findings.
When you need this
A customer or auditor is asking for a cloud-specific penetration test, and a network pentest report won't answer it.
You've grown fast on AWS or GCP and nobody has tried to break the environment end to end.
Your scanner output is thousands of findings deep and you can't tell which ones an attacker could actually chain.
You're about to expose a new workload, tenant boundary, or data platform and want it tested before customers touch it.
What we do
01
Identity first, because that's where cloud breaches start
We enumerate roles, trust policies, and permission boundaries, then hunt privilege-escalation paths — role chaining, pass-role abuse, service-linked role misuse, over-broad OIDC federation, and cross-account trust that's wider than anyone intended.
02
Reachability, not inventory
Public exposure is a graph problem: security groups, load balancers, bucket and object policies, VPC peering, and endpoint services combine into paths nobody drew on a diagram. We map what's actually reachable and from where.
03
Workload and data-plane exploitation
Container escape and node-role abuse in EKS or GKE, task and function role misuse, metadata service access, secrets recoverable from environment variables and images, and lateral movement into data stores.
04
Proof, then a fix that survives
Every finding gets a reproducible exploit path and a remediation designed for your stack — a policy change, a Terraform module, a guardrail — not a vendor recommendation copied from documentation.
What you receive
- Findings as they're confirmed, not held for a report deadline
- Reproducible exploit chains with the exact commands and conditions
- Attack-path diagrams showing identity and network reachability
- Remediation written as code or policy where the fix is code or policy
- An executive summary that describes business impact without inflating it
- A retest confirming each fix, with the evidence
How it runs
Scope
days
Environment walkthrough, accounts and boundaries agreed, fixed price set.
Test
1–3 weeks
Automated enumeration, then manual exploitation. Critical findings reported on discovery.
Report
days
Full findings, exploit paths, and prioritised remediation.
Retest
included
We verify your fixes and update each finding's status.
Durations are indicative. Actual scope and price are fixed after the scoping call.
Questions we get asked
- How is this different from a vulnerability scan?
- A scanner reports that a configuration is wrong. We prove what an attacker can do with it — chaining a permissive role, a reachable service, and a data store into demonstrated impact. The output is a small number of proven paths, not thousands of unranked findings.
- Will testing affect production?
- We agree destructive-action boundaries during scoping and work inside them. Most cloud testing is read-heavy enumeration and controlled privilege escalation; anything with production impact is discussed before it happens.
- Do you need production access?
- We test where the risk actually is, which is usually production. Access is typically a scoped, auditable role with credentials you issue and can revoke; if a representative non-production environment exists, we'll tell you honestly whether testing it is meaningful.
- What about Azure?
- We don't claim Azure depth. Our cloud practice is AWS and Google Cloud, and we'd rather say so than sell you a thinner engagement.