When an access token ends up somewhere it should not be, it usually gets revoked the same day. The question that follows is what it could have reached before it was revoked, and that is normally the question nobody in the room can answer.
We start by assuming someone has already broken in, which could be through a phished developer account, a leaked API key, or a compromised laptop. This assume breach approach skips past the obvious entry points and focuses on what happens next.
Can adversaries move between your systems?
Can they access your customer data?
Could they modify your code deployments?
This is especially important for teams using DevOps practices. Your CI/CD pipelines, automated deployments, and infrastructure as code are useful tools, and also attractive targets. We test whether adversaries could compromise your source code, hijack your build process, or use your own automation against you.
Rather than handing you a list of problems, we demonstrate exactly how an attack would unfold, what data could be stolen, and which systems could be compromised.
How we work
We agree the rules of engagement before execution with a defined scope of tenants, subscriptions, accounts and clusters, the scope includes identities we start from, what is out of scope, and how we communicate through the engagement.
We provision the agreed credentials based on an assume breach scenario. The starting positions are agreed on for each engagmenet, e.g. a standard developer identity, a CI service principal, a compromised workload, or a session taken from a compromised endpoint.
From there we enumerate what that identity can see across the identity plane and the resource plane, covering role assignments, trust relationships, federation, managed identities, secret stores and pipeline permissions. We then chain those permissions into candidate escalation and lateral movement routes and execute each one. Where a path could not be executed, it is reported as a theory and labelled as one.
The objectives are agreed up front and written in your terms, e.g. read this data set, alter a deployment, reach subscription owner, or cross from test into production. The test succeeds or fails against those objectives. We also record what we did and when, so that you can establish whether any of it was detected and work closely with your blueteam or MDR/MSSP during engagements.
What is not included
- On-premises network and Active Directory testing, except where a federation trust is the path into the cloud
- Phishing your staff. We rather simulate the outcome of a successful phish-
- Physical intrusion, denial of service, and load testing
- The application's own authorization and business logic, this is covered in our Cloud Application Security Test
What you get
- Attack path narratives, written as a sequence covering the starting identity, every step taken, the evidence, and what it achieved
- A diagram of the paths drawn against your own architecture
- Reproduction steps for every path, so that your engineers can re-run it after fixing it
- Remediation tied to the break point, meaning the specific control that stops each path and where it sits, prioritized by which fix removes the most paths
- A summary of what we did against what was detected
- A technical session and a session for the business stakeholders
- A retest of the critical paths within an agreed window, included
Our recommendations are short, and they describe remediations that make sense for your environment.
Our service covers all major platforms including Azure, AWS, Google Cloud, OCI and Kubernetes.