So far in this series, we’ve learned about the HoneyHash, a useful honeypot technique for detecting Pass-the-Hash and credential theft within a Windows environment.  We then looked into how to monitor for an attacker triggering the honeypot, and how to gather the necessary forensic details to investigate the attack.  Now let’s look at what you need to do to roll out the honeypot across multiple endpoints in your environment.

There are some basic challenges we need to consider.  First, we need a way to relate a HoneyHash to an endpoint so we know where the compromise occurred.  If we push out identical HoneyHashes to all endpoints, we may be able to detect that our credential was stolen and used, but we won’t know which system it was stolen from and which account was used to do so.  We also may want to know when the compromise occurred to guide our investigation, so we know where to look to gather all of those additional forensics we covered in the last post.

There are solutions to these problems, one of which is the DCEPT project from SecureWorks.  This solution creates identical HoneyHash accounts on each endpoint but uses different passwords.  Endpoint agents are used to deploy and manage the HoneyHashes.  Network monitoring is leveraged to monitor for authentication attempts for a HoneyHash account.  The network traffic is inspected to identify which password was used, and this will tie it to a particular computer in a particular time range.

While this is a very clever approach, some may find it difficult to deploy because it requires endpoint agents and network monitoring on domain controllers which can generate a lot of traffic.  In this post, I want to explore a less elegant, but practical approach to rolling out the HoneyHashes.

The Approach

The basic approach is as follows:

1. Push out the script to generate HoneyHashes to all desired endpoints using Startup Scripts, SCCM, remote PowerShell, or any other deployment mechanisms.
2. The script will run locally and generate a random username/password for the HoneyHash
3. The information will be logged to the local event log and can be forwarded/collected from there
4. Failed authentication events (4625) will be correlated with HoneyHash logs to identify the usage of the HoneyHash, where it was compromised from, and the time window during which it was present.

Let’s take a closer look at each step.

Deploying the Script

There are many options for deploying HoneyHashes across your environment.  A simple approach is to use Group Policy Objects with a startup script.  To do this, I created a new GPO specifically for the HoneyHash.  GPOs can be used for user logon/logoff scripts as well as computer startup/shutdown scripts.  We will use a computer startup script here so our HoneyHash will always be implanted in LSASS while a computer is running.

Once I create my GPO, I can copy my script into this policy using the PowerShell Scripts tab inside the Startup script dialog (I’ll cover what’s in the script shortly).

Okay, that was easy!  Now we just make sure our GPO is linked to the computers that we want to use for our honeypot and ensure they are rebooted for this to take effect.

Generating the HoneyHash

Now that we know how to push out our HoneyHash script, let’s spend some time on what it should actually do for us.  First, we need a way to tie a HoneyHash to a particular computer so when we see the hash in use, we know exactly where it came from.

To do that we are going to create a unique HoneyHash each time the script runs.  We want this to be realistic looking and enticing to attackers.  This is the part that should be customized to your own environment to match your naming conventions.  In this example, I’m going to use a naming convention that will look like a service account and start with “svc” and then have 5 digits.

Using this PowerShell code I can generate a unique name each time the script runs.

#Create random account name to look like a service account
$StringBuilder = New-Object System.Text.StringBuilder
$suffix = Get-Random -Minimum 10000 -Maximum 99999
$accountName = "svc" + $suffix

I’m also going to create a random, secure looking password by hashing the computer name on which this is run:

#Create random secure password based on SHA hash of computer name
$computer = $env:computername
$StringBuilder = New-Object System.Text.StringBuilder 
[System.Security.Cryptography.HashAlgorithm]::Create("SHA256").ComputeHash([System.Text.Encoding]::UTF8.GetBytes($computer))|
%{ 
    [Void]$StringBuilder.Append($_.ToString("x2")) 
}
$password = $StringBuilder.ToString().substring(1, 14)

Now we have a unique username and password for each computer we will push this out to. We will just need to dynamically grab the domain and then we can register the HoneyHash.

#Assign domain
$domain = (Get-WmiObject Win32_ComputerSystem).Domain
        
#Create Honeyhash honeypot
New-HoneyHash -Domain $domain   -Username $accountName -Password $password  

Next, we need to log this information somewhere so we can keep track of all of these HoneyHashes and what computers they are associated with.

Logging the HoneyHash

What better place to log this information than the event log!  Each time the computer starts up it will generate a new HoneyHash and create a random username and unique password.  We need a way to monitor that this is happening so we know exactly what hash exists on each computer.

To do that we are going to log this information to the event log by adding some additional code to our script.  This will register a new event source called HoneyHash and put all of the information about our newly created HoneyHash in the log.

#Create new Event Source for this if it doesnt already exist
$Sources = (Get-ChildItem HKLM:SYSTEMCurrentControlSetServicesEventLogApplication).pschildname
if ($Sources -notcontains "Honeyhash")
   { 
    New-EventLog –LogName Application –Source “Honeyhash”
   }

#Write Event containing variables used in honeyhash
$Message = @"
New honeyhash injected into memory.
Account: $accountName
Domain: $domain
Password: $password
"@
Write-EventLog -LogName Application -Source "Honeyhash" -EntryType Information -EventId 1 -Message $Message 

Now when the computer starts up we get an easy to read log message about the active HoneyHash. This tells us what computer the hash is on and what time the hash was implanted in memory.

As a side note in testing I found on some of my more modern/secure systems the HoneyHash would not persist in memory using the New-HoneyHash script unless I removed the code responsible for killing the command prompt process that is launched.  That code can be found here:

   if ($ProcInfo.dwProcessId) {
        # Kill the cmd.exe process
        Stop-Process -Id $ProcInfo.dwProcessId
    }  

Correlating this Together

Now our system is live, all we need to do is build out our alerts.  The basic approach is:

• Collect all HoneyHash logs
• Collect all failed authentication logs (Event ID 4625)
• Look for where AccountName in Event ID 4625 is equal to Account value in the HoneyHash log. Somebody stole your credentials and is passing-the-hash!

There are several ways to do this using SIEM and native Windows capabilities that are beyond the scope of this post to go into.  However, I will be going into this more in an upcoming webinar where I will cover this topic and a live demonstration of it in action!

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*