Case File: Pass-the-Hash — Hunting Lateral Movement Over SMB Before the Domain Falls

The Incident Pattern

Pass-the-Hash is lateral movement without the password. An attacker holding an NTLM hash authenticates to a neighboring host over SMB as if they were the legitimate user — no cracking, no plaintext needed. In the logs it looks like a perfectly normal network logon, because cryptographically, it is. The tell isn't in any single event; it's in the pattern: logon type 3 from an unusual source, NTLM where Kerberos should be, admin shares lighting up at odd hours.

This hunt assumes harvested credentials are already in play and asks: where are hashes being replayed across my network right now?

The Hypothesis

Hypothesis: If Pass-the-Hash lateral movement is occurring, we will find NTLM network logons (type 3) to multiple destination hosts from a single source using privileged accounts, inconsistent with that account's normal behavior — particularly logons to admin shares (ADMIN$, C$, IPC$), with mismatched workstation names or NTLM used where Kerberos is the fleet norm.

Data You'll Need

Hunting with KQL

Microsoft Sentinel / Defender — accounts performing NTLM network logons across many hosts (fan-out = lateral movement):

IdentityLogonEvents
| where Timestamp > ago(1d)
| where LogonType == "Network"
| where Protocol == "NTLM"
| where AccountName !endswith "$"
| summarize TargetHosts = dcount(DeviceName), Hosts = make_set(DeviceName), FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by AccountName, AccountDomain, SourceDevice = DeviceName
| where TargetHosts >= 3
| extend SpanMinutes = datetime_diff("minute", LastSeen, FirstSeen)
| project AccountName, AccountDomain, SourceDevice, TargetHosts, Hosts, SpanMinutes, FirstSeen, LastSeen
| order by TargetHosts desc

What this does: finds non-machine accounts authenticating via NTLM network logons from one source to three or more distinct targets within a day — the fan-out signature of hash replay. Machine accounts ($) are excluded since they NTLM legitimately all the time.

True-positive example: FINANCE\jchen | from WS-FIN-014 | 11 target hosts | span: 22 minutes — a finance user account touching eleven workstations via NTLM in under half an hour, including two servers. jchen wasn't at eleven desks tonight. Someone is wearing jchen's hash.

Companion — admin share access corroboration:

DeviceEvents
| where Timestamp > ago(1d)
| where ActionType == "SmbConnectionSuccess"
| where RemoteUrl has_any ("ADMIN$", "C$", "IPC$")
| summarize Targets = dcount(DeviceName) by InitiatingProcessFileName, AccountName = InitiatingProcessAccountName
| where Targets >= 3

Hunting with Splunk

Windows Security log hunt for NTLM type-3 fan-out plus share anomalies:

index=wineventlog EventCode=4624 Logon_Type=3 Authentication_Package="NTLM"
| search NOT Account_Name IN ("*$", "ANONYMOUS LOGON")
| stats dc(Computer) as target_hosts, values(Computer) as hosts,
    earliest(_time) as first, latest(_time) as last by Account_Name, Workstation_Name, Source_Network_Address
| where target_hosts >= 3
| eval span_min = round((last-first)/60, 1)
| sort - target_hosts

What this does: aggregates NTLM network logons by account and source, flagging accounts that hit three or more machines — with the source IP and workstation name for validation.

Example hit: Account_Name=jchen | Workstation_Name=WS-FIN-014 | Source_Network_Address=10.4.2.31 | target_hosts=11 | span_min=22 — and cross-checking EventCode 5140 shows ADMIN$ accessed on four of those hosts. Lateral movement, corroborated twice.

Validating the Hit

1. Is this the account's normal behavior? Compare against 30-day baseline — admins have patterns; attackers have bursts.
2. Check the auth package. NTLM where the fleet normally uses Kerberos is a red flag; verify the destination supports Kerberos to rule out fallback.
3. Verify the human. Was the user actually active? Logon hours, badge data, and interactive session evidence separate PtH from a busy admin.
4. Look for the toolkit. Check the source host for Mimikatz, CrackMapExec/NetExec, Impacket's smbexec, or PsExec artifacts around FirstSeen.

Tuning Out False Positives

• Vulnerability scanners and admin tooling (SCCM, Tanium, admin scripts) fan out over SMB legitimately — baseline their service accounts and source hosts.
• Legacy applications that only speak NTLM generate constant type-3 noise; identify them once and exclude by account.
• Helpdesk remote sessions can look bursty — correlate with ticket systems before escalating.
• Tune the fan-out threshold to your estate: 3+ targets works for most, but large admin teams may need per-account baselines instead of a flat number.

What to Do Next

• Contain: isolate the source host (the beachhead) and any newly accessed targets; disable or force-reset the abused account's credentials.
• Assume the hash is burned: NTLM hashes can't be "changed" without a password reset — reset and consider the account compromised until proven otherwise.
• Harden: push toward Kerberos-only where possible, restrict NTLM via GPO, segment admin tiers (no domain-admin logons to workstations), and enable SMB signing.
• Detect durably: operationalize the fan-out query as a scheduled rule with your tuned exclusions, and alert on first-seen NTLM-to-admin-share combinations.

Filed from the hunt floor: Pass-the-Hash wins because each logon looks legitimate in isolation. Zoom out to the fan-out, and the attack draws itself.