Posted by: Leap Security
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).
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.
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).
Let’s go through that process again, but this time adding in some more technical details. The resolution process goes as follows:
- 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.
184.108.40.206 rhino #net group's DC
220.127.116.11 appname #special app server
18.104.22.168 popular #source server
22.214.171.124 localsrv #needed for the include
- If not resolved, the PC submits a query for the resource to DNS server(s).
- If still not resolved, the PC then submits an LLMNR/NBNS broadcast to systems on the same network segment for the resource.
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.
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.
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.
Would you look at that, our attacker system running responder intercepted the request and obtained our victim system’s Net-NTLMv2 credential hashes.
Our victim system on the other hand received an error message as shown in the image below.
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.
Use group policy editor to disable LLMNR on Windows systems across the network. Follow the instructions below:
- Click Start > Run > type “gpedit.msc” in the text box
- Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client
- In the “DNS Client” folder, double click on “Turn Off Multicast Name Resolution” and set it to “Enabled”
Follow the instructions below to disable NetBIOS on Windows systems:
- Start > Run > type “control” in the text box
- Under “Network and Internet”, click “View network status and tasks”
- Click “Change adapter settings”
- Right-click “Local area connection” and then click “Properties”
- Double-click on “Internet Protocol Version 4 (TCP/IPv4)”, click “Advanced” then click on the “WINS” (Windows Internet Name Service) tab
- Click on “Disable NetBIOS over TCP/IP”