Lateral movement explained

Lateral movement is the phase in an attack where someone already inside moves east-west through the network: from the first system they compromised to the place where the value sits for them. Not the breach itself, not the exfiltration, but the part in between. An attacker has initial access, then uses legitimate protocols, applications and administration tools (Living off the Land, LOTL), valid credentials and existing administrative paths to move on to a server, a domain controller, a file share or a production system. MITRE ATT&CK catalogues this under tactic TA0008, with techniques such as Remote Services, Pass the Hash, Use Alternate Authentication Material and Exploitation of Remote Services. The question on the table is not whether this happens inside your network at some point. The question is how long it takes before you see it and how far they have already got by then.

This article explains what lateral movement is, why segmentation became the standard countermeasure, and why segmentation alone is not enough without detection that looks at east-west traffic and identity behaviour. It closes with the question rarely asked out loud in most organisations: how much time sits between the moment lateral movement begins and the moment you know anything about it.

What does lateral movement look like in practice?

An attacker who has just landed on a single workstation has a problem and an opportunity. The problem is that this workstation rarely gives them what they came for. The opportunity is that the workstation is part of a network built internally for productivity, not for suspicion. They have to move. What they do next looks strikingly little like what cybersecurity stock imagery shows. It looks like ordinary IT work.

They dump credentials from the memory of the machine they are on, use valid administrative tokens, open a remote session to a second system over a protocol common on the network, and look around. They query Active Directory for which accounts and group memberships exist, which service accounts hold broad rights, and which systems use those accounts. They use scripts and command-line tools that every administrator uses too. They schedule a task that fires again a week later so they do not lose what they have built up. This is the phase that falls under discovery, credential access and lateral movement in ATT&CK, and it is precisely the phase that goes unnoticed on a dashboard tuned to malware signatures and virus detection.

What makes a lateral movement action visible is not the fact that a connection is made; those connections are made all day long. The visible part sits in deviation. A service account normally used only by a backup process now logs in interactively to a file server. A workstation that usually only talks to an internet proxy and a mail server suddenly opens an SMB session to a domain controller. A valid authentication token appears from a system that has never seen that token before. Those are the signals. They are there, but only if someone looks at them at the right level, and if the telemetry in which they surface is actually collected and forwarded to the place where a rule runs against it.

Why has segmentation become the standard countermeasure?

The idea behind segmentation is already familiar from older network practice: put walls inside the network so that one compromised system cannot reach all the others. What has changed is the rigour with which that principle is applied. The Dutch National Cyber Security Centre consistently names network segmentation as a baseline control to limit the impact of a breach, and CISA's publications on post-compromise activity put it more sharply: without segmentation, every initial access turns into a potential domain compromise within hours.

The mature form of this principle is Zero Trust. The NIST SP 800-207 document describes Zero Trust not as a product and not as a network topology, but as an architectural principle: do not trust a request on the basis of its network location alone, validate every request on identity, device posture and context, and repeat that validation at every sensitive action. Microsegmentation is the implementation of that principle at network level, with segments that no longer follow subnet or VLAN boundaries but application, identity and purpose. For an attacker this means the following: one compromised system gives them no free run, but a new wall at every next hop, with a policy that checks whether this request, from this identity, to this application, at this moment, is something that appears in your policy.

The effect of tight segmentation is measurable, not as prevention of a breach, but as reduction of the blast radius. A ransomware actor who encrypts ninety percent of the network in a single night in a flat environment gets two servers in a segmented environment and hits a wall. That is not a theoretical difference. It is the difference between a week of production downtime and a contained incident. That is also why segmentation has climbed high up the list of defensive controls, and why insurers explicitly ask about it at policy renewal.

What segmentation does and does not do

There is a fallacy here that recurs in many programmes. Segmentation is sometimes sold as the solution, and then invoked as an alibi: we have segmented, so lateral movement is covered. That is not correct. Segmentation raises the cost and the visibility of lateral movement, but does not eliminate it. An attacker with a valid service account permitted to cross a segment boundary moves along exactly the routes your policy allows. An attacker who finds a misconfiguration in a policy finds an opening. An attacker with phishing access to a user who holds administrative rights moves along with that user's rights.

