When the Absence of Noise Becomes Signal: Defensive Considerations for Lazarus FudModule

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the Lazarus sample analyzed by X-Force, as well as highlight a strategy of using telemetry stream health as a mode of detecting malware designed to impair defenses through ETW tampering.

One Ring 0 to rule them all

The Lazarus FudModule begins with the installation of a Dell driver that is vulnerable to CVE-2021-21551 which allows the malware to elevate privileges to a level where DKOM attacks are possible. This type of attack is referred to as a bring your own vulnerable driver (BYOVD) attack. In a BYOVD attack, an attacker installs a driver that is vulnerable to an exploit that enables the attacker to cross the boundary from administrative access to ring 0 or kernel-mode access. Ring 0 access enables the attacker to bypass or disable security technology and evade detection by security professionals by operating deeper within the operating system.

Can’t hit what you can’t see

As detailed in the X-Force blog, after obtaining kernel mode privileges the FudModule begins targeting kernel structures to impair telemetry sources on the host by targeting Event Tracing for Windows (ETW) registration handles. ETW registration handles are used to retrieve configuration information for a specific provider, the handle can test whether a provider is enabled for specific keywords or information levels. Additionally, ETW registration handles are used to call event tracing and logging functions for a specific provider. The FudModule leverages the nt!EtwRegister function to enumerate entries associated with the RegHandle parameter and then updates the value with NULL effectively disabling all system ETW providers for all consuming applications, including those providers used by some antivirus and endpoint detection and response (EDR) solutions.

Dynamic detection opportunity through monitoring ETW data stream health

While the FudModule’s capability to tamper with ETW registration handles does enable it to create and operate within a blind spot for security tooling, this is not the first piece of malware X-Force has encountered that tampers with data streams to avoid detection. To handle these types of detection challenges, X-Force has developed a detection method focused on identification of malicious activity by testing data stream health.

The following section will demonstrate a proof-of-concept ETW data stream monitor like X-Force’s using PowerShell and Symon so organizations can start considering a similar detection capability.

The FudModule’s attack against ETW registration handles may disable ETW monitoring providers, but X-Force was not able to uncover evidence that the malware prevents new ETW registration handles from being created and used. Defenders can leverage this opportunity to register a new ETW session to an existing security-related ETW provider, create test data, and compare the telemetry between the new ETW session and the existing ETW session. Organizations can implement a similar strategy to detect when there is a discrepancy between the telemetry registered in the data source and raise an alarm regarding security-related ETW data stream health when a discrepancy is observed.

When Microsoft deployed PatchGuard in the early 2000s, it limited the ability for security vendors to hook the kernel directly to detect malware executing on a system. Since the introduction of PatchGuard, vendors have leveraged Kernel callback functions to monitor activities on a system. For a comprehensive list of Kernel callback functions here, see the Kernel CallbackFunctions list created by CodeMachine here.

The most common Kernel callback functions leveraged by security vendors are:

PsSetCreateProcessNotifyRoutine
CmRegisterCallbackEx
PsSetCreateThreadNotifyRoutine
ObRegisterCallbacks
PsSetLoadImageNotifyRoutine

For the purposes of this blog, we will be focusing on PsSetCreateProcessNotifyRoutine which is a callback routine to monitor process creation activities performed by APIs like CreateProcess(), CreateProcessAsUser(), CreateProcessWithToken(), and CreateProcessWithLogon().

Security products often leverage PsSetCreateProcessNotifyRoutine as a mechanism to be notified when a user spawns a new process via the CreateProcessW() function in kernel32.dll. With the introduction of kernel-mode drivers for modern security products, they are now able to intercept and inject into resulting process creation events by hooking ntdll.dll to perform inspections of the process activity.

To simulate the resulting blind spots from the FudModule, X-Force will disrupt the data streams enabling Sysmon to monitor process creation events via PsSetCreateProcessNotifyRoutine without stopping the Sysmon ETW Trace Session or removing the ETW Provider.

Sysmon Operating Normally

To simulate the BYOVD attack, X-Force leveraged PsExec to assume privileges of NT AuthoritySYSTEM and modified the Sysmon ETW Trace configuration so that while the System ETW Trace Session is running, no data will be written to the Event Log.

Sysmon After Trace Session Tampering

