By: Shiran Grinberg
Cynet protects its customers from this attack by actively searching for instances of Responder on the network, as well as utilizing passive mitigation methods – maintaining clients’ security and protecting credentials and data:
(To learn more about how Cynet can protect you from LLMNR & NBT-NS Poisoning as well as credential access using Responder, click here)
Name Resolution (from here on abbreviated NR) is a series of procedures conducted by a machine to retrieve a host’s IP address by its hostname. On Windows machines, the procedure will roughly be as follows:
As can be seen, the final fallback when resolving a hostname’s IP address is using multicast NR. This is managed by three main protocols: NBT-NS (NetBIOS Name Service), LLMNR (Link-Local Multicast Name Resolution) and mDNS (multicast DNS).
The three protocol are used adjunctively for two main reasons: legacy support and compatibility. NBT-NS was created in the early 80’s and is somewhat unfitting with today’s standards. As the protocol was falling out of favor, Windows machines started implementing NBT-NS’s successor, LLMNR (still supporting NBT-NS for communication with older machines). On the other hand, most Linux-based machines implemented mDNS instead. Eventually with the release of Windows 10, Microsoft added support for mDNS as well to enhance overall compatibility.
Let’s see these protocols in action:
On a Windows 10 machine we mistyped a shared folder’s name (\\filesahre instead of \\fileshare), resulting in a series of mDNS, NBT-NS and LLMNR queries. Notice that all queries are sent to designated multicast addresses.
Figure 1: Network capture of a Windows 10 machine trying to resolve an unknown hostname using multicast name resolution protocols
NBT-NS, LLMNR and mDNS broadcast a query to the entire intranet, but no measures are taken to verify the integrity of the responses. Attackers can exploit this mechanism by listening to such queries and spoofing responses – tricking the victim into trusting malicious servers. Usually this trust will be used to steal credentials.
Moreover, a number of tools have been developed to automate this procedure, making the attack a no-brainer that can run in no-time. For this article we used Python-based Responder on a Kali Linux machine.
There are many occasions in which a machine will resort to multicast NR, some of which are:
Responder is an open-source python-based LLMNR/NBT-NS/mDNS poisoner acting in two stages as described above:
In this demonstration we will use Responder to access credentials through SMB and WPAD authentication. We used a Kali Linux machine, which has this tool pre-installed and can be accessed under /usr/share/responder.
This is our network setup:
Figure 2: Demonstration network diagram, depicting the victim PC, attacker PC and a file server named fileshare.
Now let’s see Responder’s arguments on our attacking machine (192.168.68.111):
Figure 3: Responder’s arguments (running on Kali Linux machine)
We can see that WPAD capabilities are turned off by default, and to activate them we will add the flags -w and -F (to force the client to authenticate to us as part of the WPAD protocol). Coupled with the -I flag (to specify the interface to run on) and the -v flag (to have a better view of what’s happening), we will execute the following command:
Figure 4: Responder’s enabled and disabled services and options, as displayed after execution
Now everything is set up and Responder will wait for multicast NR queries.
Remember our aforementioned mistyped “\\filesahre“? This is how the same event looks on our attacking machine:
Figure 5: NR spoofing leading to SMB credential access, as seen on Responder’s log
As seen in the introduction, several NBT-NS, LLMNR and mDNS queries were broadcast by our victim Windows 10 machine, indicating that the required host is supposed to be a file server. Responder will reply to file server queries (SMB and FTP) by default. The victim then established a connection with our malicious SMB server and handed us its credentials.
Let’s see this process on Wireshark:
Figure 6: NR spoofing leading to credential access, as seen on Wireshark
First our victim (192.168.68.101) sent multiple multicast NR queries using mDNS, NBT-NS (NBNS) and LLMNR. As seen in the second packet, Responder replied to the NBT-NS query claiming our machine (192.168.68.111) is filesahre:
Figure 7: Poisoned NBT-NS answer for fileshare (mistyped filesahre)
The victim then initiated an SMB connection and authenticated to our server, as seen in the last two packets. His username and password hash code were transferred and are now visible to us as plaintext (“User: WINDEV2004EVAL\User”). The full hash code is dispersed among several fields in both packets and can be gathered manually, but responder automatically puts them together – outputting the complete hash code seen in the log.
On our second run, a query for WPAD hosts was broadcast through Google Chrome. After spoofing a response and establishing a connection, the victim requested the wpad.dat Proxy Auto-Config (PAC) file. Responder requested the victim to authenticate first – retrieving its credentials. It’s that simple!
Figure 8: Responder log demonstrating a WPAD-based credential access. Responder identified several NBT-NS, LLMNR and mDNS queries for wpad and wpad.local and responded with poisoned answers, tricking the victim to initiate an HTTP connection (1). Next our victim, 192.168.68.101, sent a GET request for wpad.dat to our machine, and was requested to authenticate in response (notice that responder displays the User-Agent as retrieved from the HTTP GET request). The victim then handed over its credentials and they were added to Responder’s log (2). Later, we can see Chrome’s 3 random hostname resolution attempts: lvgeeyxplexhzl, ndxyphcamokhchl and awlzijvh (3).
And again on Wireshark:
Figure 9: NR spoofing leading to WPAD credential access, as seen on Wireshark
First our victim machine (192.168.68.101) queried for wpad and wpad.local. Responder then sent a response, directing the victim to itself (192.168.68.111). Notice that this time the response was sent over LLMNR:
Figure 10: Poisoned LLMNR answer for fileshare (mistyped filesahre)
Then the victim requested the wpad.dat PAC file, Responder negotiated an authentication and the user’s credentials were handed over in the second to last packet:
Figure 11: User credentials retrieved from WPAD
WPAD poisoning is more reliable than waiting for a victim to mistype network locations, but it’s not perfect. Some machines we tested didn’t query for WPAD hosts at all, and some queried for WPAD but refused to authenticate. Certain browsers will also prompt the user to manually enter his credentials.
Finally, here is a video of the entire process:
Responder can spoof some services that use plaintext authentication (FTP, POP3), but in this demonstration we opted for services that use hash codes. There are many tools to crack hash codes and we used John the Ripper, which utilizes password dictionaries, wordlists and brute force methods. This tool can be very effective when passwords are not overly complex.
What if our hash codes deem uncrackable? Well then, this is when Responder’s bundled sidekick MultiRelay comes into play. This tool can be used to relay the victim’s authentication packets to a different machine and get privileged access to it. in a manner similar to Man-in-the-Middle attacks. If the spoofed victim has administrative access to the targeted machine, it will be severely compromised.
Machines can utilize SMB Signing to prevent MITM attacks in SMB connections by digitally signing the data transferred and confirming its authenticity. However, enabling SMB signing for all hosts on a network can impact performance by up to 15%.
Another option is to use Pass the Hash methods to authenticate using the compromised hash code, rather than cracking it and using the password itself.
Since multicast NR is a peer-to-peer behavior, most mitigation methods will focus on endpoint security, rather than relying on network security alone: