Support
 
Phone Live Chat
 
Support
 
US: +1 888 720 9500
 
Intl: +1 925 924 9500
Aus: +1 800 631 268
UK: 0800 028 6590
CN: +86 400 660 8680

Direct Inward Dialing: +1 408 916 9393

 
 
 
 
 
Features

Why LLMNR is a credential theft risk

Link-Local Multicast Name Resolution (LLMNR) is a protocol Windows uses as a fallback when DNS cannot resolve a hostname. When a DNS query fails, the client sends a multicast packet to the UDP port 5355 asking every device on the local subnet if it recognizes the queried name. Any device on the network can respond, including one controlled by an attacker.

This is the basis of LLMNR poisoning. A tool like Responder listens passively for these broadcast queries and answers them: “Yes, that's me—authenticate to connect.” Windows trusts the first response it receives and submits the current user's NTLMv2 credential hash to the responding host. The attacker can then attempt to crack that hash offline or relay it to authenticate to another service on the network.

In many internal security assessments, LLMNR poisoning is an early step in the path to domain compromise. The attack doesn't require any privileges, user interaction, or software vulnerability. It only requires a misconfigured name to fall back to broadcast resolution on a network where an attacker is present.

LLMNR was useful when DNS infrastructure was expensive to maintain across every subnet. In modern AD environments with properly functioning DNS, it usually serves no operational purpose. Disabling it removes the broadcast surface that poisoning attacks depend on. In environments with functioning DNS, legitimate name resolution is unaffected.

Prerequisites

Note: Disabling LLMNR and NBT-NS typically has no impact on legitimate operations in environments with functioning DNS. Disabling mDNS, covered below, can affect device discovery for printers, Chromecasts, and other services that use multicast-based service advertisement. Test mDNS separately before deploying it domain-wide.

How to disable LLMNR via Group Policy (Administrative Templates)

LLMNR is controlled by a built-in Administrative Templates policy. Unlike NBT-NS and mDNS, it does not require writing registry values manually. The policy setting writes the correct registry entry automatically when you enable it.

Step 1: Open the GPMC and create a new GPO

  1. Press Win + R, type gpmc.msc, and press Enter.
  2. In the left pane, expand the forest and domain tree to locate your target. Right-click the domain to apply the policy domain-wide, or right-click a specific OU to scope it to a subset of machines.
  3. Select Create a GPO in this domain, and Link it here.
  4. Name the GPO descriptively, for example, Disable LLMNR and NBT-NS or Network hardening - name resolution.
  5. Click OK.

Step 2: Enable the policy

  1. Right-click the new GPO and select Edit.
  2. In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Administrative Templates > Network > DNS Client.
  3. In the right pane, locate the policy named Turn off multicast name resolution.
  4. Double-click Turn off multicast name resolution.
  5. Set the policy to Enabled.
  6. Click Apply, then OK.
  7. Close the Group Policy Management Editor.

When this policy is enabled, it writes EnableMulticast = 0 to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient on every machine in scope. The Policies path means this is a managed policy value, so users and local administrators cannot override it.

Note: LLMNR changes applied through Administrative Templates take effect at the next Group Policy refresh cycle, approximately every 90 minutes for computer policy. A reboot is not required. You can force an immediate refresh by running gpupdate /force on the target machine.

How to disable NBT-NS via Group Policy (Registry Preferences)

How to disable mDNS via Group Policy (Registry Preferences)

Alternative method: Disable NBT-NS via PowerShell startup script

How to verify LLMNR and NBT-NS are disabled

Check 1: Confirm the GPO is in the applied list

On a target machine, run the following from an elevated Command Prompt:

Click to copy script
gpresult /r /scope computer

Your GPO name should appear under Applied Group Policy Objects. If it does not, check the OU membership of the machine and confirm that the GPO is linked to the correct container.

Check 2: Confirm the LLMNR registry value

LLMNR is disabled when the following registry value is present and set to 0:

Click to copy script
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast

A result of 0x0 confirms LLMNR is off. If the key does not exist, the policy has not applied yet. Run gpupdate /force and wait for the next refresh cycle.

Check 3: Confirm the NBT-NS registry value

Click to copy script
reg query "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v EnableNetbios

A result of 0x0 confirms NBT-NS is disabled through the Registry preference. If the key is absent, the preference has not been written yet. Run gpupdate /force and check again.

Check 4: Confirm NBT-NS at the interface level (optional)

