The Anatomy of Wiper Malware, Part 2: Third-Party Drivers

Originally published by CrowdStrike here.

Written by Ioan Iacob and Iulian Madalin Ionita, CrowdStrike.

In Part 1 of this four-part blog series examining wiper malware, we introduced the topic of wipers, reviewed their recent history and presented common adversary techniques that leverage wipers to destroy system data.

In Part 2, an Endpoint Protection Content Research Team discusses how threat actors have used legitimate third-party drivers to bypass the visibility and detection capabilities of security mechanisms and solutions.

Third-Party Drivers

For a wiper developer, there are several good reasons to switch operations into kernel space. When it comes to overwriting disks, user mode has certain limitations and is intensely monitored by AV/XDR vendors through hooking various APIs and blocking select actions. With the release of Windows Vista, Microsoft began restricting access to raw disk sectors from user mode. To bypass this, wiper developers began to drive their attack through the kernel space.

Threat actors may attempt to write their own kernel drivers, but this approach is difficult for a number of reasons. One is related to the lack of segregation between processes or drivers in Kernel space; anything can write to anywhere with no restriction. With no room for error, the machine may easily destabilize and crash. Another is that modern Windows 64-bit requires drivers to be signed by Microsoft.

Rather than writing their own kernel drivers, malware authors often resort to using drivers developed by third-party entities in order to achieve their goals. Some notable examples of wiper families that use third-party drivers include Destover, DriveSlayer, Shamoon, Dustman and ZeroCleare. Most of these leverage different versions of the ElRawDisk driver developed by Eldos, with the exception being DriveSlayer, who uses a driver developed by EaseUs.

ElRawDisk Driver

The ElRawDisk device driver, developed by Eldos (now part of Callback Technologies), is used by several wiper families such as Destover, ZeroCleare, Dustman and Shamoon. The driver is used as a proxy to transfer actions from user mode into kernel mode and ensures that all disk operations are done on behalf of the driver, not the wiper process. This technique removes any limitations user mode processes might encounter when writing files or interacting with the disk directly. Since this is a third-party driver, the malware must implement a way to install it on the infected machine. Usually this is achieved by dropping the driver to disk and loading it via the Service Control Manager APIs, or the sc.exe tool. Legitimate drivers are also seen as “clean” by security vendors and it would not be blocked when they are installed.

ZeroCleare and Dustman use an unsigned version of ElRawDisk driver that is loaded using Turla Driver Loader (TDL). TDL installs a signed and vulnerable VBoxDrv driver. This driver is exploited to mimic the functionality of a driver loader and the unsigned ElRawDisk driver is mapped in kernel mode without having to patch Windows Driver Signature Enforcement (DSE).

After loading the driver, the wipers must grab a handle to it via CreateFile and provide a key in order to authenticate to the driver. The key is appended to the device name, and parsed out by the driver. If no valid key is supplied, the return value will be INVALID_HANDLE_VALUE. While this seems like a good idea to limit unauthorized access to the driver, in reality threat actors can reverse engineer the legitimate applications that use the ElRawDisk drivers and extract a copy of the key. Then they use that key to impersonate the legitimate tool and achieve their goals. Analyzed wipers use different keys for the ElRawDisk driver.

Figure 1. Open handle to ElRawDisk device with the serial key appended to the device name

Shamoon retrieves information about the location of the file on the raw disk by sending the FSCTL_GET_RETRIEVAL_POINTERS control code to the ElRawDisk device via the DeviceIoControl API. This information is later used to determine the raw sectors of the file that needs to be wiped.

Figure 2. Send FSCTL_GET_RETRIEVAL_POINTERS via DeviceIoControl API

Shamoon attempts to wipe the entire disk, not only the files. In order to do so, it requests partitioning information by sending the IOCTL_DISK_GET_PARTITION_INFO_EX IOCTL to the ElRawDisk driver. The partitioning information helps the wiper to determine what sectors to overwrite. To accomplish this, the wiper opens a handle to a specific partition via CreateFile and overwrites the sectors using WriteFile and SetFilePointer APIs. Shamoon writes a JPEG image to the sectors, rendering the operating system unstable and may crash at any point in time.

Figure 3. Send IOCTL_DISK_GET_PARTITION_INFO_EX via DeviceIoControl API

The code trace from Figure 4 exemplifies how wipers overwrite raw disk clusters by proxying activity via the ElRawDisk device.

Figure 4. API trace view demonstrating how the EPMNTDRV is used to wipe the disk

