A question that I receive often enough to include in this blog post is “What fascinates you so much about cybersecurity?” While I can never seem to come up with a cool answer in that moment, I think my fascination stems from what a joke that term really is. Cybersecurity was never something that was planned. Computers were such an intricate advancement that nobody was worried about spoofing IP addresses or building in buffer protections, the engineers just wanted to get them working! Even today, many manufacturers are too worried about pushing products out the door to address the elephant in the room that is security. This seems like the perfect time to shout out all the Agile software teams out there, thanks for my job security!
Jokes aside, cybersecurity truthfully has been an afterthought. Take a minute before we get into the meat and potatoes of this blog post to really just think about this. Many computers operate purely on the honor system. When you decide that your roommate has had enough internet for the day and begin sending wireless de-authentication frames to their devices, their Xbox doesn’t reply with “Hey, are you really the router?” This level of ask-and-you-shall-receive mentality is what makes me adore Responder as a tool suite.
As an introductory crash course for those who are not familiar with Responder, consider the following. Windows devices were designed to be used with many other Window’s devices to communicate effectively, share resources, etc. To achieve this Windows bakes in some additional networking protocols. While many of these protocols exist, today we’ll be covering the infamous NetBIOS Name Service (NBT-NS), Multicast DNS (mDNS), and Link-Local Multicast Name Resolution (LLMNR) protocols. If all of these protocols sound like an off branded DNS, good, that’s because they are. Windows uses these protocols as a fallback when DNS can’t help resolve a local service. Much like our example above regarding the de-authentication packets, these protocols are also unauthenticated (insert winky face here)!
Firing off Responder with nothing but the designated networking interface with allow an attacker to spoof the previously mentioned protocols. When a user attempts to resolve a local NetBIOS name that the network’s local DNS cannot resolve, Responder will perform some malicious magic under the hood. I’ll be using my virtualized lab environment along with Wireshark to depict this scenario.
| Attacker | Victim | |
| IP Address | 10.0.0.10 | 10.0.0.20 |
| MAC Address | 08:00:27:13:F1:BE | 08:00:27:71:51:DE |
First, let’s kick off Responder and monitor for any new network traffic.
Immediately our attacker machine sets the stage for its nefarious activity. Using the Internet Group Management Protocol (IGMP) our attacker joins the 224.0.0.251 and 224.0.0.252 multicast groups. Why is this important? mDNS and LLMNR both use multicast routing for the client to request naming services. Since our attacker machine joined these multicast groups it will now receive the query traffic for further hacktivity. Using our victim machine let’s navigate to a non-existent share such as “\\WhitehatWays\test“.
While not much has appeared to take place on our victim’s screen, behind the scene Wireshark tells a different story.
A page full of traffic isn’t necessarily self-explanatory, let’s break this traffic down. Our first packet captured shows that our victim machine made a NetBIOS Name Service request to the networks broadcast address querying for “WHITEHATWAYS.” Subsequently, similar multicast queries can be seen coming from our victim machine. Each of these query requests is met with a corresponding answer from Responder on our attacker machine claiming that the requested share can be found at its IP address. Upon receiving these queries, and wrongfully assuming they are trustworthy, our victim machine completes a 3-way handshake on port 445 (SMB) with the attacker machine. SMB authentication traffic then begins to flow which Responder beautifully pieces together for us back on our attacker’s console.
If you have your hacker thinking cap on your next question may be “How often are my clients (or victims 😉 ) navigating to non-existent shares?” The answer to that is, well, unknown. Legacy Windows machines may reach out to shares that don’t exist constantly, an Administrator could fat-finger the name of a common share, etc. In some real-life scenarios, Responder used in this way may not be very effective. Instead of relying on pure chance alone, it would be beneficial to manipulate a widely-used un-authentication protocol. Sit back in your seat, fellow Whitehat, Responder has this one covered.
Before we discover which protocol we’re referring to, it’s important that you understand the concept of the Web Proxy Auto Discovery protocol- or WPAD for short. Often employed in insecure corporate networks, WPAD allows the central management of proxy configuration. Many modern browser’s reserve the ability to automatically update their proxy settings using WPAD. WPAD has a lot of strange nomenclatures that I won’t cover in this blog post, but feel free to continue your learning here. (Wikipedia link!)
DHCP! Yes, DHCP is our mysterious comprisable protocol. Host’s requiring the assistance of a DHCP server will automatically be compromised by Responder injecting a false WPAD entry in their network configuration. What’s better? Hosts already leased to an IP address will ultimately reach out within a pre-configured amount of time to renew that lease. This makes Responder the world’s most profitable waiting game. Once again, let’s take a look at how all of this works under the hood with Wireshark. Let’s setup Responder and get rolling, I’m excited to show you this!
With the -Pdv flags enabled, Responder will now, drum roll please, respond to DHCP requests and inject the falsified WPAD record. Switching over to a network that supports DHCP and issuing a “ipconfig /release” and “ipconfig /renew” will allow us to realize this attack vector.
| Attacker | Victim | |
| IP Address | 192.168.1.139 | 192.168.1.143 |
| MAC Address | 08:00:27:13:F1:BE | 08:00:27:71:51:DE |
Similar to our last encounter with Responder, upon initialization our attacker machine joins the required multicast groups. Additionally, Responder is going to generate a DHCP Discovery request. Our attacker machine is already configured via DHCP, why would it possibly need to generate a DHCP Discovery request? Great question! If Responder is to impersonate the local DHCP server it needs to know the network configuration to hand out. When Responder generates this DHCP Discovery request the local DHCP server, often a router, will respond with a DHCP Offer response detailing the network’s configuration. Responder now has all it needs to start poisoning local victims! Let’s renew our lease on the victim machine and analyze the traffic.
Once again, let’s break down this traffic. Firstly, we can see the DHCP Release packet generated by our “ipconfig /release” on the victim machine. This simulates what it will look like when a device’s IP address lease expires in the wild. When the “ipconfig /renew” is executed our victim machine then uses it’s MAC address to broadcast a DHCP Discovery request. The exploit comes in the highlighted packet from “192.168.1.1” with a DHCP offer. 192.168.1.1 is my home router. No communication between my attacker machine and my home router occurred. How could my router possibly be serving the malicious WPAD entry? Responder is spoofing my router’s IP address! If you look closely you’ll see that the MAC address associated with this response from my “router” actually matches my attacker machine’s MAC address.
Now that the victim machine took the DHCP configuration from our attacker machine, we just have to wait until the victim machine makes a web request. Lucky for us Windows is constantly making API requests!
The victim machine begins with GET’ing the malicious WPAD.dat configuration file. Upon applying this configuration and making an HTTP request the proxy responds with “407 Unauthorized.” This block requires that the victim machine authenticates via NTLM. The victim machine then, to continue making the HTTP request, authenticates to our attacker server compromising its password hash. Let’s check our console and see if we get a similar story!
Bingo!
Responder is a stellar security tool that can compromise Windows-based machines without the need for inherent vulnerabilities. This idea of ask-and-you-shall-receive vulnerabilities is everywhere! Utilizing Wireshark to review the generated network traffic, we can see how simple it was to convince our victim machine into just handing over its password hash.