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

This is the second blog post in a four-part series. Read Part 1 | Part 3 | Part 4. 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, CrowdStrike's 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\”, where represents the ID of the disk. The driver will then allow the user to operate on the “\Device\Harddisk\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.

How the Falcon Platform Offers Continuous Monitoring and Visibility

The CrowdStrike Falcon®® platform takes a layered approach to protecting workloads, harnessing over a trillion data points analyzed daily in the CrowdStrike Security Cloud. Combining on-sensor and cloud-based machine learning, industry-leading behavioral analysis to fuel indicators of attack (IOAs) (including recently announced AI-powered IOAs), and advanced threat intelligence the Falcon platform provides users with holistic attack surface visibility, unparalleled threat detection and continuous monitoring for any environment, reducing the time to detect and mitigate threats.
Figure 12. Falcon UI screenshot showcasing detection of DriveSlayer by the Falcon sensor. (Click to enlarge)
Figure 13. Falcon UI screenshot showcasing detection of Shamoon by the Falcon sensor. (Click to enlarge)

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

Wiper nameSHA256 hash value
Apostle6fb07a9855edc862e59145aed973de9d459a6f45f17a8e779b95d4c55502dcce 19dbed996b1a814658bef433bad62b03e5c59c2bf2351b793d1a5d4a5216d27e
CaddyWipera294620543334a721a2ae8eaaf9680a0786f4b9a216d75b55cfd28f39e9430ea
Destovere2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a
DoubleZero3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe 30b3cbe8817ed75d8221059e4be35d5624bd6b5dc921d4991a7adc4c3eb5de4a
DriveSlayer0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21da 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591 a259e9b0acf375a8bef8dbc27a8a1996ee02a56889cba07ef58c49185ab033ec
Dustmanf07b0c79a8c88a5760847226af277cf34ab5508394a58820db4db5a8d0340fc7
IsaacWiper13037b749aa4b1eda538fda26d6ac41c8f7b1d02d83f47b0d187dd645154e033 7bcd4ec18fc4a56db30e0aaebd44e2988f98f7b5d8c14f6689f650b4f11e16c0
IsraBye5a209e40e0659b40d3d20899c00757fa33dc00ddcac38a3c8df004ab9051de0d
KillDisk8a81a1d0fae933862b51f63064069aa5af3854763f5edc29c997964de5e284e5 1a09b182c63207aa6988b064ec0ee811c173724c33cf6dfe36437427a5c23446
Meteor and Comet/Stardust2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b d71cc6337efb5cbbb400d57c8fdeb48d7af12a292fa87a55e8705d18b09f516e 6709d332fbd5cde1d8e5b0373b6ff70c85fee73bd911ab3f1232bb5db9242dd4 9b0f724459637cec5e9576c8332bca16abda6ac3fbbde6f7956bc3a97a423473
Ordinypt​​085256b114079911b64f5826165f85a28a2a4ddc2ce0d935fa8545651ce5ab09
Petya0f732bc1ed57a052fecd19ad98428eb8cc42e6a53af86d465b004994342a2366 fd67136d8138fb71c8e9677f75e8b02f6734d72f66b065fc609ae2b3180a1cbf 4c1dc737915d76b7ce579abddaba74ead6fdb5b519a1ea45308b8c49b950655c
Shamoone2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a c7fc1f9c2bed748b50a599ee2fa609eb7c9ddaeb9cd16633ba0d10cf66891d8a 7dad0b3b3b7dd72490d3f56f0a0b1403844bb05ce2499ef98a28684fbccc07b4 8e9681d9dbfb4c564c44e3315c8efb7f7d6919aa28fcf967750a03875e216c79 f9d94c5de86aa170384f1e2e71d95ec373536899cb7985633d3ecfdb67af0f72 4f02a9fcd2deb3936ede8ff009bd08662bdb1f365c0f4a78b3757a98c2f40400
SQLShred/Agrius18c92f23b646eb85d67a890296000212091f930b1fe9e92033f123be3581a90f e37bfad12d44a247ac99fdf30f5ac40a0448a097e36f3dbba532688b5678ad13
StoneDrill62aabce7a5741a9270cddac49cd1d715305c1d0505e620bbeaec6ff9b6fd0260 2bab3716a1f19879ca2e6d98c518debb107e0ed8e1534241f7769193807aac83 bf79622491dc5d572b4cfb7feced055120138df94ffd2b48ca629bb0a77514cc
Tokyo Olympic wiperfb80dab592c5b2a1dcaaf69981c6d4ee7dbf6c1f25247e2ab648d4d0dc115a97 c58940e47f74769b425de431fd74357c8de0cf9f979d82d37cdcf42fcaaeac32
WhisperGatea196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92 44ffe353e01d6b894dc7ebe686791aa87fc9c7fd88535acc274f61c2cf74f5b8 dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78
ZeroClearebecb74a8a71a324c78625aa589e77631633d0f15af1473dfe34eca06e7ec6b86

Additional Resources

Breaches Stop Here