Retour sur le dernier succès après l'infection par Dagon
Un spécialiste de l’aéronautique dans le Sud Ouest de la France nous contacte après la demande de rançon du ransomware Dagon. L’entreprise refuse de payer la rançon.
Retour en quelques lignes sur cette nouvelle réussite technique.
Environnement du client
Nous recevons un appel le 1 novembre pour une demande d’intervention sur site, afin de récupérer les données d’une entreprise à l’arrêt suite à la destruction de son SI. Le client n’ayant pas de solution de réparation pour accéder au serveur ou de réintégration proposée par le support HP, malgré le paiement d’un niveau de support supplémentaire.
L’entreprise demande une intervention sur site pour rétablir les accès aux sauvegardes Veeam cryptées sur l’un de ses serveurs HP Store Easy. L’architecture est composée d’un serveur sous Windows Server 2012 R2 avec plusieurs volumes dont un RAID 6 de 14 disques / 20 To avec une extension de 12 disques / 24 To. L’attaque par Dagon a eu lieu lors du pont du 1er Novembre.
Après avoir échangé avec le client sur les modalités d’intervention, Recoveo a dès lors mobilisé une équipe dédiée qui s’est déplacée dans la banlieue toulousaine pour intervenir au cœur du datacenter incriminé.
La solution RAID 112
Un des experts nous décrit le processus suivi :
- Comme le serveur a déjà été arrêté par le client, la première étape consiste d’abord à sécuriser notre intervention, en réalisant l’acquisition forensique en copiant en bas niveaux tous les disques impactés sur des clones. Nous avons réalisé cette opération grâce à nos propres serveurs et disques déplacés pour l’occasion.
- Nous avons connecté les 26 clones sur notre serveur spécifique pour procéder à l’analyse des paramètres RAID. La configuration Raid du serveur était très atypique avec un premier volume ‘OS’ en Raid5, un autre volume en RAID6 sur l’extension agrégé en JBOD logiciel avec le dernier volume en RAID5 provenant du serveur. C’est cette partition résultante qui contenait les données importantes. Nous avons émulé les différents Raids avec nos logiciels, ce qui nous a permis ensuite d’analyser les systèmes de fichiers NTFS.
- Sur place, nous avons vérifié le degré de chiffrement et son impact sur l’intégrité des backups Veeam. Certains contenus ont été chiffrés, d’autres n’ont pas été impactés grâce à la réactivité de l’équipe technique du client qui a interrompu le processus de chiffrement.
- Comme le matériel sur place ne le permettait pas et pour maximiser la vitesse de traitement des fichiers prioritaires, décision prise en accord avec le client, nous avons réalisé l’extraction dans notre laboratoire principal de Roanne, sur un support supportant des taux de transferts très élevés. Ceci afin de permettre une reprise d’activité encore plus rapide.
- Dès le retour en pleine nuit dans nos locaux, les experts Recoveo ont procédé à l’extraction des fichiers Veeam Backup contenant les machines virtuelles qui contiennent elles-mêmes les bases de données nécessaires au fonctionnement de l’entreprise.
- L’envoi du NAS contenant les priorités est expédié en urgence chez le client. Le 5 novembre, l’entreprise redémarrait ainsi progressivement son système informatique.
- Comme une plainte a été déposée, les clones sont conservés plus longtemps (que nos autres cas de récupération de données plus classiques) dans la possibilité d’examens forensiques par les forces de l’ordre.
Les facteurs clés de cette réussite
- Nous pouvons souligner les bonnes pratiques mises en place par ce client qui rejoignent nos conseils présents dans notre livre blanc :
en parallèle de nos actions, le groupe a créé une cellule de crise pilotée par le DSI, avec une salle et des équipements dédiés afin de pouvoir donner les instructions aux différents sites dans le monde. - La Direction Générale a choisi de protéger cette équipe en interdisant aux différents sites de joindre cette équipe dans le but de limiter au maximum les interruptions par des appels répétitifs et les préserver de toute “sur-pression”.
- De même, les membres de l’équipe ont des consignes strictes : dormir au minimum 6 heures par nuits, ne pas travailler le samedi après midi et le dimanche et prendre un jour de repos si le besoin s’en fait ressentir. Ce afin de garder une équipe opérationnelle capable de prendre les bonnes décisions tout en minimisant le risque de burn out.
- Même si certains faits sont remontés au sein de cette cellule (pression de certains tiers), ces règles strictes ont permis à l’équipe de restée soudée et d’être efficace.
- L’objectif étant de laisser cette équipe travailler de manière hermétique en créant “une bulle” afin qu’ils aient suffisamment de recul pour prendre les bonnes décisions. Par exemple, en prenant la décision de ne pas se précipiter et de tenter de restaurer des backups défectueux sur les serveurs infectés, mais de plutôt sécuriser les disques importants en les copiant avant toute tentative.