Hi there, today’s talk about the responder tool.

Beforehand I want to inform you that in this topic I will discuss the basics too.

First of all we should deep dive into the NTLM user authentication process in the Windows environment. Let’s break down the basics of it.

Windows doesn’t store your user account password in clear-text. Instead, it generates and stores user account passwords by using two different password representations, known as hashes. When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both an LM hash and a Windows NT hash (NT hash) of the password. These hashes are stored in the local SAM database or Active Directory.

Here we should break down a little bit about LM & NT confusion.

LM-hashes is the oldest password storage used by Windows.
LM was turned off by default starting in Windows Vista/Server 2008, but might still linger in a network if their older systems are still used.

The algorithm:

1. Convert all lowercase to upper case
2. Pad password to 14 characters with NULL characters
3. Split the password to two 7 character chunks
4. Create two DES keys from each 7 character chunk
5. DES encrypt the string “KGS!@#$%” with these two chunks
6. Concatenate the two DES encrypted strings. This is the LM hash.

The NT Hash is the MD4 UTF-16 Little Endian hash of clear text password.
Which you can obtain as follows:

echo -n "PassW0rd" | iconv -t utf16le|openssl md4
(stdin)= 1afedc472d0fdfe07cd075d36804efd0

Definition of hashes:

• LM – The LM hash is used for storing passwords. It is disabled in W7 and above. However, LM is enabled in memory if the password is less than 15 characters. That’s why all recommendations for admin accounts are 15+ chars. LM is old, based on MD4 and easy to crack. The reason is that Windows domains require speed, but that also makes for shit security.
• NT –  The NT hash calculates the hash based on the entire password the user entered. The LM hash splits the password into two 7-character chunks, padding as necessary.
• NTLM – The NTLM hash is used for local authentication on hosts in the domain. It is a combination of the LM and NT hash as seen above.
• NetNTLMv1/2 – Hash for authentication on the network (SMB). Sometimes called NTLMv2, but don’t get confused; it is not the same as an NTLM hash.

NTLM is a challenge-response authentication protocol which uses three messages to authenticate a client in a connection-oriented environment.

Procedure:

1. First, the client establishes a network path to the server and sends a NEGOTIATE_MESSAGE advertising its capabilities.
2. Next, the server responds with CHALLENGE_MESSAGE which is used to establish the identity of the client. It is a 16-bit random number (8 bytes).
3. Finally, the  client responds to the challenge with an AUTHENTICATE_MESSAGE (encrypted challenge by the hash of the user’s password).

Workflow:

An abstraction of the NTLM authentication scheme workflow is shown below:

The very heart of the NTLM authentication scheme is the challenge/response mechanism, in which a random challenge is encrypted with a hash of the user’s password, who is requesting to get access to something.

So to break that down:

1. The user enters his/her plain text password, e.g. to log onto a Windows machine
2. This plain text password is hashed (using MD4) to create an NTLM hash
3. Upon accessing a service, e.g. a network share, the service creates a challenge (a big number) and sends that challenge to the user (the client).
4. The client uses the created NTLM hash to encrypt that challenge and send an encrypted blob back to the server (the response).
5. The server decrypts this challenge (using the user’s known hash) and matches it against the provided plain text challenge in order to grant or deny access to the user.

Screenshot from the real authentication procedure between two servers in the Wireshark:

NTLM Server Challenge:

Encrypted challenge, NTLMv2 (response):

Important to note at this point:

The challenge/response data transmitted over the wire does not contain the hashed user password (NTLM hash).
It does contain, however, a blob that is encrypted with that hash. So you cannot sniff the NTLM hash over the wire and match that against a rainbow table (or similar).
But you can sniff an NTLMv1 or NTLMv2 response from the wire, which also contains the plaintext challenge and use that in a brute force attack in order to crack the user’s password.

NTLM Challenge Response Computation

The computation of the NTLMv1 and NTLMv2 challenge response will help to visualize the difference between a user’s password, that user’s NTLM hash and the NTLMv1/NTLMv2 challenge response.
It is not all important to remember the whole computation chain, but spend a minute on each of the following two flow charts and get an understanding of where the user’s password gets involved, how that is used to build up the NTLM hash and finally create the challenge response.

Computation of the NTLMv1 challenge response:

Computation of the NTLMv2 challenge response:

Responder functionality

Responder is a LLMNR, NBT-NS, and MDNS poisoner. It takes advantage of the way that certain networking protocols operate in Windows environments, particularly:

• LLMNR (Link-Local Multicast Name Resolution): 

LLMNR is a protocol that 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):

