Ghost in the Network: The Persistent Threat of Multicast Name Resolution
So much of cybersecurity news is dominated by flashy new APTs, CVEs, and malware campaigns that it would be easy to think the field should care about little else but “the next thing”. However, if years of experience penetration testing is any indication, some of the most dangerous and destructive vulnerabilities in medium-to-large organizations are relatively old, poorly understood, and badly configured subsystems. In some cases, there are subsystems and protocols lurking on these organization’s networks that represent existential threats, and they are rarely aware that these threats exist.
Such is the case with Multicast Name Resolution (MNR). This article will discuss what it is, how it is exploited, what damage can be done, and most importantly, how it can be removed as a threat from the network.
After years of experience working with organizations trying (and failing) to deal with MNR poisoning from an application and service level, a fresh approach is necessary. Given that this attack vector represents abuse of a protocol that resides at the network level, combatting it can and should be handled at the network level. While most articles focus on the service-layer/policy approach to dealing with MNR, this article provides a more sustainable network-layer solution.
Background: Name Resolution
Network engineers and system administrators alike are familiar with the Domain Name System (DNS) and how it resolves hostnames to IP addresses. In general, Name Resolution (NR), i.e. resolving hostnames to Internet Protocol (IP) addresses, is a critical aspect of the modern Internet. With DNS, this process is hierarchical in nature, escalating from the original host to the the specified recursive DNS server and beyond, depending on the target resource. Queries for external hostnames like “google.com” or “microsoft.com” leverages the worldwide DNS system all the way up to the “root servers”.
Enterprise Networks and MNR
What is far less understood is what this process looks like in the context of internal enterprise networks. The assumption of most administrators is that all name resolution requests for internal enterprise resources propagate to the authoritative DNS server for the enterprise (often the Domain Controller), and if it does not have an answer, then the process stops there. Unfortunately, this is not the case. In Windows enterprise environments, there is at least one other name resolution subsystem: Multicast Name Resolution.
Whereas DNS seeks out the appropriate name server to query for a hostname resolution, MNR instead broadcasts this query to as many systems as the network will allow. MNR queries can be, and often are, broadcast using three separate protocols:
One might assume that querying the broader network would be a reasonable fallback when a local DNS server fails to resolve a hostname. However, this can lead to significant security vulnerabilities. Cynet has an excellent article on the background of how these protocols can be abused. Consider it required reading to fully understand what’s happening at the network layer and above. The essential problem boils down to this: if a host is asking everyone on the network for an answer to a question, what happens when a hostile actor answers that question?
The short answer is this: that hostile actor, with nothing more than network access, can force NTLM authentication from the querying host to the attacker’s host.
The Dangers of MNR
For example, imagine a service that is configured to perform nightly backups and one of the hosts it backs up is decommissioned, or its name changed. The next time that service runs, it will not be able to resolve that hostname through DNS, and so it will fall back to MNR to try to find it. The attacker will then respond to that request, at which point the service will immediately attempt to authenticate. Depending on the resource queried, the victim may authenticate over SMB, HTTP, or RPC via NTLM.
In a similar vein to TCP and its three-way handshake, NTLM negotiates authentication via a challenge and response method. This handshake is invaluable to an attacker:
- It can be taken offline, and if the account associated with the handshake has a weak password, it will be cracked, resulting in account compromise.
- It can be relayed to additional hosts and services. If there is not some sort of additional challenge in place that requires knowledge of the cleartext credentials of the account (e.g. SMB signing or Extended Protection for Authentication (EPA)), then the attacker can gain that account’s privileges on the other hosts/services.
This can and often does result in the host compromise or the compromise of the enterprise domain. See the Cynet article for more details.
Understanding the Attack Surface Exposed by MNR
Assumed Breach
One important consideration when discussing an attack vector is the level of access within a network a threat actor would need to leverage it. In the case of MNR protocol poisoning, the attack itself is reliant upon Layer 3 network access, meaning that control of an asset on the LAN must be obtained before it can be launched. Many penetration tests are designed to simulate a scenario in which a threat actor is able to breach the network’s perimeter, either through external host compromise or simply through bypassing physical access controls and installing a device on the network that can reach out to a Command and Control (C2) server on the network.
This “assumed breach” testing encompasses a variety of attackers including insider threats, successful phishing campaigns, and external actors. Removing the time and resources a penetration tester might need to gain network access internally saves the organization money and also provides a holistic view of the attack vectors that exist internally, providing better insight to staff on the level of impact that might be realized if an attacker were to gain successful entry.
The Tools of the Trade (Responder and NTLM Relay)
Before diving into real-world examples of MNR protocol poisoning, these are some of the tools commonly used by attackers to facilitate it. Responder is a utility that listens for and “responds” to MNR queries as they propagate in the network. The Cynet article referenced previously provides an in-depth description of the tool and its uses. This beacon is used to elicit the authentication from the victim.
NTLMRelayx is a component of the popular Impacket toolset, used by penetration testers and threat actors alike for a number of network-based attacks. NTLMRelayx stands up SMB, HTTP, LDAPS, MSSQL and RPC servers in order to capture NTLM authentication handshakes and relay them to specified targets. Depending on the target protocol selected, NTLMRelay may make use of SOCKS5 proxies (this is the case when relaying SMB to SMB).
These tools work in tandem to respond to MNR queries, capture the resulting NTLM handshakes, and relay them to a target. Once a session has been established, NTLMRelayx refreshes the connection continually to maintain access.
SMB and HTTP to SMB
NTLM authentication is prevalent throughout many of the critical services on which a Windows-based domain relies. SMB, RPC, HTTP, and even LDAPS all have the ability to respect NTLM in certain configurations, and as such the ability to relay an authentication handshake via this attack vector can be extremely destructive. The traditional exploit associated with NTLM relay attacks is standard SMB to SMB between two hosts:
The victim attempts to access a resource that cannot be resolved (i.e. \\filesahre\ is searched in File Explorer instead of \\fileshare\.
A MNR query is made throughout the network after DNS fails to resolve the hostname. The attacker responds to this request and the victim authenticates to the attacker over SMB via NTLM.
This NTLM handshake is captured by the attacker and relayed to a host that does not have SMB signing enabled and required.
The attacker can now remotely execute code against the target host within the context of the victim.
If the victim user holds administrative access to the target host, the attacker can extract its remote registry, providing access to the NTLM-hashed credentials of all local accounts, the DCC2 hashes of any cached domain user logins, and cleartext service passwords if configured.
HTTP to LDAP(S)
NTLM requests over HTTP are common in most Windows domains. This may manifest in authentication to web applications or certain services, such as Web Enrollment via Active Directory Certificate Services. Regardless, NTLM over HTTP offers an attacker several devastating attack vectors to choose from: namely, the ability to relay these authentication attempts to the Lightweight Directory Access Protocol (LDAP) subsystem or its TLS/SSL-encrypted version, LDAPS.
Consider the following scenario: an attacker has gained access to the network, and setup a Responder session. Sysadmins had previously used a service account to perform maintenance on a web app internally on a weekly basis, but that server has since been decommissioned. Unfortunately, that service account and corresponding service was not decommissioned, and it periodically reaches out to the network to resolve the old hostname and perform its intended function.
The attack starts with grabbing that NTLM over HTTP authentication handshake, and relaying it to the LDAP/LDAPS server.
Domain harvesting via LDAP
For the LDAP server, the primary danger is harvesting domain information.
After successfully authenticating to the server, the attacker is able to pull all of the LDAP data in the network: usernames, group memberships, which user has administrative access to which host, the domain’s password policies, etc. With this full list of all the domain’s users the attacker can execute a password spray attack.
If anyone is using a common password like “Winter2024!” or “Password1!”, this spray will likely compromised these accounts. It’s quite simple to test 1000’s of users against a few of the most common passwords. This is one reason, among many, why enforcing longer passwords and having a lockout is a good idea. Maintaining a blacklist of commonly-used passwords is also a good idea.
Creation of machine accounts over LDAPS
Even with the above safeguards in place, there is a further, potentially more dangerous, risk. Instead of relaying to LDAP, the attacker relays to LDAPS. LDAPS provides some functionality that its non-secure counterpart does not, and one of the most notable is the configuration of passwords. Creating a new user account and setting the password all happens over LDAPS by design, so that if this traffic was captured it couldn’t be read in plaintext. Most domains are configured to only allow specific accounts to create new domain users, and thus unless an attacker were to get a hold of an administrator’s NTLM handshake, it is unlikely that they could create a new user account.
The danger comes in to play when considering the Machine Account Quota(MAQ), an Active Directory attribute that, by default, allows any user in the domain to create up to 10 machine accounts. Windows implemented the MAQ in this manner so that users can join new computers to the domain; however, the potential for abuse of this default configuration far outweighs the benefits.
Machine accounts are functionally equivalent to a user accounts within the context of Active Directory. Sysadmins are able to delegate administrative rights on a computer to other machines and users as necessary for business functionality, although most only hold privileges similar to a standard domain user. So say the attacker captures a low-privilege user’s NTLM handshake, but can’t crack it offline. If they relay to LDAPS, they can abuse a domain that’s employing the default MAQ policy to create a new machine account, A.K.A a new domain user that they can control.
The real danger here is that a user can leverage the MAQ to enter into the domain itself without an prior compromise of a user account. With this newly created machine account, the attacker can enumerate shared network drives, enumerate LDAP, and search for methods of privilege escalation in the domain. As any penetration tester will tell you, the hardest part of achieving a domain compromise is finding the first foothold, and LDAPS relaying is a consistent, reliable method for bypassing that initial hurdle.
HTTP to ADCS
Many Windows-based domains, especially larger ones, employ Active Directory Certificate Services (ADCS) as a Certificate Authority (CA). ADCS makes the process of certificate delegation and dissemination within an Active Directory environment quick and easy, providing TLS/SSL security for internal HTTP traffic. The issue that arises is the insecure default configuration of ADCS and, more importantly, its Web Enrollment service.
Web Enrollment is designed to provide a simple interface for users to assist in certificate creation via browser, but unfortunately much like the aforementioned SMB and LDAP relaying techniques, an attacker can leverage MNR queries propagating in the network to abuse it. Take for example the endpoint in the Web Enrollment server at /certsrv/certfnsh.asp:
Although unassuming at first, this page is where an authenticated user can generate a certificate for themselves. The issue here lies in the fact that this application relies on NTLM authentication over HTTP in order to identify and authorize users making such requests, which opens up the path for NTLM authentication relaying.
In the following scenario, an attacker has access to the following:
- An ADCS server exposed to the network with either HTTP or HTTPS serving the Web Enrollment service.
- A host under its control that can respond to MNR protocol queries (likely Responder or the Windows equivalent, Inveigh).
- MNR traffic propagating throughout the network that can be responded to.
- Authentication handshakes employing NTLM over HTTP which can be captured and relayed.
The attacker will first identify the ADCS server via techniques including either enumeration of SMB shares on each host (ADCS servers always have an exposed “CertEnroll” share accessible to all domain users) or via manual enumeration of the previously mentioned /certsrv/certfnsh.asp web application resource.
NTLMRelayx is then configured to relay all authentication handshakes to this endpoint. In the event that a HTTP over NTLM request is captured and successfully relayed to the ADCS server, a PFX certificate for that user will be generated and saved to the attacking host:
ntlmrelayx --adcs --template DomainController -debug -smb2support -t https://192.168.1.10/certsrv/certfnsh.asp
[*] SMBD-Thread-5 (process_request_thread): Received connection from 192.168.1.20, attacking target https://192.168.1.10
[*] HTTP server returned error code 200, treating as a successful login
[*] Authenticating against https://192.168.1.10 as EXAMPLE/ADMINISTRATOR SUCCEED
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 281221
[*] Base64 certificate of user ADMINISTRATOR:
MIIRzQIBAzCCEYcGCS[ ... ]
At this point, the attacker controls a certificate that can be used to impersonate the user or computer object that originally made the NTLM authentication. While this in-and-of-itself is a concern, the true danger associated with this attack comes into play when Kerberos comes into play.
A Ticket-Granting-Ticket (TGT) is a vital component of Kerberos authentication and is supplied by the domain’s Key Distribution Center (KDC) as part of the service granting process. Kerberos is lightyears ahead of NTLM as far as security is concerned, but unfortunately there are vulnerabilities associated with it that researchers and attackers have leveraged in the wild. The ability to extract the NTLM hash of a compromised user’s domain credentials is a common attack vector associated with ADCS relay attacks and relies on the PKINITtools library of tools.
Abusing Kerberos, an attacker is able to request a TGT as the compromised target domain user, alongside its accompanying AS-REP encryption key (this comes into play shortly):
python3 gettgtpkinit.py "ADMINSTRATOR" -pfx-base64 '"'$(cat ../dc-cert.txt)'"' "ADMINISTRATOR.cache"
2024-06-05 18:04:54,488 minikerberos INFO Loading certificate and key from file
INFO:minikerberos:Loading certificate and key from file
2024-06-05 18:04:54,779 minikerberos INFO Requesting TGT
INFO:minikerberos:Requesting TGT
2024-06-05 18:04:54,809 minikerberos INFO AS-REP encryption key (you might need this later):
INFO:minikerberos:AS-REP encryption key (you might need this later):
2024-06-05 18:04:54,810 minikerberos INFO e42b8e...
INFO:minikerberos:e42b8e017...
2024-06-05 18:04:54,813 minikerberos INFO Saved TGT to file
INFO:minikerberos:Saved TGT to file
An attacker can take the TGT they’ve requested on behalf of the compromised user and abuse the Kerberos User-to-User (U2U) service to submit a Ticket Granting Service (TGS) service ticket on behalf of the victim:
KRB5CCNAME="ADMINSISTRATOR.cache" python3 getnthash.py "EXAMPLE/ADMINISTRATOR" -key e42b8e017f....
Impacket v0.11.0 - Copyright 2023 Fortra
[*] Using TGT from cache
[*] Requesting ticket to self with PAC
Recovered NT Hash
c5a2b7d8f4a36c2d9f1e01984f6a2b8d7
This in turn provides the attacker with a Privileged Attribute Certificate (PAC), which contains the NTLM hash of the user. With the PKINITtools toolset, this PAC can be decrypted, and the attacker now has access to the NTLM hash itself, which in a Windows domain is often functionally equivalent to the plaintext password:
nxc smb 192.168.1.10 -d example.local -u Administrator -H 'aad3b435b51404eeaad3b435b51404ee:c5a2b7d8f4a36c2d9f1e01984f6a2b8d7'
SMB 192.168.1.10 445 DC-01 [*] Windows Server 2016 x64 (name:DC-01) (domain:example.local) (signing:True) (SMBv1:False)
SMB 192.168.1.10 445 DC-01 [+] example.local\Administrator:c5a2b7d8f4a36c2d9f1e01984f6a2b8d7
The most important takeaway from this attack vector is that if the conditions described are met that any user authenticating over NTLM via HTTP can be compromised in this manner. Be it a Domain Administrator, a Domain Controller’s machine account, or any domain user, this attack can bring any organization employing Web Enrollment services to its knees, and quickly.
SMB to MSSQL
Continuing the trend of relaying NTLM authentication handshakes to critical services, MSSQL represents yet another often overlooked security gap that an attacker can compromise solely from Layer 3 network access. The volatility of this attack vector is largely dependent on the configuration of the database itself and the permissions delegated to the victim user; however, penetration testers and threat actors alike have leveraged it to great effect in recent years.
This attack takes advantage of domain authentication within a MSSQL server (or more succinctly, the use of SMB as an authentication mechanism). By default, MSSQL authenticates domain users over SMB without an extra challenge, similar to how workstations and servers that are not configured to require SMB signing function. This means that a captured handshake can be relayed to the database itself (if port 1433 is open and domain authentication is enabled), and the attacker can run arbitrary queries against the database within the context of the compromised user:
nmap -p 1433 192.168.1.10
Nmap scan report for 192.168.1.10
PORT STATE SERVICE VERSION
1433/tcp open ms-sql-s Microsoft SQL Server 2017
ntlmrelayx.py -t mssql://192.168.1.10 -i -smb2support --no-multirelay
[*] HTTPD(80): Authenticating against mssql://192.168.1.10 as EXAMPLE/ADMINISTRATOR SUCCEED
[*] Started interactive MSSQL shell via TCP on 127.0.0.1:11000
The risk posed by this attack depends significantly on the user’s privileges within the database. If the relayed handshake belongs to a user that has read access to all of the databases and their respective tables, you can assume that all of that data is now forfeit to the bad guys. Write access compounds this threat, as the attacker could manipulate or destroy the data after exfiltration, leaving you reliant upon backups or paying exuberant extortion fees to restore your organization’s data:
SQL (EXAMPLE\Administrator dbo@master)> EXEC sp_configure 'show advanced options', 1;
SQL (EXAMPLE\Administrator dbo@master)> GO
ERROR: Line 1: Could not find stored procedure 'GO'.
SQL (EXAMPLE\Administrator dbo@master)> RECONFIGURE;
SQL (EXAMPLE\Administrator dbo@master)> EXEC sp_configure 'xp_cmdshell', 1;
SQL (EXAMPLE\Administrator dbo@master)> RECONFIGURE;
SQL (EXAMPLE\Administrator dbo@master)> EXEC master..xp_cmdshell 'whoami'
output
----------------------
nt service\mssqlserver
Finally, say that a relayed authentication handshake belonged to a user that had DBA-level privilege to the database. With a few simple queries the attacker can launch arbitrary code against the database’s underlying host.
Given that MSSQL is often ran in the context of the SYSTEM account, this quickly evolves into a compromise of the host itself, and the attacker now has complete control over a server in your network.
Ridding the Network of the Ghost of MNR
The Standard Application Layer Approach
The standard means of dealing with the threat of MNR is via various configuration changes both at the domain policy and the individual host level. Solutions fall into two basic approaches:
- Disabling the MNR protocols themselves
- DNS sinkholing/resolving commonly-seen MNR query host names
There is the further issue of mitigating the threat of NTLM relay, but as this article is focusing on MNR itself, NTLM relay is out of scope. There other sources that lay out the solutions to this problem, primarily focusing on making SMB signing required and enabling Extended Protection for Authentication (EPA)) on every service where it is applicable.
Disabling MNR protocols
-
LLMNR: LLMNR can be turned-off through the group policy editor, under the “policy setting” menu under:
Local Computer Policy →
Computer Configuration →
Administrative Templates →
Network →
DNS Client →
"Turn off multicast name resolution": Enabled
This can be done via a Group Policy Object (GPO) and propagated throughout the domain.
-
NetBIOS Name Service (NBT-NS aka WINS):
- Navigate to Control Panel > Network and Internet > Network and Sharing Center.
- Click Change adapter settings.
- Right-click Local Area Connection, and then click Properties.
- Select Internet Protocol Version 4 (TCP/IPv4), click Properties, and then click Advanced.
- Click the WINS tab, and in the NETBIOS setting section, click Disable NETBIOS over TCP/IP. Click OK to close the properties windows.
- Navigate to Administrative Tools > Services, right-click TCP/IP NETBIOS Helper, and click Stop.
- Right-click TCP/IP NETBIOS Helper, click Properties, and in the Startup type list, select Disabled. Click OK.
This can only be done on each individual host, unless a startup script is distributed via group policy.
-
mDNS:
-
Disable mDNS using Powershell
set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\" -Name EnableMDNS -Value 0 -Type DWord
-
Disable using reg command
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v " EnableMDNS" /t REG_DWORD /d "0" /f
Like NBT-NS, mDNS can only be disabled on a host-by-host basis, or via startup script.
Unfortunately, experience working with organizations in dealing with MNR from the policy/host configuration perspective has shown this to be a perpetual game of “whack-a-mole”. Due diligence requires that an effort be made to disable it as much as possible, but it is exceedingly rare for any organization of any size to eliminate it entirely. The following section provides a more permanent solution for some common MNR queries seen in the wild.
DNS sinkholing/resolving common MNR queries
MNR queries only happen when the standard DNS server returns NXDOMAIN (domain does not exist) or SERVFAIL (server failure). So, one method of preventing MNR queries from being sent is to use DNS sinkholes or in some cases, provide CNAME aliases for legitimate hostnames that are being looked up incorrectly.
In the following sections, several different types of MNR queries commonly seen in the wild will be discussed. Analysis of data from the wild, i.e. from the context of actual penetration tests, will also be discussed to give a sense of the impact of using DNS sinkholing. The data comes from 14 different penetration tests where Responder data was collected. Each test is identified by the total number of MNR requests that were seen by and responded to by Responder.
To give a sense of how DNS sinkholing or resolving certain common MNR queries could affect the overall number of MNR queries made within actual Windows enterprise environment in the wild, the following graph shows the percentage reduction of queries across all the organizations in the data set. The X axis corresponds to the percentage of MNR requests (potentially) removed as a result sinkholing/resolving these requests. The Y axis corresponds to the total number of MNR requests made by all domain hosts during the course of the penetration test, so if the Y axis label is “317,167”, that means that 317,167 MNR requests were made at that organization.
MNR percentage reduction if all of the hostname types were to either be DNS sinkholed or otherwise correctly resolved
As can be seen, not all MNR queries would eliminated by capturing them in DNS. However, several highly dangerous queries could be eliminated, regardless of the quality of individual host configuration.
In the following sections, each of the different types will be discussed:
- Sinkholing WPAD lookups
- Sinkholing Misconfigured Windows file system name lookups
- Resolving incorrect but legitimate domain name lookups
- Resolving incorrect but legitimate individual server/workstation name lookups
Sinkholing Web Proxy Auto-Discovery (WPAD) protocol
By default, Windows workstations are configured to assume the existence of a web proxy server through which all internet traffic should be routed. The way this is implemented is via the use of the Web Proxy Auto-Discovery (WPAD) protocol.
- The workstation makes a request for the following hostnames:
WPAD (LLMNR & NBT-NS) and/or WPAD.local (mDNS).
- If those hostnames resolve, either through DNS or MNR, the workstation makes an HTTP request to
http://wpad/wpad.dat to retrieve the proxy configuration file.
- If there is no
WPAD configured in DNS, which is almost always the case, then a malicious host can respond to the MNR request and induce the victim workstation to authenticate to it via NTLM.
In the context of penetration testing, MNR attacks of this type very often lead to compromise of accounts and in many cases, the compromise of the domain. In the wild, the following chart shows the prevalence of WPAD requests being made.
WPAD requests as a percentage of total MNR queries
If the domain has both WPAD and WPAD.local sinkholed as a non-routable address (e.g. 127.0.0.1) in DNS, then this will cause the WPAD protocol to safely fail. While directly disabling the automated proxy discovery on each host is the most direct way of eliminating this issue, experience in the wild suggests that hosts can fall into poor configurations. Sinkholing is the only way (other than the network layer approach discussed in the next section) to eliminate WPAD poisoning as a threat, regardless of host configuration.
Sinkholing name lookups from misconfigured Windows file systems
There are at least two other hostnames that arise in MNR requests in the wild that could be sinkholed.
__MSBROWSE__ (NBT-NS)WORKGROUP (NBT-NS)
These hostnames end up being name requests due to some default (incorrect) behaviors of the CIFS and SMB protocols and are always requested with the NetBIOS name service.
Misconfigured Windows filesystems requests as a percentage of total MNR queries
If these hostnames are sinkholed in DNS with non-routable address, e.g. 127.0.0.1, this should eliminate these MNR requests.
Resolving incorrect domain name lookups
This section and the next are not about DNS sinkholing. Rather organizations might consider providing DNS aliases for known hosts in their environment.
As the first example, it is common during penetration tests to see MNR queries for the organization’s actual domain name, but the query is incorrectly referencing this domain. E.g. if you have an organziation with the following domain setup:
- The internal domain name is
INTERNAL.ORGANIZATION.COM
- The organization additionally has a domain trust (i.e. an domain alias) of
ORGANIZATION.COM
Common incorrect but legitimate MNR queries for this include:
INTERNAL or INTERNAL.LOCALORGANIZATION or ORGANIZATION.LOCAL
Below is a graph of the percentage of MNR queries seen in the wild for these types of incorrect but legitimate domain name lookups.
Incorrect but legitimate organization domain name lookups as a percentage of total MNR queries
If these common misrenderings of the domain name are provided CNAME aliases in DNS, then these MNR requests will be eliminated. The primary danger of allowing these MNR queries to happen is that many organizations use their domain controller additionally as a file server, and if hosts and/or services are incorrectly configured to seek out that file server, this is exactly the type of query that Responder exists to exploit. It is almost guaranteed to be able to induce NTLM authentication.
Resolving incorrect server/workstation name lookups
The second example far more common and corresponds to name lookups for individual hosts in the domain, usually servers but occasionally workstations.
E.g. if you have an organization with the domain setup from the above section, then fully-qualified domain names for hosts would be something like
FILESERVER1.INTERNAL.ORGANIZATION.COM orWORKSTATION1.INTERNAL.ORGANIZATION.COM
Common incorrect but legitimate MNR queries for these include:
FILESERVER1 or FILESERVER1.LOCALWORKSTATION1 or WORKSTATION1.LOCAL
Below is a graph of the percentage of MNR queries seen in the wild for these types of incorrect but legitimate hostname lookups.
Incorrect but legitimate hostname lookups as a percentage of total MNR queries
If these common misrenderings of these hostnames are provided CNAME aliases in DNS, then these MNR requests will be eliminated. The primary danger of allowing these MNR queries to happen is that the most common misconfigured lookups resulting in MNR are those involving servers, especially file servers or database servers. If these MNR name lookups are successfully poisoned, it would likely result in captured NTLM authentication.
The Big Hammer: The Network Layer Approach
Why network mitigation?
As has been stated above, preventing network clients from sending or receiving requests for “peer-to-peer” name lookup services is a hard problem, and for most environments, is nearly impossible to completely solve at the client level. The exact reasons are varied, but the general reason is simple: hostname lookup is, politely, a huge technological mess.
Technology is always a sliding window of backwards compatibility with legacy systems, and this effect is in full-swing with name lookup services. A modern Windows supports, at the OS level, no fewer than five distinct hostname lookup mechanisms. This includes:
- An ARPANET-style hosts file
- The local DNS caching resolver
- The DNS protocol over UDP and TCP, optionally TLS encrypted
- The Microsoft implementation of “multicast DNS over IP”, LLMNR
- The Apple implementation of “multicast DNS over IP”, mDNS
- The name service component of NetBIOS, most frequently seen with NetBIOS-over-TCP/IP (NBT). This service has, itself, three components:
- An IPv4 broadcast request for a hostname
- A lookup to the local WINS server
- An extension of the ARPANET-style hosts file, LMHOSTS, which includes a pseudo C preprocessor which supports including another remote system’s LMHOSTS file
Other OSes typically implement DNS, mDNS, and LLMNR, including most Linux distributions. In the past, MacOS X systems may have also supported NetInfo, UNIX systems supported NIS or NIS+, and more esoteric systems supported other proprietary lookups.
This is the first complication: these systems may be added or removed from an OS at the whim of the software vendor, and thus may be unknowingly invoked by any application that uses the system’s implementation of getaddrinfo()/gethostbyname(), or any higher-level API which relies on these functions. Configuring the behavior of a platform’s standard library/runtime is not always possible or consistent: Windows only provides partial support for configuring its resolver via group-policy, with some changes requiring touching the registry manually. From an application’s perspective, there is no way to ensure that a hostname will not be resolved from a particular method, except by bypassing the OS and implementing lookup “in-house”.
Which introduces the second major complication with controlling hostname lookups – it is essentially impossible to prevent user software from simply implementing it itself. It is possible to both perform an LLMNR request and respond to an LLMNR request without requiring administrator rights, because LLMNR (and mDNS) listen on non-privileged ports. Software which implements DNS lookups in userspace will simply ignore the OS’s configuration, and such software is not uncommon. Several web browsers, for example, will intentionally ignore/bypass the system’s DNS settings and use DNS-over-HTTPS with a separate nameserver.
The best security practice is “defense in depth” – cybersecurity has no silver bullet, and there is no real-world network or computer system that is invulnerable to attack. While system administrators should still strive to correctly and securely configure the machines they administer, there needs to be additional layers of protection. When it comes to protecting from responder poisoning attacks of any kind, an often overlooked layer is that of the network.
Network admins have the ability to do something which sysadmins are incapable of – restricting the traffic which carries multicast/broadcast name lookups, at the network level. While this is still no silver bullet, this solves several problems:
- Unknown or unmanaged hardware which could be exploited
- Changes in OS/vendor configuration enabling mDNS/LLMNR where it had previously been disabled
- Third-party software using mDNS/LLMNR regardless of OS settings
For this analysis, we’ll cover the three major sources of multicast & broadcast name lookup traffic that is common with Windows and Linux hosts, LLMNR, mDNS, and NBT-NS, which cover the vast majority of the current attack surface, but the same principles easily apply to any other or future protocol.
Principles of Broadcast & Multicast
Of these three protocols:
- LLMNR and mDNS are multicast protocols, while
- NBT-NS (NetBIOS-over-TCP/IP Name Service) is a broadcast protocol.
Let’s briefly describe what these are, and what is means for our network configuration.
The Internet Protocol (IP) is a “Layer 3” network protocol. It sits on top of “Layer 2”, which is most commonly an IEEE 802 LAN, including 802.3 “Ethernet” and 802.11 “WiFi”. Because most OSes expose 802.11 frames as regular “Ethernet II” frames, it is standard to generalize the two to just “Ethernet”.
IP’s job is to deliver data across Layer 2 network boundaries. To that end, IP hosts are given an address to identify them within the Layer 3 network. However, IP is not limited to delivering data to a single host: portions of the “address space” are reserved for use as multicast and broadcast addresses.
The three types of addresses:
- Unicast - an address representing a single IP host, for one-to-one communication
- Broadcast - an address representing every host in an IP network, for one-to-many communication
- Multicast - an address representing (potentially) multiple hosts in an IP network, for one-to-many communication
There are two versions of the Internet Protocol in use today – IPv4 and IPv6. Version 6, while not as widely deployed as version 4, is critical to discuss, as IPv6 multicast traffic may be active in a Layer 2 network even if there is no IPv6 network defined at layer 3, as almost every OS enables IPv6 by default, and will use “stateless address autoconfiguration” (SLAAC) to give every network interface an IPv6 address.
Unicast is self-explanatory – an IPv4 address of 192.168.0.1 species a single host, and one can use IP to send datagrams to specifically this host.
Broadcast is also quite simple. An IPv4 address of 192.168.0.255 species all hosts on the 192.167.0.0/24 network. The way this works at layer 2 is simple: the Ethernet frame containing the IP data is given a destination MAC address of ff:ff:ff:ff:ff:ff, and this frame is flooded across the broadcast domain, usually meaning an entire VLAN and all connected devices.
Multicast is the most complex of the three. In IPv4, all multicast addresses are under the 224.0.0.0/4 “network”, which is further divided into blocks based on “intended use”. The relevant block here is 224.0.0.0 - 224.0.0.255, which denotes the “Local Network Control Block”. These are used for traffic which is “not forwarded off link”. IPv6 similarly has a dedicated prefix for multicast traffic, ff00::/8, and is broken down into similar “blocks” through the use of flags in the second octet of the address.
Similarly to broadcast traffic, multicast traffic is sent with a particular destination MAC address. Unlike broadcast traffic, though, different multicast addresses are mapped to different MAC address. This provides a mechanism for networking hardware to more efficiently process multicast datagrams.
Stopping it at the source
Even a small number of devices vulnerable to multicast/broadcast poisoning means a broadcast domain is vulnerable to bad actors with network access, with the compromise of even a single host often being enough to cause all the dominoes to fall.
The best solution is a two layer defense in depth strategy:
- Good network segmentation to reduce the size of broadcast domains, and
- Restricting the flow of these multicast and broadcast protocols on the distribution switches themselves.
Since segmentation is such a deep and complex topic, the second option is a better starting point. Blocking MNR (mDNS, LLMNR, and NBT-NS) traffic at the switch level is the most straightforward defense against Responder-style poisoning. In an enterprise environment, there is almost no reason for these protocols to be in use; intentional use of MNR should be regarded as an “anti-pattern” in a managed network. Even for small server environments, hostnames in an enterprise network should never be resolved using MNR.
To block them, network administrators must understand what they are:
- NetBIOS Name Service is an IPv4-only broadcast protocol, communicating over both TCP and UDP port 137.
- LLMNR is an IPv4 and IPv6 multicast protocol, sending queries over UDP port 5355.
- On IPv4, it uses the multicast address
224.0.0.252, corresponding with the MAC address 01:00:5E:00:00:FC.
- On IPv6, it uses the multicast address
FF02::1:3, corresponding with the MAC address 33:33:00:01:00:03.
- mDNS is an IPv4 and IPv6 multicast protocol, sending queries over UDP port 5353.
- On IPv4, it uses the multicast address
224.0.0.251, corresponding with the MAC address 01:00:5E:00:00:FB.
- On IPv6, it uses the multicast address
FF02::FB, corresponding with the MAC address 33:33:00:00:00:FB.
What won’t work (MAC filtering)
For multicast traffic, one solution would be to apply an access list filtering the four destination MAC addresses used by LLMNR and mDNS. Unfortunately, as the story goes, Steve Deering was unable to afford more than one OUI prefix when creating IP multicast. Thus, the prefix 01:00:5E is shared by all IPv4 multicast addresses. Since there are 224.0.0.0/4 multicast addresses, a 28-bit value, and only 23-bits of space available in a MAC address after you lose 24-bits for the prefix plus one bit for the local/universal administered bit, you lose 5 bits of address per MAC address.
What this means in practice is that every IPv4 multicast MAC address is shared with two to the power of five (32) IPv4 multicast addresses. IPv6, with its larger addresses, has an overlap of two to power of 80, or approximately one septillion IPv6 multicast addresses per MAC address. This means that it’s impossible to use MAC filtering to block simply one multicast address.
Besides that, it’s not possible to filter broadcast traffic this way (i.e. NetBIOS Name Service); too much legitimate traffic such as ARP and DHCP rely on broadcast addressing to function.
What will work (IP filtering)
Fortunately, modern networking solutions such as HPE Aruba Networking’s switches running AOS-CX make blocking the specific addresses easy, via access lists. The following console log shows what creating such an ACL looks like:
switch(config)# access-list ip disable-multicast-namev4
switch(config-acl-ip)# 10 deny any any 224.0.0.252
switch(config-acl-ip)# 15 deny any 224.0.0.252 any
switch(config-acl-ip)# 20 deny any any 224.0.0.251
switch(config-acl-ip)# 25 deny any 224.0.0.251 any
switch(config-acl-ip)# 30 deny tcp any eq 137 any
switch(config-acl-ip)# 40 deny udp any eq 137 any
switch(config-acl-ip)# 50 permit any any any
switch(config-acl-ip)# exit
switch(config)# access-list ipv6 disable-multicast-namev6
switch(config-acl-ip)# 10 deny any any ff02::1:3
switch(config-acl-ip)# 15 deny any ff02::1:3 any
switch(config-acl-ip)# 20 deny any any ff02::fb
switch(config-acl-ip)# 25 deny any ff02::fb any
switch(config-acl-ip)# 30 permit any any any
switch(config-acl-ip)# exit
switch(config)#
From here, this ACL can be applied to switchport interfaces or VLAN interfaces, and this will:
- Block UDP and TCP traffic on port 137, blocking all NBT-NS lookups
- Block multicast queries and responses for both IPv4 and IPv6 LLMNR addresses
- Block multicast queries and responses for both IPv4 and IPv6 mDNS addresses
As mentioned earlier, 802.11 “WiFi” functions very similarly to Ethernet. While the layer 2 framing is not entirely the same as the forms of Ethernet most commonly used today, everything that’s been discussed applies to many wireless products, including HPE Aruba Networking’s wireless solution. With wireless access points running ArubaOS, the same ACLs can be created via the web interface. For example, when using Aruba Central, ACLs can be easily added to access points:
Handling LLMNR traffic in Aruba Central
The same ACLs should be applied to wireless access points as switches. With these in place, multicast and broadcast name services are blocked on wireless networks.
This should have minimal effect on legitimate traffic in a managed network, and will massively reduce the connected clients’ attack surface to these Responder-style exploits. Note that this is still
The only legitimate source of traffic for these queries would be client computers either requesting or receiving information about devices such as printers and wireless displays, such as conference room TVs. In most of these cases, the security risk of allowing LLMNR/mDNS far outweigh any savings in convenience through their use.
If LLMNR/mDNS are needed for such a use case, then network segmentation should be used to minimize the broadcast domain and “scope” of the multicast packets. VLANs should be kept as small as possible, and the ACLs applied to any interfaces that do not need to send LLMNR and mDNS requests.
Tuning MNR in Your Network
You may be asking yourself at this point, if MNR traffic opens the door to so man different attack vectors, why would anyone leave it enabled? As we discussed previously, mDNS does offer value for organizations that employ Apple machines and IOT devices, and services such as Bonjour are reliant on it. While the remediations presented in this article are the most effective methods for combatting MNR protocol poisoning attacks, additional optiosn do exist for tuning your network environment to both support these protocol where they’re needed and locking it down in areas where they can more easily be leveraged to initiate an attack.
Utilities such as AirGroup provide the flexibility to control how far mDNS can propagate within your network at a subnet level, and even offer granular controls such as allowing it to only reach hosts that are assigned specific roles. This is invaluable for organizations that often require services like the aforementioned Bonjour, such as educational institutions.
Each organization’s mission will shape the way that network administrators tune its multicast traffic. Some may decide that its best to completely disable it, and some may find that printing and host discovery services are not functional without it. HPE Aruba support is always available to field questions regarding network tuning and functionality to ensure that you’re able to make informed, security-conscious decisions without compromising function.
A Final Note on MNR
This article was written from the perspective of a team of penetration testers with years of experience doing hundreds of audits with many different organizations. For at least the last six years, the abuse and exploitation of MNR alone has led to the full domain compromise of about 90% of those organizations. And in every case, the team started with nothing more than network access.
The danger of Multicast Name Resolution cannot be emphasized enough.
The requirement of name resolution in enterprise networks can be completely and correctly implemented using the Domain Name System (DNS). MNR is not necessary. There are too many threats associated with poisoning MNR queries. Not only can threat actors acquire individual account credentials, but they can also relay NTLM handshakes to other hosts (SMB) and services (LDAP and MSSQL). In some cases (AD CS), threat actors can abuse MNR to compromise the domain directly.
There are application layer solutions that attempt to mitigate the threat, and these solutions should be implemented by system administrators. Configuration and policy changes can eliminate much MNR traffic. Furthermore, DNS itself can be used to handle the behaviors of misconfigured but legitimate service name lookups. However, it has been the team’s experience that even correctly implemented, these application layer approaches only mitigate; they rarely fully remediate, and even then only in tightly managed enterprise environments.
Thus, it is the team’s opinion that the only way to “close the loop” and completely address MNR is via network controls. As it is said, “A good segmentation covereth a multitude of sins.” Modern networking hardware such as HPE Aruba’s AOS-CX switchgear has the ability to stop MNR traffic before it propagates. It is long past time for the networking team to get involved with killing the Ghost in the Network.