Securing Internal Networks: Preventing LLMNR and NBNS Spoofing

Introduction Internal network environments are vast, complex, and unique per organization. Although unique, most internal network environments face being vulnerable to the same high impact issues that others do. One of the biggest threats to internal network environments today is being susceptible to Link-Local Multicast Name Resolution (“LLMNR”) and NetBIOS Name Service (“NBNS”) Spoofing attacks….

Posted by: Leap Security

Introduction

Internal network environments are vast, complex, and unique per organization. Although unique, most internal network environments face being vulnerable to the same high impact issues that others do.

One of the biggest threats to internal network environments today is being susceptible to Link-Local Multicast Name Resolution (“LLMNR”) and NetBIOS Name Service (“NBNS”) Spoofing attacks. Like NBNS, LLMNR is used to resolve hostnames to IP addresses on a local network. Systems will first attempt to resolve names locally using their cache, but if that fails they will reach out to DNS server(s).

LLMNR and NBNS Diagram

If the DNS server resolution fails, the system asking for the resolution broadcasts the question or query on the network segment across Windows systems using LLMNR or NBNS. At this stage it is safe to assume that the resource in question does not exist. It may have just been typed in wrong similar to our example of “\\pyrollshare” (should have been “\\payrollshare”). An attacker listening on the local network for broadcast requests will intercept this and respond in attempts to gain credentials.

LLMNR and NBNS Diagram

Once the attackers system responds, the requesting system will provide Net-NTLM hashes or cleartext credentials depending on the service used during the broadcast (e.g., FTP).

Technical Details

Let’s go through that process again, but this time adding in some more technical details. The resolution process goes as follows:

  1. PC checks its local cache for the resource resolution. The hosts cache file (i.e., LM Hosts) is filled with data of previously requested resources. This file is usually made up of IP addresses and host names as seen in the sample below.
    102.54.94.97 rhino #net group's DC
    102.54.94.102 appname #special app server
    102.54.94.123 popular #source server
    102.54.94.117 localsrv #needed for the include
  2. If not resolved, the PC submits a query for the resource to DNS server(s).
  3. If still not resolved, the PC then submits an LLMNR/NBNS broadcast to systems on the same network segment for the resource.

The Attack

A reliable tool to perform LLMNR and NBNS spoofing attacks with is Spider Lab’s responder. Developed by Laurent Gaffie, responder is a python based tool with the goal of quickly setting up services such as SMB, HTTP, FTP, SQL and intercepting broadcast requests.

The first thing we need to do is modify the challenge parameter within responder’s configuration file (located under “/usr/share/responder”). Some Intrusion Prevention System (“IPS”) vendors have started picking up responder’s default challenge of “1122334455667788” so we create a random challenge to evade detection.

Responder Configuration File

After starting responder we immediately notice the services listening for broadcast requests. Systems on the internal network will now communicate with our system when broadcasting LLMNR or NBNS. Let’s put it to the test with our example.

Responder

Our victim Windows system residing on the same network is requesting “\\pyrollshare”. As previously discussed, we can expect the system to check its local cache, request the resource to DNS servers and then result to broadcasting the request as a last resort.

Resource Request

Would you look at that, our attacker system running responder intercepted the request and obtained our victim system’s Net-NTLMv2 credential hashes.

Responder Hashes

Our victim system on the other hand received an error message as shown in the image below.

Resource Request Error

At this point, an attacker can use relay attacks in combination with mass credential harvesting to gain further access into the network. Using these methodologies it is not uncommon for attackers to gain full access to a network and its respective resources minutes after obtaining credential hashes from the LLMNR and NBNS spoofing attacks.

Preventing LLMNR and NBNS Spoofing

Modern networks should not have the need to allow the use of LLMNR and NBNS. A properly configured DNS server should be able to handle all resolution requests. With that said, the resolution to this attack vector is to disable LLMNR and NBNS across Windows systems on the network.

Disabling LLMNR

Use group policy editor to disable LLMNR on Windows systems across the network. Follow the instructions below:

  1. Click Start > Run > type “gpedit.msc” in the text box
  2. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client
  3. In the “DNS Client” folder, double click on “Turn Off Multicast Name Resolution” and set it to “Enabled”

Disabling LLMNR

Disabling NBNS

Follow the instructions below to disable NetBIOS on Windows systems:

  1. Start > Run > type “control” in the text box
  2. Under “Network and Internet”, click “View network status and tasks”
  3.  Click “Change adapter settings”
  4. Right-click “Local area connection” and then click “Properties”
  5. Double-click on “Internet Protocol Version 4 (TCP/IPv4)”, click “Advanced” then click on the “WINS” (Windows Internet Name Service) tab
  6. Click on “Disable NetBIOS over TCP/IP”

Disabling NBNS