La vérité sur le malvertising ?

Splunk SURGE a récemment publié un livre blanc, un blog et une vidéo qui décrivent les vitesses de chiffrement de 10 familles de ransomwares différentes. Au début de notre recherche, lors de la phase de revue de la littérature, nous avons découvert qu’un autre groupe avait mené une étude similaire sur les vitesses de chiffrement des ransomwares. Et qui était ce groupe, me demandez-vous ? Tenez-vous bien : c’était justement l’une des équipes qui produisent ces ransomwares. LockBit a publié les résultats sur son site web (et nous ne mettrons pas de lien ici car c’est un site .onion peu recommandable), dans le but de convaincre des affiliés potentiels de rejoindre l’équipe de LockBit, car ils étaient les plus rapides et donc les meilleurs. Une chose était claire : une fois notre étude terminée, il faudrait tester les conclusions de LockBit.

Lisez la suite pour tout savoir !

Dites-m’en plus sur le rapport LockBit

LockBit a publié son rapport en février 2021. Le groupe a testé les vitesses de chiffrement de 36 variantes de ransomwares différentes, dont deux des leurs : LockBit 1.0 et LockBit 2.0. LockBit 1.0 était déjà considéré comme l’un des rançongiciels les plus rapides, sinon le plus rapide. Dans ces conditions, pourquoi créer LockBit 2.0 ? Et cette nouvelle version est-elle réellement plus rapide ?

^{Fig. 1. Capture d’écran de la comparaison par LockBit des vitesses de chiffrement des ransomwares.}

Les résultats montrent que LockBit 2.0 était en effet plus rapide que LockBit 1.0, et que les deux étaient loin devant les autres variantes de ransomware. Selon ces données, LockBit 2.0 était deux fois plus rapide que la variante non-LockBit la plus proche, Cuba. LockBit a inclus les échantillons de ransomware sur son site web avec cet appel à l’action : « Si vous avez des doutes concernant ce tableau, vous pouvez facilement vérifier les informations fournies en téléchargeant les échantillons qui ont été utilisés pour les tests. »

Nous avons voulu tester Lockbit 3.0 (mentionné dans ce blog), mais malgré des heures de recherche sur Google, de supplications sur Twitter et d’envoi de messages à des groupes Keybase et Slack secrets… nous n’avons pas pu en trouver un seul échantillon !

Avions-nous des doutes sur la rapidité de LockBit ? Non. Avions-nous des doutes sur leurs conclusions générales ? Oui. Nos recherches initiales ont révélé que la vitesse de chiffrement de Babuk était beaucoup plus proche de celle de LockBit que ce que LockBit avait rapporté. Après ce constat, nous savions qu’un plan de test complet était indispensable pour débusquer les autres erreurs.

Les tests de LockBit

Le tableau de LockBit était la seule référence dont nous disposions pour reproduire cette expérience. LockBit fournit les détails suivants :

• Nom du rançongiciel
• Date de l’échantillon
• Vitesse de chiffrement en Mo/s
• Temps de chiffrement de 100 Go
• Temps de chiffrement de 10 To
• Auto-propagation ?
• Taille de l’échantillon
• Nombre total de fichiers chiffrés

S’il y a un aspect sur lequel nous aurions voulu avoir davantage d’informations, c’est le jeu de données que LockBit a utilisé pour l’expérience de chiffrement. Cela nous aiderait à mieux comprendre certaines de leurs découvertes, comme le temps nécessaire pour chiffrer 100 Go et 10 To. Ont-ils utilisé des types et des tailles de fichiers variés, ou ont-ils utilisé des milliers de copies du même fichier pour tester le chiffrement ?

LockBit a fourni les spécifications du système d’exploitation, du processeur et de la mémoire qu’ils ont utilisés dans leurs tests. Pour le disque dur, ils mentionnent un SSD, mais rien sur les IOPS ou le débit des disques sous-jacents. Ce blog donne un aperçu de haut niveau de l’impact que peuvent avoir les IOPS et le débit sur les performances des applications. Nous avons constaté dans nos recherches initiales que la vitesse du disque est tout aussi importante que la vitesse du processeur et le nombre de processeurs en ce qui concerne les performances de chiffrement globales.

Synthèse des résultats des tests de LockBit :

• 1re place : LockBit 2.0
• 2e place : LockBit 1.0
• 3e place : Cuba
• Dernière place : Avos

Nos Essais

Pour ces tests, nous avons utilisé la même approche que dans notre projet de recherche précédent. Nous avons créé un environnement identique pour chaque variante testée. Une version modifiée de Splunk Attack Range a été utilisée pour créer les systèmes dans Amazon Web Services (AWS). Le système « victime » présentait les spécifications suivantes :

• Windows Server 2016
• Type d’instance AWS EC2 : c5.2xlarge
• Nombre et type de processeurs : 8 x Intel Xeon 3,4 GHz
• RAM : 16 Go
• Disque : GP3 (débit de 16 000 IOPS ou 1 000 Mo/s)
• 98 561 fichiers de test répartis dans 100 répertoires (différents types et tailles de fichiers)

Ce sont les spécifications les plus proches que nous avons pu trouver dans AWS pour répliquer les tests de LockBit. La vitesse du disque était la plus élevée disponible, mais elle était la même pour toutes les variantes. Et comme mentionné précédemment, nous avons utilisé notre ensemble de données « victime », contenant de nombreux types et tailles de fichiers, afin de répliquer au mieux un système de fichiers réel.

