RESponDER | The tool that won't die

Yep… it's 2024 and Responder still works.

Overview

One of the most common findings we make at Contextual Security Solutions during internal penetration tests is the presence of vulnerable network protocols, like Link-local Multicast Name Resolution (LLMNR), Web Proxy Auto-Discovery (WPAD) and NetBIOS Name Service (NBT-NS). These three protocols work in a similar or complimentary fashion to Domain Name Service (DNS). When DNS resolution fails, these protocols (by default in Windows) step in, trying to find the resource your computer is looking for. There are also other vulnerable network protocols worth consideration, but I will focus on LLMNR and NBT-NS because of their widespread presence and ease of exploitability.

What makes these protocols vulnerable? Their implicit trust of hosts on the network for resolving hostnames. Executing man-in-the-middle (MiTM) attacks against these protocols often yields NTLMv2 password hashes, which can then be passed to password cracking software like Hashcat or used in an NTLM Relay attack. This can make for an easy initial foothold in an Active Directory environment. Oftentimes privilege escalation to Domain Administrator from this point can be just a matter of minutes or hours (see BloodHound Basics for one of my first actions after getting credentials on a network). This type of attack is not just a cool trick for penetration testers to get an "easy win" either. Global threat actors, like "Wizard Spider" and the "Lazarus Group" have been observed poisoning network protocols through Responder or alternative tools.

Tool Basics

Responder makes exploiting these protocols very easy. Basic usage only requires knowing the network interface you want to run it on and what protocols you want to target. A typical set of arguments would be "responder -I eth0 -wF" which also forces WPAD authentication. Running this command will have Responder running multiple servers and "poisoners" for even more protocols than just the three this post is concerned with. If you run this on your local home network, you are unlikely to see much, but in an enterprise environment with Windows and Active Directory you may see more events streaming across the screen than your eyes can take in. Typically, most of the traffic you will see will be the LLMNR, NBT-NS, and MDNS protocols. Responder will let you know when it sends a "poisoned" answer to hosts. If a host responds and sends an NTLMv2 password hash it will be shown in the output as well. Using the log files output by responder (/usr/share/responder/logs by default) instead of the "live" feed is preferable when you have successfully captured multiple hashes.

Figure 1: Running Responder with some basic arguments

Figure 2: Responder listening for events and capturing LLMNR/mDNS traffic

Digging A Little Deeper

There are already many great resources (some are linked at the bottom of this post) that explain the technical details of this style of MiTM attack with different levels of depth, so I will try to just demonstrate from a high-level without getting lost in the weeds.

My lab environment for the following examples consists of a Domain Controller (DC1) running Windows Server 2022, a victim host (Windows1) running Windows 10, and an attacker running Kali Linux, all on the same subnet. Both DC1 and Windows1 are running with default settings, the only changes I have made are creating the domain/forest and users for the lab environment, and joining Windows1 to the domain.

Packet Analysis

Passively running Wireshark from Kali while performing no other activity on either host, already shows the presence of the LLMNR protocol, so it has not been disabled on Windows1.

Figure 3: Packet Capture - Passively running Wireshark in the lab environment

If I try to visit a non-existent file share or web server, LLMNR, NBNS, and MDNS desperately try to find the resource.

Figure 4: Windows1 trying to reach the non-existent DC2 web server

Figure 5: Packet Capture - Wireshark capture of Windows1 searching for DC2

Because these protocols are multicast, an attacker can respond to them, claim to be the resource, and establish a MiTM position with Responder. If things go right (or wrong depending on your perspective) Windows1 will then try to authenticate to the resource, passing along the oh-so-valuable NTLMv2 hash. The victim may even receive an authentication prompt.

Figure 6: Windows1 prompting for credentials for the non-existent "notafileshare" file server

Figure 7: Packet Capture - Windows1 using LLMNR/NBT-NS protocols to find “notafileshare”

Figure 8: Packet Capture - Attacker answers that it is the "notafileshare" server (LLMNR)

Figure 9: Responder sending a poisoned answer for "notafileshare" and intercepting the NTLMv2 password hash

Alternative Tools

Other tools can perform the same protocol poisoning attack that Responder does but may have slightly different features or be part of an exploitation framework. Inveigh is one such example, which was originally written in PowerShell and is now cross-platform in C#. It has some handy features which are worth checking out from the perspective of an offensive security practitioner. The Command & Control framework PowerShell Empire implements Inveigh, so it can conveniently be run from an agent (say if that was your initial foothold on the network or you were able to pivot to another network segment). The uber-popular Metasploit framework also has a module dedicated to the same attack. As always, what fundamentally matters are the techniques behind the tools.

Blue Team Considerations

Detect & Prevent

While breaking stuff is fun, I want to shift focus on practically detecting and defending against these attacks. Unfortunately, our visibility metrics reveal that very few organizations detect this type of attack. There may be effective paid solutions that detect these attacks and meet the needs of your organization, but not all teams may currently have the budget or time to implement these, so I want to highlight two free open-source tools (if preferred, you could create a custom script to accomplish the same basic task). The fundamental idea behind these tools is to essentially act as a honeypot, sending LLMNR and NBT-NS requests for hosts that do not exist on the domain, and letting us know if a host responds to them, indicating a malicious host. By monitoring the tool console or file output, alerts can be generated in your platform of choice.

Conveigh

Conveigh was created by Kevin Robertson, who also wrote Inveigh, the PowerShell (now C#) alternative to Responder. Some notable features of Conveigh include the ability to change the interval at which requests are randomly sent (MaxSendRequestTime) and the total time the tool will run (RunTime). Below are screenshots of the tool in action and how its traffic is displayed in Responder.

Figure 11: Running Conveigh with no arguments

Figure 12: Responder receiving LLMNR/NBT-NS traffic from Conveigh

Figure 13: Running Conveigh with arguments for timing and file output

Respounder

Respounder has much of the same functionality as Conveigh but is a bit more basic and written in the Go language. From my experience with the tool, the simplest way to use it is by using the Go “build” command to generate an executable for your platform of choice (Windows and Linux are supported), create a job that runs the tool at a recurring time and sends the console output to a file. Below are screenshots of the tool in action and how its traffic is displayed in Responder.

Figure 16: Running Respounder with the network interface specified

Figure 17: Responder receiving traffic from Respounder

Figure 18: Running Respounder with arguments for hostname and outputting JSON log file

Configuration Management

Removing these vulnerable network protocols on Windows systems is fairly straightforward. LLMNR can be disabled through remote or local management of Group Policy. Disabling NetBIOS can be a little more complicated. There are settings you can change on your DHCP server to disable NetBIOS, but these will not apply for devices not using your DHCP server (think working from another network). Contextual Security Solutions recommends disabling NetBIOS on every Windows client through either the ethernet adapter’s advanced TCP/IP settings or registry. Depending on your environment, it may make best sense to do this for all network interfaces. Also, consider just blocking these protocols on your firewall.

Figure 20: Disabling NetBIOS via Advanced TCP/IP Settings

Figure 21: Disabling NetBIOS for the Ethernet adapter via Registry

Conclusion

TLDR

Network protocol poisoning attacks with tools like Responder are easy to execute, but typically not prioritized for detection. Prevention is critical and straightforward - disable vulnerable protocols such as LLMNR, NBNS, and WPAD. However, if a host falls through the cracks, missing your GPO or logon script, it could provide an initial foothold for the bad guys. Because of the prevalence of this style of MiTM attack, defenders should strongly consider deploying tools (such as those referenced above) for detection and response. Even if you are not vulnerable to this type of attack, detection may alert you to the presence of a malicious actor on your network before they can cause serious damage.