LLMNR Poisoning: How Windows Hands Out Password Hashes on the Network

Someone on the network types \\FILESRV into Windows Explorer — one wrong character, and no server by that name exists in DNS. Instead of returning an error and stopping there, Windows raises its hand and shouts out to everyone on the local network: "does anyone here go by FILESRV?" The attacker, listening in with Responder running on their laptop, replies immediately: "That's me." Windows accepts it, tries to authenticate — and hands over the logged-in user's NTLMv2 hash on a silver platter.

That's LLMNR poisoning. One of the most effective attacks on internal Windows networks, and by far one of the most neglected when it comes to hardening corporate environments.

What LLMNR Is and Why It Exists

LLMNR (Link-Local Multicast Name Resolution) is a Microsoft protocol defined in RFC 4795, introduced in Windows Vista as a name-resolution fallback. Windows' resolution flow works like this: it first tries the local cache, then queries the configured DNS. If DNS fails or doesn't respond, Windows falls back to LLMNR — which sends a UDP multicast packet to every device on the subnet asking who owns that name. Any machine can answer.

The protocol was designed for small networks without a DNS server, where convenience matters more than security. In corporate networks with Active Directory and working DNS, it shouldn't be necessary at all — yet it's still enabled by default on Windows to this day.

How the Attack Works in Practice

The setup is simple: an attacker with access to the local network runs Responder (an open-source tool by Laurent Gaffie, widely used in penetration testing). Responder sits listening for LLMNR and NBT-NS broadcasts on the network. When a machine asks for a name that doesn't exist in DNS, Responder answers by pretending to be that server.

1. The victim tries to reach a share with the wrong name — a typo, a misconfigured script, a broken shortcut, anything that results in an LLMNR query.
2. Responder answers the broadcast, claiming to be that server.
3. The victim's Windows machine tries to authenticate via NTLM with the fake server, sending the logged-in user's NTLMv2 hash.
4. The hash gets captured and can be cracked offline with Hashcat or John the Ripper, or relayed immediately to another system via ntlmrelayx (part of the Impacket project).

What Data Can the Attacker Actually Capture?

The NTLMv2 hash of whichever user is authenticated on the machine at the moment of the attack. The attacker doesn't see the plaintext password — but the NTLMv2 hash can be cracked offline against wordlists or through brute force. If the password is weak or sits in a known list like rockyou.txt, it falls in minutes. If it's a domain password reused across other systems, the damage multiplies.

NBT-NS: The Older Sibling With the Same Problem

NBT-NS (NetBIOS Name Service) is an even older protocol that does basically the same thing: name resolution via UDP broadcast on the local network. Also enabled by default on Windows, also open to the same kind of poisoning. Responder attacks both in parallel.

NBT-NS shows up especially often in networks with legacy infrastructure — Windows Server 2008/2012 boxes still running, old network printers, applications that depend on NetBIOS. Disabling LLMNR without addressing NBT-NS leaves half the vector wide open.

What You Can Do With a Captured NTLMv2 Hash

There are two main options:

• Offline cracking: the hash gets saved and attacked with a GPU and a wordlist. Passwords up to 8 characters with moderate complexity fall within hours on affordable hardware.
• NTLM relay: instead of cracking it, the attacker uses the hash in real time to authenticate against another system on the network — without ever needing to know the password. If the captured user has local admin rights on another machine and that machine doesn't require SMB signing, the attacker gets immediate access.

Can You Use the Hash Without Ever Cracking the Password?

Yes — that's the relay attack. The captured NTLMv2 hash gets relayed to another host before it expires. The ntlmrelayx tool automates this and is documented under MITRE ATT&CK T1557.001. The specific defence against relay attacks is enabling mandatory SMB signing on every host in the environment.

How to Disable LLMNR and NBT-NS

Both measures are simple and cause no impact on networks with correctly configured DNS.

Disabling LLMNR via Group Policy

Computer Configuration
  → Administrative Templates
    → Network
      → DNS Client
        → Turn off multicast name resolution
          → Enabled

On standalone machines without a domain, the same setting can be made via gpedit.msc or directly in the registry: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient, with the DWORD value EnableMulticast set to 0.

Disabling NBT-NS via PowerShell

$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled = True"
foreach ($a in $adapters) {
    $a.SetTcpipNetbios(2)  # 0=DHCP decides, 1=enabled, 2=disabled
}

The SetTcpipNetbios(2) method disables NetBIOS over TCP/IP on each active network adapter. The change takes effect immediately — no reboot required.

Complementary Hardening

Disabling the protocols eliminates the poisoning vector, but the environment gets more robust with a few additional measures:

• Enable mandatory SMB signing: blocks the relay attack even if some LLMNR broadcast slips through. Via GPO: Microsoft Network Server: Digitally sign communications (always).
• Monitor anomalous NTLM authentications: the post on auditing logs with PowerShell on Windows covers how to configure and query security events to detect suspicious authentications.
• Migrate to modern authentication: accounts that use passkeys or FIDO2 have no NTLMv2 hash to capture — the whole attack loses its target.
• Long, unique passwords: hashes of passwords with 16+ random characters resist offline cracking for a practically infeasible amount of time.

For a broader checklist of defensive Windows settings, the post on 10 security settings for Windows 11 covers other measures that complement disabling LLMNR.

Why This Still Shows Up in Audits in 2026

LLMNR has existed since 2007. The poisoning attack has been public and documented since at least 2013. The fix takes less than five minutes via GPO. And it's still routinely found active in corporate network audits.

The reason is that the attack doesn't show up in conventional vulnerability scans — it isn't a CVE, isn't a missing patch, isn't an outdated version. It's a protocol working exactly as designed, in a design that never accounted for adversarial environments. Disabling LLMNR and NBT-NS is the kind of measure that only gets done by someone who already knows the vector exists.

Now you know. Two minutes in gpedit.msc closes this vector in your environment.