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

vraiment trop tard

Valéry Marchive, Rédacteur en chef

Longtemps, le message fut simple : « contre les rançongiciels, soignez vos

sauvegardes ». Il apparaît désormais bien insuffisant. Car les cyberdélinquants aux
manettes ne frappent pas au hasard : après une intrusion initiale, ils se déplacent
patiemment dans l’environnement de leur victime pour accéder aux outils qui leur
permettront de distribuer largement leur charge malicieuse, avant de la faire détoner.

Le résultat est alors aussi spectaculaire que dramatique : une grande partie – sinon
l’ensemble – des ressources du système d’information commence à être chiffrée, d’un
seul coup, sans que rien de bien visible ne le laisse présager.

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 ».

pic.twitter.com/uzSUow0GpX

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é ».
 Accéder à plus de contenu exclusif PRO+
Vous avez accès à ce PDF en tant que membre via notre offre PRO+ : une collection
de publications gratuites et offres spéciales rassemblées pour vous par nos
partenaires et sur tout notre réseau de sites internet.

L’offre PRO+ est gratuite et réservée aux membres du réseau de sites internet
TechTarget.

Profitez de tous les avantages liés à votre abonnement

sur: http://www.lemagit.fr/eproducts
©2019 TechTarget. Tout ou partie de cette publication ne peut être transmise ou reproduite dans quelque forme ou de
quelque manière que ce soit sans autorisation écrite de la part de l’éditeur.