A Comprehensive Guide to LLMNR Poisoning : Threat Analysis and Countermeasures

Introduction

LLMNR (Link local multicast name resolution) poisoning is a form of man-in-the-middle attack. To understand LLMNR poisoning, let us study what a man-in-the-middle attack is.

In a nutshell, a man-in-the-middle attack is when a malicious actor positions them in between the victim and their intended destination to intercept and abuse the scenario.

By placing themselves in the middle of the victim and its destination, the attacker sends a response to the victim instead of the intended destination.

LLMNR Poisoning

LLMNR is a protocol that helps resolve the address in case of a failed DNS query. To be precise, when a system in a network sends out a query for a wrong network location (usually mistyped by mistake) or tries to resolve a nonexistent address, the DNS server responds with a failed request.

Since the path does not exist in the domain network, then in an attempt to resolve the location, the victim system broadcasts LLMNR requests to all the devices in the network. When the malicious actor comes across such a request, they respond with a positive response saying they can resolve the path and request the victim to share its NTLM hash to place the request instead of the victim.

Then the hash of the user password can be captured and can be cracked with tools like Hashcat or John the Ripper against a password list of your choice. The bigger the list, the higher the chances of cracking the password.

This attack also requires a user interaction, which is mistyping or searching for a non-existent path, which brings down the attack success rate. Yet it is one of the reliable and popular forms of Active Directory exploitation techniques.

When do these name resolution multicast scenarios happen ?

The common ones are :

• Mistyped hostname (When a user accidentally mistypes an actual legitimate hostname, they end up in multicast name resolution).

• DNS misconfiguration.

• WPAD protocol (Web proxy auto discovery) helps the browsers to autodetect and download PAC (Proxy configuration file).

• Chrome search (When a single string is entered in a Chrome search bar, though it is forwarded to the search engine to confirm if it exists on the local network, Google Chrome makes a name resolution request).

The Poisoning

The tool that is used to intercept and poison the responses is the responder. The tool automates the process of detecting the name resolution multicast and responds with malicious responses in an attempt to retrieve the NTLM hash.

The tool comes with other built-in tools like a WPAD server and a few other servers, which come in handy when testing for the vulnerability.

💡https://github.com/SpiderLabs/Responder

This tool requires sudo privileges to run and can be found preinstalled in Kali Linux.

To run, execute the following command : 

sudo responder -I eth0 -dwPv

Once the responder is up, running and listening, we wait for the name resolution multicast in the local network which is triggered by the scenarios mentioned above. For the lab we can manually trigger the LLMNR multicast by trying to open a directory which is not present in the domain network.

Run the command in the Victim Machine :

Enter dir //<someRandomAddress>

Now we flooded the network with the NBNS, LLMNR, MDNS requests. Get back to the responder to see if we managed to get any hashes.

The outputs from the responders are self explanatory, we can see the poisoned response being sent to the victims and further down we see the captured NTLM hash of the poisoned user with the hostname, IP address.

NTLM

New technology LAN manager, or NTLM, is a suite of protocols that uses a challenge-response mechanism to authenticate users by Windows in an active directory environment.

The client who requests an authentication is given a challenge, which then is encrypted using the hash of the user password. Then the username, encrypted challenge, and the challenge are sent to the domain controller to verify against the user password stored in the NDTS.dit file, which contains the usernames and passwords of all users in the domain (basically a database of creds, accounts, groups, and other important stuff). In this authentication mechanism, the NTLM hash refers to the hash of the user password, which is used to encrypt the challenge.

Cracking the hash

Once we get our hands on the hash, we proceed to attempt to crack it with tools like Hashcat or John the Ripper. The password cracking typically involves a password list from which each password is converted to an NTLM hash using MD5, and then the generated hash is compared against the captured hash to figure out the password.

Just like any other password cracking method, the success rate depends on the quality of the password lists, the complexity of the password, and the system hardware resources (GPU). The Hashcat tool itself is capable of working with different types of hashes, including NTLM.

To figure out the module, we can use the help menu of hashcat and pipe it through the grep command to filter out the protocol that we want.

Run : hashcat -h | grep "NTLM"

The hash we have is NTLMV2; thus, the module we are looking for is 5600. There are other versions of the NTLM modules, which can be used against different versions of the protocol.

Now that we have everything we need, we can proceed to crack the hash. To do so, save the hash in a file, then run it through Hashcat against the password list of your choice.

For this example, let's use the rockyou.txt list, which comes preinstalled with Kali Linux.

Run : hashcat –m 5600 hashes.txt /usr/share/wordlists/rockyou.txt

The -m refers to the module of our choice. Let it run and do its magic while we wait. Note that Hashcat uses GPU to crack the passwords; the more powerful the GPU, the faster the cracking.

Detection

The hunt for LLMNR poisoning is pretty simple since we just have to look for the NBNS, LLMNR, and MDNS spam in the network followed by a response from a rogue device that is not a domain controller server.

Run Wireshark with the filter UDP port 5355 to filter out the LLMNR traffic. Look for the device that is sending out resolution queries, then look for the device that is not a domain server sending out responses for the queries. That is the rogue device we are looking for.

Now that we have our rogue server, we can switch to the DHCP filter to look for the poisoned responses. Then proceed to analyze the packet for the confirmation.

Mitigations

• One can turn off the LLMNR in the group policy manager. Navigate to Computer Configuration > Administrative Templates > Network > DNS Client and then set Turn Off LLMNR to Enabled.

• Using static IP instead of DHCP will reduce the reliance on NR protocols.

• Using host-based firewalls helps block and prevent multicast NR traffic.