Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Lateral movement is the phase where an adversary who has landed on one host uses stolen or valid credentials to reach additional hosts, almost always via native Windows administration protocols rather than custom malware — SMB (for file copy and remote service creation, ATT&CK T1021.002), WMI (for remote process execution over DCOM/RPC, T1047), and WinRM/PowerShell Remoting (T1021.006). These are “living off the land” by definition: every one of them is a legitimate, widely-used administrative feature, which is exactly why detecting misuse of them is harder — and more valuable — than detecting a dropped malware binary.
This matters because lateral movement is the pivot point between an initial foothold and domain-wide impact; ransomware operators in particular rely almost exclusively on PsExec, WMI, and WinRM to spread before deploying payloads domain-wide, as documented repeatedly in incident write-ups from firms like The DFIR Report. Detecting these protocols’ abuse early, before the adversary reaches a domain controller or backup infrastructure, is consistently one of the highest-leverage points in the intrusion lifecycle to interrupt an attack.
Attack Prerequisites
Detecting lateral movement across these three protocols requires visibility an environment often doesn’t have by default:
- Process telemetry with parent-child lineage — Sysmon Event ID 1 (or Security 4688 with command-line auditing enabled) on every host, not just servers, since lateral movement frequently pivots through workstations.
- SMB share/object access auditing — Security Events 5140 (network share accessed) and 5145 (detailed share object access) require the “Audit Detailed File Share” and “Audit File Share” subcategories to be enabled.
- WMI activity logging — the Microsoft-Windows-WMI-Activity/Operational event log, disabled by default on many builds.
- Authentication correlation — Security 4624 logon events with logon type, source IP/workstation, and authentication package, centrally collected so a single source host touching many destinations is visible.
- Centralized collection — none of this is useful examined host-by-host; it requires aggregation across the fleet to see fan-out patterns.
How It Works
SMB-based movement (classic PsExec and its many re-implementations, including Impacket’s psexec.py) copies a service binary to the target’s ADMIN$ share, then uses the Service Control Manager (SVCCTL RPC interface) to remotely create and start a service pointing at that binary, producing output back over a named pipe. This generates a Security 7045 (“a service was installed”) on the target, 5140/5145 admin-share access, and a distinctive parent process (services.exe spawning the payload).
WMI-based movement (wmic /node:<target> process call create, or Impacket’s wmiexec.py) uses DCOM/RPC (TCP 135 plus a dynamic high port, unless WinRM is used as the transport) to invoke Win32_Process.Create remotely. Critically, this is fileless — no service is installed and no binary is dropped — so the highest-signal artifact is process lineage: the spawned command’s parent is WmiPrvSE.exe, which is abnormal for interactive shells. Impacket’s wmiexec.py specifically has a recognizable command-line pattern because it redirects command output to a file on the target’s ADMIN$ share and reads it back, rather than opening an interactive channel.
WinRM/PowerShell Remoting (Enter-PSSession, Invoke-Command) communicates over HTTP/HTTPS on TCP 5985/5986 using the WS-Management protocol. On the target, the WinRM service hosts the session inside wsmprovhost.exe, which becomes the parent of whatever the remote session executes — an equally distinctive parent-process signal. Authentication produces a Security 4624 logon type 3 (Network), and if PowerShell script block logging is enabled on the target, Event IDs 4103/4104 capture the actual commands run inside the remote session.
Practical Example / Configuration
A Sigma rule detecting the classic WMI lateral-movement parent-child pattern (WmiPrvSE.exe spawning a shell), matching both native wmic usage and Impacket’s wmiexec.py:
title: Suspicious Child Process of WmiPrvSE (Possible WMI Lateral Movement)
id: 8a9f1e10-6b2f-4a2c-9b3e-6d0c9a1f4e77
status: test
description: >
Detects cmd.exe or powershell.exe spawned by WmiPrvSE.exe, consistent
with remote WMI process execution (wmic /node, wmiexec.py, Impacket).
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: '\WmiPrvSE.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
wmiexec_pattern:
CommandLine|contains|all:
- '\Windows\Temp\'
- '2>&1'
condition: selection
falsepositives:
- Legitimate SCCM/monitoring tools invoking WMI locally
level: high
tags:
- attack.lateral_movement
- attack.t1047
Walkthrough / Exploitation
Hunting and alerting across all three protocols in sequence:
1. Baseline: identify legitimate admin sources (jump hosts, PAM/bastion,
patch management servers) so their normal SMB/WMI/WinRM traffic can be
excluded from alert volume.
2. SMB: alert on Security 7045 where the service ImagePath is under
%SystemRoot%\ with a short random name (classic PsExec pattern), or the
literal service name "PSEXESVC"; correlate with 5145 access to ADMIN$
from the same source IP moments earlier.
3. WMI: alert on WmiPrvSE.exe -> cmd.exe/powershell.exe parent-child pairs
(rule above); specifically flag command lines redirecting output to a
temp file and back ("> %TEMP%\... 2>&1"), the Impacket wmiexec
signature.
4. WinRM: alert on wsmprovhost.exe spawning an unexpected child process,
and cross-reference Security 4624 logon type 3 events on port
5985/5986 from source IPs outside the known admin range.
5. Network layer: where available, Zeek's smb_files.log/dce_rpc.log can
confirm the SVCCTL/WMI RPC interface calls independent of host logs,
useful when host logging has gaps.
6. Fan-out detection: stack-count distinct destination hosts touched by a
single source host/account within a short window across all three
protocols — legitimate admin activity is usually narrow and scheduled,
mass lateral movement is broad and fast.
Note: Impacket’s
smbexec.pydiffers fromwmiexec.pyandpsexec.py: it avoids dropping a full service binary by using a semi-interactive shell driven through a temporary service that runs cmd.exe directly, producing a different but still-detectable service-creation pattern. Don’t assume one signature covers the whole Impacket suite.
Opsec: Kerberos double-hop and delegation issues frequently break naive correlation across chained lateral movement (host A to B to C) — the logon on host C may show the identity of host B’s computer account rather than the original operator unless constrained/resource-based delegation is configured, which is a common source of missed multi-hop attribution during investigations.
Detection and Defense
Layered controls reduce both the likelihood and the blast radius of lateral movement over these protocols:
- Segment and restrict — limit ADMIN$/WMI/WinRM access to designated jump hosts/PAWs via host-based firewall rules and Windows Firewall logging on 445/5985/135, rather than allowing any-to-any admin access.
- Enable the right audit policies — Detailed File Share auditing (5145), Kerberos Service Ticket Operations, and the WMI-Activity/Operational log, none of which are on by default.
- Watch parent-child anomalies — WmiPrvSE→shell and wsmprovhost→unexpected child are both high-signal and low-volume enough to alert on directly rather than only hunt.
- Require SMB signing to blunt NTLM-relay-assisted lateral movement, and disable SMBv1 fleet-wide.
- Correlate fan-out across source host/account against destination count in a rolling window as a standing detection, not just a manual hunt query.
Real-World Impact
PsExec, WMI, and WinRM abuse are consistently among the most frequently observed techniques in annual threat detection reports (e.g. Red Canary’s Threat Detection Report) and in ransomware intrusion write-ups from The DFIR Report, where operators behind families like Ryuk and Conti were documented using PsExec and WMI extensively to spread across a domain before deploying encryptors. Impacket’s toolkit — wmiexec.py, psexec.py, smbexec.py — is ubiquitous in both real intrusions and authorized red-team engagements precisely because it reimplements these native protocols rather than introducing new, more easily signatured, malware.
Conclusion
SMB, WMI, and WinRM abuse are hard to detect precisely because they are legitimate administrative protocols, which means signature-only detection fails and behavioral, parent-child, and fan-out-based detection is required instead. The highest-value investments are enabling the audit policies that are off by default (detailed file share access, WMI activity), watching the small set of process-lineage anomalies each technique reliably produces, and restricting where these protocols are allowed to originate from in the first place.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments