| name | targeted-lateral-movement |
| description | Investigate whether an account moved through a directed chain of hosts (A to B, then B to C) rather than a broad fan-out, which is the signature of an operator pivoting toward a specific target. Use when given authentication logs and asked to trace a pivot path, hop chain, or "how did the attacker get from the initial foothold to X." |
Targeted Lateral Movement
MITRE ATT&CK: T1021 (Remote Services); relevant sub-techniques depend on
observed logon type (.001 RDP, .002 SMB/Admin Shares, .006 WinRM). Often
paired with T1550 (Use Alternate Authentication Material) if hashes/tickets
are being relayed along the chain.
1. Which question am I trying to answer?
Did account X log into system B from system A, and then log into
system C from system B — i.e., is there a directed hop-chain, as
opposed to independent/parallel access to multiple hosts?
2. Which direct evidence do I need?
Per authentication event: Time, Source, Destination, User, Success/Failure,
Logon Type. The distinguishing signal versus indiscriminate lateral
movement is sequence: each hop's destination must equal the next hop's
source, within a bounded time gap, for the same user.
3. Where do I get that data?
- Windows Security.evtx: Event ID
4624 (success), Logon Type field,
correlated with 4648 ("logon using explicit credentials") on the source
host, which is a strong indicator of an operator actively pivoting (e.g.
via runas, PsExec, WMI) rather than a normal interactive session.
- Centralized SIEM auth index spanning all hosts in the suspected path —
a chain analysis is only as good as your ability to see every hop; gaps in
forwarding coverage will silently break chains.
- EDR process-execution telemetry (e.g., Sysmon Event ID 1, or EDR
equivalent) on each hop host, to corroborate that the tool used to reach
the next hop (PsExec, WMIC, PowerShell remoting) is present around the
logon timestamp.
4. How do I analyze that data to answer the question?
Normalize into the shared CSV schema (timestamp, user, source, destination, success, logon_type), then run:
python3 scripts/analyze.py --input auth_events.csv \
--max-hop-gap-minutes 30 --min-hops 2
Logic: for each user, sort successful logons by time and greedily extend a
chain whenever the next event's source equals the current chain's last
destination and the gap between them is within --max-hop-gap-minutes.
Chains with at least --min-hops hops are reported as A -> B -> C -> ....
Tuning: --max-hop-gap-minutes should reflect how quickly a human
operator (or script) could realistically re-authenticate from the newly
reached host — 30 minutes is a reasonable starting point for hands-on-
keyboard activity; tighten it (e.g. 2-5 minutes) if you're hunting for
scripted/automated pivoting instead.
5. What answer does the analysis provide?
One or more directed paths (A -> B -> C -> ...) per user, with start/end
timestamps. This shows a plausible pivot path — it does not by itself prove
the same human/process drove every hop. Before treating it as a confirmed
attacker path:
- Rule out shared jump-host workflows where hopping through a bastion is
expected admin behavior — check whether
B is a designated jump box and
whether this chain shape is common for this user historically.
- Corroborate with
4648 and process execution on the source of each hop
— a chain built purely from 4624 events without any explicit-credential
or remote-execution artifact is weaker evidence than one with both.
- Check directionality against known asset criticality — a chain ending
on a domain controller or credential store is materially higher priority
than one ending on another workstation.
A confirmed chain gives you the pivot path to walk backward from the
suspected objective to the initial foothold, and forward to see how far the
access actually reached.
