Ransomware : pourquoi quand il détone, c’est vraiment trop tard

Une menace tout sauf superficielle

Les experts l’évoquaient déjà au printemps dernier, alors que LockerGoga faisait parler de lui, notamment chez Norsk Hydro. Ivan Kwiatkowski, chercheur en sécurité chez Kaspersky, l’assurait alors : « les acteurs derrière LockerGoga ont réfléchi sérieusement et longuement à la manière de maximiser leurs gains ». Félix Aimé, analyste chez le même éditeur, ajoutait : « ils savent parfaitement combien de postes de travail et de serveurs ont été visés grâce à [l’annuaire] Active Directory ».

Forts de cette connaissance, les attaquants n’ont pas besoin d’identifier précisément chaque machine chiffrée par leurs soins, ni de définir une clé de déchiffrement unique pour chacune d’entre elles : l’extorsion vise l’organisation touchée dans son entièreté.

Un peu plus tard, l’Agence nationale pour la sécurité des systèmes d’information (Anssi) confortait ces analyses : l’exécution du ransomware « est réalisée sur plusieurs semaines (voire plusieurs mois) après la compromission effective de la cible. Une étude approfondie de la cible et de son infrastructure est donc fortement probable ».

Ce type de mode opératoire n’est pas isolé. On le retrouve dans bon nombre d’attaques par ransomware. Cela vaut ainsi pour les cas Friedex/BitPaymer, comme le relevait l’Anssi à l’automne dernier : après quelques jours de reconnaissance, les assaillants déploient, « le week-end et au milieu de la nuit, la charge de chiffrement », expliquait alors l’Agence, « notamment sur les systèmes de sauvegarde de fichiers restés connectés ». Ryuk, MegaCortex, ou encore Crytomix Clop, qui a fait parler de lui notamment avec le CHU de Rouen, n’échappent pas à la règle.

Une reconstruction laborieuse

Dans un tel contexte, les défis techniques à relever sont nombreux. Gérôme Billois, directeur de la practice Cybersécurité de Wavestone, fort de l’expérience acquise à l’occasion de plusieurs interventions, le soulignait à l’époque.

La première difficulté peut consister à accéder aux sauvegardes. Car il n’est manifestement pas si rare que « les serveurs de sauvegarde aient été eux-mêmes chiffrés ». Là, « on a les cartouches de sauvegarde, mais on n’a plus le lecteur et l’index – ou le catalogue – qui permet de savoir où sont les données sur les sauvegardes ». A ce stade, la question de savoir si l’on choisit de restaurer ou pas à partir d’elles, en fonction de l’ampleur supposée de la compromission, ne se pose donc même pas. Et pour reconstruire l’index des sauvegardes, « souvent, c’est plusieurs jours » de travail avec les outils disponibles sur site.

Mais pour ne rien gâcher, « le serveur de sauvegarde est très souvent lui-même dépendant de l’annuaire ». Alors pour Gérôme Billois, l’une des principales mesures à prendre avant un incident, consiste « à s’assurer que les procédures de restauration peuvent être lancées même dans une situation où il n’y a plus les fonctions de support classiques ». La question étant : « imaginons un cas où il n’y a plus rien ; combien de temps faut-il pour accéder à nouveau aux sauvegardes » ?

Mais dans un cas où l’on est amené à soupçonner une atteinte à l’intégrité de l’annuaire, la restauration apparaît bien difficile. « Dans un cas pareil, on repart d’une infrastructure de base, en réinstallant de zéro. Et on en profite pour appliquer les bonnes règles d’architecture Active Directory qui, bien souvent, ne l’étaient pas avant ». De là, il devient possible d’envisager de récupérer prudemment, en les nettoyant soigneusement si nécessaire, les données d’applications qui n’étaient pas la cible de l’attaque.

D’aucun soupçonnent que l’université de Gießen, en Allemagne, ait été récemment confrontée à une telle situation, même si elle n’a pour l’heure communiqué que très sporadiquement sur l’épisode de ransomware dont elle a été victime en décembre 2018.

Chercher les signaux faibles

Dans un tel contexte, la prévention joue un rôle déterminant. Et cela d’autant plus qu’à la demande de rançon s’ajoute la menace de divulgation de données personnelles, voire sensibles, dérobées avant la détonation. De quoi infliger une sévère peine multiple aux organisations affectées – notamment dans le contexte du règlement général de protection des données (RGPD).

Andrew Thompson, chez FireEye/Mandiant, il faut notamment se concentrer sur les signaux faibles, car après « les téléchargeurs, ou étapes initiales, [qui] sont des choses personnalisées comme Dridex, Trickbot, Emotet, Terraloader/Squid », la suite passe « par des outils de sécurité offensive [OST, Offensive Security Tool] ». Et d’expliquer ainsi que les « utilisateurs/clients » des outils téléchargeurs initiaux « déploient Empire, Metasploit, Cobalt Strike, PoshC2, etc. ».

Pour mémoire, l’Anssi recommandait justement récemment de « porter ses efforts de détection » sur Powershell Empire et Dridex. C’était dans le cadre de l’alerte qu’elle lançait face à la menace Friedex/Bitpaymer.

Dans le cadre de LockerGoga, Félix Aimé recommandait de bloquer tous les serveurs de commande et de contrôle connus de Cobalt Strike, relevant que la plupart de ceux-ci, n’étant pas mis à jour régulièrement, « sont largement liés à des cochonneries (APTs, débutants, et autres) ».

Et de conseiller également d’activer la traçabilité de Powershell, « bloquer les appels entrants sur le port 445 des servers et des postes de travail en utilisant le pare-feu local, bloquer toutes les communications [de commande et de contrôle] avec la certification Cobalt Strike par défaut, prévenir l’utilisation de PSexec via Applocker ou en utilisant votre solution d’EDR préférée ».

