Quand le docteur de données vous rend malade (mais nous décryptons son rançongiciel)

Que s'est-il passé?

Récemment, nous avons été contactés par Aon Nederland Cyber Solutions, l'un des plus grands courtiers d'assurance néerlandais et l'un de nos partenaires en matière de cyber-assurance. Une petite entreprise parmi leurs clients (spécialisée dans le transport) avait été attaquée par un rançongiciel. Le vendredi matin, tous les serveurs de la société de transport avaient cessé de fonctionner. Alors que le client avait effectué un dépannage de base et redémarré tous les systèmes, l'équipe informatique a découvert une note de rançon sur les systèmes concernés. La note était signée par « veri.doktoru@mail.ru » : « Veri Doktoru » signifiant « docteur des données » en turc. Nous avions apparemment affaire à un « médecin » des données turc qui rendait ses clients malades en les infectant avec un rançongiciel.

Le point d'entrée semblait assez simple : un ancien serveur avec de nombreux services exposés à Internet. En utilisant les mots de passe trouvés sur le premier système, l'attaquant a pu accéder (et chiffrer) d'autres systèmes, y compris le contrôleur de domaine.

La plupart des documents et la base de données hébergeant une application critique ont été chiffrés, et l'attaquant a écrasé et supprimé toutes les sauvegardes. Le modus operandi de l'attaquant était toutefois différent de ce que nous voyons habituellement : au lieu de déployer un logiciel malveillant qui chiffre les fichiers, cet attaquant utilisait des outils commerciaux et libres d'accès pour chiffrer les fichiers manuellement. Ensuite, il détruisait les sauvegardes et les fichiers originaux.

L'entreprise était désemparée. Elle avait perdu des années de documents et l'application qu'elle utilisait pour gérer son activité principale était hors ligne, les données étant inaccessibles. Elle avait sérieusement envisagé de payer une rançon de plusieurs dizaines de milliers d'euros.

Confinement de la menace

Après avoir déployé notre logiciel EDR à distance, nous sommes arrivés le jour même et avons commencé à contenir l'incident. Après avoir confirmé la situation, nous avons déployé notre logiciel agent sur tous les autres terminaux et nous avons vérifié qu'aucun serveur n'était accessible depuis Internet.

Après quelques heures de priorisation, nous avons décidé qu'il était préférable de récupérer physiquement le serveur de bases de données hébergeant l'application critique. Les bases de données étaient entièrement chiffrées : ce serveur avait probablement été le premier à être compromis.

Briser le chiffrement

Les attaquants ont utilisé un logiciel appelé « Steganos Backup 2012 » pour chiffrer les fichiers sur le serveur. Au début, cela semblait être un choix étrange, le logiciel n'étant plus vendu ou maintenu par le fabricant. Il était cependant assez léger et possédait une fonctionnalité de chiffrement intégrée. Cela le rendait assez portable et donc facilement déployable sur des systèmes distants auxquels l'attaquant avait accès.

Nous avons commencé par faire des copies numériques des disques du serveur afin de maximiser les chances de récupérer les données. Pendant ce temps, nous avons jeté un coup d'œil à « Steganos Backup 2012 ». Ce logiciel n'avait probablement pas fait l'objet d'un examen approfondi de la part de la communauté de sécurité et si nous pouvions casser le chiffrement, nous pourrions remettre l'entreprise en marche.

Après avoir testé le logiciel, nous avons rapidement remarqué quelque chose d'étrange : un mot de passe était requis pour restaurer la sauvegarde, mais pas pour créer une nouvelle sauvegarde des mêmes fichiers. Nous avons soupçonné que la clé de chiffrement de la sauvegarde était stockée quelque part. Après quelques heures de rétro-ingénierie, nous avons fait une découverte encore plus intéressante : le mot de passe original était stocké dans le profil de la sauvegarde. Il était chiffré en utilisant AES avec une clé de 256 bits. Un algorithme de chiffrement parfaitement adapté, mais la clé semblait être stockée dans le programme de sauvegarde lui-même. À 1h30 du matin, nous avions enfin le mot de passe que les attaquants avaient utilisé pour chiffrer les fichiers et la base de données de l'application (et nous pouvions enfin aller nous coucher !).

Déchiffrement des données

Le lendemain matin, nous avons commencé à récupérer la base de données et les documents. Après avoir confirmé que tout semblait fonctionner normalement, nous avons contacté le client. Il était très satisfait et a pu déchiffrer toutes les données du système en utilisant le même mot de passe. Le soir même (moins de 48 heures après la découverte de l'attaque), son application la plus importante fonctionnait et il a pu reprendre ses activités.

Cette attaque n'était pas très sophistiquée, mais tout de même assez efficace. En utilisant un logiciel commercial, l'attaquant n'a pas eu besoin de consacrer du temps ou de l'argent à développer un rançongiciel personnalisé, à contourner les logiciels antivirus, etc. Bien que l'attaquant change probablement de modus operandi, nous espérons que cet article aidera les victimes de ce groupe de cybercriminels à récupérer leurs données. Vos fichiers ont-ils été chiffrés avec cette méthode ? Nous avons préparé un script en Python pour récupérer le mot de passe du fichier « localParams » de Steganos Backup 2012.

decryptSteganos.py

#!/usr/bin/python3
# Decrypts localParams file from Steganos Backup 2012 profiles
# This file can be found in:
# %APPDATA%\Local\Steganos Backup\plans\<profile_id>\control

import sys
from Cryptodome.Cipher import AES
from Cryptodome.Util.Padding import unpad

key = b"\xd7\x34\x73\x4e\xd8\x70\x2c\x2b\x34\xfa\x10\xad\x40\x17\x43\x25\x77\xfd\x02\xc8\xec\x6f\x1c\xb0\xae\x95\xed\xb2\xc5\xad\x47\x69"

contents = open(sys.argv[1], "rb").read()
iv = contents[:16]
data = contents[16:]

aes = AES.new(key, AES.MODE_CBC, iv)
print("Password: '%s'" % unpad(aes.decrypt(data), 16).decode("utf-8"))

Avez-vous déjà été victime d'attaques par rançongiciels ? Nous vous suggérons de consulter la page suivante pour voir si une solution est disponible : https://www.nomoreransom.org/ 

Reprise des activités

Le client a eu une mauvaise expérience avec un rançongiciel, où ses données ont été chiffrées pendant une courte période. Payer une rançon aux criminels était une option, mais ce n'est jamais la meilleure solution. Le client a été extrêmement satisfait de nos efforts pour déchiffrer ses données. Mais ce qui est le plus important pour nous, c'est qu'il a pu reprendre ses activités le lundi, trois jours après l'incident.

L'attaquant est le seul à être déçu dans cette histoire. Au lieu de recevoir 50 000 €, il n'a rien obtenu cette fois-ci…