reecdeep/hivev5_keystream_decryptorMauvaises choses par des méchants
# 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](https://github.com/rivitna/Malware/blob/main/Hive/Hive_samples.txt) créée par [@rivitna](https://twitter.com/rivitna2), à 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](https://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/) 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](https://twitter.com/rivitna2), 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](https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter) page Microsoft pour plus d'informations sur l'API *QueryPerformanceCounter*, et [ici](https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancefrequency) 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.  ## L'idée derrière la force brute À la fin de cette description, un point particulier est évident : la clé en clair, la clé privée et le nonce utilisés pour les deux tours de chiffrement sont générés par la même fonction ci-dessus (0044ADE0, alias *createByte*). **La fonction 0044ADE0 est conditionnée par le temps que le CPU met à exécuter le code appelé dans la boucle for.** En regardant la figure ci-dessus, qui met en évidence la structure du keystream après les deux tours de chiffrement, il est évident que nous n'avons librement accès qu'au **nonce** (sinon les affiliés Hive ne sauraient pas comment déchiffrer les fichiers). Concentrons-nous donc sur le NONCE, qui fait 24 octets : NONCE: 40 A4 08 6C D0 D0 34 98 FC 60 C4 28 8C F0 F0 54 B8 1C 80 E4 48 AC AC 10 **La différence entre un octet du nonce et le suivant (en valeur absolue) représente le temps écoulé entre une itération et la suivante. Nous introduisons le concept d'empreinte avec cette définition.** NONCE FINGERPRINT: 64 9c 64 64 00 9c 64 64 9c 64 9c 64 64 00 9c 64 9c 64 64 9c 64 00 9c Si nous analysons les valeurs obtenues, nous constatons que le temps d'exécution du code est presque identique, avec de légères variations dues en particulier à la technologie utilisée par le processeur en question (pour mes tests, j'ai utilisé un processeur i7 de 10e génération et un i5 de 5e génération ; sur d'autres systèmes, cette empreinte peut différer). Cette découverte est très importante si l'on considère que le nonce est généré par la même fonction qui génère la clé en clair et surtout la clé privée. Puisque ces valeurs mentionnées suivront également ce principe, c'est-à-dire que la différence entre les octets du nonce est prévisible, alors les valeurs de la clé privée et de la clé en clair seront également prévisibles. Cependant, les analyses ont montré que générer un tableau de 0xA00000 caractères en espérant obtenir les mêmes octets d'origine que la clé en clair calculée par Hive est très difficile : les variations des charges CPU et mémoire affectent la vitesse d'exécution du code, et souvent la clé en clair d'origine calculée par le PE de Hive est différente (ne serait-ce que de quelques octets) de celle que nous avons calculée. Nous utilisons cette empreinte du nonce pour la comparer à l'empreinte obtenue lors de la génération d'un éventuel dictionnaire de 0xA00000 octets (ce nombre a été fixé empiriquement ; après une série de tests, il a été constaté que, statistiquement, dans ce nombre d'octets se trouvent les deux clés privées de 32 octets chacune, nécessaires aux deux tours de chiffrement). Si l'empreinte du nonce est contenue dans l'empreinte du dictionnaire, nous avons trouvé le bon dictionnaire pour commencer l'attaque par force brute sur les deux clés privées. Cela ne s'arrête pas là, car les analyses dynamiques menées sur la génération du nonce, de la clé en clair et également de la clé privée ont permis de vérifier que le premier octet a une distance moyenne différente de celle du deuxième octet, par rapport à tous les autres octets, qui ont des valeurs presque homogènes. Voyons cela en détail :  Comme vous pouvez le voir, les valeurs de l'empreinte qui suivent la première subissent des variations minimes, c'est-à-dire que la distance en valeur absolue entre le premier et le deuxième octet de la clé privée a, la plupart du temps, des valeurs en dehors de celles présentes dans le reste de l'empreinte. Cela est probablement dû à certains algorithmes d'optimisation présents dans le CPU qui accélèrent l'exécution du code après la première itération de la boucle for. ## Une solution possible Le code proposé lit le nonce de chaque tour de chiffrement du keystream, détermine son empreinte et génère une liste de dictionnaires de clés possibles contenant la clé privée potentielle. Pour résoudre le problème lié au premier octet de l'empreinte, qui est toujours différent du reste de la clé, j'ai pensé à procéder ainsi : 1. nous créons un dictionnaire des octets de tête possibles, en prenant les valeurs uniques des 0x110 premiers octets du dictionnaire généré ; 2. nous créons une liste de 31 octets en prenant toutes les combinaisons possibles à partir du deuxième octet du dictionnaire généré ; 3. nous créons des combinaisons des premiers octets et des 31 octets générés restants pour former les combinaisons possibles de clé privée de 32 octets, à partir desquelles dériver la clé publique en la comparant avec celle en notre possession, présente dans le keystream. Lorsque les deux clés publiques coïncident, nous aurions trouvé la clé privée avec laquelle le deuxième (et dernier) tour de chiffrement a été chiffré. En itérant à nouveau les opérations décrites jusqu'ici, nous obtiendrons la clé privée permettant de déchiffrer le premier tour du keystream chiffré et, enfin, d'extraire la clé en clair d'origine. ## Utilisation Dans le dossier **HiveRansomwareV5-keystream_decryptor**, vous trouverez la solution VS 2017 (sln) et une bibliothèque [monocypher](https://monocypher.org/) personnalisée. Le programme vous permet de choisir l'opération à effectuer.  L'option « 1 » est la première à choisir, car elle vous permet de créer un dictionnaire d'octets « sur mesure » pour le processeur de votre PC. Elle devrait donc être exécutée sur la machine chiffrée, car il est beaucoup plus probable d'obtenir des valeurs identiques à celles présentes dans son keystream.  Ou, en alternative, si la première option ne fonctionne pas, générez votre propre dictionnaire en exécutant le malware dans le débogueur (sur le même PC déjà infecté) jusqu'à la fin de la génération de la clé en clair (juste après la boucle for), puis enregistrez le contenu de la mémoire qui contient la clé en clair. Dans ce cas, vous pouvez valider votre dictionnaire en utilisant l'option « 3 » :  Une fois que vous disposez du bon dictionnaire pour votre keystream, l'option « 2 » peut également être exécutée sur des ordinateurs plus puissants, car ils réduiraient le temps nécessaire pour épuiser les combinaisons d'octets, sans affecter en aucune manière les valeurs des octets des clés privées.    Pour exécuter correctement la fonctionnalité de l'option 2, la clé publique doit être extraite. Comme tous les échantillons Hive ne sont pas créés égaux, il n'est pas très facile de créer un extracteur de clé publique universel. Cependant, une méthode connue pour fonctionner consiste à placer un point d'arrêt dans cette portion du code désassemblé, après la création du nonce. Dans la preuve ci-dessous, la clé publique est transmise à la fonction 44E3D8 afin de dériver la clé partagée à l'aide de curve25519. C'est le seul endroit où la clé publique est révélée pendant toute l'exécution du malware.  Veuillez être attentif lorsque vous manipulez les options de Visual Studio. La sortie du programme, comme les octets du dictionnaire généré, peut être modifiée si vous passez de debug à release et vice versa. Si vous souhaitez accélérer la procédure de force brute, vous pouvez modifier la valeur *dictionary_dimension* dans le code, mais gardez à l'esprit que réduire la taille du dictionnaire peut également réduire les chances de trouver les clés privées. De plus, si vous décidez d'utiliser un tableau d'octets en clair généré en exécutant Hive et en le déversant depuis la mémoire, pensez à définir la taille de votre dump dans la variable *dictionary_dimension*. Pour tester l'outil de décryptage, j'ai mis à disposition quelques fichiers à utiliser dans le dossier **dummy_data_PoC** : - *BumAU1Ky.key* (premier keystream) - *UMvObens.key* (deuxième keystream) - *a0h2uih3d2_01058000.bin* (clé en clair extraite lors de l'exécution de Hive à utiliser comme dictionnaire) - *dictionary.bin* (exemple de dictionnaire) - *public_key.txt* (contient les clés publiques des affiliés de Hive) Bonne chance ! ## Références <https://github.com/rivitna/Malware/blob/main/Hive/Hive_samples.txt> <https://www.virustotal.com/gui/file/335d2e4a743d059955760ecf2ec25ee86d36aa60b096c9180e860c64ef78ee55> <https://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/> <https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps> <https://monocypher.org/manual/x25519> <https://monocypher.org/manual/advanced/poly1305> <https://monocypher.org/manual/advanced/chacha20> <https://monocypher.org/manual/aead>
