Lateral Movement in the Lab: SMB, WMI and WinRM with a Detection Focus

Lateral movement is not magic: it is an attacker reusing valid credentials inside legitimate protocols. In our GOAD lab with three Windows Server 2019 boxes and a Windows 10 client joined to sevenkingdoms.local, we pivoted from a workstation to the domain controller in under eight minutes using only SMB, WMI and WinRM. The goal here is not to drill pivot after pivot, but to show where each technique screams in the logs and how to write the detection before the real incident. This is defensive research: every command below runs against machines we own, and every technique ends with the telemetry and the Sigma rule that catches it. If you have not built your environment yet, start with Active Directory Pentest: Step-by-Step Kerberoasting in a GOAD Lab to get the ground ready.

Lab setup and the assumed-breach starting point#

We assume breach: the operator already holds one valid credential, obtained in the lab through an LLMNR/NBT-NS poisoning with Responder followed by an offline crack. That is realistic, because lateral movement almost never starts from zero; it starts from a single reused password or a captured hash. Our GOAD topology gives us kingslanding (DC), winterfell and meereen as member servers, and a Windows 10 workstation as patient zero. Before touching any technique we snapshot every VM, enable host-only networking so nothing leaks, and confirm the SIEM is ingesting. Detection engineering only works if the telemetry exists first, so the lab is built telemetry-first and attack-second, always in that order.

SMB execution: psexec and smbexec#

We kicked off with classic SMB through impacket-psexec and smbexec. After grabbing an NTLM hash via Responder, we ran psexec.py sevenkingdoms.local/jaime@10.0.10.10 -hashes :aad3b... and landed as SYSTEM. The noise here is massive: RemComSvc service creation under Event ID 7045, binary write to ADMIN$ triggering Event ID 5145 with share name ADMIN$ and a RelativeTargetName ending in a random .exe. The Sigma rule stays short: filter 7045 where ServiceFileName matches eight random alphanumeric chars followed by .exe and you catch 90 percent of psexec variants without ever touching binary signatures. smbexec is quieter on service creation but chattier on the command channel, spawning cmd.exe /Q /c writing output to a temporary file on the share, which Event ID 5145 also captures.

WMI execution: wmiexec and the WmiPrvSE parent#

WMI shifts the logging surface. Using impacket wmiexec.py or a direct Invoke-WmiMethod, the child process spawns from WmiPrvSE.exe rather than services.exe. In Sysmon this shows up as Event ID 1 with ParentImage=C:\Windows\System32\wbem\WmiPrvSE.exe and CommandLine containing cmd.exe /Q /c which is the textbook wmiexec fingerprint. Pair that with Event ID 3 (network connection) leaving the target on port 445 to ship output back, and your confidence is high. Because no service is created, the 7045 rule never fires here, which is exactly why teams that only watch service installation stay blind to WMI. For broader LOLBin abuse hunting, revisit Hunting Living-off-the-Land Binaries on Windows with KQL and adapt the queries to your stack.

WinRM execution: the operator favorite#

WinRM is the modern operator favorite because it looks like legitimate admin traffic. We fired Enter-PSSession -ComputerName dc01 -Credential $cred and remote Invoke-Command. Indicators land in three places: Microsoft-Windows-WinRM/Operational Event ID 91 (session created), Security Event ID 4624 with LogonType 3 and AuthenticationPackage Negotiate, and Sysmon Event ID 1 with ParentImage=wsmprovhost.exe. A solid Sigma rule correlates wsmprovhost.exe as a parent of any process that is not conhost.exe or csrss.exe within a five minute window, killing the PowerShell DSC baseline noise. WinRM travels over 5985/5986, so a network rule on those ports from a host that has never spoken WinRM before adds another cheap signal.

A fourth vector to watch: DCOM and scheduled tasks#

Two more vectors round out any honest lab. DCOM execution through MMC20.Application or ShellWindows spawns children from mmc.exe or explorer.exe with an unexpected network parent, and it rarely appears in junior detection sets; hunt it by correlating a remote 135/DCOM connection with an anomalous child process. Remote scheduled tasks via schtasks /create /s or the ATSVC pipe leave Security Event ID 4698 and a TaskCache registry write. We add both to the lab so the detection library is not lopsided toward the three headline techniques, because a real intruder switches vectors the moment one gets loud, and a detection program that only covers SMB is a program that trains attackers to use WMI.

Detecting the chain, not the technique#

