LLMNR / NBT-NS Spoofing Attack

Network Penetration Testing LLMNR / NBT-NS spoofing attackhow to use LLMNR & NetBIOS poisoning to capture credentials from the network using Kali + Responder.py during a penetration test and how to fix LLMNR & NBT-NS (NetBIOS) spoofing / poisoning attacks.

Introduction

A LLMNR & NBT-NS Spoofing Attack is a classic internal network attack that still works today, due to low awareness and the fact it’s enabled by default in Windows. This document explains what a LLMNR & NBT-NS attack is, how to use the attack during pen testing and how to secure networks against the vulnerability.

[clickToTweet tweet=”Check out the LLMNR Spoofing Guide by @AptiveSec #infosec #pentesting” quote=”Check out the LLMNR Spoofing Guide by Aptive”]

What is LLMNR & NetBIOS Name Server Broadcast?

When a DNS name server request fails Microsoft windows systems use Link-Local Multicast Name Resolution (LLMNR for short) and the Net-BIOS Name Service (NBT-NS) for fallback name resolution.

What’s the issue with LLMNR & Netbios NS Broadcasting?

If the DNS name does not resolve, the client performs a unauthenticated UDP broadcast to the network asking if any other system has the name it’s looking for. The fact this process is unauthenticated and broadcasted to the whole network allows any machine on the network to respond and claim to be the target machine.

What is a LLMNR / NBT-NS Poisoning Attack?

By listening for LLMNR & NetBIOS broadcasts it’s possible to masquerade as the machine (spoof) the client is erroneously trying to authenticate with. After accepting the connection it’s possible to use a tool like Responder.py or Metasploit to forward on requests to a rogue service (like SMB TCP: 137) that performs the authentication process. During the authentication process the client will send the rogue server a NTLMv2 hash for the user that’s trying to authenticate, this hash is captured to disk and can be cracked offline with a tool like Hashcat or John the Ripper (TJR) or used in a pass-the-hash attack.

LLMNR and NBT-NS are enabled by default in Windows and with awareness of this attack being fairly low you stand a good chance of being able to gather credentials on an internal penetration test. Leave Responder.py running during an engagement while you’re working other attack vectors.

What about Linux & Apple clients, are they Vulnerable?

Yes, Linux and Apple clients use a similar protocol called multicast DNS or mDNS for short which listens on TCP: 5353. For more information on mDSN see the mDNS wikipedia page

Typical LLMNR / NetBIOS Name Server Attack

The diagram below shows the typical scenario for this type of attack where a user mistypes a server name.

Step-by-step LLMNR / NBT-NS Poisoning Attack

User sends incorrect SMB share address \\SNARE01 DNS Server responds with \\SNARE01 - NOT FOUND Client performs LLMNR / NBT-NS broadcast Responder tells the client it’s SNARE01 and accepts the NTLMv2 hash Responder sends an error back to the client, so the end user is non the wiser and simply thinks they have the wrong share name

Practical Example: Using Kali & Responder.py

A practical example demonstrating the severity of this attack, using Kali Linux and Responder.py to capture a users credentials from the network during an internal penetration test.

Install the latest version of responder from github:

root@kali:~# git clone https://github.com/SpiderLabs/Responder.git Cloning into 'Responder'... remote: Counting objects: 886, done. remote: Total 886 (delta 0), reused 0 (delta 0), pack-reused 886 Receiving objects: 100% (886/886), 543.74 KiB | 0 bytes/s, done. Resolving deltas: 100% (577/577), done.

Run Responder.py, use your local interface and IP address as follows:

root@kali:~# cd Responder/ root@kali:~/Responder# python Responder.py -i 192.168.210.145 -I eth0

This should start Responder.py:

After Responder.py is running, we simulate a user typing the wrong SMB server name using SNARE01 instead of SHARE01 .

Simulated erroneous SMB server name From the client machine:

Note: The client machine in the lab environment is Windows 2008 Server R2

Within a few seconds of the client broadcasting the incorrect server name, Responder.py has answered the broadcast request and written the NTLMv2 hash to disk.

The following error is returned to the client machine from Responder.py:

The last step is cracking the NTLMv2 hash, depending on the complexity of the password policy within the target environment this could take some time. ocl-hashcat would be a better choice for offline cracking where password policies are known / suspected to be more secure. As the password is intentionally insecure within the test lab environment, john is used to crack the NTLMv2 hash:

How to Secure Networks against LLMNR / NBT-NS Poisoning Attacks

The good news is this attack is fairly easy to prevent. Note, that both LLMNR and NetBIOS Name Service need to be disabled, if you only disable LLMNR then Windows will failover to NetBIOS Name Server for resolution.

Disable NetBIOS Name Service

There appears to be no way to disable NetBIOS Name Service using a GPO (drop a comment below if you know of a way!), manual instructions are below.

Open: Control Panel\Network and Internet\Network Connections Right click on the network interface, select properties, double click on “Internet Protocol Version 4 TCP/IPv4“ On the next screen, click advanced, then select the WINS tab Click the radio button next to “Disable NetBIOS over TCP/IP“

See the screenshot below for guidance:

Disable LLMNR

Fortunately you can disable LLMNR using a GPO, instructions below:

Start => Run => gpedit.msc Open “Local Computer Policy” => “Computer Configuration” => “Administrative Templates” => “Network” => “DNS Client“ Click on “Turn Off Multicast Name Resolution” and set it to “Enabled

Conclusion

A classic internal network attack that still works today due to low exposure of the attack coupled with the fact it’s enabled by default in Windows.