Quick Tip: Skip Cracking Responder Hashes and Replay Them


Responder is a go-to tool for most pentesters. We use it quite often on pentests to quickly gain access to a client’s domain. However, when clients enforce strong password policies and their users don’t choose passwords like 'Ilovemykids2017!', we are forced to resort to using masks and brute force to crack these hashes. Given the time constraints of some of our pentests, this is not an effective option. Thankfully Laurent Gaffie developed MultiRelay to help us out with this:


MultiRelay is a module in Responder that allows targeted attacks using NTLMv1 and NTLMv2 relay. MultiRelay takes advantage of commonly misconfigured Windows environments not enforcing SMB signing. Not enforcing SMB signing results in both the client and server not performing any validation of each other, or the payload executing. This makes SMB man-in-the-middle attacks possible, which means shells for us!

MultiRelay+Empire = Pwnage

Now for the good stuff, having MultiRelay pop shells for you! First, we need to stage our attack environment by configuring Responder and creating an Empire listener.

We start off by editing our Responder configuration to disable SMB and HTTP servers:

nano /usr/share/responder/Responder.conf 

Change the SMB and HTTP settings to 'OFF' and save the file.

Start Responder on local network adapter and give it the NetBIOS redirect and verbose flags.

Ensure that the SMB and HTTP servers are 'OFF' as Responder is starting:

Next, we create our Empire listener:

Note: The default setting will work for our lab environment, but you’ll want to configure these options to fit your needs.

Create a PowerShell one-liner for an Empire agent:

This one-liner is plugged in to MultiRelay as our payload when we successfully replay a NTLM hash:

./MultiRelay.py -t <target host> -c <'command to run'> -u <user to target> 

Note: during a pentest, this is where we sit back and wait for a triggering event to execute our payload. This can take a while in certain environments, but on busy Windows networks it's usually only a few minutes before someone comes along and makes your day!

We’ll move the process along by attempting to accessing a share, so Responder can trigger the payload:

Once we attempt to access a share, Responder immediately gets to work poisoning traffic to the requesting host:

Simultaneously, MultiRelay is setting up a SMB challenge to capture a NTLM hash for replay:

After the requesting host replies to the SMB server with a NTLM hash, MultiRelay replays that hash to the target with our payload:

Then we’re greeted with a nice little prompt telling us things went right:

From here we can perform all our post exploitation activities in Empire, like establishing persistence, running Mimikatz, enumerating directories, and so on. And there you have it, domain pwnage without cracking passwords!

Things to Note

  • The users targeted in MultiRelay with the -u flag, must be a local administrator on the target host. This usually isn't a problem in most Windows environments, but using 'ALL' will let you know if the user triggering the event has sufficient privileges.

  • The payload for the -c flag can be changed to whatever you want, such as a Cobalt Strike beacon, a meterpreter shell, or just a Windows shell command. It’s up to you.

  • NTLM relay attacks have been around since 2001!! This method can be used to quickly exploit this legacy vulnerability and, given the right circumstances, can take an attacker from 0 access to domain admin in a matter of minutes.

  • For pentesters: SMB Signing kills this legacy vulnerability, dead in the water. MultiRelay will tell you if signing is enabled and to choose a different target; don’t waste your time on targets that have signing enabled.

  • For admins: SMB Signing kills this legacy vulnerability, dead in the water. Enforce it as much as possible!

  • Although Disabling SMB can stop NTLM relay attacks there may, at times, be negatives that come along with it.

    • Certain printers do not support SMB signing, resulting in the inability to print.
    • Major decreases in SMB performance are common when large files are transferred or many users access the same server simultaneously.


Richard De La Cruz

Read more posts by this author.