VMDK Data Recovery After an Akira Ransomware Attack
Récupération de données VMDK
Environnement :
Parc VMware sauvegardé par Nakivo sur un Synology RS3621RPXs à 12 baies, RAID 5, BTRFS
Attaque :
Rançongiciel Akira
Données à risque :
Environ 11 To de sauvegardes de machines virtuelles chiffrées, le reste ayant été supprimé
Complication :
Environ 15 To de données écrites sur le même volume le lendemain de l'attaque
Résultat :
99,91 % récupéré sur le serveur de base de données prioritaire
Une organisation d'entreprise multi-sites a subi une attaque par le rançongiciel Akira, laquelle a perturbé l'accès à des systèmes virtualisés critiques et exposé des pans importants de son environnement de production à un risque significatif. Environ 11 To de sauvegardes de machines virtuelles conservées dans le référentiel Nakivo du client ont été chiffrées. Les sauvegardes restantes ont été supprimées.
La même attaque a chiffré les machines virtuelles de production, privant l'organisation des données nécessaires au rétablissement de ses activités.
En l'espace de quelques jours, l'organisation a fait appel à son assureur cyber ainsi qu'à un cabinet de réponse aux incidents. Les méthodes de restauration classiques ont permis de récupérer certaines parties de l'environnement, mais n'ont pas pu restaurer plusieurs machines virtuelles prioritaires. Le cabinet de réponse aux incidents a alors fait appel à DriveSavers Data Recovery pour déterminer si des données exploitables pouvaient encore être récupérées à partir du support de stockage concerné, et si les disques des machines virtuelles endommagées pouvaient être reconstruits.
Au moment où les disques sont arrivés chez DriveSavers, le chiffrement causé par le rançongiciel n'était plus le seul problème en jeu.
L'analyse technique réalisée à l'aide de notre outil propriétaire de récupération de disques virtuels a permis d'identifier environ 15 To de données écrites sur le volume le lendemain de l'attaque, soit après que les sauvegardes Nakivo avaient déjà été supprimées. Ces écritures se sont révélées lourdes de conséquences.
Supprimer un fichier sur BTRFS n'efface pas son contenu. Les systèmes de fichiers de ce type marquent généralement les blocs concernés comme disponibles pour une réutilisation, tandis que les données elles-mêmes restent en place jusqu'à ce que quelque chose soit écrit par-dessus. Les écritures effectuées après l'attaque ont été affectées à des blocs qu'occupaient les sauvegardes supprimées.
Une analyse technique plus poussée a révélé qu'une part nettement plus importante des informations ciblées, voire potentiellement leur intégralité, aurait probablement pu être récupérée si le support de stockage concerné était resté inchangé.
Le support arrivé chez DriveSavers contenait donc un mélange de données originales intactes, de données chiffrées par le rançongiciel, de données supprimées et réattribuées, d'informations nouvellement écrites, de structures de système de fichiers endommagées, ainsi que des blocs partiellement écrasés. Environ 3 600 fichiers, totalisant 16,1 To, sont demeurés actifs, dont 99 % étaient des disques virtuels VMware et des instantanés dont l'extension avait été réécrite en « .AKIRA ».
Une caractéristique de l'attaque a joué en faveur d'un résultat plus favorable. L'algorithme de chiffrement utilisé lors de cet incident ne chiffrait pas les fichiers dans leur intégralité. Il chiffrait environ 15 % de chaque fichier, répartis en trois bandes, ce qui, sur les VMDK volumineux, se traduisait par un chiffrement d'environ 5 % en tête de fichier. De vastes portions de chaque disque virtuel sont ainsi demeurées intactes. Une analyse au niveau des blocs s'est avérée nécessaire pour identifier ces zones intactes.
Une évaluation à distance a permis de confirmer l'étendue du projet et de déterminer si la récupération pouvait être menée à bien à distance ou nécessitait un travail en laboratoire. Récupérer ces données impliquait de lire l'ensemble des douze disques au niveau des secteurs, y compris les zones que le système de fichiers ne référençait plus ; or, un accès à distance à un NAS en fonctionnement atteint généralement le volume logique plutôt que le support physique sous-jacent. La récupération à distance s'est donc révélée impossible. Un ingénieur a récupéré les disques à l'aéroport international de San Francisco le dimanche soir suivant.
Les douze disques ont tous été imagés dans les 24 heures suivant leur arrivée, et chaque opération ultérieure a été exécutée sur ces images. Les supports d'origine sont demeurés tels que reçus tout au long du processus, ce qui a permis de préserver l'état des preuves pendant que l'analyse se poursuivait.
Analyser environ 120 To une image à la fois n'aurait pas été viable. Les ingénieurs ont divisé le travail en tranches d'un téraoctet et ont lancé dix analyses simultanément, ce qui a permis d'atteindre les limites de débit du matériel lui-même. Un second jeu d'images a ensuite été constitué sur un second système, afin que les extractions puissent se dérouler simultanément sur les deux machines.
À mesure que les données étaient supprimées, BTRFS avait commencé à effacer la couche qui associe les données stockées à leurs emplacements physiques. Environ 7 To de cette carte ont été affectés, produisant des résultats inutilisables à partir d'un support par ailleurs lisible. Les ingénieurs ont déterminé que les zones concernées avaient été allouées de façon contiguë avant la suppression, ce qui a rendu possible une reconstruction manuelle. La reconstitution manuelle de la carte a permis de rétablir l'accès à environ 5 To de données de sauvegarde que le système de fichiers avait déjà libérées.
Un fichier VMDK endommagé est rarement simplement lisible ou illisible. Les ingénieurs ont séparé les zones intactes de celles qui étaient chiffrées, corrompues, partiellement écrasées ou structurellement endommagées. Les trois machines les plus prioritaires comportaient chacune cinq ou six points de restauration, le plus récent ayant été pris peu avant l'attaque, pour un total de 35 fichiers VMDK. Les dommages affectaient 3 à 5 % de chacun de ces fichiers. Sur l'une des trois machines, le chiffreur n'avait absolument pas atteint les fichiers de disque virtuel.
Lorsque les données de sauvegarde à elles seules ne couvraient pas un jeu de données, les ingénieurs ont intégré les zones non chiffrées des disques virtuels de production. Cette approche s'est révélée efficace, bien qu'elle ait exigé une grande prudence. Deux des trois machines prioritaires comportaient également des fichiers d'instantanés, qui n'entretiennent pas de relation biunivoque avec les données qu'ils représentent. Les structures faisant correspondre les fichiers d'instantanés aux données qu'ils représentaient se trouvaient dans les zones chiffrées. Utiliser les disques virtuels de production pour combler les lacunes risquait donc d'introduire des données plus anciennes et de provoquer une corruption difficile à retracer par la suite. Les ingénieurs ont évalué le risque propre à chaque jeu de données plutôt que de procéder à une fusion systématique.
DriveSavers a collaboré avec le cabinet de réponse aux incidents et le client pour déterminer à l'avance dans quel environnement les disques seraient réimportés. Les données extraites au niveau des fichiers ont d'abord été restituées via le réseau, ce qui a permis au client d'accéder à des fichiers spécifiques pendant que le reste des travaux se poursuivait. Les fichiers VMDK complets, prêts à être réimportés, ont suivi.
DriveSavers a mené la mission sous la forme de sept sous-missions distinctes, dont le périmètre était clairement délimité, avec plusieurs ingénieurs travaillant en parallèle, afin que les systèmes les plus prioritaires puissent être traités et restitués avant le reste de l'environnement.
DriveSavers a précisé tout au long de la mission, tant au cabinet de réponse aux incidents qu'au client, que rien ne garantissait le démarrage des fichiers VMDK reconstruits. Au moins une machine virtuelle récupérée a effectivement démarré. Les autres ont été restituées sous forme de données récupérées et de disques réparés.
Chaque disque virtuel réparé était accompagné d'un rapport au niveau des blocs indiquant précisément quelles zones du disque étaient saines et lesquelles présentaient des dommages irrécupérables, avec un décompte des objets, fichiers, répertoires et octets pour chacune. Pour les équipes techniques chargées de reconstruire un environnement, ce type de rapport fournit des informations considérablement plus détaillées qu'une simple mention « récupéré » ou « non récupéré ». Il permet aux administrateurs d'évaluer la qualité d'une image récupérée et de déterminer si une récupération supplémentaire au niveau des applications, une extraction de fichiers ou une reconstruction s'avèrent nécessaires.
Lorsqu'une application de sauvegarde ne parvient pas à mener à bien une restauration, les données sous-jacentes peuvent malgré tout être encore présentes sur le support de stockage. Ce référentiel avait été chiffré, vidé, puis écrasé avant même d'être confié à un spécialiste de la récupération, et la reconstruction au niveau des blocs a néanmoins permis de restituer les systèmes dont l'entreprise avait le plus besoin.
Récupérer des données de machines virtuelles dans de telles conditions exige des connaissances spécialisées, des outils propriétaires, ainsi qu'un développement sur mesure adapté au système de fichiers spécifique concerné. Lorsqu'un rançongiciel frappe simultanément les systèmes de production et l'infrastructure de sauvegarde, la récupération spécialisée de données après rançongiciel peut offrir une voie technique là où la restauration classique échoue.
Vous êtes confronté à une situation similaire ? Contactez DriveSavers au 1 (888) 282-2227.
English (United States) 
English (Australia) 
French (France) 
English (UK) 
French (Canada) 
English (Canada) 
Spanish (Mexico) 
German 
Dutch 
Italian 
Finnish 
Polish 
Norwegian 
Swedish 
Danish 
Spanish (Spain) 
Chinese 
Japanese 
German (Austria)