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.
Table of Contents
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”]
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.
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.
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.
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
The diagram below shows the typical scenario for this type of attack where a user mistypes a server name.
\\SNARE01 - NOT FOUND
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
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:
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.
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.
See the screenshot below for guidance:
Fortunately you can disable LLMNR using a GPO, instructions below:
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.