Responder is one of the Kali Linux tools that makes yours, as a pentester, life way easier. This tool is a LLMNR, NBT-NS and MDNS poisoner that can be used to gather sensitive information from the network. The tool is pretty capable and we will get into the specifics of what can we do with it. But with the tool being so powerful, there is always a risk. So today we are going to talk is it safe to use Responder during a pentest.
Table of Contents
What’s the Responder and How It Can Be Used During Penetration Tests?
The Responder is a penetration testing tool that can poison requests of:
- LLMNR (link-local multicast name resolution) protocol. This protocol is based on DNS and is used mostly by Windows operating systems to perform name resolution queries in the internal network. LLMNR broadcast requests are being sent on UDP 5455 port.
- NBT-NS (NetBIOS name service). It does very similar job just like the LLMNR protocol. However, NBT-NS identifies hosts by their NetBIOS names. NBT-NS broadcast requests are being sent on UDP 137 port.
- MDNS. It is another protocol of name resolution. The port the MDNS uses, is 5353.
All of these protocols are doing practically the same – providing name resolution service.
The tool is effective as it creates a man-in-the-middle attack. And it does this by responding to the request faster than the original recipient does. Responder makes the network device thinks he is communicating with the device X (it might be printer, SMB server, or just anything). But in reality, the hacker, who is running Responder, sees the flowing data.
This tool is installed on Kali Linux by default (if you use the Kali version with all tools).
The tool has also many different features:
- Built-in MSSQL auth server – used to redirect authentication requests of the SQL servers. Works with -r option.
- Built-in HTTP and HTTPS auth server – for redirecting HTTP(s) authentication. Use the -r for enabling it.
- Built-in LDAP auth server – to redirect LDAP auth. Can be enabled with -r option.
- Built-in DCE-RPC auth server – for redirecting DCE-RPC authentication queries. For this to be enabled, you should use -r and -d options.
- Built-in FTP, POP3, IMAP, SMTP auth servers – all clear text credentials of the mentioned services are collected by the Responder.
- Built-in DNS, and WPAD proxy servers – the DNS server module is handy when trying to perform ARP spoofing. And the WPAD proxy server captures HTTP requests of the users using Internet Explorer.
- Browser listener – useful when finding PDC in stealth mode.
- Fingerprinting module – can be used to find each device on the network, that is using LLMNR, or NBT-NS.
- ICMP redirect – very effective for man-in-the-middle attacks that are aiming at Windows XP, or Windows 2003.
- Rogue DHCP – this is handy feature to spoof the DHCP server.
- Analyze mode – if you do want to perform only passive actions, you will find this mode handy. This mode does not poison any responses, just fingerprints the network.
How Safe Is to Use Responder During Internal Pentest?
When you are trying the Responder penetration testing tool on your home network, you probably won’t cause any damage.
But another matter when you are performing an internal pentest on the client’s infrastructure, where hundreds of devices are communicating with each other. I’ve used the tool in the past on client networks, and I personally had not caused any disruptions. But of course there is always a risk. It might be scary to use it for the first time as you won’t know what could go wrong.
The Responder is a poisoning tool. It means that it tries to pretend being another device on the network. When the network device is tricked, he sends a legit answer to your host. If you are lucky, you might receive a NTLM hash, that can be saved and cracked, or be relayed to system on the network.
However, Responder does cause disruptions for some of the devices. However, the percentage is not that high.
During the attack some older protocols can be affected. For example, a legacy device is used in the network. By running Responder and poisoning response for that device, you prevent legit devices from connecting to it. This is because your IP, by the help of Responder, is associated with that legacy device. In the eyes of other hosts, you are that device.
There are some options that are likely to cause disruptions:
- -P – this is an option that forces NTLM/Basic authentication for the proxy. The user will have to authenticate, so it won’t be able to use the host at the moment the attack was performed.
- -r – an option that is recommended to be used with -P will also increase the risk of making a DoS attack with Responder. This option redirects various authentication requests to the Responder.
Using the default flags is way safer than using additional flags. But the thing is that additional options will be less useful for the penetration testing.
So, using the Responder might prevent some devices from connecting to file shares, printers, or other devices. This is a DoS vulnerability that should be mentioned in your penetration testing report.
While the risk of something bad happening is very low, if you are working on a network with thousands of devices, everything might happen.
However, what is good, is that there are no lasting effects. As soon as you turn the poisoning attack off, user will be able to access other devices normally. We could state that it is safe to use Responder during the pentest.
Tips for Using the Responder
Offensive security tools can have devastating consequences if used offhand. These are the tips how you can make your penetration testing with Responder go well:
- Do not leave the tool running overnight. Unlike sniffing the network with Wireshark, using the Responder for an extended period of time is not recommended. This is a tool that might potentially disrupt services, and you do not want to unintentionally create DoS attacks.
- When working with a client’s network, make sure you warn the client about the tool that you will use. Explain that it might cause disruption of services. If the client could appoint a person who could monitor the network and check if everything is fine, this would be perfect.
- If you are working as an independent consultant, make sure that your contract states you take no responsibility for the disruptions and other damages. If you are working on a consulting company, the paper work was probably taken care of by other people.
- If you are afraid that poisoning attacks might disrupt the systems use the analyze mode. There is a chance you somehow managed to reach the production network, so you do not want any risk of disrupting the business operations.
The LLMNR and NBT-NS Aren’t the Main Name Resolutions Methods
In most of the cases, internal network relies on a DNS server for name resolution. Disabling LLMNR and NBT-NS won’t break anything in the network.
If the DNS server is present and hosts are configured correctly, turning both of these protocols is safe. In any modern networks domain controllers does run the DNS servers.
But before making decision of turning off LLMNR and NBT-NS support, you must be sure that no legacy applications rely on them. Otherwise, users might have trouble using legacy devices, ex. old printers. Also, isolated networks might not have DNS servers, so the LLMNR and NBT-NS protocols are the only option for them.
Disabling these name resolution protocols would decrease the attack surface. It will become harder for a hacker to get NTLM hashes.
I hope this article helped you to better understand how does the Responder, tool that can be found on Kali Linux, works. But it works not only on Kali, as it is built with Python, it can be installed on any pentesting OS. Using the Kali Linux Responder will make your life easier. However, be careful not to disrupt other devices operation.
Using the Responder during pentest is generally safe, but there are always exceptions. But even though users might found one or another device unreachable during your pentest, this is temporary. As soon as you turn off the poisoning attack, everything will go back to normal.
Highly passionate about cyber security (penetration testing, bug bounty hunting, cybersecurity in general), and blogging. I am experienced in vulnerability assessments, penetration testing, various security audits, had worked with various clients, most of them were in finance sector.
CompTIA Security+, CEH, CEH Practical, CEH Master, and OSCP certified.