indiscriminate-lateral-movement

name	indiscriminate-lateral-movement
description	Investigate whether an account is fanning out to an unusually large number of distinct hosts from a single source in a short time window (indiscriminate lateral movement). Use when given authentication log exports and asked to check for lateral movement, account compromise, worm-like spread, or "how many systems did this account touch."

Indiscriminate Lateral Movement

MITRE ATT&CK: T1021 (Remote Services) — commonly .001 RDP, .002 SMB/Windows Admin Shares, .006 WinRM, depending on the logon type observed.

1. Which question am I trying to answer?

Did account X authenticate to an unusually large number (Y) of distinct systems in a given time window (Z) from a single source — consistent with automated/indiscriminate spread rather than normal admin behavior?

2. Which direct evidence do I need?

Per authentication event: Time, Source, Destination, User, Success/Failure, Logon Type. Distinct-destination fan-out from one source, per user, is the core signal — logon type helps distinguish remote-execution-style access (3, 10) from routine interactive use (2).

3. Where do I get that data?

• Windows Security.evtx (domain controllers and member servers): Event ID 4624 (success) / 4625 (failure), field Logon Type. Centralize via Windows Event Forwarding or a SIEM (Splunk Authentication datamodel, Sentinel SecurityEvent) — pulling from individual hosts one at a time will miss the fan-out pattern.
• Linux: /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) — Accepted password/Accepted publickey and Failed password lines.
• VPN/NPS/RADIUS logs if the source is remote access rather than on-network.
• NetFlow/firewall logs can corroborate destination fan-out when host logs are incomplete, but they don't carry User, so they're a supporting source, not a substitute for authentication logs.

4. How do I analyze that data to answer the question?

Export/normalize events into a CSV with columns: timestamp, user, source, destination, success, logon_type (see repo README for the shared schema). Then run:

python3 scripts/analyze.py --input auth_events.csv \
    --window-minutes 60 --min-destinations 5

Logic: for each (user, source) pair, slide a --window-minutes window over successful logons and count distinct destinations touched inside it. A window with distinct destinations at or above --min-destinations is flagged, with the full destination list printed for review.

Tuning: the defaults (5 distinct hosts / 60 minutes) are a starting point, not a universal constant. Jump boxes, RMM tools, and patch-management service accounts routinely exceed this — baseline those accounts and either exclude them or raise their personal threshold before trusting this against your environment.

5. What answer does the analysis provide?

A list of (user, source, time window, destination count, destination list) tuples where fan-out exceeded the threshold. This is evidence of a pattern consistent with automated/indiscriminate lateral movement — it is not proof of compromise on its own. Before escalating a flag, rule out:

• Known-legitimate fan-out sources: RMM/patch management, backup agents, vulnerability scanners, and admin jump hosts — these are the dominant false-positive driver for this analytic.
• Logon type mismatch: fan-out via type 2 (interactive) on many hosts is a different (and often more concerning) story than type 3/10 — check which logon types drove the flagged count.
• Time-of-day: fan-out during a scheduled maintenance window is lower confidence than the same pattern at 3 a.m. local time for that user.

If those are ruled out, the finding supports pivoting to host-level triage (process execution, new accounts, persistence) on the flagged destinations, starting with the earliest one in the window.