LLMNR and NBT-NS Poisoning: How Responder Harvests Windows Credentials

Responder is the reference tool for one of the most reliable attacks on an internal Windows network. It does not exploit a vulnerability in the usual sense. It exploits a fallback behavior that Windows performs by default, and it works on networks that are otherwise well patched. Understanding it teaches you more about name resolution and authentication than almost any other single technique.

The fallback that creates the opening

When a Windows host needs to resolve a name, it tries DNS first. If DNS returns no answer — a typo in a share path, a decommissioned server still in a login script, a mapped drive to a host that no longer exists — Windows does not give up. It falls back to Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS), broadcasting to the local segment: does anyone here answer to this name?

That broadcast is unauthenticated. Any host on the segment may answer, and the first answer wins. An attacker running Responder simply answers every request affirmatively. The victim, having asked the question, believes the reply and connects to the attacker's machine.

The root cause is that these protocols were designed for small trusted segments and were never given any way to verify who is answering. Compare this with properly configured DNS records, where resolution is centrally controlled and an incorrect answer is an administrative error rather than an open invitation.

From a wrong answer to a credential

Connecting is the whole attack. When the victim reaches out to what it believes is a file server, Windows offers to authenticate automatically using the logged-on user's credentials — that is the convenience of single sign-on working exactly as designed. The attacker's fake SMB service issues an NTLM challenge, the client responds, and the attacker now holds an NTLMv2 challenge-response pair tied to a real domain account.

That capture is not a password, but it is crackable offline at high speed, and a weak or reused password falls quickly. The victim sees nothing: the connection fails or hangs briefly, which is indistinguishable from the original typo that started it.

Relay: the version that needs no cracking

The more dangerous variant skips cracking entirely. Instead of storing the challenge-response, the attacker forwards the authentication live to a third system and authenticates there as the victim. If the captured account has administrative rights on the target, the attacker gets code execution without ever learning a password.

Relay depends on SMB signing being unenforced. Signing cryptographically binds the authentication to the session, so a relayed exchange fails validation. Where signing is required, the relay path closes even though the poisoning still works. This is also a good illustration of why Kerberos is the preferred protocol: it binds tickets to a named service, so an authentication issued for one service cannot be replayed against another.

The controls that actually close it

Three changes do most of the work. Disable LLMNR and NBT-NS through Group Policy and DHCP scope options respectively — almost no modern environment needs them, and removing them eliminates the broadcast the attack depends on. Require SMB signing on clients and servers so relay fails even if poisoning succeeds. Enforce strong, unique passwords and restrict where privileged accounts can log on, so a captured hash is both slow to crack and limited in value.

Fix the noise, too. Poisoning only fires when a lookup fails, so cleaning up stale login scripts, dead mapped drives, and wrong hostnames in configuration reduces how often clients broadcast at all.

Detecting it

The attack is loud if you are listening. A single host answering LLMNR and NBT-NS queries for many different names is not normal behavior and is easy to alert on once those queries are being collected into your SIEM. Watch for authentication attempts from one workstation to another outside of expected patterns, which is the relay signature.

A deliberately planted credential is the cleanest trap. Seed a fake account or share name that no legitimate process would ever request, treat any use of it as an incident, and you have a high-confidence detection with almost no false positives — the same logic behind honeytokens.

Exam angles

Know that LLMNR and NBT-NS are fallback name resolution protocols, that they are unauthenticated, and that disabling them is the primary mitigation. Recognize NTLM relay as distinct from hash cracking, and SMB signing as its specific control. Understand that the captured material is a challenge-response, not a stored password. And be ready for the scenario framing: an attacker on the internal network capturing credentials without exploiting any patched vulnerability is describing this attack.