A Detailed Guide on Responder (LLMNR Poisoning)

Introduction

Responder is a widely used tool in penetration test scenarios and can be used for lateral movement across the network by red teamers. The tool contains many useful features like LLMNR, NT-NS and MDNS poisoning. It is used in practical scenarios for objectives like hash capture or poisoned answer forwarding supporting various AD attacks. The tool contains various built-in servers like HTTP, SMB, LDAP, DCE-RPC Auth server etc. In this article, we will cover a majority of these attacks that can be performed while being aided by responder.

 

Table of content

·         LLMNR, NBT-NS, MDNS and DHCP

·         Responder Installation

·         Attack 1: LLMNR/NBT-NS Poisoning through SMB

·         Attack 2: LLMNR/NBT-NS Poisoning through WPAD

·         Responder Analyze Mode

·         Responder Basic Authentication Mode

·         Responder Downgrade NTLMv2-SSP to NTLMv2

·         Responder external IP poisoning

·         Responder Multi-Relay: Shell on a system

·         Responder DNS injection in DHCP response

·         What are these servers in responder?

·         Recommendations

·         Conclusion

 

LLMNR, NBT-NS, MDNS and DHCP

LLMNR: LLMNR is a protocol which allows name resolution without the requirement of a DNS server. It is able to provide a hostname-to-IP based off a multicast packet sent across the network asking all listening Network-Interfaces to reply if they are authoritatively known as the hostname in the query.  It does this by sending a network packet to port UDP 5355 to the multicast network address. It allows IPv4 and IPv6 hosts and supports all current and future DNS formats, types, and classes. It is the successor of NBT-NS.

NBT-NS: NetBIOS name service (NBT-NS) is a Windows protocol which is used to translate NetBIOS names to IP addresses on a local network. It is analogous to what DNS does on internet. Each machine is assigned a NetBIOS name by the NBT-NS service. Works on UDP port 137. It is the predecessor of LLMNR.

MDNS: Multicast DNS (mDNS) is a protocol aimed at helping with name resolution in networks. It doesn’t query a name server, rather, multicasts the queries to all the clients in a network directly. In multicast, an individual message is aimed directly at a group of recipients.  When a connection between sender and recipient is made, all participants are informed of the connection between the name and IP address, and can make a corresponding entry in their mDNS cache.

LLMNR/NBT-NS Poisoning: Let’s say a victim wants to connect to a shared drive \\wow so it sends the request to the DNS server. The only problem is that DNS can’t connect to \\wow as it doesn’t exist. Therefore, server replies back saying he it can’t connect the victim to \\wow. Thereafter, the victim will multicast this request to the entire network (using LLMNR) in case any particular user knows the route to the shared drive (\\wow).

An adversary can spoof an authoritative source for name resolution by responding to this multicast request by a victim as if they know the identity of the shared drive a victim wants to connect with and in turn request it’s NTLM hash. This means that the attacker has now poisoned the service!

 

DHCP Poisoning: Dynamic Host Client Protocol (DHCP) is used to provide a host with its IP address, subnet mask, gateway etc. Windows uses multiple custom DHCP options like NetBIOS, WPAD etc. By poisoning the DHCP response, an attacker would be able to help victim pinpoint its own rogue server for any kind of authentication. In turn, compromising the credentials.

 

Responder Installation

Initially developed by SpiderLabs and now being developed by Laurent Gaffie (lgandx), responder is a python coded tool which can be found here. The tool comes built-in Kali OS. Responder.exe (Windows version) of the same can be found here.

It can be run using the command:

responder -h

 

Attack 1: LLMNR/NBT-NS Poisoning through SMB

Essentially when a system tries to access an SMB share, it sends a request to the DNS server which then resolves the share name to the respective IP address and the requesting system can access it. However, when the provided share name doesn’t exist, the system sends out an LLMNR query to the entire network. This way, if any user(IP address) has access to that share, it can reply and provide the communication to the requestor.

Let’s see a share “wow” which doesn’t exist currently. If the share exists on the same network, wow can be accessed by typing “\\wow” in the address bar of file explorer. It doesn’t exist and so, Windows throws an error.

In comes responder. Now at this point the requesting machine (windows 10) sends out an LLMNR request. We set up responder to poison that request. We need to tell responder the NIC on which we want to listen for LLMNR requests. Here, eth0. The default responder run shall start LLMNR and NBT-NS poisoning by default.

responder -I eth0

Now, when the victim tries to access shared drive “wow” he sees this! Wow has suddenly been made available and the poisoner asking for user credentials.

Wow isn’t available at all! That’s just our poisoned answer in order to obtain NTLM hashes. Even if the user doesn’t input credentials, the hashes will be obtained.

We can now save these hashes in a file hash.txt and use hashcat to crack it. Please note that module number 5600 is the one suited to crack NTLMv2. If you obtained some other version of NTLM, please follow the hashcat modules here to specify the correct one.

hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

As you can see, password has now been obtained which is Password@1

Furthermore, responder creates logs of every sessions and all the hashes thus dumped can be seen under the folder /usr/share/responder/logs

 

