← All posts
detection-engineeringmitre-attack

Detecting lateral movement with behavioural event monitoring

Lateral movement is often the longest and noisiest phase of an attack. Here's how to detect it using MITRE ATT&CK-mapped behavioural signals - before the damage is done.

Once an attacker has an initial foothold, they rarely stay put. Their goal is usually somewhere else - a domain controller, a file server, a database host, or a privileged workstation. Getting there means lateral movement, and that’s where most organisations have their best window to catch an attack before it turns into a breach.

Lateral movement is, in theory, the noisiest phase of an attack. In practice, it often goes undetected because defenders are watching the wrong events, or they’re watching the right events but drowning in alerts that don’t tell a coherent story.

What lateral movement actually looks like

The MITRE ATT&CK framework documents lateral movement under TA0008, but “lateral movement” isn’t a single technique - it’s a category of behaviours. The most common in real incident response are:

  • T1021.002 - SMB/Windows Admin Shares: Attackers authenticate to ADMIN$, C$, or IPC$ on remote hosts to copy tools or execute code. Normal users and service accounts rarely touch admin shares directly.
  • T1021.001 - Remote Desktop Protocol: RDP is legitimate, but a workstation that has never received an inbound RDP session suddenly accepting one from another workstation (not a jump box) is a strong indicator.
  • T1047 - Windows Management Instrumentation: wmic /node:<target> process call create <command> is a classic living-off-the-land lateral movement primitive. It leaves no file on the source host, only telemetry.
  • T1550.002 - Pass the Hash: Credential material captured from memory (via T1003 - OS Credential Dumping) is reused to authenticate without the plaintext password. You won’t see a failed logon, only a successful one from an unusual context.
  • T1570 - Lateral Tool Transfer: Dropping a binary onto a remote host via SMB before executing it. The file creation event on the target is the signal, not the transfer itself.

Each of these has different detection characteristics. Some are loud on the network, some are invisible to perimeter tools but visible on the endpoint, and some only make sense in context.

The problem with point-in-time detection

Most signature-based detections look for individual events: wmic.exe was invoked with /node:, or a new service was created on a remote host. These fire too often on legitimate admin activity, or not at all because the attacker used a slightly different primitive.

Behavioural detection - correlating events across time and context - is what separates a tuned EDR from a collection of YARA rules.

Consider this sequence on a single endpoint:

14:03:11  lsass.exe memory read by taskmgr.exe (unusual parent context)
14:03:44  credential vault access by cmd.exe
14:04:02  net.exe  -> net use \\192.168.10.45\ADMIN$
14:04:09  copy.exe -> \\192.168.10.45\ADMIN$\svc.exe
14:04:17  sc.exe   -> \\192.168.10.45 create svc binPath= "%SystemRoot%\svc.exe"
14:04:19  sc.exe   -> \\192.168.10.45 start svc

Each event is individually explainable. The credential vault access might be a password manager. net use is standard file sharing. sc.exe is how services are managed. But in sequence, within 68 seconds, this is a textbook credential-dump-and-pivot. The detection has to look at the process tree and the timeline together, not each event in isolation.

Signals that matter and signals that don’t

Not all authentication events are equally useful. A few high-signal indicators:

Workstation-to-workstation authentication is almost never legitimate in a well-segmented environment. Users authenticate to servers; workstations don’t need to reach each other. An event where WIN-A4D7 successfully authenticates against WIN-B2F1 - neither being a server - warrants investigation.

Remote process creation without a corresponding interactive session is a key indicator of PsExec-style execution. You’ll see a service start on the target, spawned by services.exe, with a parent that isn’t an interactive user session. The network telemetry on the source will show a short-lived connection to port 445.

Authentication fan-out - a single account or endpoint authenticating against five or more distinct hosts within a 10-minute window - is almost always tooling, not a person. Humans don’t log into fifteen machines in ten minutes.

Living-off-the-land binaries (LOLBins) invoked with remote target arguments: wmic.exe /node:, winrs.exe -r:, mmc.exe making network connections. These aren’t inherently malicious but become highly suspicious when they appear shortly after a credential access event.

Mapping detections to coverage

When you’re building or evaluating your detection coverage, MITRE ATT&CK gives you the vocabulary, but coverage is meaningless without specificity. “We cover T1021” is vague. The useful questions are:

  • Do you detect admin share access from workstation-class hosts, or only from endpoints matching known server patterns?
  • Can you correlate a credential dump event to subsequent authentication events from the same endpoint within a configurable time window?
  • Do you have visibility into both source and target endpoint telemetry, or only one side?

Without 90-day telemetry depth and process-tree context, you can catch individual events but you can’t reconstruct the campaign. That’s the difference between alert-driven response and investigation-driven response.

If you’d like to see how LightEDR maps lateral movement detection across the ATT&CK matrix, get in touch via the contact page.