At this point, the Sysmon service is running, the ETW Trace is running, and the Sysmon ETW provider is available, but no process creation events are being written to the Event Log effectively simulating the behavior of the FudModule for a single ETW data source on an infected system.

As previously stated, the FudModule does not appear to remove providers or continually null value ETW registration handles, so Defenders now have an opportunity to test ETW data stream health and be alerted when security telemetry is not operating as expected either through corruption or malicious activity. Fortunately, Microsoft makes this process easy with a default ETW provider called Microsoft-Windows-Kernel-Process which handles the execution of all threads in a process and directly interacts with the PsSetCreateProcessNotifyRoutine routine.

Within the Microsoft-Windows-Kernel-Process provider, various data sources are available including new process creation, process thread, image loads, and CPU priority. Using the logman utility, defenders can easily create a new ETW Trace Session to collect new process creation events.

Creating a New ETW Trace for Process Creation Events

The following PowerShell is a proof-of-concept replicating the core capabilities of X-Force’s telemetry stream health tests for threat detection. In this script, a new ETW Trace session is created and subscribed to Microsoft-Windows-Kernel-Process WINEVENT_KEYWORD_PROCESS events. The script then creates test data using the current timestamp as a unique identifier and checks whether the test data was located within the newly created ETW Trace session and Sysmon. When the test data is not found in the Sysmon log, an alert is written to the Application Event Log which can be alerted upon for defenders.

ETW Data Health Test Script

Create Alert When Telemetry Health Test Fails

The following sections will detail static detection opportunities for the Lazarus FudModule based on the analysis of the malware sample.

Static detection opportunities within file activity

To initiate the BYOVD attack, the FudModule loads an embedded version of the Dell dbutil_2_3.system driver, which contains an insufficient access control vulnerability (CVE-2021-21551) enabling the malware to escalate privileges. The FudModule extracts the driver files to C:WindowsSystem32drivers under a name randomly chosen from the following list:

circlassmgr.sys
dmvscmgr.sys
hidirmgr.sys
isapnpmgr.sys
mspqmmgr.sys
umpassmgr.sys

X-Force was unable to locate any legitimate driver installations associated with the filenames used by the FudModule so defenders may be able to detect the malicious driver installation through monitoring file activity where the filenames listed above are written to %windr%system32drivers.

Static detection opportunities within event log data

The main functionality of the FudModule is directed towards the Windows kernel space however when first loaded, the malware is operating within user mode meaning it cannot interact with kernel memory directly. To overcome this privilege issue, the FudModule executes the BYOVD attack leveraging the previously mentioned Dell driver. The Dell driver is installed as a kernel mode driver which combined with the CVE-2-1-2155 vulnerability enables the malware to the ability to escalate privileges to allow for writing to kernel memory.

In Microsoft Windows, when a kernel mode driver is installed a System Event Log Event ID 7045 is generated. System event log 7045 entries contain the name of the driver, the full path to the driver file, and the type of driver that was installed (either kernel or user mode). Defenders can detect the installation of the vulnerable driver as part of the FudModule by collecting Windows Event System Log entries where the Service Type is set to “kernel mode driver” and the Service File Name contains one of the following filenames:

circlassmgr.sys
dmvscmgr.sys
hidirmgr.sys
isapnpmgr.sys
mspqmmgr.sys
umpassmgr.sys

Static detection opportunities within setup API log data

The following detection opportunity is not specific to the FudModule. Throughout the research performed by X-Force on malicious use of the Dell DBUtil driver, X-Force identified additional malware and tools that leverage the Dell DBUtil BYOVD attack and identified the following detection point.

When the Dell Client Platform DBUtil driver is installed, the Microsoft Windows Plug and Play Devices module initiates the driver installation process. This process is captured within the SetupAPI log file located in %windir%infsetupapi.dev.log. The SetupAPI log was introduced in Windows Vista and contains information about device and driver installations including the initiating process, driver paths, and troubleshooting data.

Analysis of legitimate and malicious installations of the Dell DBUtil driver indicated that regardless of the implementation, the Device Install in the SetupAPI log will register the device as “ROOTDBUtilDrv2”. Within the SetupAPI log file, defenders may be able to detect malicious installation of the DBUtil driver by collecting and parsing the SetupAPI log file for “ROOTDBUtilDrv2” where the associated command and INF path do not match with the legitimate Dell Driver Install data shown below.