The part nobody tells you: detecting a single technique is easy; detecting the whole chain is what matters. We built an Elastic playbook that links Responder hit, then hash crack, then first Type 3 logon with an NT hash on a host that user never touched before, then a wsmprovhost or WmiPrvSE spawn within ten minutes. That temporal correlation cut false positives from 40 alerts a day to 2 per week in our simulated lab. The lesson is that atomic rules drown analysts, but sequenced rules with a time window surface the actual attack while suppressing the admin who legitimately uses WinRM every morning. If you are starting fresh with Sigma and Elastic, Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule covers the ELK plus sigmac pipeline we use as the baseline.

Telemetry prerequisites: rules without logs are poetry#

Remember all of this assumes decent telemetry. Without Sysmon running an Olaf or SwiftOnSecurity config, without PowerShell Script Block Logging on (Event ID 4104), and without collecting the WinRM and WMI-Activity channels, your Sigma rules become poetry. In GOAD we shipped a minimal GPO that flips those four switches on every host; the same baseline we recommend in Windows 11 Hardening for High-Risk Offensive Security Workstations for corporate endpoints. Telemetry first, rule second, always in that order, otherwise you are detecting the attacker by the silence of logs that never arrive. Confirm ingestion with a known-good test before you trust a single rule, because a rule that never fires looks identical to a rule watching a channel nobody forwards.

Common pitfalls that blind lateral-movement detection#

Several pitfalls recur. First, baselining against a noisy week: if your admins ran a mass software push during the baseline, psexec-like activity gets whitelisted forever. Second, matching on process name instead of parent lineage, which any operator defeats by renaming the payload. Third, ignoring LogonType 9 (explicit credentials) that pass-the-hash and runas /netonly produce, a signal far cleaner than most teams realize. Fourth, alerting on the first hop only and missing that the interesting movement is the second and third. Fifth, forgetting that legitimate remote administration looks nearly identical, so every rule needs an allowlist of known jump boxes and admin accounts or it will be tuned to death within a week.

Detection checklist and validation with Atomic Red Team#

Before calling a technique covered, walk a checklist: the telemetry channel is collected, the Sigma rule exists and is version-controlled, the rule fires on the attack in the lab, it does not fire on the legitimate admin baseline, and it is chained to at least one preceding signal. Validate every rule with Atomic Red Team, for example T1047 for WMI, T1021.002 for SMB admin shares and T1021.006 for WinRM, then confirm the alert lands in your SIEM with the right severity. A rule you have not fired in anger is a hypothesis, not a detection, and shipping hypotheses to production is how programs accumulate silent blind spots.

From lab to production rollout#

Moving a lab rule to production is its own discipline. Deploy every new Sigma rule in audit or alert-only mode for at least one full business cycle, because the noisiest legitimate lateral movement, patch pushes, backup agents, remote support tools, only shows up when real users and real change windows are involved. Track each rule's true-positive and false-positive rate in a simple spreadsheet, tune the allowlist of jump boxes and service accounts, and only then promote it to a ticketing or auto-response action. Version-control the rules in a git repository so every change is reviewed and reversible, tag each with its ATT&CK technique ID, and schedule a quarterly re-test against Atomic Red Team so a Windows update that changes a process lineage does not silently break your coverage. A detection library is a living codebase, not a one-time deliverable, and the teams that treat it that way are the ones whose SOC actually catches the second and third hop instead of admiring the first.

FAQ#

Can I detect lateral movement with EDR alone and skip Sysmon? A good EDR covers most of this, but the WMI and WinRM channels plus Script Block Logging give you evidence the EDR sometimes summarizes away, and in a breach you want the raw events for the timeline. Run both where budget allows. Which technique is hardest to catch? In our lab WMI is the most under-detected because no service is created and WmiPrvSE is a legitimate everyday process, so teams that key on 7045 miss it entirely; that is precisely why we recommend starting your detection work there rather than on the noisy psexec everyone already catches.

Researcher OPSEC and a short practical cycle#

Finally, researcher OPSEC: lateral movement labs generate hashes, kerberos tickets and samples that cannot leak into your real workstation. We always work in isolated host-only VMs, with snapshots before every run, and we never reuse passwords between lab and personal production. For a wider view of research environment isolation, OPSEC for Security Researchers: Building a Personal Threat Model lays out the model we adopted. Practical takeaway: pick one technique this week (we suggest WMI as the least detected), reproduce it in GOAD, write the Sigma rule, validate with Atomic Red Team T1047, and only then move on. Short cycle, real detection, one technique fully closed before you open the next.