Assumed breach testing from inside your network
An assumed breach test starts with the attacker already inside your network. We skip phishing and begin from an agreed starting point, such as a regular employee's laptop or account. Over 2-4 weeks we find out how far they get and whether your team spots them before they reach the objective.
- Starts inside your network, with no phishing phase
- Measures whether and when your monitoring spots the attacker
- Usually 2-4 weeks, versus 4-8 for a full red team operation
What is an assumed breach test
An assumed breach test is an attack simulation variant in which we take it as given that the attacker has already gotten past your perimeter defenses. So we skip the break-in. We get the kind of access they would have after a successful phishing email, a leaked password or an unauthorized visit to your office, and from there we act the way they would. We measure how far we get, and whether and when your systems and people notice us.
When to choose an assumed breach test
- You have a SOC or an MSSP and want to know whether it would spot an attacker who is already inside
- You don't have a SOC yet and want to see how far an attacker would get before you invest in monitoring
- Your staff work remotely over VPN and you want to know what an attacker could do with one employee's remote access
- You need results sooner than a full red team operation allows
This test won't show whether employees fall for phishing or whether someone can get into your network from the internet, because we start inside. For those questions, choose a full APT attack simulation or an external infrastructure pentest. If what you mainly need is a list of vulnerabilities in your internal network, an internal infrastructure pentest is the better fit.
Where the test starts
We choose the starting point together, based on the scenario that is most likely for your company. Each of the four options matches a different way an attacker could get into your network. You can combine several in one test, such as a workstation and VPN access.
Compromised workstation
We start from an employee's computer, as if they had opened a malicious attachment. We check how far someone who hijacked their session can get and whether the security tools on that machine catch us.
Regular domain user account
We start with the username and password of an account without admin rights, as if the password had leaked or been phished. We check how far the permissions of that one account can take an attacker.
VPN access with an employee's credentials
We connect from outside like a remote employee, using their credentials. We check what stolen remote access allows and whether anyone notices a login that doesn't fit that person's normal work.
PWNONE device in your office
Our device goes onto your office network, as if an outsider or a rogue employee had plugged it in. We check how far someone can get from a network port and whether anyone reacts to unknown hardware.
How the test runs
Objective and starting point
We agree what the attacker should try to reach, such as the Domain Admin account or customer data, and where we start.
Authorization and rules
We sign a written authorization and rules of engagement (RoE). You name a control team, and with them we write down the stop conditions and the list of systems we won't touch.
Preparing access
Together with the control team we set up the agreed starting point: an account, a workstation, VPN access or a spot for our device.
Testing in your network
We work from the starting point toward the objective and log every step with a date and time. Your control team can pause the test whenever it sees fit.
Report, workshop and retest
In a workshop, we go through the whole timeline with your security team. Once your fixes are in, we return to check they work. The price covers one retest.
How we keep the test safe
- A control team you appoint oversees the test and can stop it at any time
- Immediate stop conditions are put in writing before we start
- Systems you point out, such as those critical to your operations, are excluded from scope
- We don't start without written authorization and signed rules of engagement (RoE)
What you get after the test
- A timeline of the test from the starting point, with every moment where we could have been detected
- A MITRE ATT&CK map of the techniques we used, to compare against what your detection rules cover
- SIEM and EDR rule recommendations so you catch the attacker earlier next time
- A workshop for your security team and, after the fixes, one retest included in the price
Frequently asked questions
How is an assumed breach test different from an internal network pentest?
An internal network pentest looks for as many vulnerabilities and misconfigurations as it can. An assumed breach test goes after one agreed objective the way an attacker would and checks whether your monitoring and your team react along the way. That's why the result is a timeline with detection points, not just a list of vulnerabilities.
How long does an assumed breach test take?
An assumed breach test usually takes 2-4 weeks. That's shorter than a full APT attack simulation, which runs 4-8 weeks, because we skip the break-in stage. The exact length depends on the starting point, the objective and the scope. We agree on it during the first call, before we send a quote.
Is an assumed breach test worth it without a SOC?
Yes. Without a SOC, an assumed breach test mainly shows how far an attacker gets from the starting point and what stops them along the way. The results tell you which gaps to close first and what to require from a SOC or MSSP provider before you sign a contract.
Which starting point should I choose for an assumed breach test?
Choose the starting point that best reflects your risk. A compromised workstation stands for a successful phishing email, a regular domain account for a leaked password, VPN access for a hijacked remote-work account and our device in your office for an outsider walking into the building. You can also combine several starting points in one test. If you're not sure, we'll help you choose on the first call.
How much does an assumed breach test cost?
The price of an assumed breach test depends on its scope: the starting point, the objective, the number of scenarios and how long the test runs. We don't quote before a call, because two tests rarely share the same scope. After a 30-minute call we send a proposed scope and a quote within two business days.
Can the test disrupt my live network?
We run an assumed breach test in your live network, so we limit the risk before we start. Systems you point out are excluded from scope, and stop conditions are written into the rules of engagement (RoE), signed along with a written authorization. During the test, your control team can pause it at any time.
Will my SOC and IT team know about the assumed breach test?
That's up to you. In a covert test only the control team knows, so you see how your SOC and IT really respond. In an overt test the teams know about it, and we check whether your security controls and procedures work the way you expect. We pick the option when we agree on scope.
See how far an attacker could get in your network
Tell us about your network and what worries you most. We'll propose a starting point, an objective and a scope, and send a quote within two business days of the call.
Book a call about an assumed breach test