When a Windows host tries to reach a name that DNS cannot resolve (a typo, a decommissioned share, a WPAD lookup), it falls back to broadcast name-resolution protocols: LLMNR, NBT-NS, and mDNS. These have no authentication: any host on the segment can answer "that's me". By answering, you make the victim connect to you and authenticate, handing you a NetNTLMv2 challenge-response you can crack offline or relay.
Lineage. The poisoning surface is a relic of WINS and NetBIOS name resolution, whose broadcast fallback LLMNR and NBT-NS inherited. Responder made abusing it routine from 2012, and mDNS and IPv6 (mitm6, rogue DHCPv6 and WPAD) are the same idea carried onto newer stacks.
Why it works#
- LLMNR (UDP 5355) and NBT-NS (UDP 137) are multicast/broadcast fallbacks with no source validation.
- mDNS (UDP 5353) behaves similarly for
.localnames. - A mistyped share, a stale drive mapping, or WPAD proxy auto-discovery produces a constant stream of failed lookups to poison.
- When the victim connects to your fake SMB/HTTP service, Windows sends a NetNTLMv2 response automatically, often for a logged-on user and sometimes for a privileged account.
Capturing#
# Responder: answer LLMNR/NBT-NS/mDNS and run rogue SMB/HTTP/etc. to capture NetNTLMv2
responder -I eth0 -wv
# Responder writes captured hashes to per-module files under logs/ (not the
# session log), e.g. logs/SMB-NTLMv2-SSP-<ip>.txt, in hashcat -m 5600 format
hashcat -m 5600 logs/SMB-NTLMv2-SSP-10.0.0.5.txt wordlist.txt -r rules/best64.rule
Target WPAD specifically: many networks never set a real wpad DNS record, so every browser's proxy lookup can be answered, capturing authentication broadly.
From capture to impact#
A captured NetNTLMv2 response has two uses:
- Crack it (
-m 5600) to recover the plaintext, then reuse the credential for spraying and authenticated access. Feasible only if the password is weak. - Relay it without cracking: forward the authentication in real time to another service and act as the victim there. This is the higher-value path, because it works regardless of password strength, as long as the target does not enforce signing.
Downgrading to NetNTLMv1#
Where a host still negotiates the older NetNTLMv1, the response is derived with weak DES and, against a known server challenge, cracks back to the NT hash itself (not merely the password) in hours on a dedicated DES service. Serve a fixed challenge, capture a v1 response, and convert it:
# Responder.conf: set Challenge = 1122334455667788 to force a static, crackable challenge
# then coerce a host (ideally a machine account) to authenticate and capture NetNTLMv1
# submit the captured NetNTLMv1 to crack.sh, which returns the NT hash near-instantly
A coerced machine-account NetNTLMv1 cracked to its NT hash is immediately reusable as pass-the-hash for that computer, which is why downgrading a domain controller's response is a known route to its hash. This needs the target to still accept NetNTLMv1, so it is a legacy-host technique, but it upgrades a one-off capture into a durable credential.
Exploitation notes#
- NetNTLMv2 is not reusable like an NT hash: it is bound to a server challenge, so it only cracks or relays, never pass-the-hash.
- Machine-account responses (
HOST$) are common and useful: a machine account's NetNTLM can be relayed even though its password is random and uncrackable. mitm6abuses IPv6 autoconfiguration (rogue DHCPv6 + DNS) to redirect name resolution more reliably than broadcast poisoning in IPv6-enabled networks, and pairs with relay.
Tools#
- Responder: LLMNR/NBT-NS/mDNS poisoning with rogue capture servers.
- mitm6: IPv6 DNS takeover to redirect and capture/relay authentication.
- Inveigh: PowerShell/C# poisoner for Windows attack hosts.