A Penetration Tester’s Best Friend – Multicast DNS (mDNS), Link-local Multicast Name Resolution (LLMNR), and NetBIOS-Name Services (NetBIOS-NS)

Written by: Stephen Nelson

Throughout our penetration testing engagements, we find that we can gain an initial foothold in the domain or gain user credentials easier. Why? The following underlying protocols are fallback protocols for when domain naming service (DNS) ultimately fails. With most of our clients, we hear that “we fixed these protocols,” or that “these protocols have no risk associated with them,” but when their DNS server fails, these protocols become the fallback and our attacker device command line lights up like a Christmas tree. Throughout this blog, we show how an attacker would best utilize these protocols, what can happen if these protocols are in use, and how to best remediate them.

What Are NetBIOS, LLMNR & mDNS?

NetBIOS-NS stands for network basic input/output system naming service. This protocol runs on UDP/TCP port 137, 138, and 139, mostly on Windows hosts running Server Message Block (SMB) and the Unix-based version, Samba. This protocol asks the receiving machine to disclose and return its current set of NetBIOS names.

LLMNR stands for Link-Local Multicast Name Resolution. This protocol runs on UDP port 5355, mostly to perform name resolution for hosts on the same local link. It mostly includes all Windows hosts and has been implemented in Linux for the systemd-resolved service.

mDNS stands for Multicast DNS. This protocol runs on UDP port 5353 and was originally made by Apple to help the AirPlay2-based services perform seamless setup via the Bonjour service. Now, it is found primarily in networks with mostly Windows and internet of things (IoT) devices. This protocol performs local network name and service discovery without the need for central name resolution.

These protocols are a penetration tester’s best friend. All these protocols are used to resolve host names on local networks. When a local network needs to resolve “google.com” to its IP address of “x.x.x.x,” computers or internet of things (IoT) devices follow a hierarchical approach when querying the target resource:

1. Check to confirm whether the request is for the local machine name.
2. Check the local cache of recently successfully resolved names.
3. Search for a local host file, which is a list of IP addresses and names stored on the local computer. Depending on the device, this file might already be loaded into the local cache.
4. Query a DNS server if one is configured.
5. If NetBIOS is enabled, attempt NetBIOS name resolution via broadcasting NetBIOS-NS queries to the local subnet if the name is not in the local NetBIOS cache. This step might use a Windows Internet Name Server (WINS) server if configured and the LAN manager hosts (LMHOSTS) file.
6. If LLMNR is enabled, broadcast LLMNR queries across the local subnet network to ask its peers for resolution.
7. If mDNS is enabled, the appropriate client sends a multicast into the network while asking which network participant matches the hostname.

In short, if the DNS fails at any point to resolve the name of the hosts during the process above, LLMNR, NetBIOS, and mDNS take over to keep everything in order on the local network.

The Attack

The inherent problem with these protocols is the trust the victim computer assumes with other devices in its segment of the network. If a computer cannot properly identify the resource it is looking for among the first four steps, the different local naming resolution protocols come into play. The best example of this is when a user mistypes the name of a resource, requests a resource that is no longer available, or a user begins to type in the Windows start menu. For example, typing \\testt\ when the \\test\ share is the correct file share. This would allow the attacker to poison the request and say “Hi, I am \\testt\, authenticate to me!”

In Summary:

1. 1. User incorrectly enters a hostname that gets queried on the local network.
   2. The domain controller responds and states that the hostname does not exist in DNS.
   3. The host discovery protocols, LLMNR, mDNS, and NetBIOS-NS broadcast the request.
   4. The attacker responds to the host discovery protocol stating that the attacker is the host being sought and that the user should authenticate to the attacker.
   5. The workstation sends authentication credentials to the attacker either in the form of username and password, or the user’s password encoded in NTLMv1 or NTLMv2 format.
   6. With these credentials, an attacker can either replay the hash to another computer and obtain a session or attempt to crack the hash offline.
   7. If an attacker receives a plaintext password, the attacker now has domain credentials and the same access as the user.

Chromium browsers (including Google Chrome, Safari, and Microsoft Edge) do use mDNS to locate printers and use Chromecast (Chrome) or AirPlay (Safari) on the internal network, which broadcasts on the accessible subnet. This is a known issue.

Mozilla Firefox has been tested and does not broadcast mDNS on the accessible subnet as it does not rely on mDNS to discover printers.

When a user requests to find a printer, as illustrated below, the Chromium browser utilizes mDNS to find that printer, and an attacker would be able to poison that request.

Remediation

These legacy protocols provide redundancy when DNS fails. An organization should investigate adopting more modern services such as DNS to ensure that compromises don’t happen.

There are several ways to mitigate such attack vectors:

