PCI Compliance Information from a PCI QSA

Disable LLMNR Netbios

How to Get Less Findings on Your Next Internal Penetration Test

…and Become More Secure

Want to skip straight to how to disable LLMNR and NetBios? Go here

The Problem

There are two broadcast type features in the Windows operating system that allow for spoofing and capturing of password hashes on a local subnet of a network.  Several popular tools in the hacking/penetration testing world exist that take advantage of this and make it EXTREMELY easy to capture a Windows user’s password hash on the same subnet.  There is a 3rd broadcast feature –WPAD that I’ll explain in a later blog post. I’ll explain the two similar features here.
Link-Local Multicast Name Resolution (LLMNR) – LLMNR is a protocol enabled by default that allows both IPv6 and IPv4 hosts to perform name resolution for the names of neighboring computers without requiring a DNS server or DNS client configuration.
NetBIOS Name Service (NBTNS) – The NBTNS protocol is basically the same thing as LLMNR but only works on IPv4 hosts and is most associated with Windows XP machines.
If you’re running a Windows O/S on your computer chances are it has LLMNR and NBTNS enabled by default. Never heard of these features?  That’s because you, your computer, and your corporate network don’t need them. Here’s how it works:
On a local network a Windows computer (typically a workstation) will send out a broadcast message (i.e., a message to call computers on your “local link” or subnet) when you or your computer is looking for single name resources. (e.g. \\fileserver ) If that computer is on that same subnet it will respond to the broadcast request and the connection will be made without needing DNS.  But it’s only good for the local subnet!  It is in effect a poor man’s DNS for a single subnet or small network.  But in the corporate world this “feature” is not needed and has become a security issue.

The vulnerability

The problem is all computers on the same local network receive these broadcast requests and if they so choose can respond to the request without any checks that the system responding is legitimate. Here’s how the hack works:
disable llmnr responder

When a workstation makes a broadcast request looking for a resource (in our example \\fileserver) a malicious computer (Workstation 2 in our example) can respond, tricking the requesting computer (Workstation 1) that they are the resource they are looking for.  In a corporate environment (domain joined computers), the requesting computer will automatically attempt to authenticate to the malicious computer over normal Microsoft networking ports (TCP 445).  The malicious computer runs spoofing software to capture the authentication process and will obtain the User ID and challenge/response password hash of the user logged-in to the requesting computer (Bob on Workstation 1 in our example).  With the password hash (Bob’s) the hacker can now use offline password cracking tools such as Hashcat or John the Ripper to crack the password.  Note: a Challenge/Response password hash cannot be used in a “pass-the-hash” attack only a raw LanMan or NTLM hash can be passed.  However, most passwords can be cracked in minutes using modern word mangling rules built into Hashcat or John the Ripper.  Or the malicious computer can relay the credentials from the requesting computer to a 3rd system and authenticate as that user – without knowing the password!  This is called an SMB Relay attack.
There are many tools to carry out this attack, SpiderLabs has a great standalone tool called Responder and Metasploit has auxiliary modules for this attack as well.  On a typical corporate network an attacker can obtain the challenge/response password hashes of many users within minutes.  Once a hacker (or pen tester) has a valid user ID and password they can quickly use the access of that user to find other issues and obtain access to sensitive data.  The beauty of this attack (from the hacker’s perspective) is that it is very stealthy.  No port scanning or other noisy network traffic that might set off alerts.

The solution

The good news is that it’s relatively easy to prevent!  The bad news is awareness to this attack is low and very few companies have implemented the fix.  Here’s what you need to do:
  1. Disable LLMNR broadcasts on all company workstations
  2. Disable NBTNS broadcasts on all company workstations (by disabling NetBios).
Disabling LLMNR can be done via GPO (follow along on the screen shots)
  1. Open gpedit.msc
  2. Goto Local Computer Policy -> Computer Configuration -> Administrative Templates -> Network -> DNS Client
  3. Click on “Turn Off Multicast Name Resolution” and set it to “Enabled

Disable LLMNR graphic 3

Unfortunately Disabling NetBios cannot be done via GPO, I’ve provided screen shots on how to do this manually and also provided reference to a script that could be pushed down via GPO to disable NetBios (See below)
  1. Open Control Panel
  2. Under “Network and Internet”, click “View network status and tasks”
  3. Click “Change adapter settings”
  4. Double-click “Local area connection”
  5. Double-click on “Internet Protocol Version 4”
Disable NetBios graphic 1

6. Click “Advanced”
Disable Netbios graphic 2

7. Then click on the “WINS” (Windows Internet Name Service) tab and Click on “Disable NetBIOS over TCP/IP”
Disable NetBios graphic 3

The script to disable NetBios is at the end of the TechNet article:


If you follow my recommendations above (after careful testing of course) you will have a more secure environment with little effort or impact to the network.  Hackers and penetration testers will find it more difficult getting a foot hold on your internal network, hopefully this will force them to try other attacks that are more likely to get noticed by your IDS/ logging processes.   If you implement these changes, which I highly recommend, post a comment and let me know your experiences!
Disable LLMNR Netbios Disable LLMNR Netbios Reviewed by Stewart Fey on 4:49:00 PM Rating: 5