Most security testing still begins with the same premise: can an attacker breach the perimeter?
It’s a valid question but increasingly, it’s the wrong one.
The wave of ransomware exploits on household names over the last year demonstrates this. In these organisations by the time the first crisis meeting was called, the attacker’s lateral movement was already done, persistence established, and the ransomware was hours away from activation.
Boards have been told for years that breach is a matter of when, not if. The recent wave of incidents has made the point concrete. The operational question that follows is less well rehearsed: once an attacker is inside, how far can they go, and how fast?
Modern attack paths rarely rely on brute-force entry alone. Access is often obtained through social engineering, compromised credentials, token theft, exposed services, or through trusted third-party relationships.
By the time suspicious behaviour is detected, the attacker is no longer probing the edge, they are operating within the environment, interacting with systems as if they belong there.
At that point, the real test of security begins.
Moving Beyond Perimeter-Centric Thinking
Every breach begins with initial access, and testing the perimeter has its place. But in the incidents that have caused the most damage over the last year, the perimeter was not breached in the conventional sense. A helpdesk was socially engineered. A supplier was compromised. A credential was reused. The adversary was not attacking the door, they were walking through one that had been opened for them.
What follows that moment is where most of the damage is done, and it is also the phase that receives disproportionately less testing attention. Budget and scope tend to weight toward whether an attacker can get in, rather than what they can do once they are.
Assumed breach testing starts from a different position. It accepts that an attacker already has a foothold whether through a low-privileged user account, a compromised endpoint, or an exposed service and focuses on what happens next.
The objective is not to prove that access is possible, but to understand how far and fast that access can be extended.
From a minimal foothold, our engineers replicate what a real attacker would do next. Enumeration begins almost immediately, mapping Active Directory, identifying trust relationships, and locating high-value systems. Misconfigurations, excessive permissions, and weak segmentation become the primary attack surface. Lateral movement techniques are used to traverse the network, blending into legitimate traffic wherever possible.
Testing the Reality of Modern Threats
This approach aligns far more closely with how contemporary attacks, and particularly ransomware operations, are executed. The attacks that cause the most damage are not opportunistic, single-action events. They are structured, multi-stage intrusions where time is spent understanding the environment before taking action.
Attackers move deliberately. They establish persistence. They identify backup systems. They target identity infrastructure. And when they act, they do so with a level of access that allows for maximum impact.
In this context, the key questions are no longer theoretical. They are operational. How effectively can suspicious internal behaviour be detected? How quickly can privilege escalation be identified? Are there controls in place to prevent unrestricted lateral movement? Can critical assets be isolated before they are reached?
Assumed breach testing is designed to answer these questions under realistic conditions.
A Practical Example of an Evolving Threat Landscape
One of the more telling patterns emerges over time.
In a recent engagement, we revisited a client environment that had undergone an assumed breach test the previous year. Following the initial exercise, the organisation had taken clear, structured steps to address the findings. Privilege boundaries had been tightened, visibility had improved, and several high-risk paths had been removed.
From a defensive standpoint, the organisation had matured.
However, during the new assessment, it was still possible to gain entry and traverse to full domain controller-level access.
This was not a failure of remediation. It was a reflection of change.
Techniques had evolved. Tooling had improved. Attack paths that were previously impractical had become viable. Identity relationships, service accounts, and operational dependencies introduced new opportunities for escalation that did not exist or were not exploitable in the same way before.
Both the defenders and the attackers had learned, and the attack surface had shifted again.
Real-Time Validation Over Static Assurance
Security controls are often implemented as part of structured improvement programmes. Findings are addressed, audits are passed, and risk is reduced against a defined set of criteria.
But environments are not static systems. They are constantly changing, driven by business requirements, user behaviour, and technology adoption. As they evolve, so too does the attack surface.
Consider something as routine as a SaaS integration. Service accounts are provisioned, federated identity is configured, access becomes seamless. Each step is individually reasonable. Collectively, they introduce new trust relationships and new privilege pathways that did not exist the week before, and none of it is visible in last quarter’s assurance report.
This is the gap between auditors and attackers. Auditors assess the environment on a specific date. Attackers observe it continuously and act when the configuration drifts in their favour. A point-in-time test captures a moment; a real adversary captures a window.
A More Direct Path to Meaningful Risk
By starting from an assumed low privilege foothold, assumed breach engagements reach substantive findings far more quickly. Effort is concentrated on high-impact areas such as identity security, privilege management, and internal network controls.
More importantly, it produces answers to the questions that matter most.
If an attacker is already inside your environment, how far can they go? How long would it take you or your security service provider to detect them? And would your internal controls be sufficient to stop them before critical systems are compromised?
These are not edge-case scenarios. They are the conditions under which modern attacks succeed or fail.
At Risk Crew, CREST-accredited security testing engineers conduct these engagements in close collaboration with internal teams. Vulnerabilities are not simply documented, they are validated, contextualised, and talked through with your team in real time so that remediation can begin. This creates a far more accurate picture of how controls perform under realistic conditions, particularly under the kind of pressure associated with an active threat.