Attack 2: LLMNR/NBT-NS Poisoning through WPAD

WPAD: Web Proxy Autodiscovery Protocol is a method used by a browser to automatically locate and interface with cache services in a network so that information is delivered quickly. WPAD by default uses DHCP to locate a cache service to facilitate straightforward connectivity and name resolution.

In an organization which uses WPAD server, to supply each browser with same proxy configurations using a file called wpad.dat. Hence, any request going from any browser in a company domain first finds wpad.dat and then reads the configuration and finally sends the request to destination.

When an invalid URL is input in the browser, browser fails to load that page using DNS and hence, sends out an LLMNR request to find a WPAD proxy server. This behaviour is there by default in browsers that have enabled “automatic configuration detection,” an option used often in corporate networks to route traffic through proxy. It then asks for wpad.dat which contains proxy’s auto configuration data.

Responder (LLMNR poisoner) creates a rogue WPAD proxy server, poisons the request, and tells the browser that it has wpad.dat file and asks for authentication. When the user inputs his credentials, the hashes travel through the attacker!

Attack: To configure WPAD rogue proxy server we use the -w option. Furthermore, we added an optional switch of DHCP injection. This switch would inject rogue proxy’s address (kali IP) in the DHCP response. The attack could still work without this switch.

responder -I eth0 -wd

As you can see above, that DHCP poisoner and WPAD proxy have now been turned on. Now, when a user inputs any wrong URL, lets say, randomurl.local, browser couldn’t locate it. Responder poisons and injects DHCP response with WPAD’s IP and the browser tries to authenticate to the WPAD server and gives a login prompt.

As soon as the client inputs his credentials, we receive their NTLM hashes!

This can be viewed in the logs too, but this time under the name HTTP-NTLMV2-IPV6.txt format

We can crack it using hashcat now

hashcat -m 5600 HTTP-NTLMv2-fe80::ddc5:3b8f:e421:a88a.txt /usr/share/wordlists/rockyou.txt

Hash has been cracked and clear text password dumped!

 

Responder Analyze Mode

In the analyze mode, responder doesn’t automatically poison the LLMNR requests, rather it tracks the network flow of the requests made in order to give essential information like name of the user, machine account being used, name of the DC, OS version etc. It can be switched on using -A switch

responder -I eth0 -A

When a victim tried to access wrong sharename (Attack 1 method), responder analyses the entire flow and gives us the DC name, Windows OS version etc.

 

Responder Basic Authentication Mode

In attack 2, we saw how an NTLM authentication windows was opened when our rogue WPAD proxy server was being accessed by poisoning LLMNR. In turn, we were able to retrieve the NTLMv2 hashes. We will imitate the same attack but this time, try to gain clear text credentials of the user using basic authentication! This can be achieved using the -b flag. Further, we are using -F switch to force basic authentication!

responder -I eth0 -wdF -b

Now, when a user tries to access any invalid URL, he sees the following prompt with the message saying that these credentials would be sent in clear text using basic authentication.

As soon as use inputs his credentials, responder receives them and displays password in clear text!

 

 

Responder Downgrade NTLMv2-SSP to NTLMv2

NTLM provides ESS functionality (Extended Session Security) which adds to the complexity of the NTLM hash. ESS functionality adds an “SSP” flag in the NTLM hash (NTLM2-SSP). This increases the length of our NTLM hash in turn increasing complexity to crack the hash. We can configure Responder to use simple NTLMv2 (without ESS) which would result in lower time complexity to crack hashes.

--disable-ess flag does that. --lm flag tries to force the NTLM authentication to version 1 instead of 2, which is not possible in later windows and windows server versions. Here, we will use Attack 2 procedure with disable-ess flag.

responder -I eth0 -wdF --lm --disable-ess

This would give the user a pop-up

As soon as Mufasa enters his credentials, we would see that a downgraded version of the NTLMv2 hash has now been obtained

This can be cracked using hashcat and you’d notice it took 3 seconds time as compared to 7 seconds in Attack 2 (half less than before)!

 

Responder external IP poisoning

Responder can be used to send LLMNR poisoned requests to the victim that contains another IP than the one we are currently using. It creates stealth and allows us to conduct more sophisticated attacks. This can be done using “-e” option

responder -I eth0 -e 192.168.1.2

 

Responder multi-relay: shell on a system

Relaying is one of the most commonly used techniques used for credential access. A relay or forwarder receives valid authentication and then forwards that request to another server/system and tries to authenticate to that server/system by using the valid credentials so received. In Attack 1, we used an invalid SMB share to get hashes of the requesting system.

What if the requestor was Admin?

Sure, we can get his credentials and wait till hashcat cracks it or be smarter and use relay to forward this authentication on our desired host and gain shell on it directly!

To do that, lgandx has included a script called “MultiRelay.py” in /usr/share/Responder/tools folder. We need to install a few dependencies and build the supporting binaries that would run on the victim system and grant us a reverse shell.

apt-get install gcc-mingw-w64-x86-64

x86_64-w64-mingw32-gcc ./MultiRelay/bin/Runas.c -o ./MultiRelay/bin/Runas.exe -municode -lwtsapi32 -luserenv                                                                                                         

