Haxoris Wiki

Unlogged Lateral Movement

How Unlogged Lateral Movement works

Unlogged lateral movement is host-to-host access that leaves no correlated trail in the SIEM, letting an operator pivot across the estate unseen. The mechanics are ordinary administration turned sideways: creating a remote service with sc.exe, executing through WMI or WinRM, registering a scheduled task, or chaining SSH sessions across Linux jump hosts. Each generates a characteristic event - 7045 for a new service, 4698 for a task, 5985 for WinRM, an accepted-key line in sshd - but only if the source is enrolled, the audit policy records it, and a rule correlates it.

The attacker gains free movement between the beachhead and the objective. Once past the first host, pivots blend into normal admin traffic, and without correlation the individual events - even when logged - never assemble into a chain a human reads as intrusion. It is easy to miss because each hop looks locally legitimate: an admin does create services and run WMI. The detection has to span hosts and tie the actions to one identity, which is exactly the correlation an under-tuned SIEM lacks. The finding here is the missing detection, not the movement itself.

Unlogged Lateral Movement in practice

Fix a marked operator identity and a movement plan

Attribution is the whole point. Use one dedicated, authorised test account and a fixed marker string so every event can be tied back and reconciled unambiguously.

Test identity : LAB\svc-purple-test  (authorised, break-glass, watched)
Marker        : CANARY-4471 (in service names, task names, file paths)
Source host   : WKSTN-07  (10.10.20.7)
Targets       : APPSRV5 (10.10.20.15), FILE02 (10.10.20.22), BASTION (10.10.30.9)
Window        : 14:00-14:40, times logged to the second for join

Execute the chain with logged commands

Run each technique deliberately and record the timestamp. Keep every artefact marked so it is trivially reversible and attributable.

# 1. Remote service creation -> expect Security 4697 / System 7045 on APPSRV5
sc.exe \\APPSRV5 create CANARY-4471-svc binPath= "cmd.exe /c whoami > C:\Temp\CANARY-4471.txt"
sc.exe \\APPSRV5 start CANARY-4471-svc

# 2. WMI process execution -> expect 4688 (+ WMI-Activity 5857/5860)
Invoke-CimMethod -ComputerName APPSRV5 -ClassName Win32_Process `
  -MethodName Create -Arguments @{CommandLine='cmd /c echo CANARY-4471'}

# 3. WinRM remote execution -> expect 5985 traffic + 4688 on target
Invoke-Command -ComputerName FILE02 -ScriptBlock { hostname; whoami }

# 4. Scheduled task -> expect Security 4698 / TaskScheduler 106
schtasks /create /s FILE02 /tn CANARY-4471-task /tr "cmd /c echo hi" /sc once /st 14:30
# 5. SSH pivot through the bastion -> expect sshd "Accepted publickey" on BASTION
ssh -J svc-purple-test@10.10.30.9 svc-purple-test@10.10.20.15 'id; echo CANARY-4471'

Reconcile each step against recorded events

Join the action timeline to the SIEM by identity, host and marker. Every row that does not resolve to a correlated alert is the finding.

Step  Technique              Expected event    Logged?   Alerted?   Verdict
----  ---------------------  ----------------  --------  ---------  --------------------
1     Remote service create  7045 / 4697       yes       no         Logged, no rule
2     WMI Win32_Process      4688 / 5857       no        no         Not logged (no cmdline audit)
3     WinRM Invoke-Command   5985 / 4688       yes       yes        Detected (MTTD 6m)
4     Scheduled task create  4698 / 106         yes       no         Logged, no rule
5     SSH -J pivot           Accepted publickey no       no         auditd/sshd silent on BASTION

Steps 1 and 4 are unalerted correlation gaps; steps 2 and 5 are unlogged source gaps. Only step 3 closed.

Measure detection latency and dwell

The chain’s value to an attacker is the time it runs unseen. Report the delta from first action to first alert as the estate’s mean time to detect for this technique set.

# first_action and first_alert as epoch seconds pulled from the plan and SIEM
first_action=$(date -d '14:00:00' +%s)
first_alert=$(date -d '14:06:00' +%s)   # WinRM was the only detection
echo "MTTD seconds: $(( first_alert - first_action ))"
echo "Undetected steps: 4 of 5 -> dwell continues past the window"

How to fix and prevent Unlogged Lateral Movement

  1. Close the source gaps first
    • Enable command-line process auditing (4688) and WMI-Activity logging, and confirm sshd and auditd ship from every jump host; an unlogged step can never be correlated.
  2. Write cross-host correlation, not single-event rules
    • Alert on one identity creating services or tasks on multiple remote hosts inside a short window, tied by account and source IP.
  3. Baseline who may move laterally
    • Remote service creation, WinRM and admin scheduled tasks from a workstation are rare; alert on the actor and source, not just the technique.
  4. Re-run the marked chain after every tuning change
    • Keep the plan and marker as a regression test; a step that returns to unalerted proves a rule or source broke.
  5. Feed dwell metrics back to detection engineering
    • Track MTTD per technique over time so slipping coverage is visible before an incident measures it for you.

Last updated

References