IAM privilege escalation
Role assumption chains, pass-role and policy-attachment paths, wildcard actions, over-broad trust policies, and confused-deputy conditions. We trace the route from the identity you gave us to the one you did not intend.
Services · AWS, Azure & GCP
Cloud infrastructure
Cloud infrastructure
penetration testing.
Cloud breaches are rarely an exploit. They are a permission that was temporary two years ago, a role that can assume another role, and a pipeline that can reach production. We map those chains in your account and prove which ones actually lead somewhere.
01
Who this is for
Built for teams who built the cloud while building the product.
01
Startups born in the cloud
IAM was configured under deadline pressure by the person who needed it to work, and nobody has reduced it since. Wildcard actions and long-lived keys accumulate quietly, and they are the most common root cause we find.
02
Companies facing SOC 2 or customer diligence
A configuration review tells you what deviates from a benchmark. A penetration test tells you which deviations are actually exploitable and in what order. Auditors and enterprise customers increasingly want the second.
03
Teams running Kubernetes
Container escape, over-permissive service accounts, and the IAM role a pod can assume are a distinct attack surface layered on top of the cloud account itself. It is scoped explicitly rather than assumed.
02
Coverage
What we actually test.
Assumed-breach by default: we start from a low-privilege identity and establish how far it reaches, because that is the realistic scenario.
Identity and credential hygiene
Long-lived access keys, unused and forgotten identities, cross-account trust, federation and SSO mapping, and service principals with far more than their workload requires.
Storage and data exposure
Bucket and container policies, ACLs and public access settings, presigned URL handling, snapshot and image permissions, and backups that are more accessible than the data they came from.
Network and metadata
Security group and NSG exposure, reachable management surfaces, and the instance metadata service, still one of the highest-value targets when an application has any server-side request capability.
CI/CD and supply chain
Secrets in pipelines and build logs, OIDC trust conditions that are broader than intended, artefact registry permissions, and whether a pipeline can reach production infrastructure directly.
Kubernetes and containers
RBAC bindings, service account token exposure, privileged pods and host mounts, container escape conditions, and the cloud IAM role a compromised pod inherits.
03
How the engagement runs
Six steps, every time.
The same disciplined sequence on every engagement, so you know what is happening and when, and so nothing reaches your report unproven.
01
Scope
A conversation, not a form. We agree the boundary, the accounts, the timing and the escalation contact, and it is enforced technically.
02
Map
We build the real picture of what is reachable, which is almost always larger than the inventory you were given.
03
Prove
Every candidate finding is actively validated against a baseline. Anything that fails is demoted or dropped before it reaches you.
04
Chain
Confirmed findings are linked into the routes an attacker would walk. One finding is a ticket. A path is a breach.
05
Report
Evidence, reproduction steps, prioritised remediation and detection content, as SARIF, JSON and HTML mapped to MITRE ATT&CK.
06
Retest
You fix, we verify, and the report is updated. A finding is not closed because someone said it was.
04
Straight answers
The questions we actually get.
Do we need to notify our cloud provider?
For AWS, Azure and GCP, testing your own resources within their policies generally does not require prior approval, though specific activities still do. We identify anything that needs notification during scoping and will not run it until the position is clear.
Is this a configuration review or a penetration test?
A penetration test. A configuration review compares settings against a baseline and produces a long list. We prove which findings chain into a real path to data or control, so remediation is ordered by impact rather than by severity label.
What access do you need?
Typically a low-privilege identity in the account, which is the realistic starting position for an attacker who has phished a developer. Read-only audit access alongside it makes the engagement more complete. We never ask for administrator credentials to begin.
Can you test production?
Yes, and the methodology is non-destructive: we do not delete resources, alter policies, or leave persistence. Where proving a path would require a state change, we demonstrate the precondition, stop, and document it rather than acting quietly.
We use more than one cloud. Can you cover all of them?
Yes. Cross-cloud engagements are scoped per account and per provider, and the most interesting findings are often at the seams, where federation or a shared CI system connects two environments that were assessed separately.
Start here
Scoping is
Scoping is
a conversation.
Tell us what you are protecting and what worries you. You will get an honest answer on whether this engagement is the right next step, who would run it, and what it would cost, before you commit to anything.