Inside almost every Windows network, there is a quiet weakness that red teamers reach for in the first ten minutes of an internal engagement. It rarely requires an exploit, a CVE, or a single line of shellcode. It abuses how Windows hosts ask each other "who are you?" when DNS fails to answer. That family of techniques is name resolution poisoning, and it targets three broadcast and multicast protocols: LLMNR, NBT-NS, and mDNS.
This guide breaks down how these protocols work, why they leak credentials, and how to both exploit and defend against them with professional-grade tooling. Everything here is written for authorized testing in environments you own or have explicit permission to assess.
Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and Multicast DNS (mDNS) are all fallback name resolution mechanisms. When a Windows machine tries to resolve a hostname and the DNS server has no answer, the operating system does not give up. Instead, it shouts the query to the entire local subnet and trusts whoever answers first.
These protocols were designed for convenience in small or zero-configuration networks. LLMNR (UDP 5355) and NBT-NS (UDP 137) let hosts find each other without a configured DNS server. mDNS (UDP 5353) powers service discovery for printers, casting devices, and Apple Bonjour services. In a home network with three devices, this is harmless. In a corporate Active Directory environment with thousands of endpoints, it becomes an attacker's microphone.
The core problem is trust. None of these protocols authenticate the responder. When a workstation broadcasts a request for a mistyped share name such as \\fileservr\data, any device on the subnet can reply: "That is me." The victim then attempts to authenticate to the attacker, handing over the user's NTLMv2 challenge and response. The victim believes it is talking to a legitimate server, but it is talking to a rogue listener.
This is the foundation of every attack covered below. If you want a structured path through Windows internals and Active Directory abuse like this, the hands-on tracks at Redfox Cybersecurity Academy walk through these primitives in lab conditions.
The attack is elegant because it is passive at the start. You do not chase victims. You wait for a host to make a mistake, which happens constantly on busy networks.
A typical poisoning sequence looks like this:
The beauty for an attacker, and the nightmare for a defender, is that no malware touches disk and no obvious alert fires on a default Windows configuration.
Before running anything against production, build an isolated lab. A minimal setup includes a Windows Server domain controller, two domain-joined Windows workstations, and an attacker host running a recent Kali or Parrot build on the same Layer 2 segment.
Confirm your interface and that you sit on the same broadcast domain as the victims:
ip -br addr show
ip neigh show
[cta]
You want the attacker and victims to share the same subnet, because LLMNR, NBT-NS, and mDNS are link-local. Routing across subnets stops the multicast and broadcast traffic, which is also your first hint about a network-level defense later in this article.
Responder is the standard tool for this work. It spins up rogue LLMNR, NBT-NS, and mDNS listeners along with poisoned SMB, HTTP, and other servers to collect authentication material.
Start by reviewing the configuration so you control which servers run:
sudo nano /etc/responder/Responder.conf
[cta]
For pure hash harvesting, keep the SMB and HTTP servers enabled but consider disabling them if you plan to relay instead of capture, since you cannot capture and relay on the same port at the same time. Now launch Responder in analyze mode first to observe traffic without poisoning:
sudo responder -I eth0 -A
[cta]
Analyze mode is a professional courtesy to yourself and the client. It shows you which hosts are broadcasting and how noisy the segment is before you actively answer anything. Once you understand the environment, switch to active poisoning with verbose, detailed wtmp logging:
sudo responder -I eth0 -dwv
[cta]
When a victim falls for the poisoned response, you will see a captured NTLMv2 hash in the console and in the logs directory. Pull captured hashes from the standard location:
ls -la /usr/share/responder/logs/
cat /usr/share/responder/logs/SMB-NTLMv2-SSP-10.0.0.55.txt
[cta]
Each captured hash follows the familiar NTLMv2 format that begins with the username and domain, followed by the server challenge and the response blob. That single line is everything you need to begin offline cracking. Practicing this capture-to-crack loop end to end is exactly the kind of workflow reinforced in the Windows Red Teaming course at Redfox Cybersecurity Academy.
NTLMv2 hashes are not directly usable for pass-the-hash, so the next step is to recover the plaintext password offline. Hashcat mode 5600 handles NetNTLMv2.
Place a single captured hash line into a file and run a straight dictionary attack first:
hashcat -m 5600 ntlmv2.txt /usr/share/wordlists/rockyou.txt -O -w 3
[cta]
If the wordlist alone fails, layer on rule-based mutation to cover predictable password patterns like seasons, years, and symbol substitution:
hashcat -m 5600 ntlmv2.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule -O -w 3
[cta]
For organizations with stronger password policies, build a targeted mask attack that reflects the policy, for example eight characters with an uppercase start, lowercase middle, and trailing digits and symbol:
hashcat -m 5600 ntlmv2.txt -a 3 '?u?l?l?l?l?l?d?s' -O -w 3
[cta]
A recovered domain password is often the pivot point that turns a quiet listener into full domain compromise. Understanding password cracking strategy, mask design, and rule tuning at this depth is core material in the structured curriculum offered through Redfox Cybersecurity Academy.
Responder covers the classic trio, but modern engagements increasingly lean on mDNS and IPv6 to reach hosts that ignore LLMNR and NBT-NS. Two tools extend your reach significantly.
Pretender is a Go-based tool built specifically to poison mDNS, LLMNR, and DNS over both IPv4 and IPv6. It is designed to feed captured authentication straight into a relay tool, which makes it a strong companion to Responder when you want clean separation between poisoning and relaying.
Run a dry run first to see what Pretender would answer without actually responding:
sudo ./pretender -i eth0 --dry
[cta]
When you are ready, run it for real and tell it to spoof for the relay workflow, disabling its own built-in answers for the protocols you want a relay tool to handle:
sudo ./pretender -i eth0 --spoof-types all --dns-reply 10.0.0.10
[cta]
Pretender shines in environments where mDNS chatter from macOS devices, printers, and casting hardware floods the segment. By answering those queries, you capture authentication that LLMNR-only tools would never see.
Most Windows networks run dual-stack, and Windows prefers IPv6 over IPv4. Critically, IPv6 is frequently unmanaged: there is no DHCPv6 server, yet Windows clients keep asking for one. mitm6 abuses this by becoming the rogue DHCPv6 server and registering itself as the primary DNS server for victims.
Launch mitm6 scoped to the target domain so you do not poison the entire segment indiscriminately:
sudo mitm6 -d corp.local -i eth0 --ignore-nofqdn
[cta]
Once victims renew their addressing, they query your attacker host for DNS, including the all-important WPAD lookup. This sets up the most reliable relay chain in modern internal testing. The interplay between IPv6 takeover and Active Directory is a deep topic, and it is exactly where the advanced Windows Red Teaming Extreme track at Redfox Cybersecurity Academy spends meaningful lab time.
Cracking is reliable but slow. Relaying is faster and does not require the password to be weak. Instead of capturing the NTLMv2 response and cracking it, you forward it in real time to a target service that does not enforce signing, authenticating as the victim against a system you choose.
The Impacket suite provides ntlmrelayx, the workhorse for relay attacks. Before relaying, disable Responder's SMB and HTTP servers in its configuration so the ports are free, then point ntlmrelayx at a target that lacks SMB signing.
A classic SMB relay that dumps the local SAM database on a vulnerable host looks like this:
impacket-ntlmrelayx -tf targets.txt -smb2support
[cta]
The targets.txt file should contain only hosts you have confirmed do not enforce SMB signing. You can build that list quickly, which the detection section below revisits from the defender side.
The most powerful chain pairs IPv6 takeover with LDAP relay against a domain controller. With mitm6 feeding poisoned DNS and a rogue WPAD response, ntlmrelayx can relay authentication to LDAPS and grant the attacker-controlled account delegation rights or create a new computer object.
Run the relay against the domain controller over LDAPS while hosting a WPAD file:
impacket-ntlmrelayx -6 -t ldaps://dc01.corp.local -wh attacker-wpad --delegate-access
[cta]
If a privileged account or a domain controller machine account authenticates through this chain, the result can escalate toward resource-based constrained delegation abuse and, ultimately, domain compromise. This is why name resolution poisoning is treated as a high-severity finding rather than a low-risk annoyance. Building this full attack path safely in a lab is the kind of scenario that the practical labs at Redfox Cybersecurity Academy are designed around.
Once you recover credentials or establish relayed access, you need to confirm what that access actually grants. NetExec, the maintained successor to earlier network execution frameworks, is ideal for spraying recovered credentials and enumerating reach across the environment.
Validate a recovered credential and enumerate accessible shares across a subnet:
netexec smb 10.0.0.0/24 -u jsmith -p 'Summer2025!' --shares
[cta]
Just as important for both attackers and defenders, NetExec can map which hosts enforce SMB signing, since unsigned hosts are precisely the relay targets identified earlier:
netexec smb 10.0.0.0/24 --gen-relay-list relay_targets.txt
[cta]
That generated list feeds directly back into ntlmrelayx, closing the loop between discovery and exploitation. From a defensive standpoint, every host that appears on that list is a liability waiting to be fixed.
Defenders are not helpless. Because legitimate LLMNR and NBT-NS responses are rare in a well-run network, their presence is itself a signal. The single most effective detection is the honeypot query: send a request for a hostname that does not exist anywhere and see if anyone answers.
A lightweight detection approach uses a deliberately bogus name. From a monitoring host, periodically resolve a name that should never resolve, then alert if a response arrives. You can script this with a simple loop and watch for unexpected answers:
nslookup thishostdoesnotexist-redfox-canary
[cta]
On the wire, a packet capture filtered for the relevant ports reveals poisoning activity quickly. Capture LLMNR, NBT-NS, and mDNS traffic and look for a single host answering many different name queries:
sudo tshark -i eth0 -f "udp port 5355 or udp port 137 or udp port 5353" -Y "llmnr or nbns or mdns"
[cta]
In a SIEM, hunt for Windows event ID 4624 and 4648 logon events that originate from unexpected source hosts, paired with sudden bursts of authentication to a single endpoint. A workstation that suddenly receives SMB authentication from dozens of peers is a textbook poisoning indicator. Pairing this telemetry with network detection gives defenders strong coverage, and learning to think from both the offensive and defensive sides at once is a recurring theme across Redfox Cybersecurity Academy coursework.
Detection catches attacks in progress. Hardening removes the attack surface entirely. The goal is simple: stop hosts from using insecure fallback name resolution, and stop relayed authentication from succeeding even if poisoning occurs.
LLMNR is best disabled centrally through Group Policy under Computer Configuration, Administrative Templates, Network, DNS Client, then setting "Turn off multicast name resolution" to Enabled. The equivalent registry change for testing or for non-domain hosts is:
reg add "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast /t REG_DWORD /d 0 /f
[cta]
NBT-NS has no clean single Group Policy toggle, so it is commonly disabled per interface or pushed through a startup script. Set NetbiosOptions to 2 on every interface to disable NetBIOS over TCP/IP. The following PowerShell applies it across all interfaces at once:
$base = "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces"
Get-ChildItem $base | ForEach-Object {
Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Value 2
}
[cta]
For a fully managed approach, push this as a startup script via Group Policy or configure NetBIOS to disabled through DHCP scope options so new hosts inherit the setting automatically.
On modern Windows builds, mDNS can be disabled through a registry value under the DNS cache service. This is increasingly relevant as mDNS becomes the protocol attackers lean on when LLMNR and NBT-NS are already locked down:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v EnableMDNS /t REG_DWORD /d 0 /f
[cta]
Test mDNS changes carefully, because some legitimate services such as printing and casting rely on it. The right answer in an enterprise is usually to disable it on servers and standard corporate endpoints while documenting any exceptions.
Even if a poisoned response slips through, mandatory SMB signing defeats the relay step because the relayed session cannot be tampered with. Enforce signing through Group Policy under Security Options by enabling "Microsoft network client: Digitally sign communications (always)" and the corresponding server setting. The registry equivalent on a client is:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 1 /f
[cta]
For LDAP relay protection, enforce LDAP signing and LDAP channel binding on domain controllers, and consider Extended Protection for Authentication on web services. Together, these settings neutralize the relay chains described earlier even in the unlikely event that poisoning succeeds.
Name resolution poisoning is rarely the end of a story. It is the opening move. A captured hash becomes a cracked password, a cracked password becomes lateral movement, and a relayed authentication becomes delegation abuse or a foothold on a domain controller. The techniques are inexpensive for attackers and devastating in their reach, which is exactly why every serious internal assessment tests for them early.
For defenders, the takeaway is that these are not exotic threats requiring expensive tooling to address. Disabling three legacy protocols and enforcing signing closes the door on an entire category of attack. For practitioners learning the trade, mastering both the offensive workflow and the defensive countermeasures is what separates someone who runs a tool from someone who understands the system. That dual perspective is the foundation of the practical, lab-driven training at Redfox Cybersecurity Academy.
LLMNR, NBT-NS, and mDNS spoofing exploit trust in unauthenticated fallback name resolution, allowing an attacker on the local segment to capture NTLMv2 hashes without exploiting any vulnerability. Tools like Responder, Pretender, and mitm6 collect and extend that authentication across IPv4 and IPv6, while hashcat recovers plaintext passwords and ntlmrelayx forwards authentication to unsigned targets for immediate access.
On the defensive side, the controls are clear and effective. Disable LLMNR, NBT-NS, and mDNS where they are not strictly required, enforce SMB signing and LDAP channel binding to break relay attacks, and deploy honeypot queries and packet-level monitoring to catch poisoning in progress. Test these controls the way an attacker would, validating with NetExec that no unsigned relay targets remain.
If you want to build these skills with guided labs that mirror real engagements, explore the Windows red teaming and ethical hacking tracks at Redfox Cybersecurity Academy and practice the full chain from poisoning to remediation in a safe environment.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
