LLMNR & NBT-NS Poisoning and Credential Access using Responder

Introduction

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:

1. The hostname fileshare‘s IP address is required
2. The local hostfile will be checked for suitable records
3. If no records were found, the machine will move on to the local DNS cache, which archives recently resolved names
4. No local DNS record found? A query will be sent to the configured DNS server
5. If all else fails – the machine will send a multicast query, asking other machines in the network for fileshare‘s IP address

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

Why It's a Problem

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.

Common Abuse Cases

There are many occasions in which a machine will resort to multicast NR, some of which are:

• Mistyping – if a user mistypes the name of a legitimate host, usually no relevant host record will be found and the machine will resort to multicast NR. This is a rather weak use case because the attacker will have to wait for an error on the victim’s side.
• Misconfiguring – false configuration on either the DNS server or the client’s side can lead to problems in NR and force the client to rely on multicast name queries.
• WPAD Protocol – if a web browser is set to automatically detect proxy settings, it will use the WPAD protocol to discover the URL of a proxy configuration file. To discover this URL, WPAD will iterate through a series of potential URLs and hostnames – and with each false attempt expose itself to spoofing. Google Chrome and Firefox will not trigger this behavior by default, but Internet Explorer will.
• Google Chrome – when a single word string is typed in Chrome’s search bar, the application needs a way to discern whether the string is a URL or a search term. Chrome first treats the string as a search term and directs the user to its configured user engine, while simultaneously making sure the string is not a hostname by trying to resolve it^[1]. Furthermore, to prevent exposure to DNS hijacking, Chrome will try to resolve several randomized hostnames on start-up to make sure they do not resolve – essentially guaranteeing some multicast NR action^[2]!

Poisoning with Responder

Responder is an open-source python-based LLMNR/NBT-NS/mDNS poisoner acting in two stages as described above:

1. First, it will listen to multicast NR queries (LLMNR – UDP/5355, NBT-NS – UDP/137) and, under the right conditions, spoof a response – directing the victim to the machine on which it is running.
2. Once a victim will try and connect to our machine, Responder will exploit the connection to steal credentials and other data.

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.

Step 1: Setting-Up

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.

Step 2: Attacking the Target

SMB Credential Access

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.

WPAD Credential Access

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:

Step 3: What Next?

Hash Cracking

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.

MultiRelay and Pass the Hash

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%^[3].

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.

Mitigation

Since multicast NR is a peer-to-peer behavior, most mitigation methods will focus on endpoint security, rather than relying on network security alone:

• Disabling LLMNR – LLMNR can be turned-off through the group policy editor, under the “policy setting” menu under Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client.
• Disabling NBT-NS – NBT-NS can be turned off through the Network Connection Settings. Navigate to Network Connections > Internet Protocol Version 4 > Properties > General > Advanced > WINS, then select “Disable NetBIOS over TCP/IP”.
• Network Traffic Filtration– host-based security products can be used to block LLMNR, NBT-NS and mDNS traffic.
• SMB Signing – as mentioned above, SMB Signing can be used to prevent NTLM relay attacks by digitally signing the data transferred.
• Monitoring – hosts should be monitored for (1) traffic on LLMNR and NBT-NS ports (UDP 5355 and 137), (2) event logs with event IDs 4697 and 7045 (relevant to relay attacks)^[4] and (3) changes to registry DWORD EnableMulticast under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient^[5].

Further Reading

1. NetBIOS and LLMNR
2. 1. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc958811(v=technet.10)?redirectedfrom=MSDN
   2. https://tools.ietf.org/html/rfc4795
   3. https://mailarchive.ietf.org/arch/msg/ietf/8iSE8wOj5U01HNZp_sUb8ymVGDk/
3. WPAD
   1. https://tools.ietf.org/html/draft-ietf-wrec-wpad-01
   2. https://www.netresec.com/index.ashx?page=Blog&month=2012-07&post=WPAD-Man-in-the-Middle
4. https://attack.mitre.org/techniques/T1171/
5. https://cccsecuritycenter.org/remediation/llmnr-nbt-ns
6. https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning
7. https://blog.secureideas.com/2018/04/ever-run-a-relay-why-smb-relays-should-be-on-your-mind.html