Segmented but Not Secured: How Modern Adversaries Are Rendering Your Network Boundaries Obsolete
Network segmentation has long occupied a privileged position in enterprise security architecture. The logic is intuitive: divide the network into discrete zones, restrict traffic between them, and an attacker who breaches one segment finds themselves contained — unable to reach the crown jewels without tripping a detection mechanism or confronting an impenetrable boundary. It is a sound principle. The problem is that most implementations of that principle were designed around an adversary model that no longer accurately describes the threat landscape.
Modern intrusion operators — whether nation-state affiliated groups or financially motivated ransomware affiliates — have systematically adapted their tradecraft to exploit the gap between how segmentation is designed and how enterprise environments actually function. The result is a class of lateral movement that traverses network boundaries not by breaking through them, but by walking through doors that were intentionally left open for legitimate business operations.
The Assumption Embedded in Most Segmentation Designs
Traditional network segmentation frameworks are built around a relatively straightforward threat model: an attacker gains a foothold in a low-trust zone, attempts to pivot toward higher-value segments, and does so using recognizable attack tooling — port scanners, exploit frameworks, credential-stuffing utilities. Firewalls and access control lists are configured to block lateral traffic that doesn't serve a documented business purpose, and security teams monitor for anomalous connection patterns that suggest probing or pivoting behavior.
This model performs reasonably well against commodity threats. Where it fails is against adversaries who have invested time in understanding the target environment before executing any lateral movement — a reconnaissance discipline that has become standard practice among higher-tier threat actors. When an attacker understands which administrative tools are in routine use, which service accounts carry elevated privileges across segment boundaries, and which business applications require persistent cross-segment communication, they can construct a lateral movement chain that is, from the network's perspective, largely indistinguishable from normal operations.
Living Off the Land Is Not a New Concept — but Its Implications for Segmentation Are Underappreciated
The phrase "living off the land" has circulated in threat intelligence circles for years, typically framed as a detection challenge: attackers using native Windows utilities like PowerShell, WMI, and PsExec leave a smaller forensic footprint than those deploying custom malware. What receives less attention is the architectural dimension of the same technique.
Consider a common enterprise topology. An organization segments its environment into endpoint, server, and management zones, with explicit firewall rules governing inter-zone traffic. The segmentation design correctly identifies that arbitrary endpoint-to-server communication should be restricted. What it may not adequately account for is that the organization's IT operations team uses a remote monitoring and management platform — a legitimate, licensed tool — that maintains persistent, authenticated connections across all three zones. An attacker who compromises an endpoint, escalates privileges, and gains access to that RMM agent's credentials or session context has, in effect, been handed a pre-approved tunnel through the segmentation architecture.
This pattern recurs across multiple tool categories: enterprise password managers with broad network reach, backup agents running under highly privileged service accounts, collaboration platforms with API integrations that traverse security boundaries, and IT service management tools that communicate freely with both user-facing and infrastructure segments. Each represents a legitimate business requirement that was accommodated by creating exceptions to the segmentation model — exceptions that, in aggregate, can constitute a navigable path from an initial access point to a high-value target.
Lateral Movement Chains Observed in Recent Breach Investigations
Post-breach forensic work conducted across a range of US enterprise incidents in recent years reveals consistent patterns in how adversaries exploit segmentation gaps. A representative chain might unfold as follows:
An attacker gains initial access through a phishing email that compromises a workstation in the general employee segment. Rather than immediately attempting to pivot — which would generate detectable traffic against firewall rules — they spend time establishing persistence and enumerating the local environment. They identify a vulnerability management agent installed on the endpoint that communicates with a centralized server in the infrastructure segment. By manipulating the agent's configuration or hijacking its authenticated session, they achieve connectivity to the infrastructure segment without generating a firewall alert, because the communication path was explicitly permitted.
From the infrastructure segment, they identify a database backup service running under a domain service account with replication rights across multiple segments. Using credentials harvested from the endpoint, they authenticate to the backup service and begin enumerating accessible database instances. The entire chain — from initial access to database enumeration — may involve no custom tooling and no traffic patterns that would trigger a signature-based detection rule.
This is not a theoretical scenario. Variants of this chain appear in public breach disclosures and private incident response reports with enough frequency to constitute a pattern that defenders must treat as a baseline adversary capability, not an edge case.
Where Segmentation Frameworks Develop Blind Spots
Several structural factors contribute to the gap between segmentation intent and segmentation reality.
Exception accumulation over time. Segmentation architectures are typically designed at a point in time and then modified incrementally as business requirements evolve. Each modification — a new SaaS integration, a vendor access requirement, a temporary exception that becomes permanent — erodes the original design without necessarily triggering a holistic review. Over a three-to-five year horizon, the cumulative effect of incremental exceptions can fundamentally alter the security properties of the architecture.
Service account privilege sprawl. Service accounts that were provisioned with broad access rights to simplify deployment are rarely revisited once operational. In many environments, a handful of service accounts carry sufficient privileges to authenticate across multiple segments, effectively functioning as skeleton keys that bypass zone boundaries entirely.
Implicit trust in managed tools. Security teams appropriately scrutinize inbound traffic from unknown sources, but traffic generated by recognized enterprise tools is frequently exempted from the same scrutiny. Adversaries who understand this dynamic target managed tool infrastructure precisely because the trust relationship is already established.
Insufficient east-west visibility. Many organizations have invested heavily in perimeter monitoring while maintaining limited visibility into lateral traffic within and between internal segments. Without comprehensive east-west telemetry, lateral movement that stays within permitted traffic patterns may generate no alert at all.
A Practical Reassessment Methodology
Addressing these blind spots requires a structured reassessment of the segmentation architecture against the actual threat model — not the theoretical one that informed the original design.
Begin with a cross-segment trust audit. Document every service account, managed tool, and application integration that maintains persistent or on-demand connectivity across segment boundaries. For each, assess whether the access scope is proportional to the operational requirement, whether authentication mechanisms are sufficiently strong, and whether the communication is monitored for anomalous behavior.
Next, conduct a lateral movement simulation exercise that specifically focuses on legitimate tool abuse rather than traditional exploit-based pivoting. Engage an internal red team or external adversary simulation provider with explicit instructions to avoid custom tooling and to rely exclusively on native utilities and deployed enterprise software. The goal is to map the paths that your current detection architecture would not surface.
From there, prioritize remediation based on path criticality rather than vulnerability severity scores. A service account with cross-segment access to a domain controller represents a higher-priority remediation target than a high-CVSS vulnerability in an isolated segment with no onward connectivity to sensitive resources.
Finally, instrument east-west traffic at the segment boundary level with behavioral analytics capable of identifying anomalous patterns in otherwise permitted traffic. The absence of a firewall alert does not indicate the absence of malicious activity — it indicates only that the traffic was not blocked. Detection must extend into the permitted traffic space.
Segmentation Remains Worth Defending
None of this analysis should be read as an argument that network segmentation has lost its value. Properly designed and maintained, segmentation meaningfully increases the cost and complexity of lateral movement, limits blast radius in the event of a breach, and provides a structural foundation for more granular access controls. The discipline is sound. The implementations, in many organizations, have simply not kept pace with the adversary tradecraft they are meant to contain.
The defenders who will fare best are those willing to interrogate the assumptions embedded in their architecture — to ask not whether the segmentation was correctly designed at the time of deployment, but whether it remains fit for purpose against the threat actors they are actually facing today.