LLMNR & NBT-NS Poisoning via Responder

5 minute read


Prologue

Before we get into this blog, I wanna make sure that you understand what is LLMNR and NBT-NS and mDNS protocols are. These two protocols are widely used in Windows Environment which are enabled by default. This poses a serious threat to the infrastructure, if it is being abused by attackers in the infrastructure network. The main goal of LLMNR and NBT-NS is toresolve the DNS hostnames from the client, when all other resolving methods are failed

LLMNR - Link Local Multicast Name Resolution

NBT-NS - NetBIOS Name Service

mDNS - Multicast DNS

Here LLMNR is the newer replacement for NBT-NS protocol, where NBT-NS protocol is still used along with LLMNR protocol to support the legacy machines. Whereas mDNS is the Linux alternative for LLMNR

So whenever a multicast call is made for hostname resolution, these three are used together to improve the compatibility and efficiency for resolving the hostnames

Windows machines does hostname resolution in the following steps if the preceeding one fails,

  1. The hostname is received from the client
  2. The hostname will be checked in hosts file of the local machine, C:\Windows\System32\Drivers\etc\hosts
  3. The hostname will be checked on Local DNS Cache
  4. The hostname will be checked on DNS Server of the domain
  5. The hostname will be checked from other machines by sending a multicast query using LLMNR and NBT-NS and mDNS protocols

Lets see an example how these protocols work,

Assuming a user/victim in an infrastructure of Windows AD Network tries to load a SMB Share with hostname, which may be real/malicious/fake

If either us or the Windows machine doesn’t know what’s the IP address of the hostname,it will try to lookup the IP address by resolving the hostname on the following order which we discussed above

If it was found in Hosts file,Local DNS Cache it would not have to interact outside the local machine, most frequently resolved hostname will be found here itself

When its not found, It will try to query the DNS Server to resolve the hostname

The client machine will send a request to the DNS Server to resolve the hostname

Since we have entered a unknown hostname to the DNS server it fails and return this response

Now our DNS server gave up, so its time we take our last option to resolve the hostname by sending mutlicast query through LLMNR , NBT-NS and mDNS protocols

This where the whole point of attack starts

Attack Vector

In order to poison mNR ( Multicast Name Resolution ) (collective term for LLMNR, NBT-NS and mDNS), an attacker should be connected into a network where the victim is able to interact and send requests to the attacker

When a user/victim mistypes a hostname in his Windows machine (or) If the DNS server is poorly configured so that it is unable to resolve the hostname and passes it to mNR, which is the common scenario for this poisoning attack

We all have to do is, sit in patience so that they interact with our poisoned requests due to their misconfigurations

After the user/victim interacts with our poisoned requests, we will be acting as the legitimate hostname which they are trying to communicate and we will ask them for authentication, which makes them to send their NTLMv2 hash for authentication

That NTLMv2 hash is a valuable information in these kind of attacks which can be used for Initial accesss/Lateral Movement inside the organisation

Responder is a great tool used by Red Teamers and APT threat actors to gain initial access into an organisation environment

This tool allows us to poison LLMNR, NBT-NS, mDNS and baits the user/victim for authentication so we get their NTLMv2 hashes, which can be further used for cracking hashes into plain text passwords (or) relaying attacks

Analysing with Responder

Lets analyze the Windows network for incoming mNR requests using Responder

Running Responder in Analyze Mode,

responder -I eth1 -A

We can see that the poisoners are off and Responder also supports many servers for relaying related attacks (which will be discussed in later blog posts)

Now lets try to load an invalid hostname to trigger mNR requests

It will be generating mNR requests which we will be able to intercept using Responder, since we are connected in the same network

So we are able to see the mNR requests in Responder along with IP address of the client, the next step is to poision the mNR requests from our end to bait the client/victim for authentication

Poisoning mNR Requests

Now lets run our Responder to poison the mNR requests to retrieve NTLMv2 hashes

responder -I eth1

Here we can see that the poisoners are active and mNR requests are being poisioned

Assuming the victim enters an invalid hostname/DNS server is poorly configured,

This will send mNR requests to resolve the hostname which will be poisioned by our Responder

We can see that our poisoned requests is sent to the victim so that we act as the legitimate hostname


Now the NTLMv2 hash exchange will be taken place in the network from the victim to attacker

After exchange, our Responder would have grabbed the NTLMv2 hash by baiting the victim using poisoned mNR requests

Now we had successfully retrieved the NTLMv2 hash of the victim, eventhough after grabbing NTLMv2 hash the Windows machine requests for authentication which is not needed for us in this scenario

Cracking NTLMv2 Hash

Now we can use the NTLMv2 hash for lateral movement using Relaying attacks or we can simply crack that using our wordlist to gain the plain text password which is more useful and persistent

Lets use hashcat to crack the NTLMv2 hash with rockyou.txt

hashcat -m 5600 user.hash rockyou.txt


We have cracked our hash into plain text password, with this we can perform lateral movement also

Now we have shell as the victim user on his machine