Detecting Pass-the-Hash with Honeypots

Detecting Pass-the-Hash with Honeypots

Credential theft within Windows and Active Directory continues to be one of the most difficult security problems to solve.  This is made clear in the Verizon DBIR where it is reported that the use of stolen credentials is the #1 action identified across data breaches.

Microsoft has acknowledged this challenge and responded with a guide on how to mitigate the Pass-the-Hash attack.  They have expanded on their recommendations and outlined steps to set up a tiered Active Directory environment and a separate administrative forest as part of the Enhanced Security Administrative Environment (ESAE).

While these recommendations are great, they can require a lot of work and expertise to accomplish.  In this series I will cover something you can do immediately to detect the use of credential theft attacks such as Pass-the-Hash within your environment through the use of honeypots.

Why is Pass-the-Hash So Difficult to Detect?

You can read up on the Pass-the-Hash attack and watch a video of it in action on our Attack Site.    Pass-the-Hash involves stealing a hashed password from the local system where an attacker has privileged access.  This hash is then used in a valid NTLM authentication interaction with a target system to gain access and move laterally.  Basically, it’s valid NTLM authentication, only bypassing that step where the user has to enter their password.

Because it appears as valid authentication, the recommended detections typically involve looking at the authentication logs to determine normal versus abnormal user behavior.  This can require lots of data analysis and result in the investigation of many false positives.

The HoneyHash

A few years back a technique was introduced that allows for fast, efficient, and accurate detection of Pass-the-Hash and credential theft through the use of honeypots.  The concept is surprisingly simple.  The approach revolves around the Runas executable on Windows and the /netonly flag.

Using Runas with netonly you can launch a process as the currently logged in user account, but specify a separate account to handle all outbound network connections – even if that account doesn’t exist!

So let’s say you were to issue this command to run as a non-existent account ADAdmin:

runas /user:gobias.local\ADAdmin /netonly cmd.exe

This will prompt you for the password for that account, but there will be no validation of that information.

Runas, /netonly, HoneyHash, Pass-the-Hash, Honeypots, Active Directory Attacks

This will launch a new command prompt window running as your current user, but all outbound connections will attempt to use the fictional ADAdmin account.

HoneyHash, Runas, /netonly, pass-the-hash

The important part of this honeypot is that the credentials for the fictional account will be stored in LSASS memory on the system and available for extraction from tools like Mimikatz.  If you do close this window, the credentials will be removed from memory so it is important to keep this open, but we’ll cover that in a bit.

Now we can wait and see if any attacker attempts to extract and then use these credentials.  If so, we conclusively have detected a credential theft attack.

Setting the Honeypot

There is a very useful script provided as part of the Empire project that we will be using to set the honeypot here: New-Honeyhash.  If you’re not familiar with Empire, you can read up on that here.

Invoke-HoneyHash follows the same concept as the runas with the netonly flag, but adds the ability to hide the command prompt window which is launched, making it more difficult to detect.

All you need to do is issue a command similar to the following to put a HoneyHash onto a system:

New-HoneyHash -Domain gobias.local -Username AD.Admin -Password ADPW123!!!

You will want to use a believable username and password to entice the attacker into using these credentials.   Once you do so, you will see a message recommending you use Mimikatz to confirm it worked, which is exactly what we’ll do next.

New-HoneyHash, PowerShell Empire, HoneyHash

Validating the Honeypot is Set

Now that we have created our honeypot, we should have our HoneyHash in memory.  To validate that, we will use Mimikatz.  The following command will pull all of the NTLM hashes and additional credential information from LSASS memory.


And there you should see your HoneyHash:

Mimikatz, sekurlsa::logonpasswords, Pass-the-Hash, Honeypots

Now we can see the trap is set and attackers will be able to retrieve the credential information for our HoneyHash from memory.  If they attempt to perform a Pass-the-Hash attack using Mimikatz, it will appear as though its working but they will have no real access to anything on the network.

Mimikatz, sekurlsa::pth, Pass-the-Hash, Honeypots

In our next post in the blog series, we will explore how to implement detections that can trigger when an attacker falls for honeypots. You can view this post, here.

I will also be presenting a webinar on August 9th,  where I will demo modern honeypot techniques to create traps for attackers and teach how to detect the use of the pass-the-hash technique within your organization. Register for the webinar here:

Jeff Warren is STEALTHbits’ Vice President of Product Management. Jeff has held multiple roles within the Product Management group since joining the organization in 2010, initially building STEALTHbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining STEALTHbits, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.

With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering STEALTHbits’ high quality, innovative solutions.

Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.