targeted-lateral-movement

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.