What segmentation does do, and does well, is three things. One, it shrinks the number-of-paths question: how many systems can someone reach from any given system without violating an explicit permission rule. Two, it makes deviation detectable: a connection that matches no policy rule is an event, not noise. Three, it forces explicit documentation of who may talk to whom and why, and that documentation is itself a form of governance. What segmentation does not do is keep out an attacker who moves within the policy. For that a second layer is needed.

What reveals lateral movement, when you look for it?

The second layer is detection, and it differs from the detection most SOCs are set up for by default. Classic detection looks at perimeter traffic (north-south) and at endpoint signatures. Lateral movement sits elsewhere. It sits in east-west traffic, in internal authentication patterns, in deviations in identity behaviour, and in the correlation between a network event and a directory event in the same minute.

Good detection of lateral movement relies on four data streams read in conjunction:

Identity events from the directory. Login attempts, ticket grants, the use of service accounts, switching between interactive and non-interactive logon types. A service account that logs in interactively is a signal. A user account that suddenly requests administrative tokens is a signal.

East-west network telemetry. Who talks to whom, on which port, at what frequency, and how that compares to the baseline. Not only flow records, but protocol context too: an SMB session between two workstations is something other than an SMB session between a workstation and a file server.

Endpoint process events. Which process opens which connection, which process runs which command line, which script appears on a system where it does not belong. Tooling such as remote management software, dual-use administration scripts and credential-dumping utilities leaves traces here.

Policy events from the segmentation platform. Which connection was allowed or blocked by which policy element, and which deviates from what was previously common here. A connection that is allowed through but falls outside every historical baseline is a point for investigation, not a green tick.

Only when these four come together in the same place and are linked to one another does lateral movement reveal itself. A single log line is almost never enough. The combination of an unusual identity event, an unusual east-west connection in the same minute, and an unknown process at the source is what turns a line of noise into an event.

What is the right measurement?

In most organisations detection is measured by how many alarms come in per day, and how quickly they are cleared. That is an operational measurement, not an effectiveness measurement. For lateral movement the right measurement is a different one: how much time sits between the moment an attacker lands on system A and the moment you are aware they are moving towards system B. That time is known in the literature as dwell time or breakout time, and it is the honest measurement for the combination of segmentation and detection together.

Dwell time is the time between the moment an attacker is inside and the moment they are detected. A long dwell time is the result of late or absent detection: the attacker has had time to look around, gather credentials and dig in, so that the incident you handle later is not an incident but a cleanup operation. A short dwell time is the reverse: they were stopped before reaching a crown jewel. The difference between the two can be expressed in euros and in production hours, and it depends directly on what you have invested in segmentation and in east-west detection.

This also changes how you read a red team test. A red team that reaches a domain controller within a day in a segmented environment does not tell you that your segmentation does not work. It tells you that either the policy had an opening, or the detection missed the east-west steps, or both. That is a far more precise answer than "we have a gap", and it points directly to which layer needs attention.

What this means for the choice you make

For the CISO opening this conversation internally, the usable summary is that lateral movement is not a standalone issue with a single answer, but the place where two disciplines meet: architecture (the segmentation that places the walls) and detection (the governance of identity and east-west traffic that sees what tries to slip through in between). Those who invest only in segmentation buy a reduction of the blast radius and stay blind to the movements that take place within the policy. Those who invest only in detection are watching an open network with a better camera.

For operational teams, the message is that the telemetry that makes lateral movement visible is different from the telemetry most SOCs are set up for by default, and that arranging that telemetry is not a tooling choice but a chain choice: identity, network, endpoint and segmentation policy must come together in one place. For the board or the CFO, the message is more businesslike: the measurement that counts is dwell time, and that measurement hangs on two investments at once, not one.

The logical next step is not an architecture document and not a tool selection. It is an honest assessment of where you now stand on those two axes. How tight is the segmentation within your network, measured in reachable paths from any given workstation. How far does a simulated lateral movement action get before you see anything, measured in steps and in minutes. If either of the two is unclear, that is the conversation you should have first, internally and possibly with someone who looks into it. Only with those two axes on the table does a choice of segmentation platform, detection rule or identity investment become a choice that solves something rather than adds something.