NetBIOS name service (NBT-NS) is a Windows protocol that is used to translate NetBIOS names to IP addresses on a local network. It is analogous to what DNS does on the 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):

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 \\test so it sends the request to the DNS server. The only problem is that DNS can’t connect to \\test as it doesn’t exist. Therefore, the server replies back saying he can’t connect the victim to \\test. 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 (\\test).

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 its NTLM hash. This means that the attacker has now poisoned the service!

Illustration:

Let’s check Responder in our test lab environment.
Run Responder with using correct network interface:

sudo ./Responder.py -I vmnet3 -v

Now let’s see what happens when the victim requests an arbitrary name (some random), triggered by requesting the share \\test.
We can observe a communication via Wireshark, let’s break down each step here:

Respectively now the victim has known that the endpoint \\test is located at 10.10.10.1 (it’s us) and the victim will attempt to authenticate by using NTLM over the SMB2 protocol.

And also at this moment what the victim is seeing.

Lastly we have caught the NTLMv2 Hash:

This explains the necessity of a trigger; in a real engagement, an attacker cannot merely wait passively for credentials to appear. Instead, they must depend on a scenario where a unique name is requested, whether due to a simple user mistake or by compelling a victim to initiate a name request for a unique identifier. While these tools are highly effective, this helps clarify situations where no hashes are captured.

Password Cracking

The hashed user password is computationally baked into the transmitted NTLM response (see computation scheme above), which enables us to break the password through offline cracking.

As outlined in the previous section the NTLMv1/NTLMv2 challenge you can sniff off the wire is not equivalent to the user’s password hash (NT hash), but you can crack NTLMv1/NTLMv2 response you sniffed from the wire.

Note the response contains the username, the realm (domain), the plaintext challenge and the encrypted challenge.

>> hashcat -a 0 -m 5600 hash.txt password_list.txt
JOHN::LABTEST:0d7fa952c63eef96:e1f387cdf372229cdb9ed6d5d58a29b2:0101000000000000006c57bb899dda010176559ac6a4593000000000020008005700470030004a0001001e00570049004e002d0045004e00540057005100590045004a0046005100500004003400570049004e002d0045004e00540057005100590045004a004600510050002e005700470030004a002e004c004f00430041004c00030014005700470030004a002e004c004f00430041004c00050014005700470030004a002e004c004f00430041004c0007000800006c57bb899dda0106000400020000000800300030000000000000000000000000200000c6a47d52e02f57e7d001c00470a260af2637276cb1f4dfee4920c9cf088dbd9a0a001000000000000000000000000000000000000900120063006900660073002f0074006500730074000000000000000000:Aa12345678!

Session……….: hashcat
Status………..: Cracked
Hash.Name……..: NetNTLMv2
Hash.Target……: JOHN::LABTEST:0d7fa952c63eef96:e1f387cdf372229cdb9e…000000
Time.Started…..: Fri May 3 20:21:20 2024 (0 secs)
Time.Estimated…: Fri May 3 20:21:20 2024 (0 secs)
Guess.Base…….: File (password_list.txt)
Guess.Queue……: 1/1 (100.00%)
Speed.#1………: 8785 H/s (0.03ms) @ Accel:1024 Loops:1 Thr:64 Vec:1
Recovered……..: 1/1 (100.00%) Digests
Progress………: 2/2 (100.00%)
Rejected………: 0/2 (0.00%)
Restore.Point….: 0/2 (0.00%)
Restore.Sub.#1…: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1….: Aa12345678! ->
Hardware.Mon.#1..: Temp: 54c Util: 7% Core:1485MHz Mem:6000MHz Bus:8

Conclusion

The Responder tool can operate without manual triggers, but its effectiveness in capturing hashes and credentials largely depends on the network environment and the behavior of other devices on that network.

Responder is a network tool used for LLMNR, NBT-NS, and MDNS poisoning. It listens on the network for these types of broadcast name resolution requests, which typically occur when a system fails to resolve a hostname using standard DNS. When such a request is broadcast, Responder answers in place of the legitimate service, pretending to be the desired resource. This is an opportunistic behavior, meaning Responder acts as soon as it detects a query it can respond to.

However, in environments where these protocols are disabled or where systems are properly configured to avoid using them, Responder won’t capture any hashes because there are no name resolution queries for it to intercept. In such cases, introducing a trigger—such as causing a device to make a request that Responder can respond to—may be necessary to generate network traffic that leads to the capture of credentials.

In summary, while Responder can work autonomously by exploiting existing conditions on a network, its success often depends on either the presence of misconfigured hosts or the use of additional tactics to induce the desired network traffic.