52 secondes chrono… et 42 minutes : analyse comparative de la vitesse de chiffrement des ransomwares

Vous avez le sentiment que les ransomwares étaient cités dans tous les incidents de cybersécurité couverts dans la presse en 2021 ? Nous aussi, et en tant que fournisseur de cybersécurité, nous avons estimé que nous devrions contribuer au bruit ambiant. :-)

Mais nous avons eu envie de faire les choses un peu différemment.

En plus des nombreux outils Splunk de détection de ransomwares produits par notre équipe de recherche sur les menaces, nous avons voulu utiliser Splunk pour apporter de la nuance et des connaissances au brouhaha médiatique. Nous avons décidé de mesurer la vitesse à laquelle les ransomwares chiffrent les fichiers ; pas seulement un ou deux binaires, mais des dizaines, tout cela en utilisant Splunk.

Pourquoi ? Eh bien, en partie parce que nous avons une licence Splunk illimitée, mais aussi parce que nous ne trouvions pas la réponse à la question : « Combien de temps avez-vous avant que le ransomware n’ait chiffré tous vos systèmes ? ». C’est pourtant une information qui pourrait aider les entreprises à organiser leurs défenses. Si elles disposent de plus de 20 heures avant que le ransomware n’ait terminé de chiffrer les fichiers, elles peuvent choisir de se concentrer sur la détection et l’atténuation après l’infection. Si un ransomware chiffre l’intégralité d’un système en 52 secondes, elles ont tout intérêt à réagir plus tôt dans le cycle de vie de l’attaque.

Dans notre hypothèse initiale, nous sommes partis du principe que si un ransomware s’exécute sur un système, l’organisation n’a déjà plus le temps de réagir efficacement. Nous avons passé en revue les documents publiés sur la vitesse de chiffrement des ransomwares et n’avons découvert que des travaux de portée encyclopédique, réalisés par un groupe de pirates.

Le groupe LockBit a publié un tableau sur son site Tor (Fig. 1) répertoriant les vitesses de chiffrement de plus de 30 familles de ransomwares, démontrant (peut-être sans surprise) que LockBit était le plus rapide. Pour être honnête, je suppose que c’est logique ; vous ne publiez généralement pas d’articles publicitaires pour mettre en avant à quel point vous êtes mauvais. Nous avons ensuite examiné le temps de séjour des intrusions de ransomwares et avons constaté que le délai de trois jours cité par Mandiant dans son rapport M-Trends 2021 était assez représentatif. Cela nous a donné une bonne idée du « temps nécessaire à l’organisation pour réaliser qu’elle est infectée par un ransomware ».

^{Figure 1 : Analyse de LockBit des vitesses de chiffrement des ransomwares de différents groupes concurrents.}

Travail de préparation

Nous ne pouvions pas laisser à l’équipe marketing de LockBit le privilège de publier ce type de contenu. Nous avons donc retroussé nos manches et nous sommes attelés à créer un environnement qui nous permettrait de mener nos propres tests de vitesse de ransomware. Nous avons pris le vaste projet Splunk Attack Range créé par l’équipe de recherche sur les menaces de Splunk, et nous l’avons adapté à nos besoins.

^{Figure 2 : Schéma décrivant l’environnement de ransomware créé à l’aide d’une version modifiée de Splunk Attack Range.}

Nous avons créé quatre profils de « victime » différents à partir de systèmes d’exploitation Windows 10 et Windows Server 2019, chacun avec deux spécifications de performances différentes établies à partir des environnements de nos clients. Nous avons ensuite choisi 10 familles de ransomwares différentes et testé 10 échantillons de chacune de ces familles. La figure 3 présente les familles que nous avons testées, ainsi que les identifiants de détection Microsoft Defender de VirusTotal.

^{Figure 3 : Familles de ransomwares et identifiants de détection Microsoft Defender correspondants de VirusTotal.}

