LLMNR and NBT-NS Poisoning Prevention: How to Stop Responder from Capturing Credentials on Your Network
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
LLMNR poisoning is one of the most reliably effective attacks on Windows networks, not because it is sophisticated, but because most environments leave it enabled by default and it requires no prior foothold. Any host on the network segment can run Responder passively and collect NTLM hashes from machines that happen to mistype a hostname or browse to a resource with a DNS failure. The fix is straightforward: disable LLMNR and NBT-NS via Group Policy. This guide covers why these protocols exist, how the attack works, the exact GPO settings to disable them, and what to verify afterward.
Why LLMNR and NBT-NS Exist and Why They Are Dangerous
DNS is the authoritative name resolution mechanism on corporate networks. LLMNR and NBT-NS exist as fallbacks for when DNS fails -- specifically for home networks and small environments without a DNS server. Windows enables both by default, even on domain-joined machines with a working DNS server. When a Windows host sends a request for a hostname that DNS cannot resolve (a typo, a disconnected share, a cached reference to a decommissioned server), Windows falls back to broadcasting an LLMNR multicast query (to 224.0.0.252 for IPv4 or FF02::1:3 for IPv6) and an NBT-NS broadcast to the subnet broadcast address. Any host on the same layer-2 network can respond to these broadcasts. Responder (github.com/SpiderLabs/Responder) is an open-source tool specifically designed to respond to these broadcasts and serve fake authentication services. When the victim Windows host connects to the attacker's fake server, Windows automatically attempts NTLM authentication, sending a Net-NTLMv2 hash. These hashes cannot be passed directly (unlike NTLMv1), but they can be cracked offline or used for NTLM relay attacks.
Disable LLMNR via Group Policy
LLMNR is disabled via Computer Configuration. Open Group Policy Management Console, create or edit a GPO linked to the domain (or to specific OUs). Navigate to: Computer Configuration > Policies > Administrative Templates > Network > DNS Client. Locate the policy 'Turn off multicast name resolution'. Set it to Enabled. This disables LLMNR on all machines the GPO applies to. Verify the setting was applied: run gpupdate /force on a workstation, then check the registry: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient, key EnableMulticast, value 0. On Windows 11 version 24H2 and later, LLMNR is disabled by default. On all older versions, it must be disabled explicitly. Note: disabling LLMNR does not break DNS -- it only stops the fallback multicast broadcast. DNS continues to work normally.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Disable NBT-NS via DHCP or Directly on Adapters
NBT-NS does not have a Group Policy setting for domain environments -- it is configured per-network adapter. The most scalable approach is via DHCP option 001 (NetBIOS node type) if you control DHCP. Set the DHCP scope option 001 to 0x2 (P-node) -- this disables broadcasts. For environments that cannot use DHCP option 001, use a startup script via GPO that sets the registry value directly on each adapter: Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces*' -Name NetbiosOptions -Value 2. Value 2 disables NetBIOS over TCP/IP. Value 0 is the default (use DHCP setting). Value 1 enables it. Deploy this as a PowerShell startup script via GPO: Computer Configuration > Windows Settings > Scripts > Startup. Verify on a test machine: ipconfig /all will show 'Node Type' as 'Peer-Peer' (P-node) when NBT-NS broadcasts are disabled. If your environment uses WPAD (Web Proxy Auto-Discovery), also disable it via GPO and remove the wpad DNS entry -- WPAD uses LLMNR and NBT-NS for discovery and adds additional poisoning attack surface.
Disable mDNS (Bonus Step)
mDNS (Multicast DNS, used by Apple Bonjour and some Linux services) provides a third poisoning channel that Responder also supports. Windows 10 and 11 include an mDNS responder that is enabled by default. Disable via registry: HKLM\SYSTEM\CurrentControlSet\Services\Dnscache, key EnableMDNS, value 0 (REG_DWORD). Deploy via Group Policy Preferences: Computer Configuration > Preferences > Windows Settings > Registry. Add a registry item: Action=Update, Hive=HKLM, Key=SYSTEM\CurrentControlSet\Services\Dnscache, Value name=EnableMDNS, Value type=REG_DWORD, Value data=0. Note: disabling mDNS breaks printing to Bonjour printers and some Apple services. If your environment uses Apple devices on the network, test this change before broad deployment.
Test That the Attack No Longer Works
After deploying the GPO and confirming application via gpupdate /force and gpresult /r, test from a workstation: open a command prompt and try to browse to a non-existent hostname: net use \nonexistenthost\share. Before the fix, this would generate LLMNR and NBT-NS broadcasts for Responder to capture. After the fix, the request should fail with a DNS resolution error immediately, with no broadcast captured. To confirm: run Responder from a test machine on the same segment (with appropriate authorization) and observe whether hashes are captured when Windows machines fail DNS resolution. Also run Inveigh (a PowerShell-based Responder equivalent) to test mDNS specifically: Start-Inveigh -LLMNR N -NBNS N -mDNS Y. If mDNS is disabled, Inveigh should capture no hashes.
The bottom line
Disabling LLMNR and NBT-NS is one of the highest-value, lowest-effort hardening steps for any Active Directory environment. It eliminates an entire class of credential capture that red teams rely on as a standard first move. The risk of breaking legitimate services is near zero in environments with working DNS -- these protocols are legacy fallbacks that modern corporate networks do not need. Do it now.
Frequently asked questions
Will disabling LLMNR and NBT-NS break anything?
In environments with working DNS that covers all resource names, disabling both protocols breaks nothing. The most common compatibility issue is legacy print servers or NAS devices that rely on NetBIOS name resolution instead of DNS -- if you have devices registered only in NBT-NS and not in DNS, those will become unreachable. Before deployment, run Responder in analyze-only mode (Responder.py -I eth0 -A) for 24 to 48 hours to see what LLMNR and NBT-NS queries are being generated and whether they represent legitimate lookups you need to add to DNS. Migrating those records to DNS is the correct fix.
What is the difference between Net-NTLMv1 and Net-NTLMv2?
Net-NTLMv1 hashes can be passed directly in some configurations and cracked much more easily due to known weaknesses in the challenge-response computation. Net-NTLMv2 hashes cannot be passed directly but can still be cracked offline with a GPU and a wordlist, or relayed to other hosts via ntlmrelayx. Both are captured by Responder. If you cannot disable LLMNR immediately, enforce NTLMv2 via GPO (Network security: LAN Manager authentication level = NTLMv2 only) to eliminate the NTLMv1 risk, but that is not a substitute for disabling the protocols.
What is NTLM relay and why is it worse than hash cracking?
Hash cracking requires the attacker to crack the captured hash before they can use it, which may take time or fail against strong passwords. NTLM relay attacks pass the authentication attempt directly to another host in real time without needing to crack the hash. The attacker catches the NTLM authentication from one victim and immediately forwards it to a file server, SMB server, or LDAP server. If the victim has permissions on that server, the relay succeeds. ntlmrelayx (part of Impacket) automates this. SMB signing is the primary defense against relay; disabling LLMNR and NBT-NS prevents the initial hash capture from occurring.
What about IPv6 and WPAD?
IPv6 has its own name resolution broadcast protocol that Responder also supports. Disable IPv6 if it is not in use in your environment. If IPv6 is in use, configure IPv6 DNS and suppress the fallback broadcasts. WPAD (Web Proxy Auto-Discovery) is a separate but related attack -- WPAD queries also use LLMNR and NBT-NS, and even with both disabled, a rogue WPAD response via DNS can redirect web traffic through an attacker proxy. Disable WPAD via GPO if you do not use it.
How do I test if LLMNR and NBT-NS are truly disabled across my environment?
Test from an attacker perspective rather than a configuration review perspective: run Responder in Analyze mode (`python Responder.py -I eth0 -A`) on your network and observe whether any LLMNR or NBT-NS queries arrive. If the interface captures any queries, those machines still have the protocols enabled. This test works from any machine on the same subnet. For a broader verification, use a PowerShell scan against all domain-joined machines: `Get-NetAdapterBinding -ComponentID ms_msclient | Select-Object Name, Enabled` checks NBT-NS binding, and reading HKLM:SOFTWAREPoliciesMicrosoftWindows NTDNSClientEnableMulticast = 0 confirms LLMNR is disabled by policy.
What else does Responder capture beyond LLMNR and NBT-NS, and how does it work as an attack tool?
Responder is a suite that poisons multiple name resolution protocols simultaneously: LLMNR (UDP 5355), NBT-NS (UDP 137), and mDNS (UDP 5353). When a target machine sends a failed DNS query and falls back to LLMNR/NBT-NS, Responder responds claiming to be the requested host and captures the NTLM authentication challenge-response the target sends when connecting. It simultaneously runs rogue servers for SMB (capturing NTLM hashes), HTTP (intercepting WPAD and web auth), LDAP (capturing LDAP binds), and FTP. The captured NTLMv2 hashes can be cracked offline with Hashcat or passed in certain scenarios. Responder is included in Kali Linux and is a standard first step in internal network penetration tests. Disabling LLMNR and NBT-NS removes the poisoning opportunity but does not protect against rogue SMB and HTTP servers -- additional controls (SMB signing, LDAP channel binding) address those vectors.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.