Join our Newsletter — 33% off our NHI Course
Home› Guides› LLMNR and NBT-NS Poisoning: Detect, Disable and Contain…
Guide Network Security

LLMNR and NBT-NS Poisoning: Detect, Disable and Contain Name Resolution Abuse

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 14 min read
On this page

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 .local names 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

ExposureWhy it is likelyConsequence
Mistyped or stale UNC pathsOld drive mappings, login scripts and shortcuts to decommissioned servers send failed lookups all daySteady stream of user hashes to any poisoner
WPAD lookupsBrowsers and the WinHTTP stack look up a proxy auto-discovery name that rarely exists in DNSVictim may authenticate to an attacker-supplied proxy
Privileged service accountsBackup, monitoring and vulnerability scanners authenticate to many hosts with powerful accountsCapturing one scanner credential can mean broad administrative access
Weak or old passwordsNTLMv2 responses crack offline at the speed of the attacker's hardwareShort or reused passwords recovered in minutes to hours
SMB signing not requiredSigning not enforced on member servers and workstationsRelay 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.

ProtocolControlExact settingNotes
LLMNRGroup PolicyComputer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution = EnabledWrites EnableMulticast under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient; disables LLMNR on all adapters
LLMNRIntune / MDMPolicy CSP ./Device/Vendor/MSFT/Policy/Config/ADMX_DnsClient/Turn_Off_MulticastADMX-backed policy, so it needs the ADMX SyncML format (or the Settings catalog equivalent)
NBT-NSDHCP scope optionVendor class Microsoft Options, option 001 Microsoft Disable Netbios Option, Long value 0x2Only affects clients set to "Use NetBIOS setting from the DHCP server" (the default)
NBT-NSAdapter settingIPv4 properties > Advanced > WINS > Disable NetBIOS over TCP/IPNeeded for statically addressed servers, which never receive the DHCP option
NBT-NSRegistry (per adapter)HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}\NetbiosOptions = 20 = use DHCP, 1 = enable, 2 = disable; deploy by script or Group Policy Preferences to cover every adapter, including VPN adapters
mDNSHost firewall and device policyBlock inbound UDP 5353 on Windows Defender Firewall profiles where discovery is not neededTest 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.

  1. 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.
  2. 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).
  3. 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.
  4. Broad workstation ring. Extend by organisational unit or Intune group. Workstations are the main source of poisoned queries and the main victims.
  5. 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.
  6. 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.

SignalSourceWhat it suggests
Any host sending responses on UDP 5355 or UDP 137 after rolloutNDR, Zeek or Suricata, switch flow recordsPoisoner or misconfigured host; investigate immediately
One host answering LLMNR or NBT-NS queries for many different namesNetwork sensorClassic poisoner behaviour: legitimate hosts only answer for their own names
Change to HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticastEDR registry telemetry, Sysmon registry eventsLocal tampering to re-enable LLMNR
Event ID 4697 (service installed) on a server shortly after inbound SMB authenticationWindows Security logPossible 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 serverWindows Security log on servers and DCsPossible relayed authentication
Canary name queries answeredDeliberately broadcast a lookup for a name that does not exist and alert if anyone repliesActive 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

FrameworkReferenceHow it applies
MITRE ATT&CKT1557.001, T1557, T1187, T1110.002, T1550.002Poisoning and relay, forced authentication, offline cracking, and use of captured hashes
MITRE ATT&CK mitigationsM1042, M1037, M1030, M1031Disable the features, filter traffic, segment, network intrusion prevention
NIST SP 800-53 Rev. 5CM-6, CM-7, CM-2Secure configuration settings, least functionality, baseline configuration
NIST SP 800-53 Rev. 5SC-8, SC-23, SC-7, SI-4Transmission integrity, session authenticity (signing), boundary protection, monitoring
NIST CSF 2.0PR.PS-01, DE.CM-01Configuration 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

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

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org