How do you detect NTLM hash theft?
How an attacker makes Windows hand over your login on its own — and the one command that shows exactly what your PC is authenticated to right now.
NTLM hash theft is silent — no prompt, no password typed. Windows auto-authenticates to file servers using your identity, and an attacker just points that automatic login at a machine they control. You detect it by looking at what your PC is actually logged into: run Get-SmbConnection and watch for a session to a LAN address that isn’t your NAS or router. The airtight tell is when that address is also caught poisoning name lookups — because then your login went to a confirmed attacker.
You didn’t give your password away. Windows did — the moment you mistyped a share name.
What NTLM hash theft actually is
Windows is designed to log you in to file shares automatically, using your current sign-in, so you don’t re-type a password every time you open \\server\share. NTLM hash theft abuses that convenience: an attacker convinces your PC that they are the server, and Windows dutifully authenticates to them — sending a NetNTLMv2 hash, a cryptographic proof of your login. That hash can be cracked offline or relayed live to log in as you.
The trigger is usually name poisoning. When a name can’t be resolved by DNS — a typo like \\fileserv, a stale mapped drive, a WPAD proxy query — Windows falls back to broadcast protocols (LLMNR, NetBIOS-NS, mDNS) that any device on the network can answer. The attacker answers first. It can also be sprung by a booby-trapped document containing a UNC path, with no typo at all.
For the full mechanism, see how NTLM hash theft works and the broader man-in-the-middle family. This guide is about the other side: how you see it.
What the attack looks like
There’s almost nothing to notice at the desk — that’s the point. The evidence lives in two places: on the attacker’s side, a poisoner answering names it shouldn’t; and on your side, an SMB session to a machine you never meant to log into.
# Attacker side (conceptual): answer names nobody should, catch the login responder -I eth0 # replies to LLMNR / NBT-NS / mDNS / WPAD lookups # victim mistypes a share -> attacker answers -> Windows authenticates # a NetNTLMv2 hash lands in the log, ready to crack or relay
- A session to an unfamiliar LAN IP. Your PC is authenticated to an address that isn’t your NAS, router, or a share you use — the single strongest local sign.
- It followed a name that didn’t resolve. A mistyped path, a dead mapped drive, or a WPAD lookup right before the mystery session appeared.
- A device on the network is answering names. Something is replying to LLMNR / mDNS requests it has no business answering — the poisoner.
- Nothing looks broken. No error, no prompt, no slowdown. The absence of symptoms is exactly why it goes unnoticed.
How to check on Windows
The fastest defender move is to list what your PC is authenticated to right now, and sanity-check every server against your own known devices:
# Which servers is your PC holding an authenticated SMB session to?
Get-SmbConnection
# Trim it to the columns that matter, then eyeball the server list
Get-SmbConnection | Select-Object ServerName, ShareName, UserName, Dialect
# Close the most common coercion path on a network you control:
# disable NetBIOS-over-TCP/IP on every adapter (2 = disable)
Get-CimInstance Win32_NetworkAdapterConfiguration | ForEach-Object { $_.SetTcpipNetbios(2) }Any ServerName that isn’t your NAS, router, or a share you deliberately use deserves a hard look. Get-SmbConnection is a live snapshot, though — it shows what’s connected the instant you run it, so a brief coercion can come and go between checks. That’s the gap continuous monitoring fills.
Why a session list alone isn’t enough
Here’s the catch: opening a new SMB session is completely normal. You connect to your NAS, a printer, a colleague’s share dozens of times a day. So you can’t alarm on “a new share appeared” — you’d drown in false positives and learn to ignore the one that matters. The signal is worthless without context.
The context that makes it airtight is pairing it with a confirmed attacker. If a device is already caught red-handed poisoning name lookups, and then your PC opens an authenticated session to that exact IP, the two facts together mean only one thing: you just handed your login to the machine attacking the network. Neither half alone is enough; the intersection has nothing benign left in it.
Catching it automatically
WifiThreatWatch does exactly that pairing. It already runs canaries that catch active poisoners and rogue devices, and it watches your PC’s own outbound SMB sessions. It stays silent on normal share churn and fires only when you authenticate to an IP a canary has already confirmed is poisoning the network — turning a poison alert into a confirmed hash-theft destination. No commands to run, no session list to read. Detection is free.
Go deeper: how we detect NTLM hash theft · man-in-the-middle attacks · the threats library
NTLM hash theft: quick answers
How do I know if my NTLM hash was stolen?
There’s no popup — the theft is silent by design. The most reliable local check is your PC’s live SMB sessions: run Get-SmbConnection in PowerShell and look for an authenticated session to a LAN IP that isn’t your NAS, router, or a known share. The strongest confirmation is when that same IP is also caught doing name poisoning (answering LLMNR/mDNS lookups it shouldn’t), because that pairing means your login went to an active attacker, not a normal server.
Is a stolen NTLM hash the same as my password?
Not exactly, but it’s close enough to matter. The captured value is a NetNTLMv2 hash — a cryptographic proof of your Windows sign-in, not your plaintext password. An attacker can try to crack it offline (weak or common passwords fall fast), or relay it in real time to authenticate to another machine as you without ever recovering the password. Treat a captured hash as a compromised credential.
Does disabling LLMNR and NetBIOS stop NTLM hash theft?
It closes the most common path. Name poisoning tools like Responder work because Windows falls back to broadcast name resolution — LLMNR, NetBIOS-NS, mDNS — when DNS can’t answer, and any device on the LAN can reply to those. Turning off LLMNR and NetBIOS-over-TCP/IP on a network you control means a mistyped share name simply fails instead of being answered by an attacker. It doesn’t stop a booby-trapped UNC path in a document, so it’s a strong mitigation rather than a complete fix.
What does Get-SmbConnection show?
Get-SmbConnection lists the file-sharing (SMB) sessions your Windows PC is currently holding open — the server name or IP, the share, the user account authenticated, and the SMB dialect in use. It’s the fastest way to answer “what am I logged into right now,” and to spot a session to an unfamiliar LAN address that you never intentionally connected to. It’s a live view, not a log, so it shows what’s connected at the moment you run it.
Is NTLM hash theft illegal?
Running name poisoning and hash capture against a network or people you don’t own or have written permission to test is illegal in most jurisdictions — it’s unauthorized interception of credentials. The same tools (Responder, Inveigh, impacket) are legitimate only in authorized penetration testing and security research on systems you control or are contracted to assess. This guide is about detecting the attack as a defender.