Nous avons testé chaque échantillon sur les quatre profils d’hôte, ce qui représentait 400 exécutions différentes de ransomwares (10 familles x 10 échantillons par famille x 4 profils). Afin de mesurer la vitesse de chiffrement, nous avons rassemblé 98 561 fichiers de test (pdf, doc, xls, etc.) à partir d’un corpus de fichiers publics, pour un total de 53 Go. Pour collecter les données nécessaires, nous avons utilisé à la fois la journalisation Windows native, les statistiques Windows Perfmon et Microsoft Sysmon, mais aussi Zeek et stoQ pour une analyse plus approfondie (vous retrouverez tout ça dans de prochains articles de blog, soyez patients).

Afin de capturer les événements de chiffrement, nous avons activé l’Audit au niveau de l’objet sur les 100 répertoires où résidaient nos fichiers de test. Nous avons ainsi obtenu des logs EventCode 4663 utilisables pour calculer le temps total de chiffrement (TTE) de chaque échantillon. Les échantillons que nous avons testés avaient DELETE comme valeur Accesses à la fin du chiffrement : c’est comme cela que nous avons mesuré la vitesse du processus. Les ransomwares ne se comportent pas tous de cette manière, si bien que la recherche EventCode=4663 Accesses=DELETE ne renvoie pas toujours les mêmes résultats.

Le braquage

Comme quand vous regardez 60 secondes chrono (la version avec Nicolas Cage, bien sûr), vous attendez les résultats dans un suspense intenable. Allons-y.

^{Figure 4 : Vitesse médiane de chiffrement mesurée sur 10 familles de ransomwares.}

Comme vous pouvez le voir, LockBit a été à la hauteur de sa publicité et a effectué le chiffrement le plus rapide parmi toutes les familles que nous avons testées. Nous avons indiqué la durée médiane car certaines familles avaient un ou deux échantillons susceptibles d’altérer la durée moyenne. Par exemple, LockBit avait l’échantillon le plus rapide avec quatre minutes et neuf secondes (Fig. 5). Babuk était juste derrière mais l’un de ses échantillons était le plus lent de tous les échantillons testés, avec plus de trois heures et demie (Fig. 6).

^{Figure 5 : L’échantillon de ransomware le plus rapide était un LockBit, capable de chiffrer des fichiers en quatre minutes et neuf secondes.}

^{Figure 6 : Babuk affiche la deuxième vitesse de cryptage médiane, mais aussi l’échantillon le plus lent à l’échelle individuelle : il lui a fallu plus de trois heures et demie pour chiffrer les fichiers.}

La fuite

Cette étude a fait l’objet d’un livre blanc completqui donne davantage de détails que cet article (j’ai de gros ennuis si je dépasse les 800 à 1 200 mots). Comme je l’ai mentionné plus tôt, notre ensemble de données va nous permettre de faire d’autres recherches. Nous prévoyons de publier les données sur le portail BOTS de Splunk à temps pour .conf22 (du 14 au 17 juin 2022). Vous pourrez ainsi analyser vous-même les données et peut-être découvrir des détails qui nous auraient échappés au cours de nos tests.

Enfin, vous vous demandez peut-être que faire de ces informations si vous êtes en charge de la protection du réseau. Si nous repensons à notre hypothèse initiale selon laquelle un ransomware est trop rapide pour qu’on puisse s’en défendre une fois qu’il a commencé à s’exécuter sur le système ciblé, il y a peut-être une piste à creuser. Commencez à regarder « à gauche de l’explosion », et évaluez vos capacités à prévenir ou à détecter le comportement du groupe de ransomwares. Authentification multifacteurs, segmentation du réseau, correctifs et journalisation centralisée (je n’ai pas pu m’en empêcher...) : ce sont autant d’excellentes stratégies pour renforcer vos défenses contre les ransomwares et tout autre acteur malveillant d’ailleurs (Nicolas Cage, c’est à toi que je pense). Et bien sûr, comptez sur SURGe pour mener précisément ce type de travaux au cours des prochains mois et cet été. Il faut bien que quelqu’un parle de ransomwares, n’est-ce pas ?

Bonne chasse !

Auteurs et contributeurs : Comme toujours, la sécurité chez Splunk est une affaire de famille. Crédit aux auteurs et collaborateurs : Shannon Davis, Ryan Kovar

_{*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.}