Lateral Movement Detection: Watching the Intruder Tiptoe Through Your Network

Category: Threat Intel

Tags: lateral-movement, threat-hunting, detection, windows-security, event-logs

Initial access gets the headlines, but lateral movement is where attacks are actually won or lost. An attacker with a foothold on a single workstation is an inconvenience. An attacker who has traversed the network to reach the domain controller, the file server, and the backup infrastructure is a catastrophe. The time between those two states is the detection window -- and for most organisations, it is alarmingly quiet.

This article maps the most common lateral movement techniques to their detectable artifacts, covering the event log evidence, network signatures, and hunt queries needed to catch an intruder mid-tiptoe.

The Detection Challenge

Lateral movement is inherently difficult to detect because it uses legitimate administrative tools and protocols. PsExec is a legitimate SysInternals utility. WMI is a built-in Windows management framework. RDP is how half the IT department does their job. The difference between an administrator and an attacker using these tools is context, not the tools themselves.

This means detection relies on anomaly -- who is using the tool, from where, when, and targeting what. A domain admin using PsExec from the management VLAN at 2pm is normal. A service account using PsExec from a workstation subnet at 3am is considerably less so.

Quick Reference: Tool Detection Matrix

PsExec

PsExec remains one of the most commonly observed lateral movement tools, used by both system administrators and threat actors -- which is precisely why it is both detectable and frequently ignored.

How It Works

PsExec copies a service executable (PSEXESVC.exe) to the target's ADMIN$ share, installs it as a service, and executes the specified command. This sequence leaves artifacts at every step.

Detection: Destination Host

System Event Log -- Event ID 7045 (Service Installed):

Service Name: PSEXESVC
Service File Name: %SystemRoot%\PSEXESVC.exe
Service Type: user mode service
Service Start Type: demand start

Security Event Log -- Event ID 4624 (Logon Type 3):

• Network logon from the source host
• Authentication Package: NTLM or Negotiate
• Source Network Address identifies the originating machine

Sysmon Event 1 (Process Create):

• Image: C:\Windows\PSEXESVC.exe, running as SYSTEM
• Any child processes of PSEXESVC.exe are the remotely executed commands

Hunt Query

Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
  Where-Object { $_.Message -match 'PSEXESVC' }

Detection nuance: Attackers frequently rename PsExec to avoid signature-based detection. Hunt for Event ID 7045 with any suspicious service name, not just PSEXESVC. Metasploit, for instance, creates services with random 7-character alphanumeric names -- a pattern that is trivially detectable if you are looking for it.

WMI Remote Execution

How It Works

Windows Management Instrumentation uses DCOM over TCP 135 to execute commands on remote systems. The command runs as a child process of WmiPrvSE.exe on the target.

Key Detection Point

WmiPrvSE.exe spawning cmd.exe, powershell.exe, or any command interpreter is almost always suspicious. In normal operations, WmiPrvSE handles management queries -- it does not launch shells.

# Sigma pattern -- WMI remote process execution
detection:
  selection:
    EventID: 1
    ParentImage|endswith: '\WmiPrvSE.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection

Source Host Artifacts

• Security Event 4688: wmic.exe process with /node: argument revealing the target
• Prefetch: C:\Windows\Prefetch\WMIC.EXE-*.pf

PowerShell Remoting

How It Works

Enter-PSSession and Invoke-Command use WinRM (TCP 5985 for HTTP, TCP 5986 for HTTPS) to execute PowerShell commands remotely. The remote session runs under wsmprovhost.exe.

Detection: Destination Host

• Security Event 4624: Logon Type 3 (Network)
• Process creation: wsmprovhost.exe spawning child processes
• Prefetch: C:\Windows\Prefetch\WSMPROVHOST.EXE-*.pf
• PowerShell ScriptBlock Logging (Event 4104): captures the actual commands executed

Hunt for: wsmprovhost.exe spawning cmd.exe or powershell.exe -- this indicates remote PowerShell command execution.

RDP (Remote Desktop)

How It Works

RDP is the most visible lateral movement technique because it generates the most artifacts. It also generates the most noise, since legitimate use is widespread.

