Threat Hunting Exercise: Analyzing Windows Pass-the-Hash Lateral Movement Dataset

This hunt uses a simulated Windows Security dataset (windows_pth_lateral_2022-06-11T150000.json) capturing T1550.002: Pass the Hash, where an adversary who dumped NTLM hashes from one host uses them directly to authenticate to other hosts, bypassing the need to crack the password, via NTLM Type 3 authentication (Logon Type 3) without an interactive logon precursor.

Step 1: Hypothesis Formation

Hypothesis: An account authenticates to multiple remote hosts via NTLM (LogonType=3, AuthenticationPackageName=NTLM) in rapid succession, from a single source host, without any corresponding interactive/RDP logon on that source host by the same account beforehand - consistent with the credential being used programmatically (in-memory hash replay) rather than typed. Indicators:

• Security 4624 LogonType=3, AuthenticationPackage=NTLM, across multiple destination hosts, same source IP, tight time clustering.
• No preceding 4624 LogonType=2/10 (interactive/RDP) for that account on the source host - the account was never "logged in" there in the normal sense, consistent with hash-only usage via a tool like Mimikatz/CrackMapExec.
• NTLM used even though the domain enforces Kerberos-preferred authentication for internal resources - NTLM fallback is itself a mild anomaly on a modern AD environment.
• Destination hosts show local admin-equivalent access (e.g., successful SMB admin-share connection, service creation) immediately following.

Null Hypothesis: A legitimate service or scheduled task authenticates via NTLM by design (e.g., legacy application, network device management). Invalidate via asset/service inventory confirming no such job is documented for this account/host combination, and by checking whether NTLM fallback is expected for that specific resource.

Rationale: Pass-the-hash leaves virtually no artifact on the source host it authenticates to (since it's just NTLM auth), so this hunt validates detecting it via the network-wide pattern - one account, one source, many destinations, NTLM, no interactive precursor - rather than any single-host artifact.

Step 2: Data Sources and Scope

• Sources: Security logs from all domain-joined hosts (4624 logon, 4672 special privileges); Sysmon (Event 3 network connections) on the source host for corroboration.
• Scope: ~2022-06-11T15:00:00-15:20:00 UTC; Source: WKS-DEV-041 (10.110.2.18); Account: it_admin_svc; Destinations: FILESRV02, PRINTSRV01, APPSRV07.
• SIEM Queries (Splunk/ELK):
• NTLM logon fan-out: index=winsecurity EventID=4624 LogonType=3 AuthenticationPackageName=NTLM AccountName="it_admin_svc" | stats dc(dest_host) as targets, values(dest_host) by src_ip
• Missing interactive precursor: index=winsecurity EventID=4624 LogonType IN (2,10) AccountName="it_admin_svc" host="WKS-DEV-041" (expect zero results)
• Admin-share follow-on: index=winsecurity EventID=5140 ShareName="ADMIN$" AccountName="it_admin_svc"

Step 3: Key Findings

Parsed events (7 shown) confirm NTLM-based fan-out authentication to three hosts within 6 minutes, with no interactive logon precursor on the source workstation.

Validation:

• Timeline: Rapid, sequential NTLM authentications to three unrelated hosts within 6 minutes, each followed immediately by administrative share access - a pattern consistent with automated lateral-movement tooling using a replayed hash.
• False Positives: Ruled out legitimate NTLM fallback via the exception list; ruled out legitimate automation via service inventory; the missing interactive-logon precursor is difficult to explain benignly.
• Correlation: Single account, single source host, three destinations in a tight window - high-confidence pass-the-hash lateral movement.

Step 4: Recommendations & Next Steps

• Immediate Response: Disable/reset it_admin_svc credentials immediately (the hash itself, not just the password, must be invalidated by a full reset); isolate WKS-DEV-041 and all three destination hosts for forensic review; hunt for the original credential-dumping event on WKS-DEV-041 (likely an LSASS access) that yielded this account's hash.
• Detection: Sigma-style rule: title: NTLM Logon Fan-Out Without Interactive Precursor → selection: EventID=4624 AuthenticationPackageName=NTLM | stats dc(dest_host) as fanout by AccountName, src_ip, bucket(_time, 15m) | where fanout >= 3 cross-referenced against absence of prior LogonType 2/10 on the source.
• Pro Tip: Disabling NTLM entirely (or restricting it via GPO to an explicit allow-list) is the most durable fix - pass-the-hash is fundamentally an NTLM-protocol weakness that Kerberos-only environments are structurally resistant to; use this hunt's findings to build the business case for NTLM deprecation.

Hypothesis confirmed - NTLM pass-the-hash lateral movement from a single source workstation to three servers within a 6-minute window, with no legitimate interactive-logon precursor!