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.localADAdmin /netonly cmd.exe

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

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.

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.

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.

privilege::debug
sekurlsa::logonpasswords


And there you should see your HoneyHash:

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.

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.

You can view the companion webinar that Jeff presented on August 9th here: Detecting Pass-the-Hash with Honeypots

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*