1. Via GPO (Group Policy Object) (LLMNR and NetBIOS-NS): this allows for remediation of both LLMNR and NetBIOS-NS but does not remediate mDNS. To remediate mDNS, a registry key needs to be added to the local Windows host (see #2 below).
   1. Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution > Setting “Enabled”
   2. Force GPUpdate “gpupdate /force”

2. 2. Via Registry (LLMNR, NetBIOS-NS, and mDNS): this helps to remediate mDNS, LLMNR, and NetBIOS-NS on the local host, but if the Windows Internet Name Service (WINS) is allowing NetBIOS-NS requests, then that needs to be disabled as well (see #3 below).
      1. “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters”-Name “EnableMDNS”-Value 0-Type DWord

2. 2. 1. “HKLM: SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces” -Name NetbiosOptions -Value 2

3. Via Control Panel (NetBIOS-NS): this helps to disable NetBIOS-NS on the local Windows hosts.
   1. Launch Control Panel from the Start Menu
   2. Make sure your View by is set to Large Icons and click Network and Sharing Center > Change adapter setting
   3. Right-click on the connected network and select Properties
   4. Select Internet Protocol Version 4 (TCP/IP) and click Properties
   5. Click Advanced > WINS > Disable NetBIOS over TCP/IP > Ok

4. 4. On IoT devices, Linux, and Apple devices
      1. Depending on the device, some need to be locked down more than others, and some services may suffer.
      2. For instance, the Avahi service running on Linux may need to be locked down with the Uncomplicated Firewall (UFW).
         1. The daemon registers local IP addresses and static services using mDNS/DNS-SD and provides two IPC APIs for local programs to make use of the mDNS record cache the avahi-daemon maintains.
         2. To disable the avahi-daemon:
            1. sudo systemctl stop avahi-daemon.service
            2. sudo systemctl stop avahi-dnsconfd

4. 1. Apple Devices need the Bonjour service to locate other Apple Devices (i.e., AirDrop, AirPlay, etc.).
      1. Bonjour, also known as zero-configuration networking, enables the automatic discovery of devices and services on a local network using industry-standard IP protocols.
      2. MacOS relies on mDNS for services such as AirPlay and may not function properly. To disable the mDNSResponder:
         1. sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
         2. sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist
            

            Figure 10: Open Port MacOS

            

            Figure 11: mDNSResponder (Bonjour)

   2. Printers utilize the Bonjour service or mDNS when hosts attempt to discover printers, but do not need LLMNR.
      1. To remediate the Bonjour service, disable it through the web console; however, this may not allow users the ability to find printers on the local network.

5. 5. Detecting local network protocol usages on Windows hosts
      1. This gives the ability to log and monitor all the protocols mentioned in this article on Windows hosts.
      2. Enable Windows Filtering Platform via GPO:
         1. Domain Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object Access > “Audit Filtering Platform Connection” & “Audit Filtering Platform Packet Drop”
         2. After the logs are enabled, the Event IDs 515_ will give a description of what is being blocked or allowed (depending on risk) including inbound and outbound network information (see Figure 14).

5. 5. 2. Either block or allow (detect) mDNS, LLMNR, and NetBIOS-NS on Windows Defender Firewall.
         1. New rule on Windows Defender Firewall (Inbound and Outbound)
            1. Protocol and Ports
            2. UDP: 5353 (mDNS), UDP 5355 (LLMNR), UDP/TCP 137,138,139 (NetBIOS).
            3. Depending on risk (“Allow the connection” or “Block the connection”)
            4. Profile: All
            5. Name: Block (or Detect) Legacy Protocols
            6. Description: Yes

5. 5. 1. 1. Right-click on Windows Defender Firewall with Advanced Security
         2. Under “(Domain/Private/Public) Profile,” click Customize
         3. “Log dropped packets” – “Yes”
         4. “Log Successful Connections” – “Yes”

In conclusion, these legacy protocols are visible on all networks, and these protocols are actively exploited allowing for easier compromise of the network. During a 2021 data breach, these protocols assisted the Lazarus group in harvesting credentials. The group used a “credential harvesting tool named ‘Responder’ and was able to laterally move using various Windows commands.” Responder is an LLMNR, NetBIOS-NS, and mDNS poisoner. This tool “was executed from one of the victim machines that had received the spear-phishing document.” (Lazarus targets defense industry with ThreatNeedle). These protocols are not only harmful by themselves but can be combined with other techniques to allow attackers to further compromise an organization’s network. Taking the appropriate steps to mitigate these vulnerable protocols will ensure that your organization reduces the risk of losing sensitive data, monetary value, or reputation loss. Use the above guide to help ensure that none of this happens to your organization.

Learn More