LLMNR, NBT-NS and mDNS: shutting down the fallback name resolution that leaks your NTLM hashes
In our internal penetration tests, name resolution poisoning remains one of the fastest ways to obtain a first authentication secret. It relies on no software vulnerability at all, just on fallback protocols that are enabled by default and rarely useful on a corporate network.
Fallback protocols that trust too easily
When a Windows machine needs to resolve a name, it asks its DNS server first. If the server does not know the name, for example because of a typo in a network path or an old share that has been removed, Windows can fall back on local broadcast mechanisms:
- LLMNR (Link-Local Multicast Name Resolution), a multicast query on the subnet;
- NBT-NS (NetBIOS Name Service), a legacy of NetBIOS over TCP/IP, using broadcast;
- mDNS (multicast DNS), present in recent Windows versions.
None of these protocols authenticates the answer. Any machine on the same network segment can reply "that's me" and the client believes it.
From a spoofed answer to an NTLM hash
Once the spoofed answer is accepted, the client tries to connect to the attacker's machine, often over SMB or HTTP. If the service asks for authentication, Windows automatically sends an NTLM response derived from the user's password. This NetNTLMv2 response can then be subjected to an offline dictionary attack, or relayed in real time to another server that does not require signing. A weak password, or a privileged account browsing to a non-existent name, is enough to open the door.
Disabling LLMNR, NBT-NS and mDNS
| Protocol | How to disable it |
|---|---|
| LLMNR | Group Policy: Computer Configuration, Administrative Templates, Network, DNS Client, "Turn off multicast name resolution" set to Enabled |
| NBT-NS | Microsoft-specific DHCP option that disables NetBIOS over TCP/IP, or a per-adapter setting (the NetbiosOptions registry value) deployed by script or Group Policy preference for statically addressed machines |
| mDNS | DNS client registry setting or Windows Firewall rules; the supported method may change, so check current Microsoft documentation |
Microsoft has also announced its intention to gradually reduce the role of LLMNR and NetBIOS in favour of mDNS: follow these changes so you do not unintentionally re-enable an equivalent protocol.
What might break
In the vast majority of DNS-managed corporate networks, disabling these protocols goes unnoticed. Exceptions to watch for:
- legacy applications or scripts using short names that are not registered in DNS;
- printers, industrial equipment or lab devices discovered by NetBIOS name;
- isolated segments with no DNS server, where machines found each other by broadcast;
- some device discovery or screen sharing features that rely on mDNS.
Roll out to a pilot group first, monitor incidents, then generalise. The fix is usually to add the missing DNS record.
Address the root cause too. Disabling these protocols stops poisoning, but not NTLM relays obtained by other means. Require SMB and LDAP signing, channel binding on LDAPS and HTTPS, and reduce NTLM usage.
What an audit checks
- whether a policy turning off multicast name resolution exists and what it covers;
- NetBIOS over TCP/IP settings on a sample of workstations and servers, statically addressed ones included;
- the status of mDNS on recent clients;
- SMB and LDAP signing requirements that limit how captured hashes can be used.