PoC du décrypteur de keystream HiveV5

Introduction

L'échantillon Hive analysé et référencé dans ce document a été choisi aléatoirement dans cette liste créée par @rivitna, à qui vont mes plus chaleureux remerciements. Les artefacts sont disponibles sur la plateforme VirusTotal.

Dans ce document, le fichier a0h2uih3d2.exe a été pris comme référence

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

Pour vous faire une idée de la complexité de ce ransomware, veuillez jeter un œil à cette analyse publiée par le Microsoft Threat Intelligence Center (MSTIC).

Veuillez lire attentivement l'intégralité du document avant de commencer à jouer avec le code !

Un bref aperçu de Hive v5

Au cours des derniers mois, j'ai consacré l'essentiel de mon énergie à l'étude et à la rétro-ingénierie de l'algorithme de chiffrement de Hive v5. J'ai eu le plaisir de collaborer avec un grand analyste de malwares et expert en rétro-ingénierie, @rivitna, qui a par le passé analysé les versions précédentes de Hive et publié du code ainsi que des PoC concernant leurs mécanismes de chiffrement. Il a contribué (et pas qu'un peu) à identifier les composants impliqués dans les opérations de chiffrement de Hive v5, qui, étant écrit en RUST, est devenu plus difficile à analyser. J'ai trouvé des points communs avec Babuk, un autre ransomware très important dont les sources ont été divulguées en juin 2021 :

• l'algorithme d'échange de clés ;
• la liste des processus à fermer avant de lancer les 1256 threads de chiffrement.

Le ransomware Hive v5, exécuté sur le système d'une victime, génère deux clés en clair, en utilisant l'algorithme présenté ci-dessous, basé sur les API Windows QueryPerformanceCounter et QueryPerformanceFrequency.

Veuillez consulter cette page Microsoft pour plus d'informations sur l'API QueryPerformanceCounter, et ici pour QueryPerformanceFrequency.

QueryPerformanceCounter est un compteur de temps très précis. Lorsqu'il est appelé, il renvoie le temps écoulé depuis le dernier démarrage du PC.

QueryPerformanceFrequency renvoie la valeur (fréquence) du compteur de performance. Elle a une valeur fixe de 0x989680. Cela signifie que la valeur de QueryPerformanceCounter est mise à jour 0x989680 fois par seconde, soit 10 000 000 fois.

Les deux clés en clair ont une taille de 0xCFFF00 octets et sont générées une à une, octet par octet. Ci-dessous se trouve l'extrait de code qui permet la création d'un tableau de 0xA00000 octets, qui constitue la plus grande partie de ce que l'on appelle la clé en clair avec laquelle Hive chiffre les fichiers sur le PC de la victime.

Chaque octet de la clé est obtenu en prenant la valeur du registre AL. Le registre EAX contient le résultat de la fonction 0044ADE0, renommée avec le label createByte, qui implémente la différence entre l'instant courant et la valeur de la graine initiale, calculée lors du premier appel de la fonction 0044A850, renommée avec le label call_to_QueryPerformanceCounter.

Voici le code écrit en C++ pour générer une clé en clair :

L'algorithme est très simple, même si, à l'intérieur de la fonction 0044ADE0, des instructions ont été insérées qui effectuent des opérations redondantes et divers sauts conditionnels pour tenter de retarder le temps d'exécution du code pendant la génération de la clé en clair :

Dans le dossier HiveRansomwareV5_custom_keygen_PoC, vous trouverez le code brut issu de la rétro-ingénierie de l'échantillon Hive v5 analysé. Ce n'est pas un code optimisé comme celui présent dans le malware, car je ne devais manquer aucune ligne de code de la version compilée.

Dans le dossier HiveRansomwareV5_custom_keygen_PoC-optimized, vous trouverez le code optimisé dérivé du code brut mentionné ci-dessus. Dans cette version, le code est beaucoup plus facile à lire que le code brut, afin de comprendre la fonctionnalité qu'il implémente.

Les deux versions doivent être personnalisées avec votre nom d'utilisateur avant de les exécuter, afin d'enregistrer la clé en clair générée sur votre Bureau.

Les deux clés en clair sont générées en utilisant le même algorithme.
Une clé en clair est composée de 0xA00000 octets générés de manière sécurisée et aléatoire. Ensuite, les 0x2FFF00 premiers octets sont copiés à la fin, créant ainsi une clé en clair finale de 0xCFFF00 octets.

Ensuite, Hive utilise les deux clés générées pour chiffrer les fichiers, mais avant tout, le ransomware Hive v5 chiffre les clés générées dans une structure personnalisée (appelée ci-après keystreams) et les place à la racine de chaque lecteur qu'il chiffre, en utilisant l'extension .key. Par exemple, si vous avez à la fois les lecteurs C et D installés sur votre système, les keystreams chiffrés seront présents à la racine de chaque lecteur.

Le ransomware Hive v5 utilise les clés en clair générées pour chiffrer les fichiers à l'aide de l'instruction XOR ; nous avons donc affaire à un chiffrement symétrique très rapide sur les CPU x86/x64 modernes.

Comment Hive v5 se protège, comment une clé en clair devient un keystream

Le ransomware Hive v5 doit protéger la clé en clair générée en la chiffrant deux fois ; nous appellerons désormais ces étapes des tours. Il faut deux tours de chiffrement pour obtenir le keystream final.

Pour y parvenir, les étapes suivantes sont effectuées à chaque tour :

1. Génération d'une clé privée de 32 octets, en utilisant le même algorithme pour créer chaque octet de la clé ;
2. En utilisant l'algorithme de courbe elliptique Curve25519 pour l'échange de clés Diffie-Hellman, Hive dérive une clé publique à partir de la clé privée qui vient d'être générée ;
3. En utilisant à nouveau Curve25519, Hive génère une clé partagée à partir de la clé privée tout juste générée et de la clé publique de l'affilié Hive (qui change dans chaque artefact Hive v5) ;
4. Génération d'un nonce de 24 octets, sorte d'IV, en utilisant le même algorithme que pour la clé privée et la clé en clair ;
5. En utilisant l'algorithme HChaCha20, la clé permettant de chiffrer la clé en clair générée est dérivée ;
6. En utilisant la clé créée à l'étape 5 et le nonce créé à l'étape 4, Hive chiffre la clé en clair avec l'algorithme XChaCha20. Cette opération produit également un MAC de 16 octets (Message Authentication Code) pour garantir l'intégrité du processus de chiffrement.

L'étape 3 garantit la création d'un keystream qui peut être ouvert par une double paire de clés privées : celles générées par Hive pendant le chiffrement et celles que l'affilié Hive a générées lorsqu'il a compilé le ransomware pour nous.