Hacking Cat déploie Gorilla RAT et Monkey Ransomware contre des cibles russes
Hacking Cat, groupe pro-ukrainien, cible la Russie avec Gorilla RAT, Monkey ransomware (.monkey) et Nemo Wiper pour chiffrer et détruire des données.
Texte généré par intelligence artificielle, publié sans relecture humaine. Transparence IA
Image d’illustration générée par IA
Les opérations pro-ukrainiennes s’orientent vers la destruction de données
Les chercheurs de Kaspersky ont attribué deux familles de malwares récemment documentées à Hacking Cat, un groupe hacktiviste pro-ukrainien qui cible des organisations russes depuis février 2024 environ.
Le groupe s’était d’abord concentré sur le défaçage de sites web et le vol de données. À l’été 2025, toutefois, ses opérations ont de plus en plus impliqué le chiffrement des fichiers des victimes ou la destruction pure et simple de données, selon les résultats de l’étude.
Les malwares identifiés comprennent Gorilla RAT, un outil d’accès à distance capable de mettre en place un tunnel réseau, et Monkey Ransomware, un rançongiciel qui ajoute l’extension .monkey aux données touchées. Plusieurs variantes de Monkey ont été découvertes sur des systèmes compromis lors d’opérations attribuées à Hacking Cat.
Les chercheurs ont également observé Nemo Wiper, un malware distinct, lors d’une attaque menée conjointement par Hacking Cat et la Ukrainian Cyber Alliance. Son objectif apparent était de perturber les opérations et d’entraîner une perte permanente de données, plutôt que d’obtenir le versement d’une rançon.
Les organisations touchées sont principalement des entités russes ou des organisations opérant dans des territoires occupés par la Russie. La liste complète des victimes, le nombre de systèmes compromis et l’ampleur des pertes de données qui en ont résulté n’ont pas été communiqués.
Gorilla RAT ouvre des voies vers les réseaux internes
Gorilla RAT est un outil d’accès à distance jamais documenté auparavant, capable de faire transiter le trafic réseau par un système infecté. Il offre ainsi à un opérateur un itinéraire potentiel entre un hôte initialement compromis et d’autres services ou machines qui ne sont pas directement accessibles depuis Internet.
Ce type de tunnel modifie le rôle du premier appareil infecté. Au lieu de servir uniquement de point d’observation, celui-ci peut devenir un intermédiaire permettant d’explorer des segments du réseau interne et d’atteindre d’autres systèmes.
Dans certains incidents attribués à Hacking Cat, les attaquants ont d’abord compromis des serveurs Microsoft Exchange avant d’installer Gorilla RAT. Les vulnérabilités précises d’Exchange exploitées pour obtenir l’accès initial ne sont pas connues. Aucun identifiant CVE, aucune édition d’Exchange concernée ni aucune version vulnérable précise n’a été communiqué.
Cette absence d’informations limite la détection et la remédiation fondées sur une vulnérabilité particulière. Les administrateurs ne peuvent pas déterminer, à partir de ces seuls éléments, si les attaquants ont exploité une faille récemment découverte, une vulnérabilité plus ancienne non corrigée ou une faiblesse de configuration.
L’exposition générale reste néanmoins évidente. Un serveur Exchange exposé sur Internet peut fournir à la fois un point d’entrée et une position durable au sein de l’organisation s’il est vulnérable ou insuffisamment protégé.
Kaspersky n’a pas communiqué les empreintes, les noms de fichiers, l’infrastructure de commande et de contrôle ni les détails des protocoles utilisés par Gorilla RAT. Les défenseurs doivent donc rechercher des comportements suspects plutôt que de dépendre exclusivement d’indicateurs fixes. Parmi les signaux pertinents figurent les connexions sortantes inexpliquées depuis des systèmes Exchange, un trafic inhabituel ressemblant à celui d’un proxy et les accès d’un serveur de messagerie à des ressources internes qu’il ne contacte normalement pas.
Monkey Ransomware a évolué au fil de plusieurs implémentations
Monkey Ransomware est apparu pour la première fois à la fin de l’été ou au début de l’automne 2025. Au cours des mois suivants, ses opérateurs l’ont modifié à plusieurs reprises et ont produit des versions écrites dans différents langages de programmation.
Le malware chiffre les données des utilisateurs et marque les fichiers concernés avec l’extension .monkey. Plusieurs variantes ont été récupérées dans des environnements compromis, ce qui témoigne d’un développement continu plutôt que de l’utilisation d’une seule version figée.
Kaspersky a estimé que la rapidité et l’ampleur de ces changements pourraient s’expliquer par l’assistance d’une IA générative. Un modèle pourrait notamment aider à réécrire des fonctions, à traduire du code d’un langage à un autre ou à générer plus rapidement des implémentations différentes qu’une petite équipe travaillant manuellement.
Il s’agit toutefois d’une hypothèse, et non d’une preuve. Une itération rapide peut également résulter d’expérimentations conventionnelles, de la réutilisation de code existant ou du travail de plusieurs développeurs. Aucun élément direct n’a été communiqué montrant que Hacking Cat aurait saisi des requêtes dans un service d’IA ou intégré du code généré par un modèle.
Cette distinction est importante pour évaluer les capacités de développement, mais elle ne change rien à la réponse à apporter à l’incident. Quelle que soit l’origine des variantes, les réécritures fréquentes peuvent réduire l’efficacité de la détection fondée sur les signatures et compliquer la comparaison entre les échantillons.
Les informations disponibles ne précisent pas l’algorithme de chiffrement de Monkey, la gestion des clés, le format de la note de rançon ni la possibilité technique de récupérer les fichiers. Il n’est pas non plus établi que ses opérateurs disposent d’un processus de déchiffrement fiable pour les victimes qui paient.
Nemo Wiper révèle des objectifs qui dépassent l’extorsion
L’activité de Hacking Cat ne peut pas être considérée comme un simple ransomware à motivation financière. Les chercheurs ont observé Nemo Wiper lors d’une opération conjointe avec la Ukrainian Cyber Alliance et ont estimé que le malware visait à détruire des informations et à perturber des infrastructures.
En juin, sans que l’année ait été précisée, les deux groupes ont mené une attaque destructive contre Donbassteploenergo. Ce fournisseur public de chauffage opère dans des zones occupées par la Russie, dans la région ukrainienne de Donetsk.
Un wiper présente un risque différent de celui d’un ransomware classique. Le chiffrement utilisé à des fins d’extorsion laisse théoriquement ouverte la possibilité d’un déchiffrement, même si le paiement ne garantit jamais la récupération des données. Un malware destructeur peut au contraire écraser ou corrompre les informations sans préserver de mécanisme pratique de restauration.
Hacking Cat a également collaboré avec le groupe pro-ukrainien Cyber Anarchy Squad. En mars, là encore sans que l’année ait été précisée, les deux groupes ont revendiqué la compromission d’un prestataire travaillant pour Rosatom, le groupe public russe spécialisé dans l’énergie nucléaire. Les détails concernant la méthode d’accès initial, les systèmes compromis et les effets opérationnels ne sont pas connus.
Ces collaborations montrent que les campagnes peuvent combiner les accès, les outils et les revendications publiques de plusieurs acteurs. Une même intrusion peut donc impliquer plusieurs groupes et poursuivre plusieurs objectifs.
Le partage des malwares complique l’attribution
L’attribution établie par Kaspersky ne fait pas l’unanimité. Hacking Cat a revendiqué la propriété de certains outils dans un message publié sur Telegram, mais a nié que les outils de chiffrement lui appartiennent. Le groupe a accusé les chercheurs d’avoir associé à tort les malwares d’acteurs sans lien entre eux et a contesté certains aspects de leurs travaux de rétro-ingénierie.
Les chercheurs ont également retrouvé les mêmes malwares dans des opérations associées à d’autres groupes. Dans certains cas, plusieurs acteurs auraient utilisé des chaînes d’infection identiques en plusieurs étapes.
Une explication possible serait l’existence d’un développement centralisé ou semi-centralisé. Un seul programmeur ou une petite équipe de développement pourrait créer et maintenir des outils ensuite distribués à plusieurs groupes hacktivistes pro-ukrainiens.
Ce modèle brouillerait la frontière entre développeurs et opérateurs. La présence d’une famille de malware donnée sur le système d’une victime ne permettrait pas nécessairement d’identifier le groupe qui a choisi la cible, mené l’intrusion ou contrôlé l’infrastructure.
Le partage des outils accroît également le risque d’une attribution circulaire. Les enquêteurs peuvent associer un malware à un groupe sur la base d’un incident antérieur, puis s’appuyer sur cette association pour attribuer des attaques ultérieures, même après la diffusion de l’outil à d’autres opérateurs.
Les résultats étayent donc l’existence d’un lien entre Hacking Cat, les campagnes observées et certains outils personnalisés, mais ils n’établissent pas que le groupe soit l’unique propriétaire de toutes les variantes de Monkey Ransomware.
Les opérateurs Exchange doivent rechercher les activités post-compromission
Aucune mesure d’atténuation formelle ni aucun indicateur propre à un fournisseur n’ont été publiés pour ces campagnes. Les organisations qui exploitent Microsoft Exchange doivent commencer par installer les mises à jour de sécurité prises en charge et vérifier que les serveurs accessibles depuis l’extérieur disposent bien de tous les correctifs pertinents du fournisseur.
Comme les vulnérabilités exploitées et les versions concernées restent inconnues, l’application des correctifs ne doit pas être considérée à elle seule comme la preuve qu’un système n’a jamais été compromis. Les administrateurs doivent examiner l’historique des activités Exchange, les journaux d’authentification, les comptes récemment créés et les processus lancés par les composants du serveur de messagerie.
L’accès aux interfaces d’administration doit être restreint partout où les contraintes opérationnelles le permettent. Les connexions inattendues depuis des hôtes Exchange vers des systèmes internes doivent faire l’objet d’une investigation, en particulier lorsqu’elles ressemblent à du tunneling, à l’utilisation d’un proxy ou à des mouvements latéraux.
Les défenseurs doivent également rechercher sur les terminaux et les serveurs de fichiers les fichiers se terminant par .monkey, les modifications massives de fichiers inexpliquées et les activités de chiffrement simultanées dans plusieurs répertoires. Les systèmes de sauvegarde doivent être contrôlés séparément afin de vérifier que les attaquants n’ont pas effacé ou corrompu les copies destinées à la restauration.
Un comportement potentiellement associé à un wiper exige une isolation rapide. Parmi les indicateurs figurent les écritures destructrices à grande échelle, la corruption soudaine de fichiers, la suppression des éléments nécessaires à la restauration et une perturbation coordonnée de plusieurs machines.
La meilleure approche défensive consiste à corréler ces signaux plutôt qu’à les examiner isolément. Une activité Exchange suspecte suivie d’un tunneling interne, du déploiement d’un logiciel d’accès à distance inhabituel et de modifications généralisées de fichiers peut révéler l’ensemble de la chaîne d’intrusion avant que le chiffrement ou la destruction ne s’étende au reste du réseau.
Sources
Cet article est une réécriture originale fondée sur les sources ci-dessous.
