The Anatomy of Wiper Malware, Part 3: Input/Output Controls
In Part 1 of this four-part blog series examining wiper malware, the CrowdStrike Endpoint Protection Content Research Team introduced the topic of wipers, reviewed their recent history and presented common adversary techniques that leverage wipers to destroy system data. In Part 2, the team dove into third-party drivers and how they may be used to destroy system data.
In Part 3, we cover various input/output controls (IOCTLs) in more detail and how they are used to achieve different goals — including acquiring information about infected machines and locking/unlocking disk volumes, among others.
Input/Output Control (IOCTL) Primer
Throughout our analysis, we encountered different uses of IOCTLs across samples. These are used to obtain information about volumes or disks, as well as to achieve other functionalities like locking, unlocking, unmounting a volume, fragmentation of data on disk, and others.
The analyzed samples use the following IOCTLs:
|IOCTL Constant Name
|Petya wiper variant, Dustman and ZeroCleare
|DriveSlayer, Dustman and ZeroCleare, IsaacWiper
|Shamoon 2, Petya wiper variant
|StoneDrill, Dustman and ZeroCleare
|DriveSlayer, StoneDrill, IsaacWiper
|DriveSlayer, Petya wiper variant, StoneDrill
|DriveSlayer, Shamoon 2
|DriveSlayer, Petya wiper variant, SLQShred, Dustman and ZeroCleare
While the majority of the wiper families use a few IOCTLs, DriveSlayer makes use of an extensive list of IOCTLs to achieve its goals. Some IO control codes are used to acquire information about the disks of the infected machine like NTFS partition tables, move files, fingerprint the drive, etc.
In the example below, DriveSlayer is using the IOCTL_DISK_GET_DRIVE_LAYOUT_EX and IOCTL_DISK_GET_DRIVE_GEOMETRY_EX IOCTLs to obtain information about the partitions and geometry of a drive. This helps the wiper to determine the location of the MFTs and MBRs in order for them to be scheduled for wiping. Similar implementations can be found using the other IOCTLs in IsaacWiper, Petya wiper variant, Dustman or ZeroCleare.
DriveSlayer also uses IOCTL_STORAGE_GET_DEVICE_NUMBER to grab information such as partition number and device type, which is later used in the wiper process.
The FSCTL_LOCK_VOLUME and FSCTL_DISMOUNT_VOLUME IOCTLs are used by DriveSlayer to lock and unmount a disk volume after the wiping routine has finished. In order to do so, DriveSlayer grabs a list of all the drive letters via GetLogicalDriveStrings, iterates through all of them, acquires a handle to each volume and sends two IOCTLs via DeviceIoControl API. A similar implementation is done by the Petya wiper variant and StoneDrill as well.
The usage of FSCTL_LOCK_VOLUME and FSCTL_DISMOUNT_VOLUME IO control codes can be seen in the following function call.
Destroying All Disk Contents
Besides the common approach of overwriting the MBR, SQLShred also calls the DeviceIoControl API with the IOCTL_DISK_DELETE_DRIVE_LAYOUT IO Control Code in order to make sure the disk is formatted from sector 0x00.
Overwriting Disk Clusters
The FSCTL_GET_VOLUME_BITMAP IOCTL is used by DriveSlayer to acquire a bitmap representation of the occupied clusters of a disk volume. The bitmap representation is returned as a data structure that describes the allocation state of each cluster in the file system, where positive bits indicate if the cluster is in use. DriveSlayer will use this bitmap to overwrite occupied clusters with randomly generated data.
DriveSlayer uses two IOCTLs to fragment the data on disk, thus making file recovery harder. In order to fragment the data, the wiper determines the location on disk of individual files by requesting cluster information via the FSCTL_GET_RETRIEVAL_POINTERS IOCTL. The wiper continues by relocating virtual clusters using the FSCTL_MOVE_FILE IOCTL.
File Type Determination
When getting information about files, besides GetFileAttributesW API, SQLShred wiper is also using the FSCTL_GET_REPARSE_POINT IOCTL to retrieve the reparse point data associated with the file or directory. In this case, the wiper is using it to check if the file is a symlink or the directory represents a mount point.
Wipers like DriveSlayer will attempt to determine existing files by parsing the MFT rather than walking the directories and files recursively. The FSCTL_GET_NTFS_VOLUME_DATA IOCTL is used to obtain information about the specified NTFS volume, like volume serial number, number of sectors and clusters, free as well as reversed clusters and even the location of the MFT and its size. All of this information is part of the NTFS_VOLUME_DATA_BUFFER structure that is sent as an argument to the DeviceIoControl API. Malware uses this IOCTL to determine the location of the MFT and MFT-mirror in order to delete both of them by overwriting the raw sectors.
The FSCTL_GET_NTFS_FILE_RECORD IOCTL is used to enumerate files from a NTFS formatted drive. The information is returned inside the NTFS_FILE_RECORD_OUTPUT_BUFFER structure that is sent as an argument to the DeviceIoControl API. Wipers like DriveSlayer use this IOCTL in order to determine the raw sectors associated with files and queue them for the wiping routine.
How the CrowdStrike Falcon® Platform Offers Continuous Monitoring and Visibility
The CrowdStrike Falcon®® platform takes a layered approach to protect workloads. Using on-sensor and cloud-based machine learning, behavior-based detection using indicators of attack (IOAs), and intelligence related to tactics, techniques and procedures (TTPs) employed by threat actors, the Falcon platform equips users with visibility, threat detection, automated protection and continuous monitoring for any environment, reducing the time to detect and mitigate threats.
Wipers frequently use various IOCTL codes in order to enrich their capabilities. Input/Output control codes can be used for various types of operations; they can help to enumerate files, locate the Master File Table (MFT), determine location of files on the raw disk, unmount drivers, fragment files, etc. These codes can be sent directly to the volume or drive itself, and even to the third-party drivers that we discussed in part 2.
In the next and final part of the wiper blog series, we will cover some less frequent techniques seen in wiper malware. The techniques are used to augment the existing destructive capabilities described so far and were seen in some particular wiper families.
|SHA256 hash value
|Meteor and Comet/Stardust
|Tokyo Olympic wiper
- Learn how the powerful CrowdStrike Falcon® platform provides comprehensive protection across your organization, workers and data, wherever they are located.
- Get a full-featured free trial of CrowdStrike Falcon® Prevent™ and see for yourself how true next-gen AV performs against today’s most sophisticated threats.