Credential Access: LLMNR/NBT-NS Poisoning
Hello everyone, This will be the first post of a long series that will focus on Active Directory/Windows Penetration testing. The goal behind these posts is to have a clear overview and understanding of some Active directory/Windows features and how to abuse them.
These posts are intended for beginners in Penetration Testing -as I myself am one of them- (only a basic understanding of the Windows protocols and architecture is required ), but I’ll try my best to go over each point and not leave any confusions.
Before starting with our first attack, I’d like to say a word or two about how awesome yet scary it is to try to Penetrate into a Windows environment, mainly because most of the attacks are simply based on abusing default features, protocols, and seemingly innocuous components that are just sitting there! Without further ado, let’s dive into it and start our fun journey!
What are LLMNR and NBT-NS ?
LLMNR, an acronym for Link-Local Multicast Name Resolution, and NBT-NS acronym for Netbios Name Service are two Windows protocols that are alternatives to the famous DNS (Domain Name System) protocols.
When a Windows machine tries to resolve a domain name ( to translate an IP address into a domain name/hostname, or the opposite) it goes through a specific set of steps :
1- Checks the hosts file entries for the wanted name, if not present,
2-Checks local DNS cache for cached entries, if not present,
3-Sends query to DNS server, and waits for the response. If the DNS server can’t find the correct name, then, the Resolution task will be assigned to LLMNR and NBT-NS Protocoles ( LLMNR first, if it fails, then NBT-NS)
How does LLMNR and NBT-NS resolve names?
Once the resolution is no longer the task for the DNS protocol, the machine will then attempt to ask all other machines on the local network for the correct name via LLMNR or NBT-NS, by sending the query in broadcast messages to all the machine on the local network.
If a machine on the local network knows the wanted host or is the wanted host, it will reply to the query. If the requested hostname belongs to a resource that requires identification/authentication, the machine will send a challenge (or a nonse: a random 16 bytes string that is unique on each session) to the host and asks the host to encrypt it with its password hash. The host will then send back the encrypted challenge and its username.
In a domain environment, once the machine receives the username, the encrypted challenge, and the clear-text challenge, it will forward it to the Domain Controller, which knows the hash of all the users and resources in the environment. The DC will use the user’s hash to encrypt the challenge and see if it matches the one received from the machine. If it’s the same, access is granted.
The process described above is the NTLMv1/2 (short for Net-NTLMv1/2) authentication protocol, which is a challenge-response protocol used by Windows machines to authenticate across the network.
How to abuse LLMNR and NBT-NS?
As you may have guessed, the weak point is that the username, challenge, and encrypted challenge are transmitted to any host in the network that responds to an LLMNR or NBT-NS Request. This means, a malicious actor can set up a man in the middle attack, where he places himself in the middle of the network, to listen for LLMNR or NBT-NS broadcasts and respond to them by pretending that he is the requested host, in order to trick the victim into sending the username, challenge, and encrypted challenge.
The process of the attack is illustrated in the figure below :
- The victim machine wants to access the file share \\fileserver but mistakenly types \\filesrvr
- The DNS server can’t resolve the host.
- The victim sends a broadcast message to all machines in the local network.
- The attacker spoofs the identity of \\fileserver and responds to the LLMNR request.
- The victim sends their own username and password hash to the attacker machine to authenticate.
- The attacker now owns the username, challenge, and encrypted challenge. A failed authentication response is sent to the victim in order to close the session.
Once the attacker owns the encrypted challenge, they can simply Brute force the password by trying to encrypt the challenge with every entry of a hash list, once they get an output that is equal to the received encrypted challenge, they can deduce the password of the user. Obviously, this approach only works if the user’s password is in the list used (i.e, the user has a weak or a common password). But don’t worry if you can’t brute force the password, because there is another extremely clever method that will allow you to Relay the hash directly without having to decrypt anything! This method will be explained in detail in a future post about SMB Relaying.
Demonstration :
For this attack, we will use the Responder tool, which will listen and answer to LLMNR/NBT-NS broadcasts, then creates a rogue authentification service, it supports services like SMB, MSSQL, HTTP, HTTPS, FTP, POP3, SMTP, Proxy WPAD, DNS, LDAP…etc
The victim will then send their credentials to one of these services, and that’s how we’ll obtain them!
I invite you to read more about the Responder tool on Github.
To launch the tool, simply chose an interface to listen on :
Responder -i Interface_name
Now, let’s imagine a user is trying to access a file server but makes a typing error
Back on our Kali machine, we will immediately get back the different pieces of information sent back to our rogue SMB server, which is: the username and Hash!
To attempt to crack the hash, we can use everybody’s favorite tool, Hahscat, and everybody's favorite word list, Rockyou (not literally, just assuming)
hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt
5600 is the module for NetNTLMv2 hashes.
And we have our password, as simple as that!
This user, unfortunately, has very poor password hygiene, but even if it wasn’t the case, we could use this hash in another attack to possibly gain access into other systems in the network. This attack will be the subject of the next blog (SMB Relaying).
Now, Let’s talk MITIGATION :
One obvious solution is to simply disable LLMNR/NetBIOS, or block these protocols traffic with dedicated security software.
If the company cannot disable LLMNR/NetBIOS, then there are two solutions :
- Network access control: which will basically only let the legitimate users of the domain get into the network, this will stop the malicious actor from getting in in the first place, so they won’t even be able to do this attack (it can be bypassed tho.)
- Require strong passwords! (which may only harden the cracking phase, it’s obsolete if the hash is relayed)
Thank you for reading, and stay tuned for more :)
