HiveV5 keystream decryptor PoC

Introduction

The Hive sample analyzed and referred to in this document was randomly chosen from this list created by @rivitna to which my warmest thanks go. Artifacts are available on the VirusTotal platform.

In this document, file a0h2uih3d2.exe has been taken as a reference

MD5: 15CF5E0DA094ACDD751A513402A8C941
SHA-1: 72E15AC4473903C814E65E3C06F54EB0399580AA
SHA-256: 335D2E4A743D059955760ECF2EC25EE86D36AA60B096C9180E860C64EF78EE55

To get an idea of the complexity of this ransomware, please take a look at this analysis published by Microsoft Threat Intelligence Center (MSTIC).

Please read carefully the entire document before starting playing with code!

A brief overview on Hive v5

In recent months, I have channeled most of my strength into the study and reverse engineering of the Hive v5 encryption algorithm. I had the pleasure of collaborating with a great malware analyst and reverse engineer @rivitna who in the past has analyzed previous versions of Hive and published code and PoCs regarding their encryption mechanisms. He has contributed (not a little) to identify the components involved in the encryption operations of Hive v5, which being written in RUST has become more difficult to analyze. I found something in common with Babuk, another very important ransomware whose sources were disclosed in June 2021:

• key exchange algorithm;
• list of processes to be closed before starting the 1256 encryption threads.

Hive ransomware v5 running on a victim system generates two cleartext keys, using the algorithm in the below evidence, based on QueryPerformanceCounter and on QueryPerformanceFrequency Windows APIs.

Please take a look at this Microsoft page for more information on QueryPerformanceCounter APIs, here for QueryPerformanceFrequency.

QueryPerformanceCounter is a very accurate time counter. When called, it returns the time elapsed since the last time the PC was turned on.

QueryPerformanceFrequency returns the value (frequency) of the performance counter. It has a fixed value of 0x989680. It means that the QueryPerformanceCounter value is updated 0x989680 times per second, which is 10,000,000 times.

The two cleartext keys have a size of 0xCFFF00 bytes and are generated one at a time byte by byte. Below is the snippet that allows the creation of 0xA00000 bytes array, which is the largest part of the so called cleartext key with which Hive encrypts the files on the victim's PC.

Each byte of the key is obtained by taking the value of the AL register. The EAX register contains the result of the 0044ADE0 function renamed with the label createByte which implements the difference between the current time instant and the initial seed value, calculated at the first call of the function 0044A850 renamed with the label call_to_QueryPerformanceCounter.

Below is the code written in C++ for generating a cleartext key:

The algorithm is very simple, even if inside the 0044ADE0 function, instructions have been inserted that perform redundant operations and various conditional jumps to try to delay the execution time of the code during the generation of the cleartext key:

In the HiveRansomwareV5_custom_keygen_PoC folder you’ll find the raw code reversed from the analyzed Hive v5 sample. It is not optimized code like the one found in malware, because I needed not to miss a single line of code from the compiled version.

In the HiveRansomwareV5_custom_keygen_PoC-optimized folder you’ll find the optimized code derived from the above mentioned raw code. In this version the code is much easier to read than the raw one, in order to understand the functionality it implements.

Both versions need to be customized with your user before running them in order to save the generated cleartext key on your Desktop.

Both cleartext keys are generated using the same algorithm.
A cleartext key is made of 0xA00000 secure randomly generated bytes. Then the first 0x2FFF00 bytes are copied at the end, creating a final 0xCFFF00 bytes cleartext key.

Then Hive uses the two generated key to encrypt files, but first of all Hive ransomware v5 encrypts the generated keys into custom structurer (hereafter called keystreams) and places them at the root of each drive it encrypts using the .key extension. For example, if you have both drives C and D installed on your system, the encrypted keystreams will be present in the root of each drive.

Hive ransomware v5 uses the generated cleartext keys to encrypt files using the XOR instruction, so we are facing a very fast symmetric encryption on modern x86/x64 CPUs.

How Hive v5 protects itself, how a cleartext key becomes a keystream

Hive ransomware v5 needs to protect the cleartext generated key, encrypting it two times, hereafter we will call these rounds. It takes two rounds of encryption to get the final keystream.

To accomplish this, the following steps are done at each rounds:

1. Generation of 32 bytes private key, using the same algorithm to create each byte of the key;
2. Using the Curve25519 elliptic curve algorithm for Diffie-Hellman key exchange, Hive derives a public key from the just generated private key;
3. Using Curve25519 again, Hive generates a shared key from the private key just generated and Hive affiliate’s public key (changes in every Hive artifact v5);
4. Generation of a 24 bytes nonce, like a kind of IV, using the same algorithm for private key and cleartext key;
5. Using the HChaCha20 algorithm, the key to encrypt the cleartext generated key is derived;
6. Using the key created in step 5 and the nonce created in step 4, Hive encrypts the cleartext key using XChaCha20 algorithm. This operation produces also a 16 bytes MAC (Message Authentication Code) to ensure the integrity of the encryption process.

Step 3 guarantees the creation of a keystream that can be opened by a double pair of private keys, those generated by Hive during encryption and those that the Hive affiliate generated when he compiled the ransomware for us.

The idea behind the bruteforce

At the end of this description one particular point is evident: the cleartext key, the private key and the nonce used for both rounds of encryption are generated by the same function above (0044ADE0 aka createByte). The function 0044ADE0 is conditioned by the time that the CPU takes to execute the code called within the for loop.