Correlating Multi-Host Authentication Anomalies to Detect Lateral Movement

Why This Matters

Post-compromise lateral movement is the phase where attackers expand from an initial foothold to high-value targets — domain controllers, file servers, and databases. The 2017 NotPetya outbreak spread through corporate networks in minutes by chaining EternalBlue exploitation with credential reuse over SMB. Detecting lateral movement in time to contain it requires analysts to understand which Windows Event IDs and network artefacts expose account reuse across hosts, and how to pivot across a SIEM to trace a path from patient-zero to the final target.

Core Concept

Lateral movement is the technique by which an attacker uses an initial compromised account or credential to authenticate to, and execute code on, additional hosts within a network. Key Windows Event IDs that expose it:

• Event 4624 (Logon Success): records account name, logon type, source IP, and authentication package. Logon Type 3 (network) is generated by SMB; Type 10 by RDP.
• Event 4625 (Logon Failure): records failed authentication attempts. Clusters from a single source signal brute-force or spray.
• Event 4648 (Logon with Explicit Credentials): generated when a process passes credentials explicitly — characteristic of runas, wmic, and PsExec.
• Event 4698 (Scheduled Task Created): attacker installs persistence or remote execution via task scheduler.

SMB lateral movement (PsExec, Impacket smbexec) creates a named pipe connection and drops a service binary. WMI lateral movement (WMIC, PowerShell Invoke-WmiMethod) leaves a 4648 event and a WMI activity log entry (Microsoft-Windows-WMI-Activity/Operational).

A same-account, multi-host authentication pattern — one account authenticating to 5+ distinct hosts within a short window — is a high-fidelity lateral movement indicator.

Technical Deep-Dive

-- Splunk: identify accounts authenticating to multiple distinct hosts
index=wineventlog EventCode=4624 Logon_Type=3
| stats dc(ComputerName) AS host_count values(ComputerName) AS hosts
       earliest(_time) AS first_seen latest(_time) AS last_seen
  BY Account_Name Source_Network_Address
| where host_count >= 5
| eval duration_min = round((last_seen - first_seen) / 60, 1)
| sort -host_count

-- Splunk: PsExec / remote service installation trace
index=wineventlog (EventCode=7045 OR EventCode=4698)
| eval artifact = case(EventCode=7045, "New Service", EventCode=4698, "Scheduled Task", true(), "Other")
| stats count values(Service_Name) AS names values(Image_Path) AS paths BY ComputerName artifact earliest(_time)
| sort earliest(_time)

# Linux: parse Windows Security event log exported to JSON with jq
# Find 4624 events with logon type 3 from a specific source
jq -r '.[] | select(.EventID == 4624 and .LogonType == "3")
  | [.TimeCreated, .TargetUserName, .IpAddress, .ComputerName] | @tsv' 
  security.json 
  | sort | uniq -c | sort -rn

# Correlate SMB connections from a single source IP across hosts using tshark
tshark -r lateral.pcap 
  -Y "smb2 && smb2.cmd == 1" 
  -T fields -e frame.time -e ip.src -e ip.dst -e smb2.filename 
  | awk '{print $2, $3}' | sort -u

Analytical Methodology

1. Start at the known compromised host. Pull Event 4624 and 4648 logs for the 24 hours surrounding the compromise time. Identify all accounts that logged onto this host from external sources.
2. For each identified account, pivot across all hosts in the domain: query for Event 4624 by that account name. Map the host-to-host authentication path chronologically.
3. Identify logon type 3 clusters — the same source IP authenticating to multiple targets in rapid succession. Logon type 3 via NTLMv2 without a Kerberos ticket is a pass-the-hash indicator (see card .pass-the-hash.v1).
4. Search for Event 4648 to find explicit credential use. The SubjectUserName field reveals the account executing the authentication; TargetUserName is the account whose credentials were passed.
5. Correlate with Event 7045 (new service) and Event 4698 (new task) on destination hosts within the authentication window. These confirm successful remote execution, not merely a logon attempt.
6. Check WMI activity logs (Get-WinEvent -LogName "Microsoft-Windows-WMI-Activity/Operational") for wmiprvse.exe spawning unexpected child processes, which indicates WMI lateral movement.
7. Cross-reference with network logs: SMB lateral movement generates port-445 connections; WMI uses DCOM (port 135 + dynamic RPC). Verify that network flows match the event log authentication path.
8. Document the full lateral movement chain: source host → destination host, timestamp, account used, technique (SMB/WMI/RDP), and any subsequent persistence artefacts on each destination.

Common Analytical Errors

• Ignoring machine accounts: SYSTEM-context services and machine accounts (ending in $) generate constant logon type 3 events for legitimate reasons. Filter on user accounts by excluding names ending in $ unless specifically investigating a machine-account attack.
• Missing the source host pivot: Most analysts query destinations first. Pivot also to the source of lateral movement events — the host originating logon type 3 may itself have been previously compromised.
• Overlooking pass-the-ticket: Kerberos-based lateral movement generates logon type 3 with AuthenticationPackageName = Kerberos. Pass-the-ticket does not require a successful 4625 brute-force phase; look for 4769 (Kerberos service ticket request) anomalies instead.
• Assuming a single path: Sophisticated operators move laterally along multiple simultaneous paths. Build a graph, not a linear chain.

NICE Framework Alignment

Further Reading

• MITRE ATT&CK: Lateral Movement tactic (TA0008) — technique catalogue with detection guidance
• Jai Minton: "Windows Lateral Movement Techniques" (SANS reading room)
• Mark Russinovich: PsExec internals — understanding what artefacts the tool leaves
• Elastic: "Hunting for Lateral Movement using Event Query Language" (EQL blog post)
• Microsoft MSDN: Windows Security Audit Events reference — complete EventID field definitions