Disable Link-Local Multicast Name Resolution (LLMNR)

What the LLMNR disabler does

This Automox Worklet™ disables Link-Local Multicast Name Resolution (LLMNR) on Windows workstations and servers. LLMNR is a fallback name resolution protocol that broadcasts hostname queries on the local subnet when DNS fails to resolve a name. The protocol has no authentication, so any host on the link-local network can answer a query and impersonate the intended target.

The Worklet writes a single registry value to enforce the policy: EnableMulticast=0 (DWORD) under HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient. This is the same path gpedit.msc writes to when you set Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution to Enabled.

Setting the value at the policies key (rather than the parent DNSClient key) matches the path Group Policy uses, so the configuration survives gpupdate and behaves identically on domain-joined and standalone endpoints. The Worklet creates the registry path if it does not exist and applies the change without a reboot.

Why disable LLMNR on Windows endpoints

LLMNR is one of the most reliable credential-poisoning attack vectors on a Windows network. When DNS fails to resolve a name, Windows falls back to LLMNR and broadcasts the query on UDP port 5355. Any host on the subnet can answer. An attacker running Responder or Inveigh impersonates the requested host and collects the NTLMv1 or NTLMv2 challenge-response the victim sends to authenticate. The captured hash is then cracked offline or relayed against another endpoint over SMB or LDAP. CIS Benchmark control 18.6.4.2 and Microsoft security baselines both call for LLMNR to be disabled in enterprise environments where authoritative DNS exists.

This Worklet writes EnableMulticast=0 to HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient on every Windows endpoint in scope, which blocks the LLMNR resolver path that Responder, Inveigh, and KrbRelayUp depend on for NTLMv2 hash capture. Idempotent registry writes keep repeat runs cheap on already-hardened workstations and servers, and any host where the value has drifted back to the default surfaces in the activity log with the prior data captured for the change-control record.

How LLMNR disabling works

1. Evaluation phase: The Worklet calls Test-Path on HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient and, when the key exists, reads the EnableMulticast property with Get-ItemProperty. The endpoint is reported compliant (exit 0) only when EnableMulticast equals 0. A missing key, a missing value, or any non-zero value returns exit 1 and queues the endpoint for remediation.

2. Remediation phase: The Switch-LLMNR function creates the DNSClient policy key with New-Item -Force when it is missing, then writes EnableMulticast=0 (DWORD) with Set-ItemProperty. The change takes effect on the next name resolution attempt with no reboot. Success returns exit 0; any registry failure writes the error to stderr and returns exit 2839, which surfaces in the Automox Activity Log as a remediation failure for follow-up.

LLMNR policy requirements

• Windows 7, Windows 8, Windows 10, Windows 11, or Windows Server 2008 R2 and later

• PowerShell 2.0 or later (no external modules required)

• Administrative rights on the endpoint to write under HKLM:\SOFTWARE\Policies

• Reachable authoritative DNS for every hostname applications and users need to resolve, including short names that previously fell back to LLMNR

• No conflicting Group Policy setting unsetting EnableMulticast at next gpupdate (the Worklet writes to the same policies path GPO uses, so a conflicting GPO will overwrite this change)

Expected name resolution behavior after remediation

After remediation, the endpoint stops sending LLMNR queries on UDP 5355. Name resolution requests route through the DNS servers configured on each network adapter. If DNS cannot resolve a name, the lookup fails immediately rather than broadcasting to the local subnet, which is the desired behavior on a network with authoritative DNS.

Verify the change by running Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast on the endpoint; the property should return 0. Confirm the network behavior by capturing traffic with pktmon or Wireshark and looking for the absence of UDP 5355 broadcasts when an unknown hostname is queried. The Automox Activity Log for the endpoint will also show the Worklet exited 0 on the most recent run.

For full coverage against link-local credential poisoning, pair this Worklet with a NetBIOS over TCP/IP (NBT-NS) disabler and with SMB signing enforcement. Responder and similar tools fall back to NBT-NS and mDNS when LLMNR is unavailable, and SMB signing blocks the relay step even if a hash is captured.