La première particularité est liée à la conduite humaine de la compromission. Nous avons pu observer, sur une précédente intervention, une première connexion RDP, en utilisant un compte utilisateur légitime compromis, de l’attaquant tôt dans la matinée, puis une déconnexion de ce même utilisateur quelques minutes plus tard. Une connexion de ce même compte utilisateur depuis la même adresse IP est observée, aux alentours de 21h, le même jour. Ce comportement ne peut pas être expliqué avec certitude, mais il est probable qu’un attaquant humain se connecte manuellement aux serveurs compromis pour réaliser ses actions malveillantes. Une seconde hypothèse est que l’attaquant se connecte une première fois pour vérifier que son compte compromis fonctionne, puis qu’il attend les heures non ouvrées pour effectivement compromettre le poste, ce qui peut être une des raisons de sa déconnexion dans la matinée et de sa reconnexion dans la nuit.

Suite à la compromission de ce patient zéro, l’attaquant dépose sur celui-ci plusieurs binaires, légitimes ou non, qu’il va utiliser pour mener à bien son infection sur le parc. Le premier qu’il utilise est IPScan2.exe (sha1 : 4E1F7C706BF752FAD3AED812A39BD39428BEA078), qui lui permet de scanner le réseau interne et découvrir d’autres machines Windows accessibles. Des traces d’utilisation de Mimikatz ont également été retrouvées sur le poste compromis, ce qui laisse à penser que l’attaquant tente d’élever ses privilèges afin de pouvoir, d’une part se connecter sans problème aux autres postes, et d’autre part désactiver les protections antivirales.

L’attaquant embarque également dans sa boîte à outils PCHunter64.exe (sha1 : F2BB3394F6A984BF3B5A4B581B0B61DF210C0055) et Process Hacker, afin de lister les antivirus démarrés sur la machine, puis stopper les processus et les services associés. Certaines traces disponibles dans les journaux d’évènements Windows ont montré que l’attaquant a arrêté trois services liés à un antivirus (AV) installé sur le poste, puis que ce même antivirus a instantanément redémarré automatiquement. Les mêmes traces de l’arrêt des services de l’AV sont observées quelques minutes plus tard, à la différence que quatre services sont stoppés, au lieu de trois la première fois. Il est probable qu’un des services de l’AV soit en charge du monitoring de l’état des autres services, et qu’il les redémarre en cas d’arrêt. Ce comportement témoigne d’une compromission manuelle des machines par un attaquant humain (à distance), sujet aux erreurs et aux oublis.

A ce stade de la compromission, l’attaquant va chercher à se connecter, toujours en RDP, sur les autres machines Windows du parc, avec un des comptes privilégiés préalablement compromis grâce à Mimikatz. Sur chacun des postes compromis, et sans infecter le patient zéro à ce stade de l’attaque, il déploie son ransomware, qui garde un fonctionnement classique :

• il ajoute un moyen de persistance, au travers d’une clé de registre, ce qui lui permet de se lancer automatiquement à chaque démarrage de la machine ;
• il lance le chiffrement de tous les fichiers présents sur le disque, en dehors du répertoire courant du malware (pour ne pas s’auto chiffrer), et du répertoire C:Windows ;
• lorsque le chiffrement est terminé, le code effectue deux actions :
  • exécution d’un script .bat, créé pour l’occasion sur le système et inclus dans le binaire, pour supprimer la totalité de ses traces (suppression de l’historique des dernières connexions RDP, suppression de l’ensemble des journaux Event Logs de Windows) ;
  • exécution d’une commande Windows pour supprimer son propre exécutable du répertoire où il a été copié par l’attaquant au moment de la compromission. La copie effectuée dans le répertoire pointé par le point de persistance n’est pas supprimée.

La persistance et le démarrage automatique du ransomware lui permettent, à chaque redémarrage, d’afficher une fenêtre d’alerte demandant le paiement d’une rançon, ainsi que le chiffrement de tout nouveau fichier présent sur le poste, ou de tout nouveau périphérique de stockage. Lorsque le code malveillant est exécuté, l’attaquant se déconnecte manuellement de la session RDP.

L’analyse des journaux du client RDP, non supprimés par l’attaquant (Rôles de serveurService Bureau à distance)) sur le patient zéro, permettent d’observer une séquentialité dans les heures de connexion et déconnexion sur chaque machine compromise du parc. Il est ainsi possible d’imaginer que l’attaquant compromet les machines séquentiellement : il installe et lance son rançongiciel sur la machine en cours, puis s’en déconnecte, avant de se connecter à une nouvelle machine pour l’infecter à son tour.

Suite à la compromission de toutes les machines accessible du parc, l’attaquant chiffre le patient zéro, avant de se déconnecter et quitter le SI. Ceci lui permet de garder un point d’entrée sain dans le SI, au cas où il se fasse détecter sur les autres machines. Une trace de l’outil NS2.exe (sha1 : 629C9649CED38FD815124221B80C9D9C59A85E74) a été retrouvé sur ce patient zéro, sans qu’une preuve d’exécution de cet outil n’ai été retrouvé. Il pourrait être utilisé pour monter, sur le patient zéro, l’ensemble des partages réseaux disponibles sur le parc, afin qu’ils soient également chiffrés. Cela permettrait de compromettre les serveurs Linux qui hébergent des partages Samba, et qui ne seraient pas touchés par le ransomware.

Comme évoqué précédemment, en plus de scanner le réseau et de désactiver les protections antivirales, l’attaquant supprime les journaux d’évènements Windows, ce qui peut complexifier l’analyse et l’investigation. Néanmoins, la compromission manuelle et humaine étant sujette à des erreurs, certains journaux ne sont pas effacés pendant la compromission, ni certains outils déposés par l’attaquant, ce qui permet d’obtenir des artefacts lors de l’investigation et de retracer l’historique de celle-ci.

L’ensemble de ces informations tirées des dernières analyses réalisées par le CERT-Amossys montre que ce type d’attaque informatique s’industrialise et que les attaquants sont de plus en plus équipés, notamment sur les outils tiers qu’ils embarquent en plus du simple ransomware. Une constante ressort de nos investigations, les attaques de ce type sont de plus en plus complexes. Le but étant pour le cybercriminel de gagner du temps afin de multiplier ses gains.

L’incident et le mode opératoire présentés ici sont similaires à d’autres campagnes du même type, tels que le ransomware Ryuk ou les campagnes du groupe Parinacota, déjà étudiés par les équipes de Microsoft. En particulier, le rançongiciel Doppelpaymer, à l’exception de certaines étapes de la chaîne de compromission qui n’ont pas été observées, est très proche du cas étudié ici.

Ces différents cas mettent en exergue la montée en puissance de la cybercriminalité, sans cesse en train d’innover afin d’être plus rentable.

Amossys souhaite rappeler que les compromissions sont de plus en plus fréquentes, dans tous les types d’entreprises, et qu’une prise en charge rapide de ceux-ci par une équipe de CERT permet une meilleure et plus rapide reprise d’activité. De plus, une campagne de recherche de compromissions efficace, menée régulièrement sur le SI, permet de détecter et/ou d’identifier les points faillibles menant à ces infections au plus tôt, et donc de s’en prémunir un maximum, d’y réagir et d’y remédier.