Most red team engagements begin at the perimeter: the team attempts to phish an employee, exploit an internet-facing system, or gain physical access to a building. An assumed breach engagement skips that step entirely. The red team starts with a foothold inside the network — a standard user account and a workstation — and the question shifts from “can they get in?” to “what happens after they do?”

The assumed breach model

In an assumed breach test, the client provides the red team with a starting position that simulates a successful initial compromise. This typically means:

  • A standard domain user account (not an administrator).
  • Access to a workstation on the corporate network, either physical or via VPN.
  • No prior knowledge of the internal network topology, systems, or security controls.

From this starting point, the red team operates exactly as they would in a full-scope engagement: enumerating the environment, harvesting credentials, escalating privileges, moving laterally, and working towards agreed objectives.

The engagement does not test the perimeter or initial access controls. It tests everything else: internal segmentation, privilege management, detection capabilities, and the organisation’s ability to contain and respond to a threat that is already inside.

Why organisations choose assumed breach

There are several legitimate reasons to start inside the network rather than at the perimeter.

Mature perimeter defences. Some organisations have invested heavily in perimeter security — advanced email filtering, EDR on every endpoint, zero-trust network access — and are confident that an initial compromise would be difficult. They want to know what would happen if those defences were bypassed, because no perimeter is impenetrable.

Time and cost efficiency. The initial access phase of a full-scope red team can consume a significant proportion of the engagement window. If the primary interest is in post-compromise impact, starting inside the network maximises the time spent on the most valuable part of the test.

Insider threat simulation. An assumed breach mirrors the position of a malicious insider: an employee, contractor, or third party with legitimate access who decides to act against the organisation’s interests. Testing from this position reveals whether internal controls are sufficient to limit the damage a trusted user could cause.

Known initial access risk. If the organisation already knows that initial compromise is possible — perhaps from a previous penetration test that identified phishing vulnerabilities, or because the business model requires granting network access to third parties — there is little value in re-demonstrating that. The more important question is what happens next.

Compliance or regulatory drivers. Some frameworks and regulators specifically recommend or require internal testing from an assumed breach position, recognising that perimeter defences alone are insufficient.

What testers do once inside

The assumed breach phase follows the same methodology as the post-compromise phase of a full red team, but with more time to go deeper.

Enumeration

The first step is understanding the environment. The red team maps the internal network, identifies domain controllers, file servers, application servers, and other infrastructure. They enumerate Active Directory to understand the domain structure, trust relationships, group memberships, and privilege assignments.

This phase often reveals early warning signs: overly permissive group policies, service accounts with excessive privileges, or legacy systems that are still domain-joined and reachable.

Credential harvesting

With a standard user account, the red team looks for opportunities to obtain additional credentials:

  • Kerberoasting. Requesting Kerberos service tickets for accounts with Service Principal Names (SPNs) and cracking them offline to recover plaintext passwords. Service accounts with weak passwords are particularly vulnerable.
  • AS-REP roasting. Identifying accounts that do not require pre-authentication and extracting their encrypted password hashes for offline cracking.
  • NTLM relay attacks. Intercepting and relaying NTLM authentication to gain access to systems or extract credentials.
  • Memory extraction. On compromised systems, extracting credentials from memory using tools that read the LSASS process.
  • Credential stores. Searching for passwords stored in scripts, configuration files, Group Policy Preferences, or password managers.

Privilege escalation

Using harvested credentials and identified misconfigurations, the red team escalates from a standard user to a domain administrator or equivalent. Common escalation paths include:

  • Exploiting misconfigured delegation settings (unconstrained or constrained delegation).
  • Abusing Group Policy Object (GPO) permissions.
  • Leveraging trust relationships between domains or forests.
  • Exploiting vulnerabilities in unpatched systems.
  • Chaining multiple lower-severity misconfigurations into a high-impact attack path.

Lateral movement

As privileges increase, the red team moves across the network towards the agreed objective. This might involve accessing file shares containing sensitive data, reaching database servers, compromising additional systems to establish redundant access, or moving between network segments that should be isolated.

Objective completion

The engagement concludes when the red team achieves the agreed objective — or demonstrates that the path to it is blocked by effective controls. Both outcomes are valuable: the former identifies gaps, the latter validates defences.

Common findings

Assumed breach engagements consistently reveal patterns of weakness in internal environments:

  • Excessive privileges. Users and service accounts with far more access than they need. A single compromised account should not provide a path to domain admin.
  • Weak segmentation. Flat networks where a standard user workstation can reach servers, databases, and domain controllers without restriction.
  • Poor credential hygiene. Weak passwords on service accounts, password reuse across systems, credentials stored in plaintext in scripts or GPOs.
  • Insufficient monitoring. No detection of credential harvesting, lateral movement, or privilege escalation. The security team has no visibility into east-west traffic.
  • Stale accounts and systems. Disabled accounts that are still domain-joined, legacy systems with known vulnerabilities, and service accounts that no one owns or monitors.

How assumed breach complements full-scope red teaming

Assumed breach testing is not a replacement for full-scope red teaming — it is a complement. A full-scope engagement tests the entire kill chain from initial reconnaissance to objective completion. An assumed breach engagement provides deeper coverage of the post-compromise phase.

Organisations with mature security programmes often use both:

  • A full-scope red team engagement every one to two years to test the complete attack surface.
  • Assumed breach testing more frequently — annually or after significant changes to the internal environment — to ensure that internal controls remain effective.

Together, they provide a comprehensive picture of the organisation’s resilience: how hard it is to get in, and how much damage can be done once someone does.