Responder is tool that can be used to poison DNS,LLMNR, and Netbios requests on a network. There are other resources out there that will provide more info on the tool. A common example of the tool is if someone enters the wrong network share, their computer will start searching for the path. If it isn’t found responder can come in and send out false LLMNR, NBT-NS, and DNS info. This way the computer will reach out to responder thinking it has found the right path. The users computer will first use the credentials they are signed in with to authenticate, if that doesn’t work the user will get a login prompt. Whatever credentials get put in that prompt get forwarded to responder as a Net-NTLM hash. These can’t be used for pass the hash such as attacks from tools like Mimikatz. However you can use these in various relay attacks.
Responder also has little known features (don’t see them talked about as much) In the configuration you can enable RDP, FTP, and SMTP servers. The RDP ones are usually Net-NTLM hashes. This means if the user tries logging into a machine that doesn’t exist through RDP you can use responder to get the password hashes. FTP is nice in that the credentials will be cleartext. Before I start with the experiments there are some ways to prevent these kinds of attacks, you can disable services such as LLMNR and NBT-NS. Sometimes they are needed for legacy support, in that case SMB signing can be enabled. Also some environments might not work well with SMB signing especially if you have old devices on the network. Final thing to note is responder runs on linux/mac os. One should also be aware of how Responder can end up on your network. The threat actor has 3 methods; plant a device with responder on your network, install a Linux VM on a machine (Since windows 8 hyper-v is supported by default, however it is disabled by default, and admin privileges are required to install it), relay their tools through a compromised machine to their command and control infrastructure (tools like cobalt strike have relay and proxy options). There are numerous ways to handle the risk in each of these cases, so I will leave it up to the user to figure out.
Now we can start going over our first experiment. A common situation that ends up happening in most network environments, is users have access to certain network shares, that then end up being decommissioned. The file server may be moved, maybe someone had an old RDP shortcut to a machine that isn’t their anymore. Imagine you have thousands of machines. In that situation very few if any IT personal will go to each machine and update the network path of file shares. The option might be that each computer has a certain user profile set through group policy or some other tool. In that case if your file share gets changed, you just update it to the right location for user profiles, . Though this doesn’t fix the issue that in most cases users can change items in their user profile, and group policies don’t apply successfully to all machines. This leaves time for tools like Responder to pickup the password hashes for machines still reaching out to old network file shares.
I setup 3 machines. Kali linux with Responder, a windows 10, and server 2016 DC. I added two network path Shortcuts to the Desktop. one is \\DC01\Scans which exists, and \\DC02\Scans2 for a server and file share that doesn’t exist. Responder was used with default options and command ran was responder -I eth0 At first I did a reboot and noticed nothing showing in Responder. I then added the credentials to credential manager. A reboot wasn’t showing anything. This shows us that one needs to access the shares for this to work. Clicking on the shortcuts worked for \\DC02, which makes since since it doesn’t exist. The only time it worked for \\DC01 was when it was shut down. Showing us that a denial of service attack on the DC with a responder attack will also work. I then removed the Scans share from the DC. I tried the shortcut again, even tried variations such as \\DC01\Scan3. Neither of these worked since DC01 was reachable now, and was telling us the share doesn’t exist.
The other test was to create a mapped drive instead of a Desktop shortcut. In this case we have the option to reconnect at sign-in. I then shutdown DC01 to test again to emulate a file share server that has been decommissioned. It worked on both a reboot and logoff/logon event. It didn’t work if I locked the computer and signed back in. What was also interesting is anytime explorer got opened to the This PC page, I would start seeing requests and hashes show up in Responder. I then closed everything and just let the Windows 10 machine sit with nothing open, 20 minutes later nothing showing. I opened File explorer again, went to This PC and hashes started showing.
This experiment has shown us a couple things about Responder. If the same file server still exists, but the share name has changed, this attack won’t work in that case. That file server and DNS entry needs to be unreachable for this to work. Most environments have the Domain Controller also hosting the DNS, if this was to be hit with a DOS attack, then this attack would work. What this shows us if DNS can’t find a response to the query for the share path, then the computer resorts to other methods like Netbios, multicast MDNS, and LLMNR.
One also has to keep in mind how the share path is inputted. I added a DNS entry for \\dc03.lab.internal.local\ . Even using Responder with option -r for Netbios suffix queries, didn’t work. trying stuff like dc03 didn’t work. I tried a path that doesn’t exist such as \\dc04.lab.internal.local Responder didn’t get any password hashes. I then tried \\dc04 this worked. The reason it worked is the full path wasn’t used and DNS didn’t have an entry for the hostname. If the full path was used, even if it was wrong path, DNS would respond and Responder wouldn’t have a chance. In cases where the full path isn’t used, the computer starts trying to resolve just DC04, then using whatever suffixes are set automatically. These suffixes can be stuff like dc04.local. DNS obviously won’t have an entry for these, so MDNS and LLMNR is used, which results in Responder getting password hashes. As shown below 192.168.1.104 tries dc04 and dc04.local. Responder responds with poisoned responses and picks up the password hash used to authenticate.
The NBT-NS poisoning may work in older environments with endpoints that are running windows 7 and server 2003. In these test cases with Windows 10 and Server 2016 it did not work. Finally keep in mind if it’s a shortcut to the file share, it will need to be manually opened. Mapped drives can be set to mount automatically on sign-in. The mapped drive reconnecting at sign-in is very concerning. This is a common method used in most IT environments, and can be a useful vector for threat actors to abuse. The way this would work is if the file share isn’t accessible anymore, and no DNS entry exists for the host. This could happen in cases where the domain gets changed. For example a company moves from contoso.local to internal.contoso.com. Obviously a file share path to contoso.local won’t work, and if no DNS entry exists, Responder can start poisoning MDNS and LLMNR requests.
As mentioned previously a denial of service attack on internal DNS, will result in Responder working. Keep in mind that in a DOS attack on DNS, it won’t matter if you have the right file share paths, DNS cache will run out on hosts, and since the path can’t be found anymore, Responder poisoning will work. For cases like these disabling LLMNR, Netbios, and MDNS will work to a degree. You will still need to implement security measures to prevent rogue DNS servers from coming in. An easy method is to use security features in your network equipment to prevent rogue DHCP servers. A rogue DHCP server could hand out DHCP leases with a malicious DNS server to use. A final method to prevent Responder from working is to use a black hole DNS setup. What this does is if a DNS request can’t be resolved such as DC04 or DC04.local, DNS will still resolve these. This will result in Responder not having a chance to use poisoned responses to gain NET-NTLM hashes or perform a relay attack.