Detection: Destination Host

Security Event 4624 -- Logon Type 10 (RemoteInteractive):

• Source Network Address identifies the connecting host
• Logon Process: User32

TerminalServices-LocalSessionManager/Operational:

• Event ID 21: Session logon succeeded (user + source IP)
• Event ID 24: Session disconnected
• Event ID 25: Session reconnected

Hunt Query

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object { $_.Properties[8].Value -eq 10 } |
  Select-Object TimeCreated,
    @{N='User';E={$_.Properties[5].Value}},
    @{N='SourceIP';E={$_.Properties[18].Value}}

Source Host Artifacts

These are frequently overlooked but extremely valuable:

• Registry: HKCU\Software\Microsoft\Terminal Server Client\Servers\ -- records every hostname connected to
• Bitmap cache: %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache\ -- cached screen fragments showing what the user saw on the remote system

Pass-the-Hash

How It Works

The attacker uses a stolen NTLM hash to authenticate without knowing the plaintext password. Authentication uses NTLM rather than Kerberos.

Detection

Security Event 4624 -- Logon Type 3:

• Authentication Package: NTLM (not Negotiate or Kerberos)
• Logon Process: NtLmSsp
• Key Length: 0 (indicates hash-based auth, not password-based)

# Sigma pattern -- Pass-the-Hash via NTLM
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: 'NTLM'
    KeyLength: 0
  filter:
    SubjectUserName|endswith: '$'
  condition: selection and not filter

Hunt logic: NTLM authentication in an environment where Kerberos is the norm is suspicious. The same account authenticating via NTLM from multiple source IPs in a short window is more suspicious. NTLM logons from workstation subnets to servers at unusual hours is a pattern worth investigating.

Golden and Silver Tickets

Golden Ticket Detection

A golden ticket is a forged Kerberos TGT created with the stolen krbtgt hash. Detection focuses on anomalies:

• TGT with an unusually long lifetime (default maximum is 10 hours -- golden tickets often use 10+ years)
• Kerberos ticket without a corresponding AS-REQ in domain controller logs
• User account SID mismatches between the ticket and Active Directory

Silver Ticket Detection

A silver ticket is a forged service ticket. Look for:

• Event ID 4769 (Service Ticket Request) that appears without a corresponding TGT request (4768)
• Encryption type anomalies in service ticket responses

Detecting Evidence Cleanup

Sophisticated attackers clean up after themselves. Detecting the cleanup is sometimes easier than detecting the original activity.

Event Log Clearing:

• Event ID 1102 (Security): "The audit log was cleared" -- this event is always worth investigating
• Event ID 104 (System): System log was cleared
• wevtutil.exe cl in process creation logs

Timestomping:

• Sysmon Event 2: File creation time changed -- compare CreationUtcTime with PreviousCreationUtcTime

Audit Policy Requirements

Most lateral movement detections require non-default audit policies. If these aren't enabled, the events simply don't exist:

:: Process creation with command line logging
auditpol /set /subcategory:"Process Creation" /success:enable
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

:: Logon events (essential for Type 3/10 detection)
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

:: Kerberos (for golden/silver ticket detection)
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

Without command-line logging enabled, process creation events (4688) show that wmic.exe ran but not what it targeted. That's the difference between a detection and a shrug.

Building a Hunt Programme

A structured approach to lateral movement hunting:

1. Baseline normal -- understand what legitimate lateral movement looks like in your environment (which accounts, which tools, which hours)
2. Hunt the high-value -- start with techniques targeting domain controllers, backup servers, and credential stores
3. Use BloodHound -- map AD attack paths before the attacker does, then monitor those paths
4. Correlate across hosts -- a single Type 3 logon is noise; the same account performing Type 3 logons across six servers in twenty minutes is a campaign

---

What's Next in the Series

• Threat Hunting 101: Methodology -- the hypothesis-driven hunting process
• MITRE ATT&CK Guide -- mapping these detections to the framework
• Windows Forensics 104: Event Logs -- parsing the event sources referenced here
• Active Directory Attacks -- the offensive perspective on these techniques