Active Directory Exploitation Part 2 - LLMNR/NBT-NS Poisoning

Disclaimer: Do not perform anything listed below unless you are a certified/hired penetration tester with proper written authorization and LLMNR poisoning is considered "in-scope" for your current engagement. I am not responsible for any associated illegal activities, and everything below is widely-known within the security community.

A different kind of poisoning.

Welcome back to my security blog series on Active Directory exploitation. My previous post was a general introduction to Active Directory, and today we're jumping straight into actual exploitation. I've decided to begin with one of the simplest and perhaps most prevalent vulnerabilities that involves LLMNR and NBT-NS. If you're working with AD, you absolutely need to know about this attack. The attack utilizes both LLMNR and NBT-NS but is generally referred to as LLMNR poisoning, as NBT-NS is generally outdated. Since the attack is the same for both services, and LLMNR is the successor to NBT-NS, I will call it "LLMNR poisoning," as most reseachers/ethical hackers do. Just remember that for NBT-NS, the steps are exactly the same, and we'll get to mitigation at the end.

Introduction to LLMNR and NBT-NS

So, what are these horrific acronyms? LLMNR stands for Link Local Multicast Name Resolution, and NBT-NS stands for NetBIOS (Basic Input-Output System) Name Service. LLMNR is simply used to identify hosts within the network when DNS fails to do so. LLMNR replaced NBT-NS years ago, and it is essentially the same service/exploit process. That's it - they are just Windows components used for host identification/name resolution.

To explain it further, on almost every modern network, IP addresses are assigned to resources within the networks, such as servers, workstations, etc. Since IP addresses are difficult to remember, services exist to translate them to names rather than numbers. For example, "www.google.com" is much easier to remember than an IP address such as "173.194.17.2." (Bonus: want to see what a website's IP address is? Type "nslookup <website.com>" into a command prompt!)

DNS (Domain Name System) typically handles this resolution process. However, if it fails to match a hostname to an IP address, LLMNR will take over, and broadcast LLMNR queries across the subnet to ask other machines if they can resolve the name to an IP address (if LLMNR fails, NBT-NS will attempt resolution, if enabled). This is where LLMNR/NBT-NS poisoning starts. There's a bit of a problem with this whole process, as you'll see.

Steps: LLMNR and NBT-NS Poisoning

The problem with LLMNR queries is that the service responds to queries with a username and NTLM hash, which can be cracked relatively easily (of course, depending on the strength of the password, which is usually weaker than you might think in large environments). By inserting ourselves into the middle of this LLMNR conversation and spoofing legitimate network resources, we can capture these usernames and hashes (yes, this is a man-in-the-middle attack). I will outline the steps of this attack, which generally require a Domain Controller, victim machine, and attacker machine in an AD environment.

1. User on victim workstation mistypes/enters some hostname that does not exist.

2. Since it doesn't exist, DNS fails to resolve the name/IP.

3. LLMNR (or NBT-NS) broadcasts a query, asking everyone in the subnet if they can fix this naming resolution issue.

4. The attacker's machine, which is listening for these queries, spoofs the network object/resource by simply stating, "I am the resource you're seeking, send me your authentication credentials!"

5. The victim's machine inherently trusts this response, and the attacker is sent the victim's username and hash.

6. The attacker cracks the hash, and can now log in as the victim.

Responder.py output. Had to censor nearly everything; what matters is we received hashes (the giant blocks of orange)!

That's it. With those few steps, you have an initial foothold into the Active Directory environment. Compromising that user is bad enough, but just imagine the potential havoc if that user happens to have administrator-level rights!

Tools Utilized

For this specific attack, there are incredible tools available, but all you really need is Responder.py (that is a link to its Github, and it may throw a warning in your browser, heads-up) and a hash-cracking tool such as hashcat, my personal favorite. Responder is a python-based program that listens for those LLMNR broadcasts, and responds, capturing credentials in the process, all according to your options. Hashcat is a very powerful hash-cracking program that allows for extremely fast cracking. Hashcat allows you to utilize your GPU for cracking rather than your CPU. Modern GPUs have thousands of cores, compared to CPUs which only have a few. If you're a PC gamer like myself, and have a very powerful GPU, you'll crack passwords in seconds, or even less in some cases!

Responder is quite easy to configure and use. The image after Step 6 in the previous section is output from Responder. The syntax is as follows:

python Responder.py -I <interface i.e. eth0, tun0> -rdw

This allows you to listen for LLMNR or NBT-NS broadcasts, respond, and retrieve credentials, all by typing in the above and pressing enter. It's a good idea to start Responder ASAP and let it run at the beginning of the day, when employees are walking in, sitting down, and opening/accessing their daily resources. Responder has other options; this is all we need to cover for our example. By the way, you can simulate all of this in a virtual Active Directory environment at home for $0 (I did it myself), but that's way beyond the scope of this blog.

Hashcat is similarly easy to use, and again, extremely powerful. All you need is the hash in a text file, and a long list of passwords (easily obtainable via a Google search). You will also need to specify the type of hash, which, in our example, is a NetNTLMv2 hash, or 5600. Hashcat has multiple additional options, such as creating rule lists that can modify password lists and greatly increase the chance of cracking a password, but that is also not necessary for our example. The syntax is as follows:

hashcat -m 5600 hash.txt passwords.txt

If the hashed password exists in the password list, hashcat will find it, and you will have successfully cracked a password! If you need a good password list to begin with, here's rockyou.txt, which contains well over 14 million likely passwords.

Mitigation

The mitigation for this vulnerability is simple, and for some reason, often overlooked. Simply disable LLMNR and NBT-NS. LLMNR can be disabled via a GPO (group policy object), and the steps are below:

1. Create a new policy in GPMC.

2. Navigate to Comptuer Configuation > Administrative Templates > Network > DNS Client.

3. You must enable "Turn off multicast name resolution."

That's it! You can implement that policy across the entire network and not have to complete this for each machine. NBT-NS should be disabled by default in most cases, but it never hurts to check. To disable NBT-NS on workstations:

1. Navigate to Network Connections > Network Adapter Properties > TCP/IPv4 Properties > Advanced > WINS tab

2. Select "Disable NetBIOS over TCP/IP."

If for some reason you cannot disable LLMNR or NetBIOS-NS, require strong user passwords, such as 15-character or longer passwords and enforce complexity. Even if an attacker/ethical hacker captures the hashes, they will not be able to crack them if they are properly long and complex. Remember that it doesn't hurt to have a 15+ character, complex password absolutely everywhere. :)

I hope you enjoyed this installment of Active Directory Exploitation! LLMNR poisoning is relatively simple to replicate but also still relevant, so I decided to dedicate an entire blog to this attack. We will explore other attack vectors in Part 3, and we will see Responder again. After exploring other attack vectors, we will move on to post-compromise strategies, including enumeration and further attacks. We may even explore modern options for persistence, which is critical when the entire AD environment is in scope. By utilizing the correct tools and methodologies, you'll be surprised to see how quickly a penetration tester can assume total ownership of an unsuspecting network! Thanks for reading!