LLMNR/NBT-NS Poisoning in Windows environment

LLMNR/NBT-NS Poisoning

In this blogpost, we’ll talk about poisoning name services (such as LLMNR, NBT-NS) within local networks. In a local area network, you can do name server poisoning to steal authentication credentials.


Introduction:-

LLMNR stands for -> Link-Local Multicast Name Resolution
NBT-NS stands for -> NetBIOS Name Service

  • LLMNR and NBT-NS are Microsoft Windows components and are basically the alternate methods of host identification.
  • LLMNR is based upon the DNS format and allows hosts on the same local link to perform name resolution for other hosts.
  • NBT-NS identifies the systems on a local network by their NetBIOS name.

Throughout this post, we’ll use Responder which is a LLMNR, NBT-NS and MDNS poisoner. It also has built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication.
Link to Responder-: https://github.com/SpiderLabs/Responder

How we can use responder to accomplish this?

  • It abuses the default behaviour of Microsoft Window’s name resolution services and steals authentication credentials.
  • When a windows host cannot resolve a hostname using DNS, it uses the LLMNR protocol (Link-Local Multicast Name Resolution) to ask neighboring computers about it. If that also fails, then it uses the NBT-NS (NetBios Name Service).
  • When LLMNR/NBT-NS is used to resolve a name, any host on the network can reply. So, Responder is one of such tools that poisons the request.

Let’s understand this attack scenario using below picture:

Attack:
Let’s see how we can use this open source tool Responder to conduct NetBIOS Name Service poisoning, which captures the usernames and hashed passwords that allows access to legitimate credentials.

First access the help content of Responder by typing below command to check for all available options:

responder -h

Start Responder and listen for any queries on the same network interface (eg/. eth0) in which our other windows clients are:

responder -I eth0 -wbf

Responder will go into a listening state and respond to LLMNR requests on the local network. Once discovered, it’ll print the NTLMv2 hash on the terminal.

Collecting hash for users accessing network shares:

Below picture shows when the currently logged in user tries to access a UNC share (Universal Naming Convention) “\\CORPCL2” (which DNS has no answer for):

Responder poisons the response and pretends that it has answer for “CORPCL2”. The client machine tries to connect to “\\CORPCL2” and in the process, it sends the username and hashed password to the attacker which can be seen on the Responder stdout screen. Below is its NTLMv2 hash displayed in the output:

From the screenshot, it looks like it is a domain user from domain CORP. Once the attacker gets the hash, and after he is successfully able to crack the hash, he can get inside domain and do further enumeration in the environment.

Cracking the hash:

We can use Hashcat to crack the hash. Link to Hashcat: https://hashcat.net/hashcat/
Save the hash in a text file eg. ntlmhash1.txt and attempt to crack it using below command in hashcat to crack the hash:

hashcat -m 5600 -o passntlmfile -a 0 ntlmhash1.txt rockyou.txt --force
hashcat -m 5600 -o passntlmfile -a 0 ntlmhash1.txt rockyou.txt --force

In this command:
-m 5600 refers to hash mode. (5600 is for NTLMv2),
-o is for output file (i.e. passntlmfile),
-a is for attack mode.
You can check these options in the help context of hashcat by typing hashcat -h

It’ll take some time to crack the hash. Once cracked, you can see the password in the output file:

Collecting hash and clear text password for users accessing internal websites:

We can also capture passwords in clear text in cases when a user tries to open a local website mistypes the name. When user tries to open a website and does a mistake such as typing http://intranet2 instead of http://intranet1, which DNS has no record for and so it cannot resolve the name, Responder comes into the picture and asks for user authentication. Responder answers this request and prompt the user with a login prompt to access that resource as shown in diagram below:

When user enters the credentials, it displays the response as below:

Epilogue:

In this post, we learnt basics of how to do the man in the middle attack in local area networks having windows machines connected. We can also use Wireshark side by side to intercept the network packets and get more visibility. Hope you enjoyed this post.

For more blogs click here

Author


Leave a Reply

Your email address will not be published. Required fields are marked *