x86_64-w64-mingw32-gcc ./MultiRelay/bin/Syssvc.c -o ./MultiRelay/bin/Syssvc.exe -municode

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py

python get-pip.py

pip install pycryptodome

 

Once its done, we can run MultiRelay.py without any errors or warnings.

cd /usr/share/responder/tools

python3 MultiRelay.py

Now, first criteria for this attack to work with SMB is that SMB signing has to be disabled. It is disabled by default so that checks our ease to exploit. It can be tested using the nmap script smb-security-mode

nmap -p445 --script=smb-security-mode 192.168.1.3

As you can see, SMB signing is disabled so the coast is cleared. We can run MultiRelay now. To run it we need to specify the target using “-t” and “-u” specifies users to which relay is to be forwarded. You can choose selectively too and create lesser noise in network.

python3 MultiRelay.py -t 192.168.1.3 -u ALL

As you can see above, the script has detected my victim’s OS, computer account name (workstation01) and SMB signing status too. One other thing to note here is that this script is using HTTP and SMB ports. So, to prevent any conflict, we need to turn these servers OFF in responder.conf file. We just open the file in /usr/share/responder/Responder.conf and turn off HTTP and SMB. If done properly, when we launch responder next time, an OFF switch like this shall be there.

Now, as per Attack 1’s methodology, we run responder

responder -I eth0

Now, an administrator tries to open a shared drive. He is unsuccessful as the share wowowow doesn’t exist! So, responder intervenes and poisons requests successfully.

Now, in Attack 1, we had SMB server running in responder, so the victim authenticated to us and we were able to see creds. Here, SMB relaying is setup in MultiRelay.py, so that credential is now forwarded to our victim “192.168.1.3” and we gain a shell successfully on it! We received an NT AUTHORITY privilege too. This is possible because Admin had required rights on the C$ and the binary we compiled earlier was upload, ran and gave us a great shell. It could be done to gain access to a lower priv account too.

 

Responder DNS injection in DHCP response

In the event where DHCP is being used to identify the IP which is hosting, let’s say, an SMB drive called “wow” (refer attack 1), responder can also inject a rogue DNS record in DHCP responses.

Responder has a rogue DNS server set up. Basically, any victim trying to access a false shared drive tries to resolve the name by finding the correct DNS server. DHCP tries to resolve the IP by locating correct DNS server. It sends out a request. Responder replies to the DHCP request and injects its own DNS server IP in the DHCP response successfully poisoning the DHCP response. Victim receives this, sees our DNS server IP and tries to access the share “wow” by connecting to us. Victim now authenticates to our rogue DNS server rather than discarding the query.

The DHCP-DNS injection can be set up using “-D” option:

responder -I eth0 -D

When the victim accesses any invalid share, a prompt is now visible.

NTLM hashes have now been successfully retried by injecting our rogue DNS server IP!

 

What are these servers in responder?

Responder supports multiple servers as shown below in the screenshot. These are rogue servers that may facilitate one or more attacks.

Upon an nmap scan, we see that the servers are operable

For example, in the demo above, a DNS server IP was needed, so responder created a rogue DNS server and added its own IP in order to facilitate DHCP-DNS poisoning. Similarly, SMB server captures auth credentials directly of a victim when a share on our Kali machine is being accessed. Like:

Responder successfully captures the NTLM hashes

An FTP server is also given here. Let’s try and access it via victim’s browser

As you can see, anonymous credentials are obtained. Please note that while accessing it with browser valid username and password can be given as well which will be obtained in clear text

An RDP server is there as well. Lets access it using victim’s machine

Upon entering the credentials, we receive the NTLMv2 hashes associated successfully

And a WinRM server is also given. It is a protocol use for powershell remoting. So, if a victim connects to this rogue WinRM server like this:

New-PSSession -ComputerName 192.168.1.4 -Credential (get-credential)

A hash is therefore obtained!

WHATS THE POINT? Often in pentest scenarios, to conduct lateral movement, we need to compromise credentials. Sending in malicious attachments with links to our rogue servers may fool a user into authenticating and hence, give us his credentials. Alternately, we can us relaying (Impacket’s toolkit) to conduct various other attacks. For example, in this article, we have conducted LDAP relaying using impacket’s ntlmrelay script and poisoning using responder in order to take over workstations.

 

Recommendations

To prevent attacks demonstrated above, following are recommended:

·         Turn off LLMNR and NBT-NS in computer policy->computer configuration->admin templates->network

·         If an organization can’t turn it off, they must put network access control

·         Use strong user passwords.

·         To mitigate against the WPAD attack, you can add an entry for "wpad" in your DNS zone so that no LLMNR is sent.

·         Use SMB signing to prevent SMB relay attacks

 

Conclusion

The article covered various useful attacks which can be performed with the help of Responder. The tools is coded in Python and hence, is platform independent. Red teamers heavily use this tool to conduct lateral movement. The aim of the article is to serve as a ready reference when it comes to using responder in pentest scenarios. Hope you liked the article. Thanks for reading.