Assumed breach testing

What it is

An assumed-breach test starts from inside: the tester is given the access an attacker might already have, such as a standard user account or a foothold on one machine, and tests how far they can get from there.

Why it matters

Perimeters fail through phishing, exploited edge devices or stolen credentials. Assumed-breach testing measures what happens next: lateral movement, privilege escalation and access to critical data.

How we test it

We agree the starting access and objectives, then test internal network and Active Directory paths, credential exposure and segmentation, recording each step of the path and the controls that did or did not stop it.

Common mistakes

• Spending the whole budget trying to get in instead of testing what happens after
• No agreed objectives, so findings lack business context
• Not involving the detection team

An example

Starting from one domain-joined laptop with a normal user account, a tester reaches a domain admin group within a day because of a misconfigured service account.

Not to be confused with

Red teaming, which also tests detection and response and is usually broader and stealthier. Assumed breach is a scoping assumption, not a full red team.

Related at PoCForge

• Network & Active Directory pentesting
• Red team assumed-breach case study

Sources

• MITRE ATT&CK: Lateral Movement