by Bhabesh Raj Rai, Security Research

Sysmon (System Monitor) is one of the popular tools from Sysinternals for monitoring and logging system activity to the Windows event logs.

Of course, you can say Windows already has its native event logs, so why bother? And, we already have an endpoint detection and response (EDR) solution installed on our systems, so isn’t that enough?

In this blog, I’ll explain why Sysmon is important for situational awareness and I’ll walk through how Sysmon can detect the ultra-stealthy HandleKatz credential dumper.

Why use Sysmon?

Sysmon complements native Windows event logs by providing detailed information about process creations, network connections, registry tampering and more. Windows already logs these events, but it comes with its own caveats. For example, process creation (EID 4688) logs don’t have hash information. Logging network connections is another challenge because of log flooding due to system noise and even Microsoft recommends only enabling logging network connections during troubleshooting.

Sysmon process creation events

Sysmon process creation events

Sysmon benefits security teams in three key ways.

1. Sysmon makes it easy to precisely configure what events to generate by providing more detailed and useful information. For example, analysts can configure Sysmon to log network connections by only specific processes or to log every connection except by specific processes.


Sysmon network connection events

2. Perhaps most importantly, Sysmon fills the visibility gap created by the native Windows event log’s inability to log important events needed for detection and threat hunting, such as processes loading DLLs or processes opening other processes.

3. Through sysmon, administrators get control over their telemetry, which is not the case with EDRs. With EDR, it’s very difficult to uncover a visibility gap because EDR vendors have total control over the telemetry collected by their agents.

Now that we know the benefits of using Sysmon, let’s take a look how we can use it detect HandleKatz.

How to detect HandleKatz credential dumper

In Brucon2021, Ben Heimerdinger and Sebastian Feldmann from Code White showcased the HandleKatz tool that used cloned handles to the lsass process in order to create its obfuscated memory dump. The obfuscated memory dump can be later deobfuscated to obtain the dumped credentials from lsass.

At the time of the release of this blog, both Defender AV and Microsoft Defender for Endpoint (MDE) EDR do not detect this tool or this technique.

The working of HandleKatz is explained below:

  • Find a benign process that already has a handle to the lsass process
  • Clone the existing handle using NtDuplicateObject
  • Use modified MiniDumpWriteDump and EnumerateLoadedModules functions from ReactOS codebase to dump the process without opening any new handles to LSASS
  • Use that handle to dump the memory

Lsass usually has a handle to itself so we can point HandleKatz directly to lsass. But here’s the fun part. HandleKatz does not require suspicious access rights such as PROCESS_VM_READ, so the process looks benign to defenders and monitoring tools alike.

I used Cygwin to compile the source. The writers of HandleKatz have also provided a loader for ease. So, I just need to drop the loader and cygwin1.dll (required by the loader).

HandleKatz dumping lsass memory
HandleKatz dumping lsass memory

My first intuition is to look for processes loading samlib.dll and cygwin1.dll. The former is the Security Authority Manager (SAM) API library that credential dumpers like mimikatz require for functioning.

We can see the loader process loading both the DLLs in Sysmon’s image load events (EID 7).

norm_id=WindowsSysmon event_id=7 image IN ["*\samlib.dll", "*\cygwin1.dll"] 
-source_image IN ["C:\Windows\explorer.exe", "C:\Windows\System32\*", "C:\Program Files*"]
| chart count() by host, user, source_image, image

HandleKatz loader loading samlib and cygwin1 DLLs
HandleKatz loader loading samlib and cygwin1 DLLs

Next, let’s see processes accessing the lsass process that stores all the credentials. Note, this can be very noisy depending upon what tools are running in the system.

norm_id=WindowsSysmon event_id=10 image="*\lsass.exe"
| chart count() by host, user, source_image, image, access

HandleKatz loader accessing lsass
HandleKatz loader accessing lsass

We can see the osquery daemon and the loader process accessing lsass. We can immediately notice how the loader opened the lsass process with a 0x1440 access mask. This is a low privilege access mask that provides only PROCESS_DUP_HANDLE, PROCESS_QUERY_LIMITED_INFORMATION, and PROCESS_QUERY_INFORMATION permissions.

The important PROCESS_VM_READ permission is missing. For context, mimikatz opens lsass using a0x1010 access mask that has PROCESS_QUERY_LIMITED_INFORMATION and PROCESS_VM_READ permissions.

The absence of PROCESS_VM_READ may be the reason behind HandleKatz staying under the radar of Defender AV and MDE.

One more subtle observation is that I executed the loader as admin, but the above process access events show that the user is SYSTEM. This is because the lsass process is running as SYSTEM and upon the loader duplicating the lsass’s handle got “elevated” to SYSTEM.

[norm_id=WindowsSysmon event_id=1 -user=SYSTEM -user=*$] as eid_1 
followed by 
[norm_id=WindowsSysmon event_id=10 image="*\lsass.exe"] as eid_10 
within 5 minute on eid_1.host=eid_10.host 
and eid_1.process_guid=eid_10.source_process_guid 
| rename eid_1.host as host 
| chart count() by host, eid_1.user, eid_10.user, eid_1.image,eid_1.command, 
eid_10.image, eid_10.access

Notice the different users in process creation and process access events of the same loader process
Notice the different users in process creation and process
access events of the same loader process

How administrators can deploy Sysmon

Admins should first create a separate small lab that mirrors the production environment to test the Sysmon configuration. Every environment is different and administrators need to tune their configuration to only generate logs of interest and, most importantly, to prevent log flooding.

Logpoint customers can use our baseline sysmon configuration as a starting point to begin tuning Sysmon for their environment. Alternatively, customers can use other publicly available baseline configurations such as SwiftOnSecurity’s configuration and Florian Roth’s configuration. If you have EDR installed in your environment, administrators need to safelist the EDR agent to reduce noise.

Administrators also need to make an allowlist of configurations so as to detect adversaries’ tamperings with Sysmon.

Logpoint supports both Sysmon and its newer Linux counterpart Sysmon for Linux and provides several analytics based on Sysmon in the Alert Rules application.

Augment your Windows and EDR telemetry with Sysmon

Contact Logpoint

Contact us and learn why
industry-leading companies
choose Logpoint: