Whispergate Stage 1

While the kinetic war between Russia and Ukraine began in earnest on the 24th of February of this year, the cyberwar between the two countries began long before that point. Indeed one could argue that it started as early as 2013, just prior to the annexation of Crimea, and that it has continued unabated ever since, albeit with varying degrees of intensity. On the 13th of January of this year, just after the failed NATO-Russia talks regarding the future status of Ukraine, a number of cyberattacks were launched against numerous targets within Ukraine. While these attacks were supplemented by targeted defacements of 70 Ukrainian government websites, the most worrying aspect of the attacks was the use of a novel strain of destructive malware dubbed by the Microsoft Threat Intelligence Centre (MTIC), the team who first discovered it, with the moniker WhisperGate.^[1]

WhisperGate was assessed by the MTIC to be a 2 stage piece of malware.

The first stage is an MBR wiper & pseudo-ransomware executable and is the subject of this article. MBR wipers are pieces of malware designed to effectively destroy the operating system present on a computer by corrupting the master boot record (MBR) on the system’s primary hard drive. On systems that employ an MBR, it contains critical data and executable code used by the system to start the operating system. Without a functional MBR it is impossible to start the system. The stage 1 binary was observed to overwrite the MBR with the following fake ransom message:

Your hard drive has been corrupted.
In case you want to recover all hard drives
of your organization,
You should pay us $10k via bitcoin wallet
1AVNM68gj6PGPFcJuftKATa4WLnzg8fpfv and send message via
tox ID 8BEDC411012A33BA34F49130D0F186993C6A32DAD8976F6A5D82C1ED23054C057ECED5496F65
with your organization name.
We will contact you to give further instructions.

This ransom warning is completely empty: the malware makes no back up and simply overwrites the MBR with this message. The malware authors could not restore the contents of the MBR even if they wanted to.

The second stage was observed to be a dropper for a file corrupter should the first stage fail. We will explore its functionality and internals in a follow-up post to this.

Technical Analysis

The sample of WhisperGate stage 1 used in this analysis was sourced from “The Malware Bazaar” hosted by abuse.ch, a research project at the Bern University of Applied Sciences which makes malware samples publicly available for security researchers to investigate.^[2] The SHA256 sum of the file was computed and was verified to match the hash of the sample used by the US CISA in their analysis of the WhisperGate malware.^[3]

$ sha256sum ./whispergate.bin 
a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92  ./whispergate.bin

Having established that we are dealing with the correct binary we proceeded to load it into Ghidra for analysis. By examining each of the functions detected by Ghidra in turn we see that the majority of the functionality of the malware is contained within its main function.

The malware begins by writing many copies of the ransom message into a 2050 byte buffer.

Following this WhisperGate performs a call to CreateFileW, specifying PhysicalDrive0 as the target.

Parsing this into a more readable form, it can be seen to be equivalent to the following function call:

HANDLE drive0 = CreateFileW( L"\\\\.\\PhysicalDrive0", GENERIC_ALL, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);

CreateFileW creates or opens a file or, in this case, an I/O device, and returns a handle to the file or device. PhysicalDrive0 is an I/O device which allows for the direct reading and writing of bytes to the primary physical hard drive.^[4] If the malware is able to successfully open a handle to this device then it will be able to write bytes to arbitrary locations on disk, including to the MBR.

Having opened a handle to PhysicalDrive0, the malware simply calls the WriteFile API function to write the buffer containing the ransom message to the initial 512 bytes of the disk.

Once again here is a tidier version than that offered by the Ghidra decompiler:

WriteFile(drive0, buffer, 512, NULL, NULL);

With this call to WriteFile (assuming it was successful) the MBR has been completely destroyed and replaced with the malware author’s pseudo-ransom note. Next time the system is power cycled it will fail to boot and instead the attacker’s unscrupulous demands will be presented to the user.

The malware finishes up by considerately closing the handle to PhysicalDrive0 that it opened.

Summary and Thoughts

I must say I was somewhat disappointed by how dated and rudimentary this malware was. The technique of directly opening a handle to PhysicalDrive0 and using that to overwrite the MBR is very old and is likely ineffective against modern systems. Indeed, on almost any modern system with UEFI the primary drive will be partitioned using GPT and as a result will not even have an MBR. That being said, however, I doubt that having half a kilobyte of random data scribbled at the start of your hard drive will do much for you in terms of your system’s stability.

It’s possible that the attacker who deployed this malware selectively deployed it against systems they knew to be vulnerable to it. Indeed the prevalence of machines running outdated versions of Windows and/or using legacy BIOS is likely fairly high in Ukraine, so that doesn’t seem an unreasonable notion.

In my next post I will analyse the second stage of this malware and see if it is of greater sophistication.

Sources

1. https://www.microsoft.com/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/
2. https://bazaar.abuse.ch/sample/dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78/
3. https://www.cisa.gov/uscert/ncas/alerts/aa22-057a
4. https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew