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 on a penetration test and finally, how to secure networks against the vulnerability.
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:
Run Responder.py, use your local interface and IP address as follows:
root@kali:~# git clone https://github.com/SpiderLabs/Responder.gitCloning into 'Responder'...remote: Counting objects: 886, done.remote: Total 886 (delta 0), reused 0 (delta 0), pack-reused 886Receiving objects: 100% (886/886), 543.74 KiB | 0 bytes/s, done.Resolving deltas: 100% (577/577), done.
This should start Responder.py:
root@kali:~# cd Responder/root@kali:~/Responder# python Responder.py -i 192.168.210.145 -I eth0
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 R2Within 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.
Due to an image limitation on the kali forum it's not possible to upload the remediation step screenshots, you can view the original article at https://www.aptive.co.uk/blog/llmnr-nbt-ns-spoofing/