Windows
View all Worklets
WindowsWindows

Disable Link-Local Multicast Name Resolution (LLMNR)

Disables Link-Local Multicast Name Resolution (LLMNR) to prevent network name resolution poisoning attacks

Worklet Details

What the LLMNR Disabler does

This Automox Worklet™ disables Link-Local Multicast Name Resolution (LLMNR) on Windows endpoints. LLMNR is a protocol that allows endpoints to resolve hostnames on the local network when DNS resolution fails. While convenient, LLMNR broadcasts name queries that attackers can intercept and respond to maliciously.

The Worklet modifies the Windows DNS client configuration by setting the EnableMulticast registry value to 0 at HKLM:\SOFTWARE\policies\Microsoft\Windows NT\DNSClient. This configuration change applies at the machine level and affects all users on the endpoint.

When LLMNR is disabled, Windows no longer broadcasts multicast queries for name resolution. The endpoint relies exclusively on DNS servers configured in network settings, which provides more secure and predictable name resolution behavior.

Why disable LLMNR on your network

LLMNR poisoning is a common attack technique used in penetration testing and real-world attacks. Tools like Responder and Inveigh exploit LLMNR to capture NTLMv1 and NTLMv2 hashes when endpoints broadcast name resolution requests. Attackers respond to these broadcasts pretending to be the requested host, causing the victim to send authentication credentials to the attacker.

Once attackers capture NTLM hashes, they can crack them offline to recover passwords or relay them to authenticate against other systems. This makes LLMNR poisoning a reliable method for gaining initial access or escalating privileges within a network.

CIS Benchmarks recommend disabling LLMNR as a security hardening measure. Microsoft security guidance also recommends disabling LLMNR in enterprise environments where DNS infrastructure provides reliable name resolution. The protocol offers no authentication mechanism, making it inherently vulnerable to spoofing attacks.

How LLMNR disabling works

  1. Evaluation phase: The Worklet checks the registry path HKLM:\SOFTWARE\policies\Microsoft\Windows NT\DNSClient for the EnableMulticast property. If the registry key does not exist or the EnableMulticast value is not set to 0, the endpoint requires remediation. A value of 0 indicates LLMNR is disabled and the endpoint is compliant.

  2. Remediation phase: The Worklet creates the DNSClient registry path if it does not exist, then sets the EnableMulticast property value to 0 using Set-ItemProperty. This immediately disables LLMNR without requiring a reboot. The Worklet reports success or failure based on whether the registry modification completed successfully.

LLMNR configuration requirements

  • Windows 7 or later, Windows Server 2008 R2 or later

  • PowerShell 2.0 or later

  • Administrative privileges to modify HKLM registry

  • Functioning DNS infrastructure for reliable name resolution

Expected name resolution behavior after remediation

After remediation, the endpoint stops broadcasting LLMNR queries for name resolution. All hostname lookups route through configured DNS servers. If a hostname cannot be resolved via DNS, the resolution fails rather than falling back to multicast queries. You can verify this change through the Automox Activity Log or by checking the endpoint configuration directly.

You can verify the configuration by checking the registry value at HKLM:\SOFTWARE\policies\Microsoft\Windows NT\DNSClient where EnableMulticast should equal 0. Consider also disabling NetBIOS Name Service (NBT-NS) for complete protection against local name resolution poisoning attacks, as attackers can use NBT-NS as an alternative to LLMNR.

How to validate disable link-local multicast name resolution (llmnr) changes

  1. Run this Worklet on a pilot Windows endpoint and review evaluation output for disable link-local multicast name resolution (llmnr).

  2. Confirm Automox activity logs show successful completion and exit code 0.

  3. Verify endpoint state using checks aligned to evaluation script logic, such as Check-LLMNREnabled, Test-Path, Get-ItemProperty.

  4. Validate remediation effects from script operations such as Switch-LLMNR, Test-Path, New-Item, then rerun evaluation for compliance.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklet automation scripts perform configuration, remediation, and the installation or removal of applications and settings across Windows, macOS, and Linux.

do more with worklets