Sean Ennis

Mimikatz Credential Theft Detection in NetWitness Suite [Logs/Endpoint]

Blog Post created by Sean Ennis Employee on Oct 30, 2017

Mimikatz is an open source research project with it's first commit back in 2014 via @gentilkiwi, that is now used extensively by pen testers and adversaries alike for various post-exploitation activities.  One of many write-ups on Mimikatz can be found here.

 

The intention of this post is to show how you might instrument your NetWitness environment to detect attempts to use Mimikatz for credential theft which is arguably it's most common application.  Designed to be as generic as possible to account for re-compilations, the primary detection mechanism focused on fingerprinting loaded dlls is based on some great research done by @Wardog, detailed here.

 

Here are the detection opportunities discussed in this post:

 

This post focuses primarily on the log-based detection via an ESA rule.  The choice to feed sysmon logs into NW is predicated by the requirement to gather ImageLoaded events every time a DLL is loaded by a process.   

 

 

Getting Sysmon logs into NetWitness

The general process for enabling sysmon capture is fairly straight forward and detailed by Eric Partington in his post: Log - Sysmon 6 Windows Event Collection. The key events we care about for this scenario are Sysmon EventID 1 (process creation) and Sysmon EventID 7 (ImageLoaded).  

 

 

Two recommendations:

  1. Although not required for detection, for stronger analysis, you may consider adjusting table-map-custom.xml on your log decoder to add the parent.process meta key and toggle parent.pid from "Transient" to "None" to gain visibility into these values.  Sample addition to table-map-custom.xml (more details on this process here)

    <mapping envisionName="parent_pid" nwName="parent.pid" flags="None" format="Int32"/>
    <mapping envisionName="parent_process_val" nwName="parent.process" flags="None"/>


  2. Sysmon can get very, very noisy if not properly filtered.  This part is up to you (and the capacity of your system) but I started with this sysmon config template: sysmon-config/sysmonconfig-export.xml at master · SwiftOnSecurity/sysmon-config · GitHub  and modified the EventID 7 config within the template shown below - only including ImageLoaded events necessary for the detection logic:

    <!--SYSMON EVENT ID 7 : DLL (IMAGE) LOADED BY PROCESS-->
    <!--DATA: UtcTime, ProcessGuid, ProcessId, Image, ImageLoaded, Hashes, Signed, Signature, SignatureStatus-->
    <ImageLoad onmatch="include">
    <ImageLoaded condition="contains">cryptdll.dll</ImageLoaded>
    <ImageLoaded condition="contains">hid.dll</ImageLoaded>
    <ImageLoaded condition="contains">winscard.dll</ImageLoaded>
    <ImageLoaded condition="contains">logoncli.dll</ImageLoaded>
    <ImageLoaded condition="contains">netapi32.dll</ImageLoaded>
    <ImageLoaded condition="contains">samlib.dll</ImageLoaded>
    <ImageLoaded condition="contains">vaultcli.dll</ImageLoaded>
    <ImageLoaded condition="contains">wintrust.dll</ImageLoaded>
    </ImageLoad>

* full sample template attached to the bottom of this post.

 

Important note:  When setting up sysmon on your source endpoints, to enable capturing of ImageLoaded events you will need to add "-l" to the  installation or run time command line.

 

 

NW Log Config - ESA Rule

The logic of this ESA rule is pretty straight forward but is implemented as an Advanced EPL rule - look for any process loading the set of "fingerprint" dlls indicative of Mimikatz and alert.  The rule is attached to this post, and instructions on how to import it are located here: Alerting: Import or Export Rules. Two separate formats have been attached - one in native/exported format that can be directly imported as per the instructions, the other as a text file for you to modify/copy/paste into a new Advanced EPL ESA rule if you prefer to do it that way.

 

Note:  This rule was tested in a lab environment, so please feel free to test and provide feedback on performance and false/true positive rates.  You'll notice a second ESA rule suffixed with "(aggressive)" that may catch more implementations of mimikatz but might be prone to false positives.  I wasn't able to get either to falsely trip in my lab, but your mileage may vary.

 

 

NW Endpoint Config - IIOCs

No additional config is required if you see the following InstantIOCs in your system already:

 

If we combine endpoint & log visibility for this use case, we get increased fidelity overall due to a combination of approaches to corroborate.  NWE automatically looks for various behavioral indicators involving lsass.exe for credential theft which is a great compliment to the DLL fingerprinting approach.   For an attacker, subverting either behavior individually will be easier than subverting both.   While not covered in this post, it's certainly possible to create a new alert for the NWE IIOC detection by itself OR add them to the conditions of the DLL fingerprinting ESA rule to increase fidelity.  If your NWE IIOCs are configured to send a syslog event for every match, the output when triggered looks as follows (sample CEF logs attached):

 

 

 

Results

The ESA rule triggered successfully after running mimikatz in a number of ways, including as a native binary, PowerShell Mafia via PS command line & interactive shell, PowerShell Empire via native powershell and injected process, Crackmapexec, and Metasploit.  I'd love some feedback from anyone willing to test alternate methods. 

 

ESA alert rolled up into an incident:

 

 

Incident details:

 

If you have NetWitness Endpoint, you can pivot into it to gain deeper context.  In the tracking data below, bottom up shows initial compromise (this example happened to be a simple PowerShell Empire stager), subsequent activity, and interaction with lsass.exe triggering a Level 1 IOC:

 

It should also be noted that as of NW 11.0 and NW Endpoint 4.4, an integration exists to bring the same NW Endpoint tracking data directly into the broader NW platform as log events.  As this integration matures, you can undoubtedly expect a closer tie between related log & endpoint behavior.

 

 

____________________________________________________________________

Sample Data

I've attached a set of sample logs that should trigger the rule if replayed into a log decoder.  These logs contain the suspect event as well as some benign logs from the same endpoint.  An easy way to replay these is by using the NWLogPlayer utility (How To Replay Logs in RSA NetWitness - note, if using version 11.0 the package name has changed and can be installed with yum install rsa-nw-logplayer).

The second attached log set shows 2 sample CEF syslog alerts sent directly from NW Endpoint when the discussed IIOCs trigger.

____________________________________________________________________

Outcomes