Home > Network Pentesting

Responder

Responder is a powerful network exploitation tool used to capture, relay, and abuse authentication traffic in Windows environments. It targets LLMNR, NBT-NS, and MDNS broadcasts—protocols that attempt to resolve hostnames when DNS fails. By poisoning these name-resolution requests, Responder tricks victims into sending hashed credentials or authentication attempts to the attacker. This makes Responder essential for internal network pentesting, credential harvesting, and launching relay attacks.

Understanding Responder’s Role

Responder helps pentesters:

  • Capture NTLMv1/NTLMv2 password hashes

  • Force authentication attempts from Windows hosts

  • Poison LLMNR/NBT-NS/MDNS traffic

  • Harvest usernames, machine accounts, and admin credentials

  • Relay captured hashes to SMB/HTTP/etc.

  • Identify insecure network configurations

  • Launch SMB/HTTP relay attacks for remote code execution

Most corporate networks have LLMNR/NBT-NS enabled by default, making Responder extremely effective.

How Responder Poisoning Works

When a Windows machine tries to reach a hostname that DNS cannot resolve:

  1. The machine broadcasts LLMNR/NBT-NS queries on the LAN

  2. Responder answers “I am that host” (spoofing)

  3. Victim connects to the attacker assuming it’s the legitimate host

  4. Authentication attempt is sent to the attacker (NTLM hashes)

  5. Hashes are captured or relayed to another host

This process requires no interaction from the victim.

Starting Responder

Navigate to Responder’s directory:

cd /usr/share/responder

Start poisoning on an interface (e.g., eth0):

sudo responder -I eth0

Responder begins listening for:

  • LLMNR

  • NBT-NS

  • MDNS

  • SMB

  • HTTP

  • LDAP

  • FTP

  • SMTP

  • Kerberos (limited)

Captured hashes appear in:

Responder/logs/

Capturing NTLM Hashes

Responder automatically grabs NTLMv1 and NTLMv2 hashes.

Look for lines like:

[*] NTLMv2-SSP Client   : WIN10-PC
[*] NTLMv2-SSP Hash     : user::domain:hash

These hashes can be cracked with tools like:

  • hashcat

  • john the ripper

Cracking NTLMv2 (Example)

hashcat -m 5600 hash.txt wordlist.txt

If the password is weak → instant compromise.

Forcing Authentication (WPAD Attack)

WPAD (Web Proxy Auto-Discovery Protocol) is often enabled on Windows networks. Responder exploits this to force automatic authentication.

Enable WPAD in Responder config:

Responder.conf

Set:

WPAD = On

Restart Responder:

sudo responder -I eth0

Victims automatically try to fetch proxy scripts, leaking NTLM hashes.

Credential Harvesting via SMB or HTTP

Responder spoofs SMB and HTTP servers.

SMB captures hashed credentials:

SMB NTLMv2 hash from victim

HTTP captures Basic authentication or NTLM handshake credentials.

These leaks occur whenever users:

  • Open network shares

  • Access mapped drives

  • Mistype hostnames

  • Access internal web apps that fail DNS lookup

Relay Attacks with Responder + ntlmrelayx

Instead of cracking hashes, relay them to another machine for direct access.

Disable SMB in Responder (to allow relaying):

SMB = Off

Start Responder:

sudo responder -I eth0

Start ntlmrelayx (from Impacket):

sudo ntlmrelayx.py -tf targets.txt -smb2support

If a privileged user authenticates, ntlmrelayx can:

  • Get a shell

  • Dump SAM

  • Execute commands

  • Add users

  • Dump LSASS

This leads to instant lateral movement.

Enumerating Hosts That Use LLMNR/NBT-NS

Monitor Responder logs for hostname queries such as:

Query for FILESERVER01
Query for BACKUPSRV
Query for ADMIN-PC

Seeing these queries confirms:

  • LLMNR is active

  • DNS resolution failures are common

  • Internal workstation misconfigurations exist

This creates reliable credential-capture opportunities.

Detecting and Investigating Network Traffic

You can observe poisoned responses with:

Using tcpdump

sudo tcpdump -i eth0 port 5355 or port 137

5355 = LLMNR
137 = NBT-NS

Look for broadcast queries followed by attacker replies.

Responder Logs and Output Analysis

Logs include:

  • NTLMv2 hashes

  • HTTP cleartext creds

  • SMB authentication attempts

  • Hostnames and users

  • WPAD requests

Files typically found in:

Responder/logs/

These logs provide usernames, domain names, and access patterns.

When Responder Works Best

Responder succeeds when:

  • LLMNR is enabled (default Windows setting)

  • NBT-NS is enabled

  • DNS misconfigurations force fallback queries

  • WPAD is enabled

  • Users browse to nonexistent hosts

  • Mapped drives reference dead servers

  • Internal networks lack segmentation

These conditions exist in most enterprise networks.

Preventing Detection

Responder is noisy if run carelessly. For stealth:

  • Disable SMB to avoid conflicts

  • Use ntlmrelayx (relay instead of capture)

  • Limit interface broadcasts

  • Avoid running in high-visibility environments

  • Monitor for logs instead of flooding replies

Stealthy poisoning increases the chance of capturing high-value credentials.

Why Responder Mastery Matters

Responder remains one of the most effective internal network attack tools. It allows pentesters to:

  • Capture high-privilege NTLM hashes

  • Force authentication traffic

  • Perform NTLM relay to compromise servers

  • Map hostname resolution weaknesses

  • Move laterally without initial creds

  • Identify insecure network configurations

Responder turns simple broadcast traffic into powerful credential-gathering opportunities.

Intel Dump

  • Responder captures NTLM hashes via LLMNR/NBT-NS poisoning

  • WPAD attack forces automatic authentication

  • Use ntlmrelayx for relay-based remote access

  • Logs store usernames, hashes, and queried hostnames

  • Disabling SMB enables relaying

  • Highly effective inside Windows enterprise networks

HOME LEARN COMMUNITY DASHBOARD