In our first post of this series, we explored the Honeyhash, and how it can be used to create a honeypot to catch attackers performing credential theft and pass-the-hash attacks.  Now that our trap is set, we need to make sure we can catch any attacker in the act who may fall for it.

The concept of detection for the Honeyhash is simple.  We put a fake account in memory on a system, so let’s see if anybody tries to use it.  If they do, we know they used credential theft techniques to get to it and we can react appropriately.

But let’s take a closer look at what we really need to know to catch somebody in the act and respond.

Detecting the Use of a Honeyhash

The first detection that you must put in place is identifying when an attacker attempts to use the stolen credentials.  This is pretty straightforward.  Whether the attacker is performing a Pass-the-Hash or attempting an interactive login, it will result in a failed authentication.

Let’s say we’ve created a Honeyhash in memory for a user AD.Admin with the following command:

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

If an attacker retrieves that and attempts to use those credentials with a Pass-the-Hash attack using Mimikatz:

sekurlsa::pth /domain:Gobias.local /user:Ad.Admin /ntlm:d8ea22150c93f450cc9e15495e4cb2b3

This will result in a failed authentication event 4625 on our domain controllers.  This event will contain the name of our Honeyhash account, so it is pretty easy to tie this to the honeypot we set up.

This will also contain the source computer so now we know where the attacker attempted to use this account from:

So now we know for sure that an attacker has fallen for our honeypot and we know where the attempt came from.

Looking for Recon Activity for the Honeyhash

Perhaps the attacker was smart enough to not attempt using our account and decided to first do some basic investigation through LDAP reconnaissance.  The attacker could perform some basic recon to see what groups a user is a member of using a simple command such as:

([ADSISearcher]"(samaccountname=AD.Admin)").FindOne().GetDirectoryEntry().memberOf

For the Honeyhash account, they would quickly see it’s not a real account:

This would force the attacker to back off before actually using the account in a Pass-the-Hash.

Unfortunately, there is no easy way to detect this activity natively with Microsoft, and approaches such as network monitoring can be pretty expensive for a simple task like this.  Fortunately, we have a product that does this here at STEALTHbits.  While I don’t normally pitch products in these posts, I think this is a very powerful detection to put in place and very easy to do using StealthINTERCEPT.  All I had to do is build a LDAP policy to look for my Honeyhash account and I can see all inbound queries against that account.

Here is my policy:

You can see the above LDAP recon can now be easily detected against my Honeyhash account.  We know who issued the query, when, and from where.  Now we have caught the attacker without them even having used the account in a lateral movement.

Collecting Additional Forensics with Sysmon

Knowing that an attacker stole our honeypot credentials is great, but to effectively respond to the attack we need to know more.  We may want to know what tool was used by the attacker to retrieve the credentials from LSASS memory.  We also may want to emphatically know which account they had compromised to perform the credential theft.  Sysmon is a perfect solution for gathering these additional details.

By installing Sysmon on the systems where I have deployed my honeypot, I can monitor for additional useful information such as when a process accesses the LSASS memory.  You can build custom configuration files to tell Sysmon what to look for.  For my purposes I put together the following file that will focus on two things:

• Detection of hacking tools that read the memory contents of processes like Local Security Authority (Lsass.exe)
• Detection of process creation for PowerShell and Mimikatz so I can tie the hacking tool usage to an individual actor

Here is the configuration file:

<Sysmon schemaversion="4.10">
<!-- Capture all hashes -->
<HashAlgorithms>*</HashAlgorithms>
<EventFiltering>
<!-- Event ID 1 == Process Creation. -->
<ProcessCreate onmatch="include">
<Image condition="end with">powershell.exe</Image>
<Image condition="end with">mimikatz.exe</Image>
</ProcessCreate>
<!-- Event ID 5 == ProcessTerminate. -->
<ProcessTerminate onmatch="include"/>
<!-- Event ID 10 == ProcessAccess. -->
<ProcessAccess onmatch="include">
<TargetImage condition="is">C:Windowssystem32lsass.exe</TargetImage>
</ProcessAccess>
<ProcessAccess onmatch="exclude">
<TargetImage condition="is">C:Windowssystem32svchost.exe</TargetImage>
</ProcessAccess>
<!-- Event ID 11 == FileCreate. -->
<FileCreate onmatch="include"/>
<!-- Event ID 12,13,14 == RegObject added/deleted, RegValue Set, RegObject Renamed. -->
<RegistryEvent onmatch="include"/>
<!-- Event ID 15 == FileStream Created. -->
<FileCreateStreamHash onmatch="include"/>
<!-- Event ID 17 == PipeEvent. -->
<PipeEvent onmatch="include"/>
</EventFiltering>
</Sysmon>

Then all you need to do is import that configuration file into Sysmon for the monitoring to kick in.

.Sysmon64.exe -c .sysmon_config.xml

Once that is enabled you will see events show up in your Windows Event Log (Applications and Services Logs/Microsoft/Windows/Sysmon/Operational).

Here is Event ID 10 indicating a tool accessed LSASS memory.  In this case, this was done using sekurlsa::logonpasswords within Mimikatz. You can see the SourceImage contains the application which initiated the LSASS access, but you do not see the user who launched the process.

To tie this to a user account, we will look at Event ID 1 which identifies the creation of a new process and who launched it.  Now I know that the Michael.Bluth account is the compromised account who performed the credential extraction.

So now we have lots of powerful ways to monitor our honeypot and perform forensic investigation into the attack if we do identify an attacker attempting to harvest and use our Honeyhash credentials.

In our next post, we will explore how this can be effectively rolled out to a production environment. View the next post in the series by clicking 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*