Cloud penetration testing
Cloud breaks at the
identity layer.
Cloud compromise is rarely an unpatched host. It is a role that can assume another role, a pipeline that can deploy to production, and a token sitting in an environment variable that nobody thought was reachable.
Permissions are the new network.
In a data centre, reachability decided the blast radius. In cloud, permissions do. A workload with one over scoped role can often reach further than a compromised host in a flat network ever could, and it leaves far less obvious a trail while doing it.
Where cloud
estates give way.
Tested with a real identity in your environment, because an external only view of a cloud account tells you almost nothing.
01 · IAM
Identity and privilege escalation
Role assumption chains, wildcard actions, iam:PassRole abuse, trust policies that trust too much, and the escalation paths that turn a read only identity into an administrator.
02 · Storage
Data exposure
Buckets and blob containers with public or over broad access, unencrypted snapshots, database backups in shared accounts, and pre signed URLs with no meaningful expiry.
03 · Metadata
Instance metadata abuse
SSRF into the metadata service to steal role credentials, IMDSv1 still enabled, and container workloads inheriting node level permissions they were never meant to have.
04 · Kubernetes
Cluster and container security
RBAC review, privileged pods and host mounts, service account token abuse, network policy gaps, and container escape to the underlying node.
05 · Pipeline
CI/CD and supply chain
Build systems with production credentials, workflows triggerable from a fork, artefact integrity, and secrets that live in the pipeline rather than a vault. Read the field guide.
06 · Detection
Logging and visibility
Whether CloudTrail, Activity Log or audit logging would have captured what we did, and whether anything downstream would have noticed.
Seen in the field
What it looks like
in practice.
An illustrative example of the class of issue this engagement is built to find, and what changes after it.
Illustrative example, not client data
BeforeWhat we found
# server side request forgery reaches the metadata service GET /preview?url=http://169.254.169.254/latest/ meta-data/iam/security-credentials/app-role 200 OK { "AccessKeyId": "ASIA...", "SecretAccessKey": "...", "Token": "..." } # role could read every bucket in the account
AfterAfter the fix
# IMDSv2 required, hop limit 1, egress allowlisted GET /preview?url=http://169.254.169.254/latest/ meta-data/iam/security-credentials/app-role 401 Unauthorized # v1 disabled, PUT token required # role scoped to one prefix, not the account
SSRF into instance metadata. One unvalidated URL parameter turned into account wide credentials, because the workload role was far broader than the workload needed. Requiring IMDSv2 stops the theft, and scoping the role limits what it is worth.
AWS, Azure,
Kubernetes.
The principles are shared. The specifics are not, and the specifics are where the findings are.
| Platform | Where compromise usually starts | What we test hardest |
|---|---|---|
| AWS | An over permissioned role or an exposed key | iam:PassRole chains, assume role graphs, S3 policy, IMDS exposure, Lambda execution roles |
| Azure | Entra ID identity and consent | Managed identity scope, role assignment inheritance, application consent, Key Vault access policy |
| Kubernetes | A workload with a generous service account | RBAC bindings, privileged pods, host path mounts, network policy, secrets handling |
Scope the cloud test.
Request a quoteAssumed access,
then escalate.
We start with a low privilege identity you issue us, and see how far it goes.
01
Inventory
Full enumeration of accounts, identities, roles, policies and resources in scope, including the ones outside your infrastructure as code.
02
Graph the permissions
Build the escalation graph. Who can assume what, who can pass which role, and which paths end at an administrator or at your data.
03
Escalate for real
Execute the paths. A theoretical escalation path and a proven one are different findings and deserve different urgency.
04
Reach the data
Prove impact by reaching something that matters, then stop. We show you what we could read, never exfiltrate it.
Questions
The usual
questions.
Do we need permission from AWS or Azure to run a penetration test?
For customer operated workloads, both AWS and Azure permit testing under their published policies without prior approval. Some activities such as denial of service testing remain prohibited. We work within those rules and confirm the boundary in scoping.
What access do you need?
A low privilege identity in the account, plus read access to the configuration. Starting from a realistic identity is what makes the results meaningful. An unauthenticated external scan of a cloud account finds very little.
Do you test Kubernetes clusters?
Yes, including RBAC review, workload configuration, container escape paths and network policy. Clusters are usually scoped alongside the cloud account that hosts them.
Is this the same as a cloud configuration review?
A configuration review compares your settings to a benchmark. This engagement chains the gaps into working escalation paths and proves impact. A benchmark tool will not tell you that three separately acceptable permissions combine into an administrator.
Can you test our CI/CD pipeline?
Yes. Pipelines hold production credentials and frequently accept input from anyone who can open a pull request, which makes them one of the highest value targets in a modern estate.
Scope the cloud test.
A senior operator replies within one business day. No sales pipeline, no bot.