Any Windows host that still falls back to LLMNR or NetBIOS name resolution will hand a password hash to whichever machine on the subnet answers first. Name resolution poisoning is one of the oldest internal network attacks and still one of the first things an intruder or penetration tester tries after landing on a corporate LAN, because it needs no exploit, only a foothold on the same broadcast domain. This guide explains how the poisoning works at protocol level, how to switch LLMNR, NBT-NS and mDNS off safely with Group Policy, Intune and DHCP, how to find the systems that still depend on them, and how to detect a poisoner on the wire. It is written for Windows infrastructure engineers, network defenders and SOC analysts. The relay step that often follows is covered in depth in the NTLM Relay Guide; this page focuses on removing the poisoning opportunity and catching it.
Key takeaways
- Poisoning exploits a fallback, not a bug. When DNS cannot resolve a name, Windows asks the local link by multicast (LLMNR, UDP 5355) or broadcast (NBT-NS, UDP 137), and nothing authenticates the answer.
- The prize is an NTLM authentication. A spoofed answer makes the victim connect and authenticate to the attacker, who either cracks the NTLMv2 response offline or relays it to another server.
- Disabling is cheap and well documented. The "Turn off multicast name resolution" policy kills LLMNR, and DHCP option 001 or the per-adapter NetBIOS setting kills NBT-NS; most estates break nothing when DNS is healthy.
- Disabling alone is not enough. SMB signing, LDAP signing and channel binding, long service account passwords and NTLM reduction limit what a captured or relayed authentication is worth.
- Detection is straightforward once the protocols are off. After rollout, any host answering on UDP 5355 or 137, or any registry change re-enabling multicast name resolution, is an alert, not noise.
How name resolution poisoning works
Windows resolves names through a chain. It checks its cache and hosts file, then asks DNS. If DNS returns nothing, for example because a user mistyped a share name or a stale drive mapping points at a server that no longer exists, older defaults fall back to two link-local protocols that ask every machine on the segment instead of a trusted server.
- LLMNR: defined in RFC 4795 (January 2007, published as Informational after the IETF failed to reach consensus on it as a standard). Queries go to multicast 224.0.0.252 (IPv4) or FF02::1:3 (IPv6) on UDP and TCP port 5355. The RFC's own security considerations note that an on-link attacker sees every multicast query and can answer without guessing the transaction ID.
- NBT-NS: NetBIOS Name Service over TCP/IP, which broadcasts on UDP 137 to the local subnet when no WINS server answers.
- mDNS: multicast DNS for
.localnames on UDP 5353, used by printers, casting devices and newer Windows builds. MITRE ATT&CK lists it alongside LLMNR and NBT-NS in the same technique.
The attack, catalogued as T1557.001 Name Resolution Poisoning and SMB Relay, follows a simple pattern. An attacker on the segment listens for these queries and replies "that name is me". The victim connects to the attacker's address and, if the resource asks for authentication, Windows sends the user's NTLM challenge-response automatically. ATT&CK describes two outcomes: the NTLMv2 hash is captured and cracked offline (T1110.002 Password Cracking), or the authentication is relayed in real time to another server over SMB, LDAP, MSSQL or HTTP. Open-source tools automate the listener, which is why defenders usually call this "Responder-style" poisoning.
Three conditions make it work, and each is a place to break the chain: a fallback protocol that is enabled, a client that tries to reach a name DNS cannot resolve, and an authentication protocol (NTLM) that can be captured or relayed.
Why it matters more than its age suggests
| Exposure | Why it is likely | Consequence |
|---|---|---|
| Mistyped or stale UNC paths | Old drive mappings, login scripts and shortcuts to decommissioned servers send failed lookups all day | Steady stream of user hashes to any poisoner |
| WPAD lookups | Browsers and the WinHTTP stack look up a proxy auto-discovery name that rarely exists in DNS | Victim may authenticate to an attacker-supplied proxy |
| Privileged service accounts | Backup, monitoring and vulnerability scanners authenticate to many hosts with powerful accounts | Capturing one scanner credential can mean broad administrative access |
| Weak or old passwords | NTLMv2 responses crack offline at the speed of the attacker's hardware | Short or reused passwords recovered in minutes to hours |
| SMB signing not required | Signing not enforced on member servers and workstations | Relay to code execution without ever cracking a password |
Credentialed vulnerability scanners deserve special mention. ATT&CK notes that automated scans which use credentials can authenticate to an adversary-controlled system, and the accounts behind them are often domain-wide administrators. Treat scanner and backup accounts as high-value non-human identities. See the Service Account Security Guide.
Disabling LLMNR, NBT-NS and mDNS
MITRE's primary mitigation is M1042 Disable or Remove Feature or Program: switch the protocols off where they are not needed. The settings below are the documented controls.
| Protocol | Control | Exact setting | Notes |
|---|---|---|---|
| LLMNR | Group Policy | Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution = Enabled | Writes EnableMulticast under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient; disables LLMNR on all adapters |
| LLMNR | Intune / MDM | Policy CSP ./Device/Vendor/MSFT/Policy/Config/ADMX_DnsClient/Turn_Off_Multicast | ADMX-backed policy, so it needs the ADMX SyncML format (or the Settings catalog equivalent) |
| NBT-NS | DHCP scope option | Vendor class Microsoft Options, option 001 Microsoft Disable Netbios Option, Long value 0x2 | Only affects clients set to "Use NetBIOS setting from the DHCP server" (the default) |
| NBT-NS | Adapter setting | IPv4 properties > Advanced > WINS > Disable NetBIOS over TCP/IP | Needed for statically addressed servers, which never receive the DHCP option |
| NBT-NS | Registry (per adapter) | HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}\NetbiosOptions = 2 | 0 = use DHCP, 1 = enable, 2 = disable; deploy by script or Group Policy Preferences to cover every adapter, including VPN adapters |
| mDNS | Host firewall and device policy | Block inbound UDP 5353 on Windows Defender Firewall profiles where discovery is not needed | Test first: printers, casting and some collaboration devices rely on it |
Disabling should be layered with filtering, which ATT&CK lists as M1037 Filter Network Traffic: host firewall rules blocking UDP 5355, UDP 137 and UDP 5353 catch machines the policy missed, and switch or wireless controller ACLs can drop link-local name resolution traffic between client ports. Microsoft has also announced, in its networking blog in April 2022, a move towards turning NetBIOS name resolution and LLMNR off by default in favour of mDNS, but do not rely on defaults: set the policy explicitly so audits can prove it.
Rolling it out without breaking things
The protocols exist because something once needed them. In a domain with working DNS that need is usually gone, but find out before you switch them off.
- Measure current use. Capture UDP 5355 and UDP 137 traffic for one to two weeks on representative segments using a network sensor or switch span port. List the names being queried: each one is either a typo, a stale reference to fix, or a real dependency.
- Fix the sources. Correct DNS records, remove stale drive mappings and login script references, add a DNS suffix search list where single-label names are used, and decide how WPAD should be handled (publish a deliberate record or block the name in DNS).
- Pilot ring. Apply the LLMNR policy and NetBIOS disable to IT staff devices and a small server group. Watch the helpdesk queue and file share access logs for two weeks.
- Broad workstation ring. Extend by organisational unit or Intune group. Workstations are the main source of poisoned queries and the main victims.
- Servers and special cases. Static-addressed servers need the adapter or registry setting. Check legacy line-of-business applications, older network-attached storage, multifunction printers that scan to SMB, and OT or lab segments, which may genuinely need NetBIOS. Document each exception with an owner and a review date, and isolate those hosts.
- Enforce and monitor. Add the settings to the security baseline, confirm them with configuration compliance reporting, and turn on the detections described below.
Rollback: set the Group Policy back to Not Configured or remove the Intune assignment, and for NetBIOS remove the DHCP option or set NetbiosOptions back to 0. Changes take effect at the next policy refresh or DHCP renewal; NetBIOS changes may need an adapter reset. Keep rollback scoped to the affected group rather than the whole estate.
Reducing the value of a captured authentication
Turning the protocols off removes the easiest way to trigger an authentication, not every way. Forced authentication through malicious shortcuts and documents (T1187 Forced Authentication), rogue DHCPv6 and other adversary-in-the-middle methods still exist. Defence in depth means a captured or relayed authentication should be close to worthless.
- Require SMB signing: set "Microsoft network client: Digitally sign communications (always)" and "Microsoft network server: Digitally sign communications (always)" under Security Options. Microsoft's documentation states that the signature binds each message to the sender and recipient, which prevents relay. Domain controllers already require signing for SYSVOL and NETLOGON.
- Protect LDAP and HTTP endpoints: enforce LDAP signing and channel binding on domain controllers and Extended Protection for Authentication on web services such as AD CS enrolment. See the NTLM Relay Guide and the AD CS Security Guide.
- Prefer Kerberos and reduce NTLM: Microsoft notes that connecting by IP address or CNAME forces NTLM. Audit NTLM use and plan its removal with the NTLM Deprecation and Elimination Guide.
- Make cracking expensive: long passphrases for users and, for service accounts, managed passwords. Group Managed Service Accounts use 120-character random passwords rotated automatically, which removes the offline cracking path for those identities. See the Group Managed Service Accounts (gMSA) Guide.
- Segment: poisoning is link-local, so smaller broadcast domains limit who can hear whom. Client isolation on wireless networks and private VLANs between workstations remove the attacker's audience. See the Network Segmentation Guide.
Where identity fits
Name resolution poisoning is a credential attack delivered over the network. The identities most worth stealing are rarely ordinary users: they are the vulnerability scanner account that logs into every server, the backup agent's domain account, the monitoring service that checks file shares, and administrators browsing to a typo. These non-human identities authenticate automatically, at scale and without a human noticing a failed connection, and their passwords are often old because rotation breaks things. Inventory them, check whether any hold Domain Admin or equivalent rights, move them to gMSA or vaulted, rotated credentials, and restrict where they may log on. See How to find service accounts with Domain Admin rights.
Detection and measurement
MITRE's detection strategy for this technique (DET0462) combines network flow anomalies on UDP 5355 and UDP 137, SMB relay attempts, registry modification of the multicast policy value and suspicious service creation. Once the protocols are disabled, the signal-to-noise ratio becomes very good.
| Signal | Source | What it suggests |
|---|---|---|
| Any host sending responses on UDP 5355 or UDP 137 after rollout | NDR, Zeek or Suricata, switch flow records | Poisoner or misconfigured host; investigate immediately |
| One host answering LLMNR or NBT-NS queries for many different names | Network sensor | Classic poisoner behaviour: legitimate hosts only answer for their own names |
Change to HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast | EDR registry telemetry, Sysmon registry events | Local tampering to re-enable LLMNR |
| Event ID 4697 (service installed) on a server shortly after inbound SMB authentication | Windows Security log | Possible relay to remote code execution |
| Event ID 4624, logon type 3, authentication package NTLM, from a workstation IP that does not normally authenticate to that server | Windows Security log on servers and DCs | Possible relayed authentication |
| Canary name queries answered | Deliberately broadcast a lookup for a name that does not exist and alert if anyone replies | Active poisoner on that segment |
The canary technique is cheap and effective: a scheduled task on a few hosts per segment queries a non-existent name over LLMNR and NBT-NS, and any reply is by definition a spoof. Deception platforms package the same idea. See the Deception Technology Guide.
Metrics that show the control is working:
- Policy coverage: percentage of Windows endpoints and servers reporting LLMNR disabled and NetBIOS over TCP/IP disabled (target 100% minus documented exceptions).
- Residual link-local traffic: count of UDP 5355 and UDP 137 queries per day per segment, trending to zero.
- Exceptions: number of documented exceptions, each with an owner and review date, and how many are overdue.
- SMB signing enforcement: percentage of servers requiring signing.
- Test results: whether the annual internal penetration test captured any hashes through poisoning (the target is none).
Common failure patterns
- Disabling LLMNR but forgetting NetBIOS. The LLMNR policy is a single click; NetBIOS needs DHCP plus per-adapter settings. Many estates stop halfway and remain exposed on UDP 137.
- Missing static and VPN adapters. DHCP option 001 does nothing for servers with static addresses or for adapters that do not take the option, so those hosts keep NetBIOS on.
- Treating disable as the whole fix. With SMB signing not required and NTLM widespread, an attacker who triggers authentication another way can still relay it.
- Privileged scanner accounts with static passwords. A single captured response from a domain-wide scanning account can be cracked or relayed into broad access.
- No detection after rollout. The best moment to alert on UDP 5355 and 137 responders is after the protocols are off, yet many teams never add the rule.
- Undocumented exceptions. Lab, OT and printer segments left with NetBIOS on "temporarily" become the permanent soft spot.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK | T1557.001, T1557, T1187, T1110.002, T1550.002 | Poisoning and relay, forced authentication, offline cracking, and use of captured hashes |
| MITRE ATT&CK mitigations | M1042, M1037, M1030, M1031 | Disable the features, filter traffic, segment, network intrusion prevention |
| NIST SP 800-53 Rev. 5 | CM-6, CM-7, CM-2 | Secure configuration settings, least functionality, baseline configuration |
| NIST SP 800-53 Rev. 5 | SC-8, SC-23, SC-7, SI-4 | Transmission integrity, session authenticity (signing), boundary protection, monitoring |
| NIST CSF 2.0 | PR.PS-01, DE.CM-01 | Configuration management practices; network monitoring for adverse events |
Practitioner checklist
- Capture UDP 5355, 137 and 5353 traffic for one to two weeks and list every name being queried.
- Fix stale DNS records, drive mappings and login script references found in the capture, and decide how WPAD is handled.
- Enable "Turn off multicast name resolution" by Group Policy or the Intune Turn_Off_Multicast policy, in pilot rings.
- Disable NetBIOS over TCP/IP with DHCP option 001 (0x2) and set NetbiosOptions to 2 on static and VPN adapters.
- Add host firewall rules for UDP 5355 and 137, and test mDNS blocking where discovery is not needed.
- Require SMB signing on clients and servers, and enforce LDAP signing, channel binding and Extended Protection.
- Move scanner, backup and monitoring accounts to gMSA or vaulted, rotated credentials and remove unnecessary Domain Admin rights.
- Alert on any UDP 5355 or 137 responder, on changes to the EnableMulticast value, and deploy canary name queries per segment.
- Record every exception with an owner, a reason and a review date, and isolate those hosts.
Standards and references
- MITRE ATT&CK: Name Resolution Poisoning and SMB Relay (T1557.001)
- MITRE ATT&CK: Detect LLMNR/NBT-NS Poisoning and SMB Relay on Windows (DET0462)
- IETF: RFC 4795 Link-Local Multicast Name Resolution (LLMNR)
- Microsoft Learn: ADMX_DnsClient Policy CSP (Turn off multicast name resolution)
- Microsoft Learn: Disable NetBIOS over TCP/IP by using DHCP server options
- Microsoft Learn: Overview of Server Message Block signing
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: NTLM Relay Guide · NTLM Deprecation and Elimination Guide · Active Directory Security Monitoring and Event IDs Guide · Service Account Security Guide