Let's talk about multicast name resolution. "In 2025 rewks? The 2010s want their blog post back!" I hear you say. Well hear me out. Things change. Especially so in the tech world and sometimes that means we need to update our approaches along with it. Yes, there is a plethora of advice out there on how to tackle this subject but from what I could see the last time I looked it is a bit outdated - specifically in relation to NBT-NS where most guidance suggests modifying the settings on each individual network interface (messy, error-prone and annoying).
Let's also just be clear from the start that the contents of this blog post are written very much through a Windows operating system lens.
Understanding Multicast Protocols
What happens when you try to interact with a remote resource from your computer? Usually you'll do so by typing in a fully qualified, or unqualified name.
- Fully qualified: These are readable addresses containing a domain like
fileserver01.google.com. - Unqualified: This is when you just type in a hostname without qualifying it with the domain it is part of e.g.
fileserver01.
The first thing the operating system does is a DNS lookup for the resource name you have given. If your configured DNS server is unable to find a matching record the DNS lookup fails. In the case of fully qualified names the journey ends here - nothing else happens.
It is an entirely different story for unqualified hostnames though. When DNS fails here Windows falls back to three multicast name resolution protocols: mDNS, NBT-NS and LLMNR (in that order).
Here is an example of this in action, for demonstration purposes I am attemping to ping a nonexistent resource.
ping -n 1 fileserver01
If you're now challenging the protocol order I wrote earlier then you have a keen eye. Apologies though, the image above has misled you. There is actually an additional NBT-NS query just before the first LLMNR one that I have taken the liberty to filter out because initially it is sent singlecast to the configured DNS server before resending to the network's broadcast address, and it takes a bit of time for the Netbios client to timeout waiting for a response hence the NBT-NS broadcast requests being delayed.
What is mDNS
Multicast DNS is a networking protocol defined in RFC 6762 designed to resolve hostnames to IP addresses in small networks. It uses the same packet format and semantics as the DNS protocol but operates in multicast rather than querying a dedicated DNS server.
Microsoft has publicly stated an intention for mDNS to be the primary multicast name resolution protocol in Windows, with plans to disable NBT-NS and LLMNR by default in the future.
One special thing to note about mDNS is that requests originating from the Windows OS mDNS client will actually query single-label .local names. That is, if something causes a lookup for fileserver01.local then mDNS will search for it. If a lookup for fileserver01 triggers, then mDNS will still look for fileserver01.local. Remember: single-label only so you won't see mDNS traffic for fileserver01.rewks.local.
What is NBT-NS
The NetBIOS Name Service exists to allow applications to register their NetBIOS name and operates by default on UDP port 137. This facilitates name lookups in a local network segment, allowing applications on computers to communicate with each other without the need of a centralised name server.
What is LLMNR
Link-Local Multicast Name Resolution was first introduced by Microsoft in Windows Vista and defined in RFC 4795. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS.
The Dangers of Multicast
I'm just going to provide a brief overview here as there really are an uncountable number of how-tos out there, and as far as attacking the protocols goes, things really haven't changed.
Due to the nature of multicast protocols, an adversary within the same broadcast domain as a Windows device with these protocols enabled will receive any fallback name queries it sends. In enterprise environments it is not uncommon to see this happening frequently due to users mistyping hostnames or as a result of outdated service configurations searching for resources that no longer exist.
Exploitation of the implicit trust in responses to these messages is an extremely common vector through which attackers can attempt to establish initial access to a user account or escalate their access to other devices. Though not as prolific as it once was, compromising accounts or even domains through this attack path is still a thing today.
How to Prevent Multicast Name Resolution
Look back at the broadcast requests in that Wireshark capture. Every one of those requests is a risk for your network. To answer the question on how to prevent this, it is best to first understand what the operating system is checking for when deciding whether to utilise any of these protocols. I'll be taking the same investigation approach as detailed in a great blog post by Andreas Finstad, albeit with a slight amendment to the recommendation.
Process Monitor from Microsoft sysinternals allows for inspection of file system, registry and process events. This can get very cluttered very fast so it is best to apply some filters if you have an idea what you're looking for.
Running the simple ping -n 1 fileserver01 command again shows what is happening behind the scenes:
So Windows wants to check for some registry values in two keys, following this order of priority:
- HKLM:\Software\Policies\Microsoft\Windows NT\DnsClient
- HKLM:\CurrentControlSet\Services\Dnscache\Parameters
If the key is not found Windows moves on to the next one. However, if it does exist then the system checks if the following values are defined within it:
- EnableMulticast
- EnableMDNS
- EnableNetbios
You can see where we're going with this right? It is as simple as making sure those registry values exist and are set to 0. (When they don't exist at all Windows follows default behaviour which is the same as having them enabled.)
I said my recommendation would differ slightly from that in the blog post linked above. I believe the best approach is to set the mitigations in the first registry key whereas Andreas chooses the second. In almost every case the outcome is the same, but by setting values in the most prioritised location you avoid that edge case where your mitigations don't take effect because you unknowingly have a conflicting configuration in a higher priority key.
After creating the higher priority registry key and defining the appropriate values within it, Windows successfully retrieves them and stops its search. If we repeat the ping test and view the resultant traffic in Wireshark once more, we can see that the only name resolution performed is over DNS.
Now we've seen the mitigation and how effective it is, let's look at how to actually apply it through Group Policy, Microsoft Intune and good old PowerShell.
Group Policy
LLMNR
Probably the most well documented setting in this post. As various other sources have pointed out, LLMNR can be disabled through Group Policy as follows.
- Within the Group Policy Management application either choose an existing policy to modify or create a new one (I recommend just enforcing this mitigation through the Default Domain Policy).
- Navigate through the settings tree to Computer Configuration > Policies > Administrative Templates > Network > DNS Client.
- Modify the Turn off multicast name resolution item to Enabled.
NBT-NS
Microsoft also offer the ability to disable Netbios name resolution requests through Group Policy as follows.
- Within the Group Policy Management application either choose an existing policy to modify or create a new one (I recommend just enforcing this mitigation through the Default Domain Policy).
- Navigate through the settings tree to Computer Configuration > Policies > Administrative Templates > Network > DNS Client.
- Modify the Configure NetBIOS settings item to Enabled.
- In the options panel select Disable NetBIOS name resolution.
mDNS
You can also disable mDNS through a Group Policy setting, although if you can't find it you may need to download newer Administrative Templates from Microsoft.
- Within the Group Policy Management application either choose an existing policy to modify or create a new one (I recommend just enforcing this mitigation through the Default Domain Policy).
- Navigate through the settings tree to Computer Configuration > Policies > Administrative Templates > Network > DNS Client.
- Modify the Configure multicast DNS (mDNS) protocol item to Disabled.
Microsoft Intune
Intune unfortunately at the time of writing only has a native option for disabling LLMNR, which can be achieved through the Settings Catalog in a configuration policy.
To address NBT-NS and mDNS you can either:
- Apply the registry changes directly through a PowerShell script that Intune deploys.
- Upload windows.admx/.adml and dnsclient.admx/.adml files then create a configuration profile using Imported Administrative Templates where you will be able to find the NetBIOS and mDNS related settings from Group Policy.
I've heard of way too many struggles with ADMX file weirdness so my preference would be straightfoward PowerShell.
PowerShell Script (All Protocols)
- Access the Intune Admin Centre at https://intune.microsoft.com
- Select Devices > Scripts and remediations > Platform scripts
- Click Add > Windows 10 and later
- Continue until the Script settings tab
- Upload the script below (you must upload a file), removing the line that sets "EnableMulticast" if you plan to use the native Intune setting for LLMNR
- Configure the script to not run using the logged on credentials (we need a privileged context for registry changes). Also turn off the script signature check.
- Continue through the menus, assigning the script to all devices.
$path = "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient"
if (!(Test-Path -Path $path)) { New-Item -Path $path -Force }
Set-ItemProperty -Path $path -Name "EnableMulticast" -Type DWord -Value 0
Set-ItemProperty -Path $path -Name "EnableNetbios" -Type DWord -Value 0
Set-ItemProperty -Path $path -Name "EnableMDNS" -Type DWord -Value 0
Settings Catalog (LLMNR Only)
- Access the Intune Admin Centre at https://intune.microsoft.com
- Select Devices > Configuration
- Click Create > New Policy
- For Platform choose Windows 10 or later and for Profile type choose Settings Catalog
- Continue until the Configuration Settings tab
- Click Add settings then search for "DNS Client". Click on the administrative template result and from the list of settings select Turn off multicast name resolution
- Close the settings picker and toggle the Turn off multicast name resolution setting to Enabled
- Continue through the policy creation, assigning it to all devices.
PowerShell
There isn't much to write here, you've already seen my suggested PowerShell script above. Run the commands on individual machines or deploy the script however you see fit.
Auditing
Finally, to query the registry values discussed above (in both possible registry locations) as well as check for the old-style NBT-NS individual interface hardening, you can use the commands below.
Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast,EnableNetbios,EnableMDNS -ErrorAction SilentlyContinue
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Dnscache\Parameters" -Name EnableMulticast,EnableNetbios,EnableMDNS -ErrorAction SilentlyContinue
Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration | ? { ($_.TcpIpNetbiosOptions -eq 0) -or ($_.TcpIpNetbiosOptions -eq 1) } | Select-Object Caption,TcpIpNetbiosOptions
A quick note about the last command, it will only return interfaces where the NetBIOS options are 0 (use registry setting) or 1 (enabled). Any interfaces where NetBIOS is disabled would return a 2 and so not be included.