Assumed breach testing
Assumed breach testing starts from the position an attacker reaches once prevention has already failed, such as a compromised laptop or a stolen staff account, and measures what happens next: how far the attacker gets, whether your monitoring notices, how fast your team responds, and whether they can contain it.
What it tests
- Lateral movement. How far an attacker can travel from the starting point, and how quickly they reach systems that matter.
- Privilege escalation. Whether a normal account can be turned into an administrative one.
- Detection. Which actions your monitoring records, which raise alerts, and which go unnoticed.
- Response. How your team investigates, who they call, and how long containment takes.
- Objectives. Whether the attacker can reach a defined goal, such as signing infrastructure, treasury approvals or customer data.
Why it matters in crypto
Many of the largest crypto thefts began with an ordinary compromised machine. In the campaign Lazarus Group runs through fake job interviews, a developer runs a “technical assessment” that installs malware, and the attackers work outward from there. An assumed breach test starts at that moment and shows you what would happen next. See fake recruiter attacks.
What you get
A full debrief covering the techniques used, what was and was not detected, the gaps found, and concrete steps to close them.
Frequently asked questions
Why assume a breach instead of testing the perimeter?
Because perimeters get through. Phishing, fake job offers and compromised suppliers reliably put attackers inside well defended organisations. Assumed breach spends the engagement on the part that decides how bad an incident becomes.
How is it set up?
Usually we are given a standard staff device and account, or we plant a foothold that mimics one, and agree an objective, such as reaching treasury systems. Only a small group knows the test is running.
Published Updated