Welcome to Part 1 of this series. As each part gets released, we’ll dive deeper and deeper into the joys of LLMNR poisoning and I’ll demonstrate just how easy it makes the life of an attacker when this default legacy protocol is still running in your environment.
By the end of this series, you will be able to pivot across an ENTIRE poorly configured domain with SYSTEM-level access.
Part 1 Table of Contents:
- What is LLMNR & NBT-NS?
- Brief Explanation of the Exploit
- Downloading and Installing Responder
- Capturing NTLMv2 Hashes w/ Responder
What is LLMNR & NBT-NS?
Crowe.com does a fantastic job at giving you a high-level overview of what NetBIOS & link-local multicast name resolution do. Instead of reinventing the wheel, I will simply provide an excerpt from their website below.
“NetBIOS and LLMNR are protocols used to resolve host names and facilitate communication between hosts on local networks. NetBIOS is generally outdated and can be used to communicate with legacy systems. LLMNR is designed for consumer-grade networks in which a domain name system (DNS) server might not exist.”
If none of this sounds familiar, I highly recommend checking out the below link and reading more about these protocols before moving on.
Great! So how can I exploit this?
When a computer requests access to a legitimate network resource, it usually follows a set of pre-defined queries. LLMNR and NetBIOS come into play as last resort options when other methods (such as DNS or local hosts files) don’t prove helpful. Since LLMNR & NetBIOS will attempt name resolution via broadcasted requests to the broadcast-domain, we can set up tools to listen for these requests and respond back pretending to be the intended recipient.
Downloading & Installing Responder
Navigate to the following GitHub page and Copy the clone URL.
Navigate to your /opt folder and Download the tool using git.
sudo git clone https://github.com/lgandx/Responder.git
Poisoning Requests With Responder to Capture NTLMv2 Hashes
Now that we have our tools set up. Let’s take a deeper look at Responder.
We see a handful of files, including Responder.conf (the configuration file) and Responder.py (the script used to perform the exploit). Let’s take a closer look at Responder.conf.
So there’s a lot going on in here, but I just wanted to make you aware of the section titled Servers to Start. This is where we can configure which servers we’d like Responder to spin up to perform the exploit. We won’t actually make any changes in here just yet, just know that this conf file is very important and will be brought up in the future.
With all servers active, let’s go ahead and Run Responder on our primary interface (note yours may differ depending on your environment).
sudo python Responder.py -I eth0
So what’s happening here? Responder is listening for all incoming requests in the three listed Poisoners (LLMNR, NBT-NS, DNS/MDNS). If any devices on the network need a hand resolving a hostname, fileshare, etc. they will send a broadcast out to the entire network. With this tool running, we will be able to ‘Respond’, pretending to be that destination server. From there, the device will reply back with its NTLMv2 Hash as it attempts to authenticate to the resource.
You’ll get the most responses back on a busy network with many devices in use. I’ve also found that we will get a lot of results during the beginning of shifts or once users return from lunch breaks. If you have enough patience, you should receive a response pretty soon. If you don’t have patience, then let’s see if we can force a LLMNR request..
From a Windows machine on the network, launch a File Explorer window, and attempt to Browse to a fileshare that doesn’t exist.
Within just a few moments, Responder is able to capture my NTLMv2 Hash.
That’s it for this post! Next up, I’ll be showing you what you can do with these hashes to pivot onto other machines or even score a reverse shell. In the mean-time, let me know what you thought of this and whether or not it has been helpful!