Nous avons testé chaque variante individuellement pour éviter toute contamination par d’autres variantes susceptibles de se propager latéralement au cours de l’expérience. Chaque variante a été lancée manuellement, car certaines ne fonctionnent pas bien lorsqu’elles sont lancées via PowerShell (oui Babuk, je parle de toi). Nous avons effectué une observation manuelle via RDP pour confirmer l’aboutissement de chaque test.

Dans notre laboratoire, nous avons également configuré un serveur Windows 2019 agissant en tant que contrôleur de domaine. Il n’avait pas de disques partagés, mais aucune règle de pare-feu sur le système ou AWS n’empêchait l’accès entre celui-ci et le système « victime » initial.

Et le gagnant est...

Avant les révélations, sachez simplement que nos résultats étaient proches de ceux de LockBit, mais pas identiques. Et je pense que vous pouvez avoir davantage confiance en nous qu’en une équipe de pirates à la fois juge et partie dans ses tests.

Cela dit, LockBit encore une fois remporté la première place lors de nos tests. Mais pas LockBit 2.0 ! LockBit 1.0 était en fait plus rapide que son homologue plus récent. Pas de beaucoup, mais tout de même.

Temps de chiffrement total :

• LockBit 1.0 : 2 minutes 20 secondes
• LockBit 2.0 : 2 minutes 30 secondes

Cependant, LockBit 2.0 est beaucoup plus efficace que 1.0 : il utilise deux fois moins de threads CPU et accède au disque 27 fois de moins. Il semble donc que LockBit ait apporté un certain nombre d’améliorations entre ces deux versions, mais pas dans le domaine de la vitesse globale.

Mais LockBit 2.0 est quand même arrivé juste derrière 1.0, non ? Tout faux. Une autre variante a fait reculer LockBit 2.0 d’une place !

• PwndLocker : 2 minutes et 28 secondes

Petit résumé de nos résultats :

• 1re place : LockBit 1.0
• 2e place : PwndLocker
• 3e place : LockBit 2.0
• Dernière place : Avos

PwndLocker, LockBit 1.0 et LockBit 2.0 exécutent des méthodes de chiffrement partiel similaires, ce qui permet d’accélérer le chiffrement.

LockBit 2.0 ne chiffre que les 4 premiers Ko d’un fichier et laisse le reste intact. C’est encore suffisant pour rendre la plupart des fichiers inutilisables après le chiffrement.

^{Fig. 2. Capture d’écran d’un exemple de fichier .txt chiffré par LockBit 2.0 (les 4 premiers Ko, en rouge, ont été chiffrés et le début du reste, en vert, n’a pas été modifié).}

PwndLocker ne touche pas aux 128 premiers octets, chiffre seulement les 64 Ko suivants et laisse le reste intact.

^{Fig. 3. Capture d’écran d’un exemple de fichier .txt crypté par PwndLocker (128 octets non chiffrés en vert, chiffrement des 64 Ko suivants en rouge).}

Et notre variante la plus rapide, LockBit 1.0, chiffre 256 Ko de chaque fichier très rapidement en utilisant un nombre élevé de threads CPU ainsi qu’un grand nombre d’accès au disque.

Les variantes les plus rapides ont tendance à utiliser des méthodes de chiffrement partiel, davantage de threads CPU ou une combinaison des deux.

Avos termine bon dernier dans le test de LockBit comme dans le nôtre. Cependant, en dehors de ce classement, peu de résultats coïncident entre les deux séries de tests. Nous avons ajouté un tableau détaillé de nos résultats de test indiquant les statistiques de chiffrement à la fin de ce blog.

Voici le tableau comparant nos résultats de test à ceux de LockBit.

Notre principale hypothèse concernant les divergences entre les résultats est l’utilisation de différents types et tailles de fichiers. Si nous savions quel ensemble de données LockBit a utilisé, nous aurions plus d’informations sur les résultats de leurs tests.

Les enseignements

Après cette expérience, voici quelques points clés et recommandations :

• Partez du principe qu’une fois qu’une équipe de pirates a atteint le stade où elle peut chiffrer vos systèmes, il est trop tard.
• LockBit est très rapide, mais ce n’est pas la seule variante de ransomware capable d’atteindre des vitesses extrêmement élevées. D’autres variantes utilisent également des techniques de chiffrement partiel pour accélérer leurs opérations.
• Protégez votre organisation avant l’exécution du rançongiciel. Assurez les fondamentaux (correctifs, sauvegardes hors ligne) et mettez en place des dispositifs qui devraient aujourd’hui être considérés comme de la cyberhygiène de base : authentification multifacteurs, segmentation du réseau, journalisation centralisée.

Conclusion

Il était intéressant d’utiliser dans nos tests les mêmes échantillons que LockBit. Si le classement des échantillons les plus rapides et les plus lents était étroitement aligné entre les tests, entre ces extrêmes, les résultats étaient très différents. Cependant, le temps total nécessaire au chiffrement de notre système de fichiers de test était encore assez court, même dans les tests les plus lents, ce qui nous incite à réitérer notre recommandation de regarder en amont de l’explosion lorsque vous hiérarchisez vos défenses réseau.

Bonne chasse !

Annexe

Statistiques de chiffrement de nos tests :

Valeurs de hash SHA256 des fichiers des échantillons testés :

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

^{Photo principale/d’en-tête par Artem Beliaïkin de Pexels}

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