We’re migrating product documentation to docs.vmware.com, starting with Carbon Black Cloud. Learn more.

Mimikatz Rapid Config

Mimikatz Rapid Config

What is Mimikatz

Mimikatz started life as a GitHub project by Benjamin Delpy to illustrate flaws within the Windows Authentication subsystem. It is a tool that can extract plain text passwords, NTLM hashes, Kerberos Ticket Granting Tickets (TGT), and more from memory.

Malicious actors have leveraged this technology to infiltrate environments and move laterally across systems using legitimate credentials...undetected. 

How can Cb Protection help?

An endpoint in default deny mode (or what we like to call High Enforcement) will be protected from a binary-based Mimikatz attack because the process used to launch the attack will not be approved and therefore blocked. 

Cb Protection can protect endpoints in other enforcement levels against binary and memory based attacks with the use of the Mimikatz Protection Rapid Config. 

Rapid Config Details

The Mimikatz Protection Rapid Config has three sections that look for different indicators of compromise.

The first section allows you to Report or Block on the detection of a combination of DLLs loading. This particular combination (samlib.dll, cryptdll.dll, and vaultcli.dll) is a good indication of a Mimikatz process as these are not typically loaded at the same time by other processes.

 mimikat 1.png

 

As with all Rapid Configs we recommend setting each section to Report prior to setting to Block. You will want to ensure that the legitimate behavior of these dlls will not be impacted.

The second section of the Rapid Config looks for specific command lines. It will look for:

  • *sekurlsa* anywhere within the command line. Sekurlsa is a Mimikatz module that extracts passwords, keys, etc from the memory of lsass.
  • *privilege*debug* in the command line argument. The combination of “privilege” and “debug” within a command line argument is typically used by Mimikatz to get access rights.

mimikat 2.png

*These command line arguments can be changed by a malicious actor, we believe the default arguments will help catch low hanging fruit.

  

The final section of the Rapid Config centers on the reading of Lsass.exe memory. 

mimikat 3.png

Most processes should not be reading from lsass memory, however there are executables that legitimately need to do this. Out of the box we’ve included processes like ntoskrnl.exe, msiexec.exe, svchost.exe, and others that should be allowed to read the memory. 

It is crucial to initially set this section to Report so that you can find that approved applications in your environment that legitimately need to read the lsass process memory. After letting the Rapid Config run in Report mode for a few weeks, add any approved processes that access lsass memory to the exception list.

 

 

Labels (1)
Tags (1)
Comments

What's the best way to see a report of all events blocked by a Rapid Config?

I struggled to find these events also due to the volume of events kept timing out my event search.  FInally since I have this rapid config set to report I setup a filter to Subtype= Report Execution (custom Rule) & Subtype=Report Execution (Memory Rule) and then I grouped by Rule Name.

Shouldn't the following be added as part of the default rapid config?

Exception Processes Allowed To Read Lsass.Exe Memory:

<system>\explorer.exe

<system>\logonui.exe

Use the Rule Name column and build a view similar to the one here.

https://community.carbonblack.com/t5/CB-Protection-Discussion/CB-Protect-8-0-Rapid-Configs-question/...

 

 

 

@jkirkland Thank you, that looks like what I needed!

Is this rapid config only available in 8.1?

Seeing cryptdll.dll, hid.dll, winscard.dll, samlib.dll, vaultcli.dll executions coming from setupprep.exe (Win 10 setup file), which is triggering this Rapid config quite a bit.  Anyone else seeing similar?

This is a good rapid config.... but wow is it noisy. I exempted about 25 additional processes and still getting reports. It seems like so many program scrape from lsass.exe.

 

apache, AV agents, drivers, print servers, VMware... it's insane.

Rocky I am seeing those same dlls. The process is mostly explorer.exe, svchost.exe, and logonui.exe. About 1k per hour.

Rocky_haley and i_smith, I can confirm the same. Extremely voluminous in report-only mode. I do wonder what REALLY needs this access vs what is safe to silently block. Currently trying to figure out the best way to proceed as I'm struggling to replicate production traffic in the test policy. May just have to move a few production boxes here to see what actually blows up.

Hi, I am looking for a way to be kept up to date about the level of protection this gives you. As this is a cat&mouse game, how to know your configured Mimikatz rapid config rule is still providing protection? In other words how to ensure you will be notified when Mimikatz behavior and it's nature changes which may result in CB not being able anymore to discover and block the attack?  

Thx.

Article Information
Author:
Creation Date:
‎01-11-2019
Views:
2624
Contributors