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 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.

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)


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.


Wiper name SHA256 hash value
Apostle 6fb07a9855edc862e59145aed973de9d459a6f45f17a8e779b95d4c55502dcce


CaddyWiper a294620543334a721a2ae8eaaf9680a0786f4b9a216d75b55cfd28f39e9430ea
Destover e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a
DoubleZero 3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe


DriveSlayer 0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21da



Dustman f07b0c79a8c88a5760847226af277cf34ab5508394a58820db4db5a8d0340fc7
IsaacWiper 13037b749aa4b1eda538fda26d6ac41c8f7b1d02d83f47b0d187dd645154e033


IsraBye 5a209e40e0659b40d3d20899c00757fa33dc00ddcac38a3c8df004ab9051de0d
KillDisk 8a81a1d0fae933862b51f63064069aa5af3854763f5edc29c997964de5e284e5


Meteor and Comet/Stardust 2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b




Ordinypt ​​085256b114079911b64f5826165f85a28a2a4ddc2ce0d935fa8545651ce5ab09
Petya 0f732bc1ed57a052fecd19ad98428eb8cc42e6a53af86d465b004994342a2366



Shamoon e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a






SQLShred/Agrius 18c92f23b646eb85d67a890296000212091f930b1fe9e92033f123be3581a90f


StoneDrill 62aabce7a5741a9270cddac49cd1d715305c1d0505e620bbeaec6ff9b6fd0260



Tokyo Olympic wiper fb80dab592c5b2a1dcaaf69981c6d4ee7dbf6c1f25247e2ab648d4d0dc115a97


WhisperGate a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92



ZeroCleare becb74a8a71a324c78625aa589e77631633d0f15af1473dfe34eca06e7ec6b86

Additional Resources

Related Content