Some flavors of #Emotet, which other flavor you know??? pic.twitter.com/uzSUow0GpX

— \_(ʘ_ʘ)_/ (@pollo290987) January 7, 2020

Et il convient encore de ne pas oublier les outils et services légitimes, susceptibles d’être détournés par les assaillants à leur profit, à l’instar de ceux permettant le déport d’affichage ou l’administration de systèmes. Pour LockerGoga, l’Anssi indiquait ainsi que l’assaillant « prend le contrôle d’au moins un compte administrateur et effectue différents rebonds via le protocole RDP dans l’infrastructure ciblée pour ensuite déposer ses outils dans des serveurs spécifiques ».

Accessoirement, sur certains incidents, la console d’administration des outils de protection des postes de travail s’est même vue détournée pour déployer les charges malicieuses…

Identifier et protéger les points d’entrée

Mais la protection commence avant cela, au niveau des points d’entrée. L’un des plus affectés reste la messagerie électronique. Et c’est là qu’Emotet ne manque pas de faire régulièrement parler de lui. Pour Marcus Hutchins, le menace est à prendre très au sérieux : « si vous êtes alerté d’une infection par Emotet ou Trickbot sur votre réseau, nettoyez immédiatement. Les deux essaient de se diffuser à tous les systèmes du réseau. Et en cas de réussite, le ransomware Ryuk peut être déployé simultanément sur tous les ordinateurs ». Pire encore, Ryuk ne frappe pas au hasard, mais après une longue et prudente reconnaissance. Du coup, au moment du verrouillage des systèmes, « votre réseau a été infecté depuis des semaines voire des mois ».

Full network emotet (or trickbot) infection resulting in all servers and workstations infected with ryuk ransomware. I'm trying to laugh... But it's still raw :P

— Justin (@echoztrip) January 11, 2020

Mais voilà, le nettoyage, n’a rien de trivial. Kyle Hanslovan, PDG de Huntress Labs, le soulignait en mars 2019 : « chaque jour, notre équipe voit les réseaux de 5 à 15 clients touchés par Emotet. Le nettoyage peut prendre entre 3 jours et 3 mois suivant les compétences, les outils et la télémétrie disponibles ».

Et ce n’est pas la seule porte d’entrée. Le phénomène n’est pas nouveau : certains acteurs s’invitent directement via des services RDP exposés ouvertement sur Internet sans véritable sécurité, à commencer par une authentification de l’utilisateur au niveau du réseau (NLA, ou Network Level Authentification). Certaines vulnérabilités ne manquent d’ailleurs pas de les y aider, lorsque les correctifs requis n’ont pas été appliqués.

L’état américain du Texas a d’ailleurs émis plusieurs recommandations à la suite de l’attaque d’une vingtaine d’entités locales de gouvernement dans le courant de l’été dernier : « n’autoriser l’authentification sur les outils d’accès à distance que de l’intérieur du réseau du prestataire ; utiliser l’authentification à double facteur sur les outils d’administration à distance et des tunnels VPN plutôt que RDP ; bloquer tout le trafic entrant provenant de nœuds de sortie Tor ; bloquer tout le trafic sortant vers Pastebin ; des outils d’EDR pour détecter les scripts PowerShell exécutant des processus inhabituels ».

Mais d’autres systèmes servant de point d’entrée sur le système d’information peuvent être affectés par des vulnérabilités, à l’instar de serveurs de réseau privé virtuel (VPN). Le rançongiciel Revil/Sodinokibi ne manque ainsi pas d’être distribué via des serveurs VPN Pulse Secure laissés vulnérables. Travelex est soupçonné d’en avoir fait les frais. Et d’aucuns s’attendent à ce que la vulnérabilité CVE-2019-19781 affectant les systèmes Citrix/Netscaler ADC/Gateway soit également prochainement exploitée avec le même objectif.

Se préparer au pire

Face à la difficulté de la protection et aux défis de la reconstruction, même avec les meilleures volontés, il apparaît essentiel de se préparer à la gestion d’incident – y compris lorsque la menace est arrêtée tôt dans la chaîne d’attaque. Et cela d’autant plus qu’une crise de cybersécurité n’est pas une crise IT.

Jérôme Saiz, d’Opfor Intelligence, le soulignait récemment dans nos colonnes : la principale différence tient au fait qu’un plan de reprise de l’activité (PRA) traditionnel ne tient pas compte de la présence d’un assaillant. De fait, avec un PRA, il s’agit de « remettre l’outil informatique debout le plus vite possible », quitte à effacer des traces ou à prendre des raccourcis susceptibles de conduire à une recompromission très rapide. Mais par exemple, « dans une crise cyber, il faut considérer que l’on n’a plus confiance en ses moyens de communication », avec tout ce que cela peut avoir comme vastes implications – or, « les plans de secours informatiques considèrent, implicitement ou explicitement, que les moyens de communication sont accessibles ».

Maersk, Fleury Michon ou Norsk Hydro, voire même Altran et le groupe M6, ont sûrement des histoires à raconter dans le domaine, même si tous ne se prêtent pas à l’exercice, et c’est bien regrettable.

Mais même d’une crise comme celle traversée par Travelex, il y a au moins un enseignement à tirer : préparer une solide réponse à un incident affectant une fonction métier critique, est indispensable et implique bien plus que la seule DSI. De fait, comme le souligne Brian Honan dans les colonnes de ComputerWeekly (groupe TechTarget), « Travelex est rapidement devenu l’exemple de ce qu’il ne faut pas faire pour répondre à un incident de sécurité ».