Haxoris Wiki

LLMNR And NBT-NS Name Poisoning

How LLMNR And NBT-NS Name Poisoning works

LLMNR and NBT-NS are broadcast fallbacks that let any host on a segment answer for a name DNS could not resolve. They live in the default Windows resolution order: when DNS returns nothing, the client shouts the name at the whole broadcast domain and trusts the first reply.

An attacker on the same VLAN answers “yes, that is me” to a mistyped share, a stale login script path or a WPAD lookup, and the victim authenticates to them - handing over NetNTLMv1 or v2 material for offline cracking or coercion. It is easy to miss because everything works: DNS still resolves the names that matter, so the fallback is never noticed until someone listens. This page is about the resolution configuration itself. Turning the captured hash into access - relaying it and the SMB signing that would stop the relay - belongs to the Active Directory section, covered on the NTLM Relay and Signing Gaps page.

LLMNR And NBT-NS Name Poisoning in practice

Observe the fallback passively

Before answering anything, prove the protocols are live and answerable. A read-only capture is safe on any segment and needs no consent to run.

# Watch broadcast name-resolution traffic; no responses sent.
sudo tcpdump -i eth0 -n 'udp port 5355 or udp port 137 or udp port 5353'
# LLMNR = UDP 5355, NBT-NS = UDP 137, mDNS = UDP 5353.
# Any query here means a client will accept a poisoned answer.

Confirm client resolution order from the host side

Read the policy that should have disabled the fallback. This attributes the exposure to configuration, not to one noisy client.

# LLMNR should be off: EnableMulticast = 0
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' `
  -Name EnableMulticast -ErrorAction SilentlyContinue
# NBT-NS per interface: 2 = disabled, 0/1 = still answering
Get-CimInstance Win32_NetworkAdapterConfiguration -Filter 'IPEnabled=TRUE' |
  Select-Object Description, TcpipNetbiosOptions

Run a scoped, consented responder capture

Only inside an authorised, time-boxed window and on the agreed VLAN, run an analysis-mode responder to capture material and prove the answerable path. Keep it analyse-only where the goal is evidence, not credential capture.

# -A = analyse mode: log poisoning opportunities WITHOUT answering.
sudo responder -I eth0 -A
# Evidence run (authorised, scoped): answer LLMNR/NBT-NS, capture NetNTLM only.
# sudo responder -I eth0
# Captured hashes land in /usr/share/responder/logs/ - treat as sensitive.

Record the finding as observable evidence

Tie the capture back to a resolvable-by-anyone name so the report shows configuration, not a fluke.

19:04:11  LLMNR poisoned  -> name "fileservr" (typo of fileserver)
          victim 10.20.4.55  ->  NetNTLMv2 for CORP\j.novak captured
Finding:  EnableMulticast absent on victim; NBT-NS TcpipNetbiosOptions=0
Meaning:  any host on VLAN 20 can answer for mistyped names.
Do NOT:   relay or crack here - hash handling and relay = AD section scope.

How to fix and prevent LLMNR And NBT-NS Name Poisoning

  1. Disable LLMNR by Group Policy
    • Set “Turn off multicast name resolution” to Enabled (EnableMulticast = 0) across all client and server OUs so DNS is the only resolver.
  2. Disable NBT-NS on every interface
    • Push TcpipNetbiosOptions = 2 via DHCP option or a startup script; a per-adapter GUI toggle does not survive re-imaging.
  3. Disable mDNS where it is not required
    • Turn off the mDNS responder on Windows and Linux hosts that have no need for link-local discovery.
  4. Fix WPAD so it fails closed
    • Serve or block wpad by authoritative DNS and disable “Automatically detect settings” so no broadcast WPAD lookup ever leaves the host.
  5. Monitor for residual broadcast queries
    • Alert on UDP 5355 and 137 query volume after rollout; any remaining traffic points at a host the policy did not reach.

Last updated

References