LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) poisoning attacks are among the highest-yield, lowest-effort techniques available during an internal network penetration test — and among the most consistently overlooked defenses in enterprise environments. Despite being documented for over a decade, LLMNR/NBT-NS poisoning remains viable on a large share of enterprise internal networks, because the protocols are enabled by default and the defense — disabling them via Group Policy — is rarely applied. Understanding this attack is essential for any security professional defending a Windows environment.
How LLMNR and NBT-NS Work
When a Windows host fails to resolve a hostname through standard DNS, it falls back to LLMNR — a multicast protocol that broadcasts the query to all hosts on the local network segment. If LLMNR fails, it falls back further to NBT-NS, the legacy NetBIOS name resolution protocol. Both protocols operate by broadcasting a name resolution query to the entire subnet and accepting a response from any host that claims to know the answer.
The critical security flaw: there is no authentication or validation on these responses. Any host on the network can respond to an LLMNR or NBT-NS query claiming to be the requested resource, and the querying host will believe it and attempt to authenticate — sending its NTLM credentials directly to the attacker's machine.
The Responder Attack: Step by Step
Setting Up Responder
The Responder tool, maintained by Laurent Gaffie, is the standard implementation for LLMNR/NBT-NS poisoning attacks. Running Responder on a network segment causes it to respond to any LLMNR or NBT-NS broadcast query, presenting itself as the requested resource and capturing credentials from any host that attempts to authenticate:
sudo python3 Responder.py -I eth0 -wrf
The -w flag enables the WPAD (Web Proxy Auto-Discovery) rogue server, -r enables NBT-NS poisoning for reverse lookups, and -f fingerprints remote hosts. Within minutes on an active corporate network, Responder begins capturing NTLMv1 and NTLMv2 challenge-response hashes from workstations that mistype file server names, have misconfigured scripts, or access non-existent network resources.
What Triggers LLMNR Queries
Common triggers for LLMNR broadcasts on corporate networks include:
- Users mistyping a file server name in Windows Explorer (e.g.,
\fileserveinstead of\fileserver) - Stale mapped network drive scripts pointing to decommissioned servers
- Applications with hardcoded hostnames that no longer exist in DNS
- WPAD proxy auto-discovery queries from browsers in environments without WPAD DNS entries
- Print spooler queries and SMB client broadcasts
On a corporate network with hundreds of workstations, at least some of these will occur within the first hour of a penetration test, providing a steady stream of captured credentials.
NTLM Relay Attacks
Beyond simply capturing and cracking hashes, the more dangerous variant is the NTLM relay attack. Rather than responding to the authentication request, the attacker relays the captured credentials to another service in real time — authenticating as the victim user without ever cracking the hash. The ntlmrelayx.py tool from Impacket implements this:
python3 ntlmrelayx.py -tf targets.txt -smb2support
Combined with Responder running in analyze mode (not responding to requests), this setup captures authentication attempts and relays them to target systems. If SMB signing is not enforced on target machines — which is the default for Windows workstations — the relay succeeds and the attacker gains authenticated access as the victim. In environments where the captured credential belongs to a local administrator, this provides immediate code execution on every machine sharing that credential.
NTLMv1 vs NTLMv2
NTLMv1 hashes are significantly weaker than NTLMv2. NTLMv1 uses DES-based challenge-response and can often be cracked using rainbow tables or precomputed tables at crack.sh in seconds for any password. NTLMv2 uses HMAC-MD5 and is salted with a client challenge, making precomputed tables ineffective — but GPU-based cracking with hashcat (mode 5600) is still effective against weak passwords.
Environments still using NTLMv1 are in critical condition. Setting the network security LAN Manager authentication level to "Send NTLMv2 response only / refuse LM & NTLM" via Group Policy is a non-negotiable baseline control.
Detection Strategies
Detecting LLMNR poisoning in progress relies on monitoring for authentication anomalies:
- Event ID 4625 (Failed logon): A machine receives a large number of failed authentication attempts from a single source IP — the Responder host responding with incorrect credentials or as a honeypot trigger
- Event ID 4648 (Explicit credential logon): Workstations attempting authentication to unusual hosts not in their normal peer set
- Network monitoring: LLMNR traffic (UDP port 5355) and NBT-NS traffic (UDP port 137) can be monitored on network taps. Any host responding to these broadcasts (other than the querying host itself) is suspicious.
- Honeypot accounts: Deploy accounts whose credentials would only ever appear if captured by Responder. Any authentication attempt using these credentials is an unambiguous alert.
Remediation: Disabling LLMNR and NBT-NS via Group Policy
The remediation for LLMNR/NBT-NS poisoning is definitive: disable both protocols. These protocols provide minimal legitimate value in modern enterprises where properly-configured DNS is universally deployed.
Disabling LLMNR via Group Policy
Navigate to: Computer Configuration > Administrative Templates > Network > DNS Client
Enable: Turn Off Multicast Name Resolution
GPO path: HKLMSoftwarePoliciesMicrosoftWindows NTDNSClientEnableMulticast = 0
Disabling NBT-NS
NBT-NS is disabled at the network adapter level and requires a PowerShell script deployed as a GPO startup script:
$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration; foreach ($a in $adapters) { $a.SetTcpipNetbios(2) }
Setting value 2 = Disable NetBIOS over TCP/IP.
Requiring SMB Signing
SMB signing prevents NTLM relay attacks against SMB services. Enable it via Group Policy:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Set: Microsoft network server: Digitally sign communications (always) to Enabled.
Set: Microsoft network client: Digitally sign communications (always) to Enabled.
Note that enabling SMB signing has a measurable performance impact on high-throughput file server workloads, but this is an acceptable trade-off for the security benefit. Modern hardware handles the overhead gracefully. Our penetration testing team validates these controls as part of every internal assessment engagement. Contact us to find out if your environment is currently vulnerable.