The Hidden Dangers of Legacy Protocols: NetBIOS, LLMNR, and mDNS

Introduction

Throughout our penetration testing engagements, we’ve discovered that gaining an initial foothold in a domain or acquiring user credentials can often be much easier than expected. Why is that? The culprit is often the fallback protocols: NetBIOS, LLMNR, and mDNS. While many organizations claim that these protocols are either “fixed” or pose no risk, the reality is that they become the go-to fallback when DNS fails. In such scenarios, our attacker’s command line lights up like a Christmas tree.

In this blog, we’ll walk through how attackers leverage these protocols, the potential consequences of their use, and how to best remediate them.

What Are NetBIOS, LLMNR & mDNS?

These three protocols serve as fallbacks when DNS (Domain Name System) fails, ensuring that local network name resolution continues to function properly.

NetBIOS-NS (Network Basic Input/Output System Naming Service)

  • Ports: UDP/TCP 137, 138, 139
  • Used By: Primarily Windows hosts running SMB (Server Message Block) and Samba (Unix-based).
  • Purpose: Resolves host names on the local network, often when DNS fails. The protocol sends a broadcast request for the computer to return its NetBIOS name.
  • Port: UDP 5355
  • Used By: Mainly Windows hosts and some Linux systems using systemd-resolved.
  • Purpose: Resolves names for hosts on the same local network, especially when DNS cannot be reached.

mDNS (Multicast DNS)

  • Port: UDP 5353
  • Used By: Originally developed by Apple, it is now used widely across networks with IoT (Internet of Things) devices, including Windows systems.
  • Purpose: Local network name and service discovery without central DNS resolution.

Why These Protocols Are Dangerous

These protocols, while useful for name resolution in local networks, create a significant security risk when DNS fails. Here’s the typical process of how these protocols kick in:

  1. Initial Attempt to Resolve a Name: A device or system first attempts to resolve a domain name using DNS. If DNS fails, the system proceeds to fallback protocols.
  2. Check for Local Resources: The system checks its local cache or hosts file. If it can’t resolve the name, it uses fallback methods like NetBIOS, LLMNR, or mDNS.
  3. Broadcast Requests: If still unresolved, the system sends a broadcast across the local network:
    • NetBIOS: Queries via broadcast to resolve names.
    • LLMNR: Broadcasts a name resolution request to all devices on the local subnet.
    • mDNS: Sends a multicast asking which local device matches the requested hostname.

An attacker can exploit this situation when these protocols are enabled and improperly configured. If a user mistypes a hostname or requests a resource that no longer exists, an attacker on the local network can respond to the request, posing as the requested resource.

Example Attack Scenario:

  • Mistyped Hostname: A user types \testt\ instead of the correct \test\ share in the Windows File Explorer.
  • Domain Controller Response: The domain controller states that the hostname does not exist in DNS.
  • Fallback Protocols Triggered: The system sends a broadcast request via NetBIOS, LLMNR, or mDNS.
  • Attacker Responds: The attacker, listening for these broadcasts, replies, pretending to be the requested resource and asks for user authentication.
  • Credentials Sent to Attacker: The victim’s machine sends authentication credentials (username, password, or hashed passwords) to the attacker’s device.

The attacker now has the victim’s credentials in the form of a plaintext password or NTLM hash, which can be used to gain unauthorized access to the network.

Exploiting Printers and Other IoT Devices

Chromium browsers (including Google Chrome, Safari, and Microsoft Edge) use mDNS to locate printers and services like Chromecast. This presents another vector for attackers to poison mDNS queries, potentially hijacking printer discovery requests. For example:

  • Chromium Browser: When a user searches for printers, it uses mDNS to find them. An attacker can poison the mDNS request and impersonate the printer, capturing authentication data in the process.
  • Mozilla Firefox: Unlike Chromium-based browsers, Firefox does not rely on mDNS for printer discovery, making it less vulnerable to this specific attack.

Remediation: How to Mitigate These Protocols

1. Group Policy Object (GPO) for LLMNR and NetBIOS-NS:

  • LLMNR and NetBIOS-NS can be disabled using a GPO. However, mDNS requires a registry change.
    • GPO:
      • Path: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution > Setting "Enabled"
      • Force GPO Update: Run gpupdate /force

2. Registry Modification for LLMNR, NetBIOS-NS, and mDNS:

  • For local machine remediation, registry keys can be adjusted to disable these protocols:
    • Disable mDNS:
      • Path: HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
      • Key: EnableMDNS (Value = 0)
    • Disable NetBIOS-NS:
      • Path: HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces
      • Key: NetbiosOptions (Value = 2)

3. Control Panel Method for Disabling NetBIOS-NS:

  • Navigate to Control Panel > Network and Sharing Center > Change adapter settings.
  • Right-click the connected network and select Properties.
  • Internet Protocol Version 4 (TCP/IP) > Properties > Advanced > WINS.
  • Disable NetBIOS over TCP/IP.

4. Disabling mDNS on IoT Devices, Linux, and Apple Devices:

  • Linux (Avahi Daemon):
    • Stop the Avahi service:
      • sudo systemctl stop avahi-daemon.service
      • sudo systemctl stop avahi-dnsconfd
  • Apple Devices (Bonjour/mDNSResponder):
    • Disable mDNSResponder service:
      • sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
      • sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist

5. Windows Defender Firewall Configuration:

  • Blocking Legacy Protocols:
    • Create rules to block or detect incoming/outgoing traffic on the respective ports:
      • mDNS: UDP 5353
      • LLMNR: UDP 5355
      • NetBIOS-NS: UDP/TCP 137, 138, 139
    • Log all packets: Enable logging for both dropped packets and successful connections in Windows Defender Firewall.

6. Monitoring and Logging:

  • Windows Filtering Platform (WFP): Use GPO to enable WFP auditing for inbound/outbound traffic. Monitor Event IDs 515 (indicating blocked or allowed traffic) for potential malicious behavior.

Conclusion

Legacy protocols such as NetBIOS, LLMNR, and mDNS are still prevalent in many organizations and present a significant security risk. These protocols can be exploited to facilitate credential harvesting and lateral movement within the network. By properly configuring and remediating these protocols, organizations can significantly reduce the risk of data breaches, lateral attacks, and compromised systems.

As evidenced in the 2021 breach involving the Lazarus Group, these protocols were used in conjunction with tools like Responder to harvest credentials and move laterally within networks. Taking proactive steps to disable or secure these protocols will help mitigate these risks and prevent attackers from exploiting them.

Use the steps outlined in this guide to ensure your organization is protected from these vulnerabilities. Don’t leave your network exposed to these easily exploited fallback protocols. Secure your environment today.