Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
When DNS resolution fails for a name, Windows does not simply give up — it falls back to broadcasting the question to the local network segment, trusting whichever host answers first. Three protocols implement this fallback: LLMNR (Link-Local Multicast Name Resolution, RFC 4795), the older NBT-NS (NetBIOS Name Service), and mDNS (multicast DNS, RFC 6762, used heavily by Apple’s Bonjour and Linux’s Avahi). All three share the same fundamental flaw: they are broadcast or multicast, unauthenticated, and answer on a first-response-wins basis, which means any host on the local segment can simply answer every query and have every other host on that segment believe it is whatever name was being resolved.
This is not a theoretical weakness — it is the mechanism behind one of the single most reliable techniques on internal penetration tests: running Responder or a similar tool to poison LLMNR/NBT-NS queries, harvest NTLMv2 challenge/response hashes from every host that mistypes a share name or has a stale DNS cache, and either crack those hashes offline or relay them live to another host. It requires no vulnerability, no privilege, and no user interaction beyond the ordinary behavior of Windows name resolution — which is precisely why it remains effective years after it was first popularized.
Attack Prerequisites
Exploiting link-local name resolution requires very little:
- Layer 2 presence on the target broadcast/multicast domain — the same VLAN or segment as victim hosts; no credentials or prior compromise needed.
- LLMNR and/or NBT-NS enabled on victim hosts, which is the out-of-the-box Windows default — these protocols are not disabled unless an administrator explicitly turns them off via Group Policy.
- A trigger that causes a name-resolution fallback — a mistyped share path, a stale/incorrect DNS record, a misconfigured application referencing a hostname DNS cannot resolve, or WPAD auto-discovery.
- No signing enforcement on the relay target if the goal is relay rather than offline cracking — see SMB signing for why this matters.
How It Works
Windows’ default name-resolution order tries DNS first; if DNS returns no answer (NXDOMAIN, timeout, or the query is for a single-label name DNS cannot resolve), the host falls back to LLMNR, broadcasting a multicast query to 224.0.0.252 (IPv4) or FF02::1:3 (IPv6) on UDP port 5355 asking “does anyone here answer to this name?” If nothing answers LLMNR, it falls back further to NBT-NS, a much older NetBIOS-based broadcast mechanism on UDP port 137. Neither protocol authenticates the responder in any way — the querying host accepts whichever reply arrives first as authoritative, with no verification that the responder actually is the requested name.
An attacker running a listener on the segment — Responder is the standard tool — simply answers *every* LLMNR/NBT-NS/mDNS query it sees, regardless of what name was requested, and tells the victim “that’s me, connect here.” The victim host, believing it has found the legitimate resource, proceeds to authenticate to it exactly as it would to the real server — for an SMB share lookup, that means the victim sends an NTLMv2 challenge/response, which Responder captures. Depending on the workflow, the attacker either takes that captured hash offline for cracking with hashcat, or — if the goal is immediate access rather than a crackable hash — captures the live authentication attempt and relays it in real time to another host on the network that does not enforce SMB signing, gaining an authenticated session as the victim without ever needing to crack anything.
mDNS operates on the same principle over multicast UDP 5353 and is primarily associated with Bonjour/AirPrint/Avahi service discovery rather than Windows name-resolution fallback, but it is exploitable the same way when present: unauthenticated multicast queries answered by whoever responds first. Mixed-OS networks (macOS/iOS/IoT devices alongside Windows) often have all three protocols — LLMNR, NBT-NS, and mDNS — live simultaneously, widening the set of query types (A, AAAA, SRV, service-discovery records) an attacker can poison.
Vulnerable Code / Configuration
The vulnerable state is simply the Windows out-of-the-box default: LLMNR enabled with no Group Policy override, and NetBIOS over TCP/IP left at “Default” (which enables it unless DHCP explicitly disables it):
; LLMNR: enabled by default (no GPO to disable it ships enabled-by-default
; Group Policy value is simply absent, which means enabled)
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
EnableMulticast = (not set) ; absent = LLMNR active
; NetBIOS over TCP/IP per-adapter setting -- "Default" enables NetBIOS
; unless the DHCP scope option explicitly turns it off
HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}
NetbiosOptions = 0 ; 0 = Default (enabled via DHCP or fallback), 2 = Disabled
The hardened equivalents disable both explicitly. Group Policy:
Computer Configuration > Administrative Templates > Network > DNS Client
"Turn OFF Multicast Name Resolution (LLMNR)" = Enabled (i.e. LLMNR is turned off)
; NetBIOS disabled per-adapter, or centrally via DHCP option 001 (Vendor scope)
HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}
NetbiosOptions = 2 ; Disable NetBIOS over TCP/IP
On Linux/macOS hosts, Avahi/Bonjour mDNS is frequently enabled by default with no access restriction beyond network reachability:
# /etc/avahi/avahi-daemon.conf (VULNERABLE default: responds to any query
# from anywhere on the reachable network with no restriction)
[server]
use-ipv4=yes
use-ipv6=yes
# no allow-interfaces / deny-interfaces restriction configured
Walkthrough / Exploitation
Run Responder to passively confirm exposure and capture hashes from natural network traffic (no active probing needed — normal Windows chatter triggers it constantly):
sudo responder -I eth0 -wrf
# -w: start the rogue WPAD proxy -r: respond to NBT-NS -f: fingerprint OS
# Captured NTLMv2 hashes are written to Responder's logs directory automatically.
Crack captured hashes offline, or relay the live authentication instead of capturing it, depending on which non-signing targets are available:
hashcat -m 5600 captured_ntlmv2.txt wordlist.txt # offline NTLMv2 crack
# Or, for live relay instead of capture (requires Responder's SMB/HTTP
# servers disabled in Responder.conf so ntlmrelayx can bind those ports):
ntlmrelayx.py -tf relay_targets.txt -smb2support
Confirm LLMNR/NBT-NS exposure organization-wide as part of an assessment by simply listening — a live capture over a normal business day is usually sufficient evidence without needing to actively poison anything:
sudo responder -I eth0 -A # analyze mode: listen only, do not respond
Note: LLMNR/NBT-NS poisoning captures NTLMv2, not NTLMv1 or cleartext passwords — NTLMv2 is a challenge/response and is not trivially reversible, so its value depends on either successful offline cracking (weak passwords) or live relay to a non-signing target. Neither path requires any vulnerability, only the protocol’s absence of authentication.
Opsec: Responder’s rogue WPAD proxy (
-w) is a separate and additional credential-capture vector beyond LLMNR/NBT-NS poisoning itself — hosts with WPAD auto-discovery enabled will authenticate to the rogue proxy even without ever making a fallback name-resolution query.
Detection and Defense
The fix here is unusually clean: these protocols provide little value on a modern, well-managed DNS estate and can generally be disabled outright:
- Disable LLMNR via Group Policy (“Turn OFF Multicast Name Resolution”) fleet-wide unless a specific, documented dependency exists.
- Disable NetBIOS over TCP/IP per-adapter or via DHCP option, closing the second fallback layer.
- Restrict or disable mDNS/Bonjour/Avahi on hosts that do not need zero-configuration service discovery, and scope it to trusted interfaces where it is required.
- Enforce SMB signing everywhere as a second layer — even if LLMNR/NBT-NS cannot be fully disabled due to legacy dependencies, signing enforcement closes the relay path, leaving only offline cracking of captured hashes as a residual risk.
- Monitor for rogue LLMNR/NBT-NS/WPAD responders — a host answering an unusually high volume of name-resolution queries, or unexpected WPAD PAC file requests, is a strong Responder indicator; several free and commercial tools detect this pattern directly.
- Enforce strong, non-crackable password policy as defense in depth, since captured NTLMv2 hashes are only useful to an attacker if they crack quickly.
Real-World Impact
LLMNR/NBT-NS poisoning via Responder is consistently one of the highest-yield, lowest-effort techniques observed on internal penetration tests and is explicitly cataloged in MITRE ATT&CK as technique T1557.001 (Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay). Its persistence in the field over more than a decade reflects the fact that the protocols remain enabled by default on Windows, that disabling them has essentially no legitimate downside on a properly functioning DNS environment, and that the resulting captured credentials routinely provide the initial foothold for full domain compromise chains.
Conclusion
Link-local name resolution exists to make DNS failures invisible to users, but it does so by trusting whoever answers first on the local network — a design assumption that has no place on a hostile internal segment. Disabling LLMNR, NBT-NS, and unnecessary mDNS, combined with enforced SMB signing as a backstop, closes one of the most reliable and consistently exploited paths into an Active Directory environment, and does so with almost no operational cost on a network where DNS is properly maintained.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments