What is assumed-breach penetration testing?

Assumed-breach penetration testing starts the test from a credential an attacker could already hold — a phished employee login, a reused password, an insider account — and measures how far that foothold reaches: what the identity can touch, whether its access is correctly scoped, and whether the chain leads to Domain Admin.

Why assume the breach?

Phishing succeeds eventually, credentials leak and get reused, and insiders already hold a login. A network can keep attackers out at the perimeter and still fall the moment one of those credentials is used from the inside. Assumed-breach testing accepts that a foothold will happen and measures what it costs you.

The starting point is a real credential you hand the test, used the way the attacker who obtained it would. What matters from there is reach: how much of the network that one identity opens up.

Blast radius: how far a phished login reaches

The first thing assumed-breach testing answers is blast radius. Hand the test a single employee’s credential — the one a phishing email would capture — and set the objective to Domain Admin or the systems that matter most. It walks the real path from that foothold: which host the login opens, whose credentials sit on it, and whether the chain reaches domain-wide control.

That is the distance between “an employee got phished” and “an employee got phished and the domain fell an hour later.” On the standard Active Directory lab, an autonomous adversary reaches Domain Admin from a self-earned foothold with no credentials at all — so from a credential you hand it, the path is only shorter. See the Active Directory takeover path.

Access validation: is this identity correctly scoped?

The same starting point answers a quieter question: does an identity have only the access it should? Set the objective to the systems a given account has no business reaching — the finance database, the domain controllers, another team’s servers — and let the test try. If it can’t get there, least privilege holds for that account. If it can, you have found the over-privilege or lateral-movement path a real breach of it would ride.

This is access control proven by walking it. An entitlement review shows what a policy says an identity can do; assumed-breach testing shows what it can reach, including the access it inherits through misconfigurations no policy lists.

Assumed breach vs black-box testing

Black-box testing starts with nothing and asks whether an attacker can break in at all. Assumed-breach testing starts one step later, with the access an attacker would have just after breaking in, and asks what happens next. They answer different questions: one tests the perimeter, the other tests everything behind it.

The costly part of most intrusions happens behind the perimeter, which is why assumed-breach testing maps so directly onto a phished credential or a malicious insider. Running both covers the whole story: whether an attacker can get in, and what it costs when one does.

Is assumed-breach testing safe to run in production?

Done properly, yes. Working from a credential doesn’t change the safeguards: attempts stay under the domain’s own lockout policy, nothing is installed or written to disk on your hosts, and the run is ephemeral. The account you hand it is used the way its owner would — no destructive action, nothing encrypted, nothing left behind. See how AutoAttack stays safe on a production network.

How AutoAttack runs an assumed-breach assessment

AutoAttack takes the assumed breach as an input. When you create a campaign you can hand it one or more starting credentials — a domain login, an email and password, a local admin — or leave it empty for a black-box start. You set the goal in plain English, and it works the path from that foothold, proving each step with captured evidence. There is nothing to install on the hosts it tests.

On hardened GOAD — the standard Active Directory proving ground — it reached Domain Admin across all three domains in a 0:51 median over ten independent runs. Read how autonomous penetration testing works, see the Active Directory takeover path, or start a campaign from a credential.