
If a laptop gets compromised tomorrow, how far does it go?
Perimeter defences stop most opportunistic attacks, but a single phished user or unpatched workstation puts an attacker inside anyway. We test what happens from that point onwards.
Perimeter security tells you nothing about what happens after the first compromise.
Most organisations have invested heavily in perimeter defences — firewalls, email filtering, endpoint protection — and reasonably expect that investment to keep attackers out. It does, most of the time. The problem is what happens the small percentage of the time it doesn't: a phishing email gets through, a personal device connects to the office network, or a contractor's laptop arrives already compromised. Once an attacker has any foothold inside the network, the perimeter is irrelevant, and it's the internal environment that determines whether that foothold stays contained or turns into full domain compromise.
Active Directory is almost always the deciding factor. It's the system that governs who can access what, and in practice it accumulates years of small compromises to convenience: a service account with domain admin rights because it was easier at the time, a group policy object with weak permissions, delegation settings configured for a project that ended two years ago. None of these individually look dangerous. Chained together, they routinely provide a direct path from a standard user account to full domain control.
Lateral movement techniques exploit the fact that most internal networks trust devices and accounts far more than they should once they're past the perimeter. Cached credentials on shared workstations, local administrator passwords reused across the estate, and overly permissive file shares all let an attacker move from one compromised machine to dozens more with very little additional effort.
Legacy protocols compound the problem further. LLMNR and NetBIOS broadcasts, SMB signing left disabled, and unencrypted LDAP are still common in environments that have grown organically over years, and each one can be abused to intercept or relay credentials without ever triggering an alert, because from the network's perspective it looks like ordinary traffic.
Segmentation is meant to be the safety net when all of this goes wrong — guest networks, office VLANs and production environments kept apart so a compromise in one doesn't reach the others. In practice, firewall rules drift, VLANs get bridged for a temporary fix that never gets reversed, and the segmentation that appears in the network diagram often doesn't match what actually happens on the wire.
- Service accounts and delegation settings creating unintended admin paths
- Cached and reused local administrator credentials across the estate
- Legacy name resolution and SMB protocols still enabled by default
- Segmentation that exists on paper but not in firewall rules
We start where a real attacker would, and see how far that gets us.
Most engagements begin from an assumed-breach position — a standard domain user account on an ordinary workstation, with no special access. This mirrors the realistic outcome of a successful phishing email or a compromised device far more closely than a hypothetical zero-knowledge external attack, and it lets us focus testing time on the part of the network that carries the most risk: what happens after the initial compromise.
From that starting point, we systematically enumerate the Active Directory environment — trust relationships, group memberships, delegation configuration, group policy permissions and service account behaviour — looking for the specific misconfigurations that turn a low-privilege account into a path towards domain administrator. Where a credible path exists, we follow it to demonstrate genuine impact rather than reporting a theoretical weakness.
Lateral movement is tested directly. We check whether credentials or password hashes captured on one machine grant access to others, whether local administrator passwords are shared across the estate, and whether file shares, print servers or backup systems expose more than they should to a standard user account.
Legacy protocol abuse is tested as standard: LLMNR and NetBIOS poisoning, SMB relay attacks, and unencrypted LDAP binds are all attempted where the environment permits, because these are consistently among the fastest routes to credential capture in real intrusions.
Segmentation is validated by actually attempting cross-segment access rather than reading firewall rulesets in isolation — testing from a guest network, an office VLAN or a lower-trust environment to see what genuinely reaches domain controllers, production servers or sensitive data stores.
Every path we successfully exploit is documented step by step, with the specific misconfiguration responsible identified clearly enough that your team can close it permanently rather than patch the symptom. We agree rules of engagement upfront to avoid account lockouts and unnecessary disruption, and free retesting is included for every critical and high finding.
- Assumed-breach starting point matching a realistic attacker foothold
- Active Directory misconfiguration and privilege escalation paths mapped and demonstrated
- Legacy protocol abuse and lateral movement tested directly, not inferred
- Segmentation validated by attempted cross-segment access, not just rule review
Everything in the engagement, set out up front.
A fixed-scope engagement covering internal reconnaissance, Active Directory testing and segmentation validation.
Assumed-breach starting position
Testing begins from a standard user account and workstation to reflect a realistic post-compromise scenario.
Active Directory security review
Systematic testing of trusts, delegation, group policy and service accounts for privilege escalation routes.
Lateral movement testing
Assessment of credential reuse, cached authentication data and shared local administrator access across the estate.
Legacy protocol testing
Targeted testing of LLMNR, NetBIOS, SMB signing and LDAP configuration for credential capture and relay risk.
Segmentation validation
Direct testing of whether network boundaries between zones actually hold up rather than reviewing rules on paper.
Privilege escalation path mapping
Full documentation of each demonstrated route from initial foothold to elevated or domain-level access.
What you receive.
- Executive summary suitable for boards and auditors
- Risk-rated findings with realistic business impact
- Step-by-step attack path documentation with evidence
- Active Directory misconfiguration inventory
- Segmentation test results by network zone
- Legacy protocol and credential exposure summary
- Remediation guidance prioritised by risk and effort
- Free retest report for critical and high findings
Built for organisations that need the work done properly.
Organisations that have never tested internally
Businesses that have invested in perimeter and endpoint security but never validated what happens once that perimeter is bypassed.
Environments with legacy Active Directory
Domains that have grown over many years, through mergers or staff turnover, where nobody has a full picture of delegation and trust configuration.
Multi-site or segmented networks
Organisations relying on VLANs and firewall zones to separate guest, office and production environments and wanting that assumption tested.
Firms preparing for insurance or compliance review
Businesses that need evidence of internal testing to satisfy cyber insurance underwriting or a client's due diligence requirements.
What changes once the work is done.
What changes once testing and remediation are complete.
Privilege escalation paths closed
The specific misconfigurations that turned a standard account into domain administrator access are identified and fixed.
Lateral movement contained
Shared credentials and cached authentication data no longer let a single compromised device reach the whole estate.
Legacy protocol exposure removed
LLMNR, NetBIOS and unsigned SMB traffic no longer provide a quiet route to credential capture.
Segmentation genuinely enforced
Confirmation that guest, office and production zones are actually isolated, not just diagrammed as separate.
A realistic view of breach impact
Leadership gets an evidence-based answer to 'how bad would this actually be', not a guess.
Evidence for insurers and clients
A dated, detailed report demonstrating internal testing for underwriting, audits or supplier due diligence.
Why assumed-breach testing matters more than perimeter testing alone.
There's a persistent assumption that if the outside of the network is secure, the inside doesn't need separate attention. Every serious internal engagement we run disproves that within the first day or two. Domain environments accumulate small, individually reasonable decisions over years, and it's the combination of those decisions — not a single dramatic flaw — that usually provides the route from a phished laptop to full domain compromise.
Assumed-breach testing exists because the realistic question for most organisations isn't 'can someone get in from the internet', it's 'when someone inevitably does get in, what can they reach'. Starting from a low-privilege foothold and measuring how far it spreads gives a far more useful answer than a theoretical external test that spends most of its time simply trying to gain that same initial access.
Segmentation deserves particular scrutiny because it's so often trusted more than it deserves. A network diagram showing separate zones for guests, offices and production servers is a design intention, not a guarantee. Firewall rules get loosened for a project, a VLAN gets bridged temporarily and never unbridged, and nobody revisits the configuration until it's tested directly.
We deliver this testing for organisations across Chesterfield, Sheffield, Derby, Nottingham, Leeds, Manchester, Birmingham and London, and the underlying finding is consistent: internal environments are rarely tested as thoroughly as the perimeter, simply because they're harder to reach from outside. That gap is exactly where an assumed-breach engagement adds the most value, and exactly where real attackers spend their time once they're past the front door.
Questions we are asked most often.
What is assumed-breach testing?
Rather than spending days trying to get an initial foothold, we start from a position an attacker would realistically reach after a successful phishing email or a compromised laptop — a standard domain user account on an ordinary workstation. This lets us spend the engagement testing what actually matters: how far that access can spread across your network.
Why focus on Active Directory specifically?
Active Directory is the backbone of authentication and authorisation for most UK organisations, and it's the single most common route from a low-privilege foothold to full domain control. Misconfigured group policy, excessive delegation, weak service account passwords and legacy trust relationships routinely turn one compromised laptop into complete network compromise.
Will this test disrupt our network or users?
We agree rules of engagement in advance to avoid account lockouts, service disruption or unnecessary alerts to your team, unless detection testing is specifically part of the brief. Techniques like password spraying are throttled deliberately, and anything with a realistic chance of causing an outage is flagged and agreed before we run it.
Do you test our segmentation between networks?
Yes, this is a core part of the engagement. We test whether access gained in one network segment — a guest network, an office VLAN, a test environment — can reach production servers, domain controllers or sensitive data stores that firewall rules and VLANs are supposed to keep separate.
Can you test without any credentials at all?
Yes. A fully unauthenticated internal test starting from network access alone is a valid and common scope, and it tells you what a visitor plugging into a meeting room port, or malware landing on an unmanaged device, could reach. Many clients run this alongside an assumed-breach test to compare both starting points.
What legacy protocols do you check for?
LLMNR and NetBIOS Name Service resolution, SMBv1, unsigned SMB traffic, and unencrypted LDAP are the most common culprits, because each one can be abused to capture or relay credentials across the network. We also check for older authentication protocols still enabled alongside Kerberos where disabling them has simply never been prioritised.
How do you report privilege escalation paths?
Each path is documented as a chain — the starting point, each step taken, and the specific misconfiguration that allowed it, whether that's a stored credential, an insecure ACL, or an over-delegated service account. We include the exact commands and tools used so your team can reproduce, verify and permanently close each step.
How long does an internal network test take?
A typical mid-sized Active Directory environment takes five to seven days of testing plus reporting. Larger, multi-site or multi-domain environments, or engagements that also cover segmentation validation between numerous network zones, are scoped individually based on the size and complexity of the estate.
Penetration testing
Our full range of testing services across web, API, infrastructure and cloud environments.
Vulnerability management as a service
Ongoing scanning and patch tracking to keep internal systems in a known, defensible state.
Managed security
Continuous monitoring and detection support for organisations wanting more than a point-in-time test.
Ready to find out how far a compromised laptop would get?
Book a short scoping call and we'll agree a realistic starting point, rules of engagement and a fixed price — no pressure, no hard sell.
Scope an internal network test