NTLM Hash Theft

NTLM hash theft — also called authentication coercion — is how an attacker on your network gets a usable copy of your Windows login credential without ever asking you for a password. Windows is built to automatically authenticate to file servers using your logged-in identity. The attacker simply points that automatic login at a machine they control.

What they walk away with is your NetNTLMv2 hash — a cryptographic proof of your Windows sign-in. It isn’t your plaintext password, but it’s enough to crack offline at leisure, or to relay in real time to another machine and log in as you.

You never see a prompt, never type a password, never click allow. A mistyped share name or a booby-trapped document is all it takes — your PC hands over your identity on its own.

The attacker plants a lure and waits for Windows to authenticate to it. The most common lure is name poisoning: when your PC looks up a name that DNS can’t resolve — a mistyped \\fileserv, a stale mapped drive, a WPAD proxy query — it falls back to broadcast protocols (LLMNR, NetBIOS-NS, mDNS) that any device on the LAN is allowed to answer. The attacker answers first, says “that’s me,” and your PC opens an authenticated SMB session straight to them.

Other lures skip the typo entirely: a booby-trapped document or email carrying a UNC path like \\attacker\share\pixel.png, or a fake network device advertising a share. Any of them makes Windows reach out and log in on its own.

# Attacker: answer names nobody should, then catch the auto-login
responder -I eth0        # replies to LLMNR / NBT-NS / mDNS / WPAD lookups
# your PC mistypes \\fileserv  ->  attacker answers  ->  Windows authenticates
# your NetNTLMv2 hash lands in the log, ready to crack (hashcat) or relay

Off-the-shelf tools make this a two-part attack: a poisoner like Responder or Inveigh to answer the name lookups, and a fake SMB server (impacket’s smbserver) to receive the login and record the hash.

This detector is a corroborator — built to be false-positive-free. WifiThreatWatch already runs canaries that catch active attackers on your network: name poisoners (LLMNR / mDNS) and rogue SSDP / WS-Discovery devices. Those tell us a device is behaving like a poisoner right now.

Separately, we watch your PC’s own outbound SMB sessions. On its own, a new file-share session is normal churn — you connect to your NAS, a printer, a colleague’s share all the time, so we never alarm on that alone. We fire only on the intersection: your PC just opened an authenticated SMB session to the exact IP a canary already confirmed is actively poisoning this network.

# Which servers is your PC holding an authenticated SMB session to right now?
Get-SmbConnection

# An unfamiliar LAN IP here that isn't your NAS or router is worth a hard look
Get-SmbConnection | Select-Object ServerName, ShareName, UserName, Dialect

That turns a suspicion into a confirmed hash-theft destination — not “a share appeared,” but “you just authenticated to the device that is attacking you.” Because both halves have to be true at the same instant, there’s nothing benign left to mistake it for. You can surface the same session list yourself with Get-SmbConnection.

The confirmed alert names exactly which device to distrust — the LAN IP that both poisoned a name lookup and received your login. You disconnect from it, and with a subscription you can tap Protect Me to change your network identity and bring up an encrypted tunnel so nothing else on the segment can coerce another login out of you.

The durable fix is closing the coercion path itself. On a network you control, turn off LLMNR and NetBIOS-over-TCP/IP — the broadcast name-resolution fallbacks the whole attack depends on. With those gone, a mistyped share name simply fails instead of being answered by whoever shouts first.

For the wider picture, see man-in-the-middle attacks and the full threats library →