Back to The Controls Desk
// Controls Desk · 30 April 2026 · Network

Disable LLMNR, NetBIOS-NS and mDNS on Windows networks

Three legacy name-resolution protocols on Windows let any attacker on the LAN poison hostname lookups and harvest hashes from any user that mistypes a server name. Disable them.

Quadrant
Quick win
Ease
4 / 5
Impact
4 / 5
Control family
Network
Cost band
none
Catalogued incidents
7

What the control is

LLMNR (Link-Local Multicast Name Resolution), NetBIOS-NS (NetBIOS Name Service over UDP/137) and mDNS (multicast DNS) are name-resolution fallback protocols that Windows hosts use when a normal unicast DNS lookup fails. The host broadcasts the query to the local subnet and accepts the first reply. The protocols predate Active Directory and exist on modern Windows for backwards-compatibility reasons that have not been operationally relevant for two decades.

Any device on the same broadcast domain can respond to the query, claim to be the requested resource, and either capture the user’s NTLMv2 challenge-response — which can be cracked offline or relayed in real time to an SMB or LDAP service — or simply receive whatever traffic the user thought was going to the legitimate server. The Responder tool, the canonical implementation of the attack, is mature, well-documented and trivially-deployed; the equivalent Inveigh runs natively in PowerShell.

The control is to disable the three protocols at the operating-system level across the estate. Modern Windows can resolve everything it needs to via unicast DNS. The fallback protocols are a residual attack surface with no remaining business value.

Why it matters

LLMNR / NBT-NS poisoning is the entry vector that turns an internal foothold — a phished user, a compromised laptop, a malicious insider with a network port — into domain-credential theft within hours. Once the attacker has a captured NTLMv2 hash for a privileged user, the path to lateral movement is well-trodden: offline crack, SMB-relay to a server with the user’s permissions, or pass-the-hash to any service that accepts NTLM authentication. The technique is registered in MITRE ATT&CK as T1557.001 and appears in incident-response reports across two decades.

The catalogue makes the case indirectly because the technique is upstream of named events rather than the named event itself. The OPM breach of 2015 (federal background-check database, 21.5 million records) used credential-theft-and-lateral-movement of this class as part of the chain. Anthem 2015 (78.8 million health-insurance records), Target 2013 (HVAC vendor pivot to point-of-sale terminals), Operation Aurora (Google and 30 US technology firms in 2010), and Sony Pictures (Guardians of Peace, 2014) all involved internal lateral movement that relied on credential capture from name-resolution-style attacks at some stage. Maersk’s NotPetya recovery story names a single Active Directory domain controller in Ghana as the survivor of a flat-network propagation that started with credential capture and SMB-style lateral movement against unhardened Windows hosts.

The catalogue’s signal is that internal-network credential-capture is the technique that almost every multi-stage Windows-environment intrusion uses. The cleanest mitigation at the protocol layer is to remove the broadcast-fallback channel.

Where the regulators sit

NCSC’s Active Directory hardening guidance recommends disabling LLMNR and NetBIOS-NS as a baseline, citing the broadcast-poisoning risk specifically. Microsoft’s own AD-DS hardening guide says the same and provides the Group Policy and Intune configurations. The NSA’s published Active Directory security guidance — usually issued jointly with CISA — repeats the recommendation across multiple advisories. MITRE ATT&CK lists the technique as T1557.001 with documented detection and mitigation guidance pointing to disablement.

The control is one of the few where the framework guidance has been completely consistent across vendors, agencies and jurisdictions for at least a decade. There is no advocate for keeping these protocols on.

Where it usually breaks

The historical objection was that legacy applications relied on NetBIOS name resolution. In 2026, that population is vanishingly small in any actively-managed Windows estate. The modern objection is closer to “we haven’t got round to it” than to a substantive technical concern. The fix is a phased Group Policy rollout with monitoring on the LLMNR and NetBIOS DNS-client logs to surface any host that is genuinely depending on the fallback before enforcement.

The second failure mode is mDNS. It tends to be left enabled because it’s quieter than LLMNR and the historical AD-hardening writing predates its widespread default-on status. The fix is to disable it by the same mechanism — modern Windows supports the configuration via Intune Cloud Policy or Group Policy.

What good looks like

LLMNR disabled tenant-wide via Group Policy or Intune. NetBIOS-NS disabled via DHCP option 1 or WINS-server-list-empty distributed via DHCP, plus a Group Policy configuring the NetBIOS-over-TCP/IP setting on the network adapter to “disabled.” mDNS disabled via the modern Group Policy or registry mechanism. Endpoint Detection and Response tuned to alert on the appearance of Responder/Inveigh signatures or LLMNR/NBT-NS DNS-client fallback events post-disablement.

The configuration is free. The deployment is a sprint of phased rollout. The control eliminates the most reliable internal-network credential-theft vector that has ever existed on Windows.

Where this control would have changed the outcome

Sources

Back to The Controls Desk