LLMNR / NBT-NS Spoofing Attack

LLMNR / NBT-NS spoofing attackhow to use LLMNR & NetBIOS poisoning to capture credentials from the network using Kali + Responder.py 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 when performing pen testing services 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 network. 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.

responder.py LLMNR NetBIOS Name Server spoofing

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

  1. User sends incorrect SMB share address \\SNARE01
  2. DNS Server responds with \\SNARE01 - NOT FOUND
  3. Client performs LLMNR / NBT-NS broadcast
  4. Responder tells the client it’s SNARE01 and accepts the NTLMv2 hash
  5. 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 engagement.

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:

Start Responder.py on Eth0 and your local interface IP

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:

Client machine error SMB server name responder.py Windows 2008 R2

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.

Responder.py LLMNR / NBT-NS Poisoning Attack - writing NTLMv2 to disk

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

Windows client error 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:

John (JTR) Crack 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.

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

See the screenshot below for guidance:

Disable NetBIOS Name Service 2008 Server R2

Disable LLMNR

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

  1. Start => Run => gpedit.msc
  2. Open “Local Computer Policy” => “Computer Configuration” => “Administrative Templates” => “Network” => “DNS Client

  3. Click on “Turn Off Multicast Name Resolution” and set it to “Enabled
How to disable LLNMW Multicast Name Resolution GPO MS

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.

3 Comments

Leave a Reply to Øystein Cancel reply

Your email address will not be published. Required fields are marked *