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
Responder is a LLMNR, NBT-NS, and mDNS poisoner: it listens on a segment for the broadcast name-resolution requests Windows still sends whenever DNS fails to resolve a name, and answers every one of them, claiming to be whatever host was asked for. Windows clients trust that reply and authenticate to the attacker’s fake service using NetNTLM, handing over a challenge-response hash without any user interaction. It requires no vulnerability in the traditional sense — it abuses a legacy fallback protocol that ships enabled by default on nearly every Windows install.
Its impact on an internal assessment is disproportionate to the effort involved: a single unauthenticated laptop on the LAN, running one command, can passively harvest a steady stream of NetNTLMv2 hashes from every workstation that mistypes a share name, has a stale mapped drive, or hits a typo’d UNC path. Those hashes crack offline or, worse, relay live into immediate SMB/LDAP sessions on hosts where SMB signing is not enforced. Because the traffic never touches a domain controller or leaves the broadcast segment, it evades most network-perimeter and DNS-based monitoring entirely.
Attack Prerequisites
Poisoning only works because of how Windows name resolution degrades, so the attack needs:
- Layer-2 presence on the broadcast/multicast domain — a VLAN a compromised host, rogue device, or a dropped implant sits on, since LLMNR/NBT-NS/mDNS do not route past a subnet boundary.
- LLMNR and/or NBT-NS enabled on client machines (the Windows default) with no GPO disabling the fallback protocols, and no DNSSEC/strict split-DNS policy that prevents lookups from ever failing.
- A trigger for a failed DNS lookup — a mistyped share (
\\fileserver\), a decommissioned host still referenced by a script or mapped drive, WPAD auto-proxy discovery, or any application that probes a hostname before falling back to broadcast resolution. - SMB signing disabled or not enforced on the target(s) if the goal is relay to code execution rather than offline cracking of the captured hash.
How It Works
DNS is always tried first. When a Windows host cannot resolve a name via DNS, it falls back — in order — to LLMNR (Link-Local Multicast Name Resolution, UDP/5355, a lightweight peer protocol standardized in RFC 4795) and then NBT-NS (NetBIOS Name Service, UDP/137, a decades-older broadcast protocol). Both are *unauthenticated* and *trust-on-first-answer*: any host on the segment may respond, and the requester accepts the first response it gets with no verification that the replying host is who it claims to be. mDNS (UDP/5353) is the analogous multicast protocol used mainly by Bonjour/AirPrint-aware software but present on many Windows builds too.
Responder puts a network interface into promiscuous listening mode and answers every LLMNR/NBT-NS/mDNS query it observes, claiming to be the requested host. The victim then tries to authenticate to that “resolved” host, most commonly over SMB, and Windows performs NTLM authentication automatically without a prompt: it sends a NetNTLMv2 challenge-response that Responder’s built-in fake SMB, HTTP, LDAP, and MSSQL servers simply log to disk instead of validating. The captured value is not a reversible password but a salted, keyed hash of it — crackable offline with GPU compute, or, more damagingly, relayable *live* to a different host before it expires, using it to open an authenticated session as the victim without ever knowing the plaintext.
Responder ships additional analysis and MITM modules beyond plain listen-and-log: -w starts a rogue WPAD proxy server so any client with “Auto-detect proxy settings” enabled authenticates to Responder while trying to fetch wpad.dat, and the built-in fake HTTP/HTTPS/SMB/MSSQL/FTP servers each prompt for or capture credentials in whatever form that protocol’s client naturally offers them, widening the capture surface well beyond a mistyped share name.
Vulnerable Code / Configuration
The exploitable misconfiguration is that LLMNR, NBT-NS, and mDNS are enabled by default and rarely disabled, either at the OS or via Group Policy. The relevant client-side toggle for LLMNR sits in a GPO ADMX template and, unset, defaults to enabled:
Computer Configuration > Administrative Templates > Network >
DNS Client > Turn OFF Multicast Name Resolution
State: Not Configured <-- VULNERABLE (LLMNR stays enabled, Windows default)
Equivalent raw registry value most orgs never set:
HKLM\Software\Policies\Microsoft\Windows NT\DNSClient
EnableMulticast (DWORD) = 1 ; 1 or missing = LLMNR ON, 0 = OFF
NBT-NS is controlled per-adapter rather than by GPO ADMX and is very rarely turned off fleet-wide because it also underpins some legacy NetBIOS-name browsing; disabling it requires either DHCP option 001 or a per-NIC WMI/netsh setting most environments never touch:
# NetBIOS over TCP/IP setting per adapter (2 = Disable NetBIOS over TCP/IP)
# left at 0 ("Default: use DHCP") almost everywhere, i.e. left ON.
Get-WmiObject Win32_NetworkAdapterConfiguration |
ForEach-Object { $_.SetTcpipNetbios(0) } # 0 = default/EN, 2 = disable
SMB signing is the second half of the vulnerable configuration: the captured hash is only relayable to code execution if the destination host does not require it. RequireSecuritySignature = 0 (or “Negotiate”, not “Required”) on either the SMB client or server policy is what turns a captured hash into an authenticated session rather than just crackable material:
Computer Configuration > Windows Settings > Security Settings > Local Policies
> Security Options
Microsoft network server: Digitally sign communications (always) = Disabled
Microsoft network client: Digitally sign communications (always) = Disabled
Walkthrough / Exploitation
Identify the correct interface and start Responder listening on the target segment, enabling analysis mode first to observe traffic before actively poisoning:
sudo responder -I eth0 -A # analyze-only: see queries, poison nothing
sudo responder -I eth0 -wd # full poison: LLMNR/NBT-NS + WPAD + debug
Within minutes, captured NetNTLMv2 challenge-responses appear in Responder’s log directory (/usr/share/responder/logs/) in hashcat/John format. Crack them offline against a wordlist:
hashcat -m 5600 SMB-NTLMv2-SSP-10.10.20.15.txt rockyou.txt --force
# -m 5600 = NetNTLMv2 mode
Where the target host does not enforce SMB signing, relay the captured authentication live instead of cracking it, using impacket’s ntlmrelayx against a list of non-signing hosts (Responder’s HTTP/SMB listeners must be disabled in Responder.conf first so ntlmrelayx can bind those ports):
# Responder.conf: set SMB = Off and HTTP = Off, then:
sudo responder -I eth0 -wd
# in a second terminal, relay to hosts confirmed signing=False via nxc/CME:
ntlmrelayx.py -tf targets_no_signing.txt -smb2support -c 'whoami'
A relayed session that lands on a host where the victim account has local admin drops straight into command execution or a SAM/LSA secrets dump — the same outcome as a stolen password, obtained without ever seeing a credential prompt.
Note: Responder’s
-wWPAD module is often the highest-yield listener because “Automatically detect settings” is enabled by default in Internet Explorer/WinINET, so nearly every process making an HTTP request on a misconfigured segment probes forwpad.datand authenticates to it, independent of any share-path typo.
Opsec: Responder is extremely noisy to anyone watching multicast/broadcast traffic or running a canary token for it — poisoned answers are trivial to fingerprint with a passive listener like
Conveighin reverse, or with basic mDNS/LLMNR anomaly detection. On a monitored engagement, favor-Aanalyze-only mode first, poison narrowly and briefly, and coordinate timing with the blue-team contact if one exists.
Detection and Defense
The most effective fix removes the attack surface outright rather than trying to catch every poisoned response after the fact:
- Disable LLMNR and NBT-NS via GPO (
Turn OFF Multicast Name Resolution= Enabled) and per-adapter NetBIOS settings; disable mDNS where unused. Requires reliable internal DNS so fallback is never triggered legitimately. - Enforce SMB signing (
Required, notNegotiate) on clients and servers domain-wide to make captured hashes non-relayable even when poisoning succeeds. - Disable WPAD if unused (
Turn off automatic proxy result cache; remove any legacy WPAD DNS/DHCP entries) and disable “Automatically detect settings” via GPO. - Monitor for LLMNR/NBT-NS/mDNS traffic anomalies — a single host answering an unusually high volume of name-resolution queries, or answering for names it does not own, is a strong poisoning indicator; several commercial and open-source canary/honeytoken tools alert on exactly this pattern.
- Use Protected Users / restrict NTLM (
Network security: Restrict NTLM) where feasible so Kerberos is preferred and NTLM fallback — the thing Responder actually captures — is minimized or logged via Event ID 8004. - Long, high-entropy service account passwords so any hash that is captured despite the above resists offline cracking.
Real-World Impact
LLMNR/NBT-NS poisoning via Responder is one of the single most common “quick win” findings in internal penetration test reports; it appears constantly in public CTF write-ups, OSCP-style engagements, and vendor assessment summaries because the enabling misconfiguration — legacy broadcast resolution left on — persists in the vast majority of Windows environments regardless of company size. Combined with ntlmrelayx and unsigned SMB, it is a well-documented path from a single network tap to domain compromise, and remains one of the top initial-foothold techniques cited by red teams and incident responders alike.
Conclusion
Responder does not exploit a flaw in NTLM cryptography — it exploits the trust Windows still places in unauthenticated broadcast name resolution left over from a pre-DNS era. The fix is straightforward and durable: turn the legacy protocols off, require SMB signing so a captured hash cannot be relayed even if one is caught, and monitor the broadcast segment for the unmistakable signature of a host answering queries it has no business answering.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments