Most network penetration tests start where the tester has no access, no credentials, and their goal is to attempt to break in. That approach makes sense for testing perimeter defences. But it is not how most organisations get compromised.
Phishing emails land, credentials get stolen, or a contractor’s laptop becomes infected. At this point the question is not whether an attacker can get in, it is what they can do once they are in. Assumed breach penetration testing is a goal-oriented approach to internal network penetration testing that starts from the position where an initial compromise has already happened.
How assumed breach testing works
An assumed breach test skips the initial infiltration access phase and places the tester directly inside the environment with a limited foothold. That starting position is agreed during scoping and typically resembles one of the access levels an attacker is likely to have obtained - e.g. a standard domain user account, an authenticated session on a workstation, or access from a server within a specific network segment.
From here, the tester works to understand what can be reached, what access can be escalated, and what an attacker could do before anyone notices. The focus is the post-compromise attack chain through privilege escalation, lateral movement, access to sensitive systems.
The goal is to determine how far limited access can lead to an attack path with real business impact, such as domain administrative control, access to financial data, or a viable ransomware deployment route, and whether your internal controls are effective at preventing or detecting that path.
Why start from the point of breach?
Most real-world attacks involve getting through the perimeter using social engineering, credential theft, or a vulnerability in a remote access service, rather than novel exploitation of internet-facing infrastructure. Once inside, attackers often move slowly and quietly, escalating access and establishing persistence over days or weeks before doing anything that triggers an alert.
For organisations with relatively mature external controls, the perimeter is not typically where the most significant risks are. Assessing the perimeter is still worthwhile, but you can have a well-hardened external surface and still be completely exposed internally. Active Directory misconfigurations, weak internal credentials, over-privileged service accounts, and flat network designs are common findings in internal assessments, and they are invisible from the outside.
An assumed breach test makes better use of testing time when the primary concern is internal resilience rather than initial access. Testing effort is concentrated on the attack paths that create the greatest risk, rather than spending time proving a way in that both parties already accept is theoretically possible.
When assumed breach testing is the right choice
There are several situations where starting inside the environment makes more sense than starting from scratch.
You already have confidence in your perimeter. If your external infrastructure has been tested, and you have addressed the findings, the next question is what happens if an attacker gets through anyway. An assumed breach test addresses that question directly.
You want to understand Active Directory and lateral movement risk. Assumed breach is the natural model for testing Active Directory environments. Techniques like Kerberoasting , pass-the-hash, ACL abuse, and delegation misconfigurations all require a foothold inside the domain to test. An assumed breach test covers this ground efficiently.
You are validating the response to a previous incident. After a security event, the question is whether the attack path has been closed and whether any residual weaknesses remain. An assumed breach test from a realistic starting position gives you this answer.
You have compliance requirements focused on internal controls. PCI DSS Requirement 11.4 requires internal penetration testing. Assumed breach can be used to satisfy this, particularly where the intent is to test segmentation and privilege controls rather than initial access.
You are not ready for a full red team. A red team exercise tests the full attack chain, including initial access through social engineering and physical access. Assumed breach is a more contained and cost-effective option when you want internal coverage without the broader red team scope.
If this is your first network security assessment, and you have not previously tested your external perimeter , starting there is usually the better choice. Our guide to scoping a network pentest covers how to think through this decision.
What an assumed breach engagement looks like
The starting position and objectives are agreed during scoping. A typical engagement for an internal network penetration test using assumed breach approach might start with a standard domain user account and have the objective of determining whether that account can be used to reach domain administrative privileges, access sensitive file shares, or compromise systems in a protected network segment.
The key element for scoping a successful engagement is to align the objectives with your own business concerns, rather than an off-the-shelf checklist.
During testing, the consultant will work through the environment using their penetration testing methodology. This includes enumerating the domain, identifying misconfigured services and accounts, testing for weak or reused credentials, assessing trust relationships between systems, and looking for paths to escalate privileges. Where vulnerabilities are found, they are exploited to demonstrate real-world impact, not just flagged as theoretical risks.
To illustrate what this looks like in practice, a common pattern in Active Directory environments is that a standard domain user account (equivalent to the access gained from a successful phishing email) is enough to enumerate service accounts that are configured with Service Principal Names. A Kerberoasting attack against a weakly-set service account password can elevate access within hours to a privileged account used across several servers. From there, lateral movement to a domain controller is often straightforward, and the environment is effectively compromised before the end of the first day of testing.
None of this requires an advanced technique or a zero-day vulnerability. The path runs through misconfigurations that have frequently been in place for years and are entirely invisible from the outside. The external perimeter can be clean while the internal environment is not.
With Exploitr, critical findings are communicated directly during the engagement rather than held until the report. If the domain can be compromised on day one, you hear about it on day one.
At the end of the engagement, you receive a technical report with findings, reproduction steps, and remediation guidance, plus an executive summary that explains the business risk in plain terms. A debrief session is included to walk through findings with your team and discuss next steps.
How it differs from a red team exercise
People sometimes use “assumed breach” and “red team” interchangeably. They are related but are not the same.
A red team exercise simulates a targeted adversary from start to finish. It typically involves initial access attempts through phishing, OSINT, and physical intrusion, followed by post-compromise activity. Red team engagements run over longer timelines, often several weeks, and test detection and response capabilities as much as technical controls.
An assumed breach penetration test is a more focused engagement that concentrates on the internal environment and potential attack paths from a compromised position. It does not include initial access simulation or tests whether your SOC detects the attack.
For most organisations looking at internal network penetration testing, assumed breach testing is a good starting point. It is a technical security assessment of what is reachable, escalatable, and exploitable once an attacker has a foothold.
A red team engagement makes more sense once you have baseline confidence in your internal controls and want to test your detection and response processes against a realistic adversary. See our overview of what a red team engagement involves for more detail on where the two approaches differ.
Getting the most from an assumed breach test
The starting position is one of the most important aspects to plan out for the engagement. A standard domain user account in the general IT network gives a different perspective than a service account in the server subnet, or a low-privilege account with access to the card data environment.
Conversely, if you’re more concerned with what an attacker could do with a compromised internet-facing server, it would be more beneficial to start from that position rather than a workstation in the internal network.
During scoping, it is worth thinking about which foothold most realistically reflects the access a real attacker might obtain, and which internal risks you most want to understand.
Being clear about your business concerns and risk appetite helps focus the assessment too. If reaching your customer database, compromising your domain controllers, or accessing your finance systems represents the worst-case scenario for your business, then these are the primary focal points for your assessment scope. Testing time can then be structured around whether those systems are reachable and by what route.
If you have had an incident previously or have a specific attack scenario in mind, share that context. A realistic starting position informed by your actual risk produces more useful findings than a generic foothold.
For more on how we scope and run internal assessments, and how assumed breach fits into the wider internal penetration testing process, see our internal pentest service page.