This attack has been a staple of internal penetration tests for years, and it keeps working because the underlying behavior is on by default and rarely noticed. Understanding it does not require reverse engineering. It requires understanding what happens when a name lookup fails.
How Windows Resolves a Name
When a Windows machine needs to find another host, say a user mistypes a file server as fileserv instead of fileserver, it works through a sequence. First it checks its local cache and hosts file. Then it queries DNS. If DNS returns nothing, most Windows configurations fall back to two legacy protocols instead of simply giving up.
- LLMNR (Link-Local Multicast Name Resolution) sends the query to a multicast address that every machine on the local segment receives. It is, in effect, shouting "does anyone here know who fileserv is?" to the whole subnet.
- NBT-NS (NetBIOS Name Service) is the even older equivalent, broadcasting the same kind of question over NetBIOS.
Both were designed for small, trusted networks with no DNS server, where being helpful mattered more than being careful. The fatal detail is that neither has any authentication. There is no way for the asking machine to know whether the reply it receives is from the real host or from a stranger who spoke up first.
The Attack
An attacker on the same network runs a listener, the widely used open-source tool for this is Responder, that watches for LLMNR and NBT-NS queries and answers every one of them, claiming to be whatever host was asked for. When the victim's machine hears "yes, I am fileserv, connect to me," it does.
Here is the part that turns a name mixup into a credential theft. Windows tends to connect to file shares using integrated authentication. To prove who the user is, the client automatically sends a challenge-response derived from the user's password, the NTLM authentication exchange, to the server it thinks it is talking to. The attacker's fake server sends a challenge, the victim's machine responds, and the attacker walks away with an NTLMv2 hash for that user, without the user doing anything beyond a fat-fingered path or an application quietly looking for a resource that no longer exists.
The victim never sees a prompt, an error, or a warning. A background process on their machine tried to resolve a name, an attacker answered, and their credentials were sent to the attacker automatically. The whole exchange looks, to the user, like nothing happened at all.
From Captured Hash to Access
A captured NTLMv2 hash is not the password, but it is close enough to be dangerous in two distinct ways.
| Follow-on technique | What the attacker does |
|---|---|
| Offline cracking | Feed the captured hash to a password-cracking rig. A weak or common password falls in seconds; a short one falls in hours. The output is the plaintext password. |
| NTLM relay | Skip cracking entirely. Forward the authentication attempt in real time to another server that accepts it, authenticating as the victim without ever learning their password. This is why unsigned SMB is dangerous. |
Relaying is the sharper risk. If a network does not require SMB signing, an attacker can take an authentication meant for their fake server and replay it against a real one, gaining access as the victim. Combined with a privileged account that mistypes a hostname, this path has ended more than one internal assessment with domain-wide control.
The protocol is doing exactly what it was designed to do. That is the problem. A network built on the assumption that everyone on the local segment is trustworthy has no defense once that assumption is false.
How to Shut It Down
Unlike many attacks, this one has clean, well-understood mitigations that cost nothing but configuration. The fixes stack, so apply as many as you can.
- Disable LLMNR through Group Policy (Turn Off Multicast Name Resolution). Properly functioning DNS makes the fallback unnecessary.
- Disable NetBIOS over TCP/IP on network adapters, ideally pushed through DHCP options so it applies everywhere.
- Require SMB signing across the domain. This directly breaks the relay technique by making forwarded authentication attempts fail integrity checks.
- Segment the network so that a compromised or rogue device on a guest or user segment cannot hear the multicast traffic of sensitive systems. See our guide to network segmentation.
- Use strong, long passwords so that a captured hash resists offline cracking even if one is obtained. Length beats complexity here, as covered in how password hashing works.
Detecting It on Your Network
The mitigations above prevent the attack. Detection tells you whether someone is already trying it. Both are worth having, because a rogue responder is often the first move in a longer intrusion, and catching it early is cheaper than cleaning up after credentials have been relayed.
A few signals are within reach of any team that watches its own traffic:
- Honeytokens. Have a monitoring host periodically request a hostname that does not exist and should never resolve. On a healthy network the request fails silently. If something answers claiming to be that fake host, a responder is running and you have caught it in the act.
- Multicast traffic baselines. LLMNR and NBT-NS queries are normal in small volumes. A device that suddenly answers a large share of them, especially one that answers for many different names, is behaving like a poisoner, not a client.
- Authentication anomalies. A burst of NTLM authentication attempts from a single unexpected source, or logons for accounts that have no business touching a given host, can indicate captured credentials being replayed.
None of this replaces turning the protocols off. Detection is the backstop for the machines and segments where, for compatibility reasons, the fallbacks cannot yet be fully disabled.
The Pattern Behind the Bug
Name-resolution poisoning belongs to the same family as ARP spoofing and DNS cache poisoning: an unauthenticated protocol trusts the first plausible answer it receives on a shared medium. The specific fix differs each time, but the lesson does not. Any protocol that accepts input from the network without verifying who sent it is a candidate for this class of attack.
That principle is why Haven does not rely on network position for trust. Identity is verified cryptographically at the endpoints, so intercepting or impersonating traffic in the middle yields ciphertext and nothing usable. An attacker who owns the local segment can see that a connection happened; they cannot become one of its endpoints. That distinction, authenticating the parties rather than trusting the path, is the durable defense against the whole family.