Detecting Lateral Movement Without Drowning in Noise

Lateral movement is where an intrusion stops being a single compromised host and starts becoming an incident. It’s also one of the noisiest things to detect, because the techniques attackers use — remote services, admin shares, scheduled tasks — are the same ones administrators use every day.

Start from the technique, not the tool

Tool-specific detections age badly. Anchor detections to the underlying technique and they survive the attacker swapping tooling.

• Remote service creation — a service installed over the network
• Remote scheduled tasks — task registration from a non-local session
• Admin share access — C$ / ADMIN$ writes followed by execution

Build a baseline first

The single biggest lever on false positives is knowing what “normal” east-west traffic looks like in your environment. Before writing a rule, ask: which service accounts legitimately move between hosts, and on what schedule?

A worked example

Here’s the shape of a detection for remote service creation, expressed as pseudo-KQL:

SecurityEvent
| where EventID == 7045              // service installed
| where ServiceFileName has_any ("\\\\", "%COMSPEC%", "powershell")
| summarize count() by Computer, Account, ServiceName, bin(TimeGenerated, 1h)
| where count_ > 0

The has_any filter is doing the real work: legitimate services are rarely installed from a UNC path or launched through a shell interpreter.

Tuning the signal

Once the rule fires, the work isn’t done — it’s begun. Track precision over time and prune the accounts and hosts that generate benign hits. A detection you can’t tune is a detection you’ll eventually mute.

The goal isn’t zero alerts. It’s alerts a human can triage in the time they actually have.