Overview
The engagement has two halves. From outside, the cloud estate is enumerated as an attacker sees it: exposed storage, public snapshots, forgotten subdomains pointing at deallocated resources, credentials in public repositories and container registries. From inside, with a read-only role, identity and access management is analysed for the escalation paths that turn a low-privilege compromise into account-wide control.
Findings are delivered as paths, not as inventory. “This Lambda role can pass a role it should not, which can attach a policy, which reaches the production database” is a finding. A list of 400 CIS deviations is not.
Engagement at a glance
- Providers
- Amazon Web Services, Microsoft Azure, Google Cloud Platform
- Typical duration
- 5 to 15 working days, depending on account and subscription count
- Modes
- External (black box) and configuration-assisted review with a read-only role
- Standards
- CIS Benchmarks, provider well-architected security pillars, MITRE ATT&CK for Cloud
- Authorisation
- Provider testing policies confirmed before any active testing begins
- Deliverable
- Attack paths drawn end to end, not a list of misconfigurations
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- IAM policy analysis and privilege escalation paths
- Over-permissive roles, trust policies and cross-account access
- Exposed object storage, S3, Blob Storage, Cloud Storage
- Instance metadata service access and SSRF chaining
- Secrets in environment variables, user data and build logs
- Container and Kubernetes security, RBAC, escape paths, exposed etcd and dashboards
- Serverless function permissions and event injection
- CI/CD pipeline compromise and build-time supply chain
- Network exposure, security groups and peering
- Logging, monitoring and detection gaps
- Subdomain takeover from dangling DNS records
- Public snapshots, AMIs and container images
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Identity and access | Every principal enumerated, then every escalation primitive tested: iam:PassRole, policy attachment, trust relationships, assumable roles | Low-privilege identity reaching administrative control |
| Storage | Bucket and container policies, ACLs, signed-URL handling, public listing, sensitive object discovery | Customer data exposed without authentication |
| Metadata | Every application input that fetches a URL, redirect chains, IMDSv1 fallback, gopher and DNS-rebinding paths | Instance credentials stolen through the application itself |
| Containers | RBAC bindings, privileged pods, host mounts, service account tokens, exposed API server and etcd | Container escape to node, then to cluster administrator |
| Pipelines | Workflow trigger conditions, injectable build inputs, secret scope, artefact signing, dependency resolution order | Code execution in the build environment with deployment credentials |
| DNS | Every record resolved and matched against claimable provider resources, with claimability verified before reporting | Subdomain takeover enabling phishing and cookie theft |
What we commonly find
A role that can grant itself more
The escalation is rarely a single bad policy. It is two reasonable policies that compose into administrative access.
SSRF that reaches the metadata service
An image resizer, a PDF renderer or a webhook validator that fetches an attacker-supplied URL from inside the VPC.
Secrets in build logs
Masked in the console, plain text in the artefact, and the artefact is world-readable.
Dangling DNS records
A CNAME left pointing at a deallocated resource. Claimability is verified before anything is reported, a provider error page alone is a lead, not a finding.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- After a migration, a major re-architecture or a move to multi-account.
- Before an audit that covers infrastructure controls.
- When the estate has grown faster than the review process: typically past the point where nobody can name every account.
- Annually, and after any incident involving credentials.
Questions
Do we need to notify our cloud provider?
AWS, Azure and GCP all permit customer-initiated penetration testing of your own resources under published policies, with some service categories excluded and denial-of-service testing prohibited. The applicable policy is confirmed in writing during scoping, and any test that requires prior authorisation is identified before it runs.
Black box or with credentials?
Both, ideally. External-only testing shows what an unauthenticated attacker reaches. A read-only role added afterwards reveals the escalation paths behind that perimeter, which is where the severe findings usually are. Assisted testing typically returns three to four times as many actionable findings for the same duration.
Is this the same as a CSPM scan?
No. A posture tool reports configuration deviations; this engagement proves which deviations compose into a path to your data. The output is a small number of demonstrated attack chains rather than a large inventory of settings.
Can you test Kubernetes specifically?
Yes, RBAC bindings, service account token scope, privileged and host-networked pods, admission control, exposed API server, kubelet and etcd, and escape paths from a compromised container to the node and the cluster.
How much does cloud penetration testing cost?
Scope is driven by account and subscription count, the number of workloads and identities, and whether Kubernetes or serverless estates are included. A fixed quote follows a short scoping call and covers the review of configuration as well as the exploitation of what it permits.
Which providers do you test?
AWS, Azure and Google Cloud, including multi-cloud estates tested as one engagement. The escalation paths differ by provider but the pattern does not: identity is the perimeter, and the severe findings are usually two reasonable permissions that compose into something neither was meant to allow.
Do you test Terraform or infrastructure as code?
Yes, where it is in scope, and it is the cheapest place to fix what we find. Reviewing the definition alongside the deployed state also shows drift: resources created by hand, permissions widened during an incident and never narrowed, and modules whose defaults were never read.
Can you test our CI/CD pipeline?
Yes, and it is frequently the shortest path to production. Build systems hold deployment credentials, run untrusted code from pull requests, and are rarely scoped into a test. Coverage includes runner isolation, secret handling, branch protection, and what a contributor with no production access can reach through a workflow file.
What is the difference between this and a cloud security posture review?
A posture review lists misconfigurations against a benchmark. This engagement proves which of them an attacker can actually chain into access, and to what. A public storage bucket is a finding either way; whether it leads to a role assumption that reaches your production database is what changes the severity.