LLMNR: poisoning, relay and credential theft

LLMNR (Link-Local Multicast Name Resolution) is a protocol defined in RFC 4795 that allows hosts on a local network segment to resolve hostnames when DNS fails to return an answer. LLMNR sends multicast queries over UDP port 5355, expecting any peer on the subnet to respond. This fallback mechanism is enabled by default on Windows Vista and later versions. The security risk is fundamental: any machine on the network can respond to an LLMNR query, even without being the legitimate host. An attacker who intercepts a failed DNS lookup can immediately reply with their own IP address, redirecting the victim's authentication attempt. The victim then sends NTLMv2 credentials to the attacker's machine. This attack chain requires no prior foothold and works on default Windows configurations. LLMNR operates alongside NBT-NS (NetBIOS Name Service) on UDP port 137 and mDNS on UDP port 5353, forming a trio of legacy fallback protocols that each carry the same spoofing risk. Understanding this mechanism is the starting point for any internal network penetration test.

Detecting LLMNR poisoning requires monitoring at both the network and host levels. On the network, capture UDP multicast traffic to 224.0.0.252 on port 5355. Any host responding to LLMNR queries it did not originate is a strong indicator of a rogue responder. IDS rules can flag unexpected LLMNR responses from hosts that are not registered DNS servers. On Windows endpoints, Event ID 4648 (explicit credential logon attempt) and Event ID 4625 (failed logon) in the Security log can indicate that a host sent credentials to an unintended destination. Event ID 5156 in the Windows Filtering Platform log records outbound connections and can reveal authentication attempts toward unknown hosts. SIEM correlation rules should alert when multiple hosts send NTLM authentication to a single non-DC IP within a short time window. Zeek (formerly Bro) can parse LLMNR traffic and log query-response pairs, enabling baseline deviation detection. Deploying honeypot hostnames that should never be resolved is also effective: any LLMNR response to a non-existent hostname confirms an active poisoner on the segment. NetFlow data showing sudden spikes in multicast UDP 5355 traffic is another reliable early indicator.

The standard exploitation tool for LLMNR poisoning is Responder, written in Python. Running 'responder -I eth0 -rdwv' on a local segment immediately begins answering LLMNR, NBT-NS, and mDNS queries with the attacker's IP. Captured NTLMv2 hashes are written to log files and can be cracked offline using Hashcat with mode 5600, or relayed in real time using ntlmrelayx from the Impacket suite. Relay attacks are particularly powerful when SMB signing is not enforced: ntlmrelayx forwards the captured authentication to another host on the network, potentially gaining remote code execution without ever cracking a password. For hardening, Microsoft recommends disabling LLMNR via Group Policy under 'Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution' (set to Enabled). NBT-NS should be disabled through the network adapter properties or via PowerShell on each host. Enforcing SMB signing domain-wide via GPO neutralizes relay attacks even if LLMNR remains active. Network segmentation using VLANs limits the blast radius of a poisoning attack to a single segment. These mitigations are low-cost and high-impact, making them a priority on any internal hardening checklist.