ZeroCleare and Dustman use the driver a bit differently than Shamoon. Once the ElRawDisk driver is loaded using TDL and a handle to the driver is obtained, it calls DeviceIoControl using one of two different IOCTLs (0x22BF84 or 0x227F80), depending on the Windows version. This call is capable of overwriting the contents of the physical drive with a message (as in Dustman wiper), or a buffer with the same byte value (as in ZeroCleare wiper).

The following figure is used in both ZeroCleare and Dustman wipers. The customdata buffer contains the data that is used to overwrite the contents of the physical drive.

Figure 5. How ZeroCleare and Dustman use the ElRawDisk to overwrite the disk with a custom buffer

As seen in the ElRawDisk driver version used by Dustman and ZeroCleare, both these two IO control codes translate to the same function call. The following snippet cannot be found in the driver used by Shamoon because it's an older version.

Figure 6. Examples of two custom IOCTL codes from the ElRawDisk driver

EPMNTDRV Driver

EPMNTDRV is another example of a driver developed by a legitimate entity being used for malicious purposes by threat actors. This driver is developed by EaseUs for their partition manager utility. Back in March of 2022, the DriveSlayer wiper used this driver against Ukraine. It was kept inside a LZA compressed resource and loaded via the Windows Service Control Manager APIs after it was written to disk by the malware. In the following figure, we can observe the main function of the EPMNTDRV driver. It creates the device and a symbolic link followed by initialization of the DRIVER_OBJECT structure with the necessary dispatch routines.

Figure 7. Main function of the EPMNTDRV initiating various dispatch routines

Similarly to the previous driver, it allows any user-mode process to interact with the disk by proxying actions through itself. Interaction is achieved via dispatch routines like IRP_MJ_CREATE, IRP_MJ_WRITE as well as IRP_MJ_DEVICE_CONTROL. To interact with the driver, the process needs to open a handle to the device via CreateFile and provide a path like “\\.\EPMNTDRV\[value]”, where [value] represents the ID of the disk. The driver will then allow the user to operate on the “\Device\Harddisk[value]\Partition0” device through it.

Figure 8. Pseudocode view of the IRP_MJ_CREATE dispatch routine from EPMNTDRV driver, showcasing how it opens a handle to the local disk (\Device\Harddisk%u\Partition0)

In the IRP_MJ_CREATE routine of the driver, a pointer to the “\Device\Harddisk%u\Partition0” is obtained via IoGetDeviceObjectPointer and IoGetAttachedDeviceReference APIs and stored in a global variable to be later used in the other dispatch routines.

Figure 9. Pseudocode view of the IRP_MJ_WRITE dispatch routine from EPMNTDRV driver, showcasing how an IRP request is created and sent to the driver handling the HardDisk device.

The IRP_MJ_WRITE handles the write requests coming from the user mode process.and forwards them to the driver handling the disk operations. In order to achieve this, the driver makes use of the IoBuildAsynchronousFsdRequest API to construct an IRP request and sends it to the driver via the IofCallDriver API.

Figure 10. Pseudocode view of the IRP_MJ_DEVICE_CONTROL dispatch routine from EPMNTDRV driver, showcasing how IO control codes are forwarded to the HDD device driver

The the user mode process send a IOCTL to the EPMNTDRV device, the dispatch routine handling IRP_MJ_DEVICE_CONTROL requests is called and it forwards the requests to the driver handling disk operations via the IoBuildDeviceIoControlRequest and IofCallDriver APIs.

Figure 11. Pseudocode from DriveSlayer displaying how to data is sent to the third-party driver in order to overwrite the disk

Now that the EPMNTDRV driver is installed, the wiper can grab a handle to it via CreateFile and use standard WriteFile and DeviceIoControl APIs in order to send data to the driver. All requests from user mode are then forwarded to the disk driver. Now, the malware can now wipe the MBR, MFT, and files on behalf of the legitimate driver.

Summary

Multiple wiper families leverage legitimate third-party kernel drivers as proxies for running malicious activities. This provides the wipers with multiple advantages; enabling them to operate in a stealthy manner and bypassing several security products. A kernel implant provides limitless capabilities for the attacker, including easy access to the entire disk, without the operating system getting in the way. Many of the wipers we've analyzed use legitimate drivers to wipe raw disk sectors and, in some instances, protected files. The main weakness of this approach is that wiping raw sectors will destabilize the operating system, making it liable to crash at any moment. Crashing the OS may be in the victim's advantage because this would halt wiping operations and potentially allow the victim to recover some of their data.

In Part 3 of this wiper series, we will discuss additional and less frequently utilized techniques implemented by various wiper families.

Hashes