The Anatomy of Wiper Malware, Part 4: Less Common “Helper” Techniques

Originally published by CrowdStrike.

Written by Ioan Iacob and Iulian Madalin Ionita, CrowdStrike.

In Part 3, a leading Endpoint Protection Content Research Team covered the finer points of Input/Output Control (IOCTL) usage by various wipers. The fourth and final part of the wiper series covers some of the rarely used “helper” techniques implemented by wipers, which achieve secondary goals or facilitate a smaller portion of the wiping process.

Delete Volume Shadow Copies

During ransomware attacks, many ransomware families will attempt to delete the shadow copies of the Windows OS. Out of all of the analyzed wiper families, only Meteor (with its Stardust/Comet variants) deletes shadow copies by either using Windows Management Instrumentation command-line utility wmic.exe or by calling the native Volume Shadow Copy Service Admin tool vssadmin.exe.

In the case of families that use a third-party driver to wipe the sectors, it does not make sense to delete the VSS because their corresponding sectors will be wiped by the driver, rendering volume shadow copies unusable.

An interesting approach seen in DriveSlayer is that it only disables the VSS service and doesn’t attempt to delete the snapshots. In order to stop the service, the wiper will open a handle to the Service Control Manager via OpenSCManager, grab a handle to the VSS service via OpenService, and make use of ChangeServiceConfig to disable the service and ControlService to stop it.

Figure 1. DriveSlayer disabling VSS service

Fill Empty Space

The IsaacWiper wiper creates a thread that tries to fill the unallocated space of the disk with random data in order to make recovery even more unlikely.

Figure 2. IsaacWiper pseudocode responsible for filling the empty space of the volume

This technique is implemented by first obtaining the amount of space available for a volume, using GetDiskFreeSpaceExW, and then creating a temporary file that grows in size until the disk is filled. The temporary file is filled with random data, written in blocks of size 0x1000.

Boot Configuration

Similar to a ransomware attack, Meteor wiper (with its Stardust/Comet variants) makes the operating system unbootable by changing the boot configuration of the infected machine. This can be done by either corrupting the system’s boot.ini file, or by using a series of bcdedit commands. The first one is used to identify configurations, while the latter is used to delete a specific entry.

Figure 3. Example of the how boot menu entries can be deleted using bcdedit

Active Directory Interaction

In order to keep the network online, the CaddyWiper and DoubleZero wiper families ensure that they do not run on a domain controller. In the code snippet below, the DsRoleGetPrimaryDomainInformation API is used by CaddyWiper to determine if the victim machine is not a primary domain controller.

Figure 4. Determine if the machine is a domain controller via the DsRoleGetPrimaryDomainInformation API

However, Meteor wiper (and its Stardust/Comet variants) implements a different mechanism when interacting with the domain controller. This wiper unjoins the workstation from the domain using either a call to NetUnjoinDomain or using the following wmic command:

Scripts

Some malware authors choose not to implement an actual wiper module and instead use the default OS functionalities, accessible via a BAT file. For example, Apostle is dropping and executing the following script:

This script tries to recursively delete the files in system drive, then instructs Windows to process idle tasks, and finally issuing a self-delete command.

The Olympic wiper is one of the simplest samples we analyzed. It only used batch commands to achieve its goals. It deletes several extensions from the user directories, with each extension being deleted by its own “cmd.exe” process.

Reboot

After wiping the disk and files, some wipers will forcly reboot or shutdown the machine. Families like Apostle, DoubleZero, Destover, KillDisk and StoneDrill use the ExitWindowsEx API to reboot the system. The arguments of the API vary across wipers, but in the end the reboot/shutdown will cause the OS to not load.

Figure 5. Acquire shutdown privilege and shut down the machine seen in KillDisk

The Petya wiper variant implements a different approach, calling NtRaiseHardError instead of ExitWindowsEx.

Figure 6. Forcing operating system reboot by calling NtRaiseHardError with the 0xC0000350 error status

DriveSlayer is attempting to reboot the machine after a period of time. The wiper has a predefined value set for the Sleep call, but that can be changed by using command line arguments of the process. The reboot is achieved by calling InitiateSystemShutdownEx API with the following reasons/arguments: SHTDN_REASON_FLAG_PLANNED, SHTDN_REASON_MAJOR_OPERATINGSYSTEM, SHTDN_REASON_MINOR_INSTALLATION and SHTDN_REASON_MINOR_HOTFIX.

Figure 7. Another API used to reboot/shutdown the infected machine

Disable Crash Dumps

DriveSlayer is the only wiper that disables crash dumps from being generated by the operating system. These may provide additional information to a potential researcher in case the machine crashes due to a bug in the driver or malware.

To disable this feature, the wiper changes the following registry key value to 0x0 via the RegOpenKey and RegSetValue APIs:

Wiper, Ransomware or Both

Some malware authors decide to use the same source code to transition their malware from ransomware to wiper or vice versa. Another approach seen in the analyzed samples is to generate different variants of the malware, by improving the wiper, and/or fixing errors in the execution flow. There are a few approaches seen in the analyzed samples:

• Apostle evolved from a wiper to ransomware, fixing bugs in the code and adding extra functionalities like changing background, dropping ransom notes, etc.
• Petya generated a wiper variant from the known ransomware.
• Meteor and KillDisk implement variations of the same code, but don’t change the scope of the malware.
• Ordinypt masquerades as ransomware, deleting the files, replacing them with dummy ones and dropping a ransom note on the disk. However, the wiper has a logical bug that writes and then deletes its own ransom notes several times (as shown in Figure 8).

Figure 8. Screenshot demonstrating how Ordinypt wiper accidentally deletes its own ransom notes

Registry Wiping and Deletion

DoubleZero was the only analyzed sample that implemented a mechanism in which each registry value is set to 0x00 or empty string, followed by a deletion of the subkey tree via Windows APIs.

Figure 9. DoubleZero overwrites the registry keys

Impact

Over the last 10 years, the security industry has seen the use of wipers grow in popularity, notably for sabotage attacks (as illustrated by their use to target Ukraine in the spring of 2022). Although wipers share many features with ransomware, they differ in their ultimate objective. Rather than pursuit of financial gain, the objective of wipers is to destroy data beyond recoverability.

There are multiple ways wipers can achieve their goal, land wiper developers need to make a trade-off between speed and effectiveness when deleting data — the faster techniques may allow for data to be recovered, while the slower ones may allow the victim to intervene and stop the deletion process. Cybersecurity professionals can use different countermeasures and tools in order to recover the lost data. This has motivated wiper developers to increase effectiveness by overwriting files as well as raw disk sectors, in order to decrease recoverability options as much as possible.

Over the years, wipers have not increased in complexity — instead, some only delete the user files and volume shadow copies, with the more advanced ones using legitimate kernel driver implants on the victim’s machine in order to proxy the entire wiping activity through them and to remain as undetectable as possible. Often, the final nail in the coffin is achieved by force rebooting the machine, combined with other techniques that completely eliminate any recovery options.

We have summarized the complex combinations of techniques observed across wiper families in the following table.

Hashes