What is assumed-breach penetration testing?

Assumed-breach penetration testing starts from a foothold an attacker could already hold, such as an employee account or access to an internal network. It tests what that starting access can reach toward an agreed objective.

This lets you examine the consequences of an initial compromise without making the assessment depend on how that compromise happens.

Test the reach of a particular identity

Suppose an employee’s password has been exposed. A useful objective is access that account should not have: the finance file share, a backup server or Domain Admin.

The route might pass through a machine the account can access and a more privileged credential stored there. The report should connect the starting identity to the access actually gained, so you can see where the boundary failed.

What it says about least privilege

If the campaign reaches a forbidden target, the route demonstrates excessive access. If it does not, you still need to know what was reachable and attempted before drawing conclusions about the permission model.

An entitlement review and an access test answer related questions. The review examines assigned rights; the test can demonstrate how those rights combine with exposed credentials or other weaknesses.

Work through an employee-access test

In a hypothetical assessment, an employee account should have no access to finance records. Choose a designated test document on the finance share as the objective, and supply credentials with that employee’s ordinary permissions. Keep the deployment host in the network position you intend to assess.

If the campaign retrieves the document using a service credential found elsewhere, the result concerns a route through that exposure. It does not mean the employee account was directly granted access to the finance share. That distinction tells the owner which permission or credential handling to investigate.

Starting with a finance administrator account would bypass the question of how the employee could acquire that access. Record supplied privileges separately from any privileges the campaign gains.

The internal network assessment guide expands this example into a scope and evidence plan.

Assumed breach and black-box testing

A black-box campaign starts without supplied credentials. An assumed-breach campaign starts from specified access. Record that starting point when comparing reports; changing it changes the question being tested.

In AutoAttack, provide starting credentials when creating the campaign or leave them empty for a black-box start. Set the objective and scope, then review the campaign's attack path. Each new campaign starts fresh.

Read the quickstart for deployment and the data access walkthrough for an objective beyond directory control.