To confirm that NBT-NS is also disabled at the adapter level, which is relevant after using the startup script method, run:

Click to copy script
Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled = TRUE" | Select-Object Description, TcpipNetbiosOptions

Each active interface should return TcpipNetbiosOptions = 2.

Impact: What disabling these protocols affects

The three protocols carry different operational risk when disabled. Use this table when deciding how to stage the deployment.

Protocol Port Disable method Operational impact Recommendation
LLMNR UDP 5355 Administrative Templates Minimal. Environments with proper DNS will not notice Disable domain-wide
NBT-NS UDP 137 Registry preference/startup script Minimal. Legacy protocol with little legitimate modern use in AD environments Disable domain-wide
mDNS UDP 5353 Registry preference May break printer discovery, Chromecast, AirPlay, and other multicast service advertisements Test on a scoped OU first

Troubleshooting common issues

The LLMNR policy applied, but name resolution is still failing

Check whether the machine's DNS configuration is correct before attributing the failure to LLMNR being disabled. Run nslookup hostname against your domain controller. If DNS resolves the name correctly, the application or service using it is relying on something other than LLMNR for fallback. If DNS itself is failing, fix DNS rather than re-enabling LLMNR.

The NBT-NS registry key is present, but name resolution still uses NBT-NS

The registry key may have been written, but another GPO or local policy is overriding it. Run gpresult /h report.html and examine the Registry preference entries to identify the winning GPO. Adjust link order or use the Enforced option to ensure that your hardening GPO takes precedence.

A specific application broke after disabling LLMNR

Applications that rely on single-label name resolution, such as \\fileserver instead of \\fileserver.contoso.com, may fail to resolve when LLMNR is disabled if those hostnames are not registered in DNS. The fix is to add the missing A records to DNS, not to re-enable LLMNR. Run nslookup fileserver against your domain controller to confirm whether the record is missing.

The startup script method is not running on older machines

Confirm that the target machine can reach the NETLOGON share used in the script path. Check Applications and Services Logs > Microsoft > Windows > GroupPolicy in Event Viewer for script execution errors. Verify the PowerShell execution policy with Get-ExecutionPolicy -List. If the machine policy is set to Restricted, the script will not run. Set it to at least RemoteSigned through the GPO Administrative Templates setting at Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell > Turn on Script Execution.

Should you also enable SMB signing?

Disabling LLMNR and NBT-NS removes the broadcast query surface that poisoning attacks depend on. It does not prevent credential relay through other paths. If an attacker can intercept SMB connections, they can still forward captured NTLMv2 hashes to authenticate elsewhere on the network, even with LLMNR disabled.

Enabling SMB signing is the complementary control. Each SMB packet is signed with a session key, which a relay attacker cannot forge without the original session credentials. Security teams and penetration testers often treat disabling LLMNR and NBT-NS alongside requiring SMB signing as a pair: One removes the broadcast query vector, and the other helps address the relay vector. Neither control alone is sufficient.

Managing GPO deployment at scale with ADManager Plus

Deploying a hardening GPO to a pilot OU and then confirming that it applied cleanly to every machine in the domain, without a competing policy overwriting your settings, is the part that takes time at scale. ManageEngine ADManager Plus provides a centralized GPO management console where you can handle that follow-on work without opening GPMC on individual servers.

  • Bulk GPO linking: Link your LLMNR hardening GPO to multiple OUs simultaneously rather than adding each link manually in GPMC. This is useful when the policy needs to cover workstations, servers, and domain controllers in separate containers.
  • Link order management: Adjust GPO precedence directly from the web console when a competing policy is overwriting your EnableMulticast or EnableNetbios registry values, so the correct configuration wins without opening GPMC on each domain controller.
  • On-demand policy refresh: Push an immediate GPO refresh to selected computers without logging into each machine individually. This is useful for confirming that the hardening policy has propagated after you adjust a link or OU scope.
  • Application visibility: Use the GPO Settings report to confirm that the LLMNR and NBT-NS settings are in place across all GPOs in one view, and the Resultant set of policy report to verify that the policy actually applied to a specific machine after deployment.
  • Delegation oversight: Scope GPO refresh and reporting tasks to help desk technicians through role-based delegation, so staff can investigate GPO application issues without needing Domain Admin rights or RSAT installed on their workstations.

Streamline AD management with ADManager Plus

ADManager Plus Trusted By

The one-stop solution to Active Directory Management and Reporting