
Hive v5 file decryption algorithm
Le travail effectué au cours des derniers mois a été nécessaire pour révéler le mécanisme de chiffrement malveillant des fichiers de Hive v5-5.2. Le travail a été divisé en deux parties
Je tiens à remercier le grand @rivitna pour le soutien, le dialogue et les conseils de ces mois de travail ! Veuillez noter le github de rivitna plein d'informations utiles sur le ransomware Hive et plus encore.
Dans ce readme, vous trouverez quelques informations sur l'algorithme de déchiffrement des fichiers, en vous renvoyant au PoC pour une vision plus complète de son fonctionnement. Un keystream est un texte clair chiffré. Un texte clair est un ensemble de 0xA00000 octets auxquels ont été ajoutés les premiers 0x2FFF00 octets, pour un total de 0xCFFF00 octets. Ces octets ont été créés avec l'algorithme faible déjà abordé dans la première partie publiée en juillet 2022. Vous trouverez ci-dessous un exemple de texte clair :

L'échantillon Hive analysé et référencé dans ce document a été choisi à partir de cette liste créée par @rivitna à qui vont mes plus chaleureux remerciements. Pour avoir une idée de la complexité du ransomware, veuillez jeter un œil à cette analyse publiée par le Microsoft Threat Intelligence Center (MSTIC).
Le texte clair (un keystream déchiffré) est utilisé par le ransomware Hive lors du chiffrement de chaque fichier. Lors du chiffrement d'un fichier, le ransomware Hive calcule deux entiers se référant à des positions précises dans le texte clair (offsets) à utiliser pour chiffrer le fichier selon la formule suivante :

où c = i % 0x2FFF00 et d = i % 0x2FFD00, avec i comme compteur d'octets.
Les opérations préliminaires avant l'écriture d'un fichier sont :

Dans ce cas également, le texte clair joue un rôle fondamental. En fait, il est utilisé pour :
Cependant, le premier offset est chiffré à l'aide d'une position fixe du texte clair et est différent pour chaque échantillon Hive 5/5.1/5.2. Une sorte de valeur magique. Dans de nombreux artefacts Hive 5/5.1, cette valeur magique est affichée explicitement dans une référence mémoire, comme dans ce cas 0x98072A :

Ou ce cas 0x7539D :

Mais dans la preuve suivante, la boucle for est légèrement différente et a été écrite de manière à ne pas expliciter la valeur magique que nous devons identifier. Cela concerne un artefact appartenant à Hive 5.2 :

Dans ce cas, il est possible d'utiliser la fonction de bruteforce d'offset présente dans l'outil publié, en utilisant un fichier avec une extension connue et le keystream déchiffré correspondant. En utilisant l'en-tête du fichier chiffré et l'en-tête du fichier non chiffré, il est possible de comprendre quel est l'offset à partir duquel le décrypteur doit commencer à déchiffrer le fichier.
Le mode de chiffrement des fichiers peut avoir deux valeurs : 0xFB ou 0xFF
Pour plus d'informations concernant le calcul de la taille des blocs non chiffrés et de l'offset du texte clair, veuillez vous référer au code du PoC.
Le programme offre deux options :

https://github.com/rivitna/Malware/blob/main/Hive/Hive_samples.txt