VMDK Data Recovery After an Akira Ransomware Attack
VMDK-Datenrettung
Umgebung:
VMware-Umgebung, gesichert von Nakivo auf einem 12-Bay-Synology RS3621RPXs, RAID 5, BTRFS
Angriff:
Akira-Ransomware
Gefährdete Daten:
Etwa 11 TB an verschlüsselten Backups virtueller Maschinen, der restliche Teil gelöscht
Komplikation:
Rund 15 TB, die am Tag nach dem Angriff auf dasselbe Volume geschrieben wurden
Ergebnis:
99,91 Prozent auf dem prioritären Datenbankserver wiederhergestellt
Eine standortübergreifend tätige Unternehmensorganisation wurde von einem Akira-Ransomware-Angriff getroffen, der den Zugriff auf kritische virtualisierte Systeme störte und erhebliche Teile ihrer Produktionsumgebung gefährdete. Rund 11 TB an Backups virtueller Maschinen, die im Nakivo-Repository des Kunden gespeichert waren, wurden verschlüsselt. Die verbleibenden Backups wurden gelöscht.
Derselbe Angriff verschlüsselte auch die produktiven virtuellen Maschinen und ließ die Organisation ohne die Daten zurück, die für die Wiederherstellung des Geschäftsbetriebs benötigt wurden.
Innerhalb weniger Tage zog die Organisation ihren Cyberversicherer sowie ein Incident-Response-Unternehmen hinzu. Konventionelle Wiederherstellungsmethoden konnten Teile der Umgebung zurückholen, versagten jedoch bei mehreren prioritären virtuellen Maschinen. Das Incident-Response-Unternehmen wandte sich daraufhin an DriveSavers Data Recovery, um zu klären, ob sich noch nutzbare Daten aus dem betroffenen Speicher gewinnen ließen und ob sich die beschädigten Festplatten der virtuellen Maschinen rekonstruieren ließen.
Als die Laufwerke bei DriveSavers eintrafen, war die Ransomware-Verschlüsselung nicht mehr das einzige Problem.
Die technische Analyse mithilfe unseres proprietären Tools zur Wiederherstellung virtueller Festplatten identifizierte rund 15 TB an Daten, die am Tag nach dem Angriff auf das Volume geschrieben wurden – nachdem die Nakivo-Backups bereits gelöscht worden waren. Diese Schreibvorgänge erwiesen sich als folgenreich.
Das Löschen einer Datei auf BTRFS löscht nicht deren Inhalt. Dateisysteme dieser Art markieren die betroffenen Blöcke in der Regel als zur Wiederverwendung verfügbar, während die Daten selbst an Ort und Stelle verbleiben, bis etwas darüber geschrieben wird. Die nach dem Angriff durchgeführten Schreibvorgänge wurden den Blöcken zugewiesen, die die gelöschten Backups zuvor belegt hatten.
Eine weitergehende technische Analyse ergab, dass ein wesentlich größerer Teil der betroffenen Informationen – potenziell sogar die gesamten Daten – höchstwahrscheinlich hätte wiederhergestellt werden können, wenn der betroffene Speicher unverändert geblieben wäre.
Das bei DriveSavers eingetroffene Volume enthielt somit eine Mischung aus ursprünglich intakten Daten, durch Ransomware verschlüsselten Daten, gelöschten und neu zugewiesenen Daten, neu geschriebenen Informationen, beschädigten Dateisystemstrukturen sowie teilweise überschriebenen Blöcken. Etwa 3.600 Dateien mit einer Gesamtgröße von 16,1 TB blieben aktiv, wobei 99 % davon VMware-Festplatten und Snapshots waren, deren Dateiendungen in „.AKIRA" umgeschrieben worden waren.
Ein Merkmal des Angriffs verbesserte die Aussichten. Der bei diesem Vorfall verwendete Verschlüsselungsalgorithmus verschlüsselte keine kompletten Dateien. Er verschlüsselte etwa 15 % jeder Datei in drei Bändern, was sich bei den großen VMDKs als etwa 5-prozentige Frontend-Verschlüsselung darstellte. Erhebliche Bereiche jeder virtuellen Festplatte blieben daher intakt. Eine Analyse auf Blockebene war erforderlich, um diese intakten Bereiche zu identifizieren.
Eine Remote-Bewertung bestätigte den Projektumfang und diente dazu, festzustellen, ob die Wiederherstellung aus der Ferne durchgeführt werden konnte oder Laborarbeit erforderlich war. Die Wiederherstellung dieser Daten bedeutete, alle zwölf Laufwerke auf Sektorebene auszulesen, einschließlich Bereiche, auf die das Dateisystem nicht mehr verwies – ein Fernzugriff auf ein laufendes NAS erreicht in der Regel jedoch das logische Volume und nicht das zugrunde liegende physische Medium. Eine Fernwiederherstellung war daher nicht möglich. Ein Ingenieur holte die Laufwerke am darauffolgenden Sonntagabend am San Francisco International Airport ab.
Alle zwölf Laufwerke wurden innerhalb von 24 Stunden nach Ankunft abgebildet (imaged), und jede nachfolgende Operation wurde an diesen Images durchgeführt. Die Originalmedien blieben während des gesamten Vorgangs im Anlieferungszustand, wodurch der beweisrelevante Zustand während der laufenden Analyse erhalten blieb.
Rund 120 TB nacheinander, jeweils ein Image nach dem anderen, zu scannen, wäre nicht praktikabel gewesen. Die Ingenieure teilten die Arbeit in Terabyte-Bereiche auf und führten zehn Scans gleichzeitig durch, wodurch der Durchsatz an die Grenzen der Hardware selbst stieß. Anschließend wurde ein zweiter Satz Images auf einem zweiten System erstellt, sodass die Extraktionen gleichzeitig auf beiden Maschinen fortgesetzt werden konnten.
Während Daten gelöscht wurden, hatte BTRFS damit begonnen, die Ebene zu löschen, die gespeicherte Daten ihren physischen Speicherorten zuordnet. Rund 7 TB dieser Zuordnungstabelle waren betroffen, was aus ansonsten lesbarem Speicher unbrauchbare Ausgaben erzeugte. Die Ingenieure stellten fest, dass die betroffenen Bereiche vor der Löschung zusammenhängend zugewiesen worden waren, was eine manuelle Rekonstruktion ermöglichte. Der handgeführte Wiederaufbau der Zuordnungstabelle stellte den Zugriff auf rund 5 TB an Backup-Daten wieder her, die das Dateisystem bereits freigegeben hatte.
Eine beschädigte VMDK-Datei ist selten einfach lesbar oder unlesbar. Die Ingenieure trennten intakte Bereiche von solchen, die verschlüsselt, beschädigt, teilweise überschrieben oder strukturell geschädigt waren. Die drei Maschinen mit der höchsten Priorität hatten jeweils fünf oder sechs Wiederherstellungspunkte, wobei der aktuellste kurz vor dem Angriff erstellt worden war, was insgesamt 35 VMDK-Dateien ergab. Die Beschädigung betraf 3 bis 5 % jeder dieser Dateien. Bei einer der drei Maschinen hatte die Verschlüsselungssoftware die virtuellen Festplattendateien überhaupt nicht erreicht.
Wo Backup-Daten allein einen Datensatz nicht abdeckten, integrierten die Ingenieure die unverschlüsselten Bereiche der produktiven virtuellen Festplatten. Dieser Ansatz war wirksam, erforderte jedoch Vorsicht. Zwei der drei prioritären Maschinen verfügten zudem über Snapshot-Dateien, die zu den von ihnen repräsentierten Daten in keiner Eins-zu-eins-Beziehung stehen. Die Strukturen, die die Snapshot-Dateien den von ihnen repräsentierten Daten zuordneten, befanden sich in den verschlüsselten Bereichen. Die Verwendung der produktiven virtuellen Festplatten zum Füllen von Lücken konnte daher ältere Daten einbringen und zu Beschädigungen führen, die sich im Nachhinein nur schwer nachvollziehen ließen. Die Ingenieure bewerteten das Risiko für jeden Datensatz individuell, anstatt standardmäßig zusammenzuführen.
DriveSavers arbeitete mit dem Incident-Response-Unternehmen und dem Kunden zusammen, um im Voraus festzulegen, in welche Umgebung die Laufwerke reimportiert werden sollten. Die extrahierten Daten auf Dateiebene wurden zunächst über das Netzwerk zurückgeliefert, sodass der Kunde auf bestimmte Dateien zugreifen konnte, während die übrigen Arbeiten fortgesetzt wurden. Anschließend folgten vollständige, für den Reimport geeignete VMDK-Dateien.
DriveSavers führte den Auftrag als sieben separat abgegrenzte Teilaufträge durch, an denen mehrere Ingenieure parallel arbeiteten, sodass die höchstprioritären Systeme bearbeitet und zurückgeliefert werden konnten, bevor der Rest der Umgebung folgte.
DriveSavers wies das Incident-Response-Unternehmen und den Kunden während des gesamten Verlaufs darauf hin, dass für die rekonstruierten VMDKs keine Garantie für einen erfolgreichen Bootvorgang übernommen werden konnte. Mindestens eine wiederhergestellte virtuelle Maschine konnte erfolgreich gestartet werden. Die übrigen wurden als wiederhergestellte Daten und reparierte Festplatten zurückgeliefert.
Jede reparierte virtuelle Festplatte wurde von einem Bericht auf Blockebene begleitet, der auswies, welche Bereiche der Festplatte intakt waren und welche nicht wiederherstellbare Schäden aufwiesen, mit Objekt-, Datei-, Verzeichnis- und Byte-Zahlen für jeden Bereich. Für technische Teams, die eine Umgebung wiederaufbauen, liefert diese Art der Berichterstattung erheblich mehr Informationen als eine einfache Kennzeichnung als wiederhergestellt oder nicht wiederhergestellt. Sie ermöglicht es Administratoren, die Qualität eines wiederhergestellten Images zu beurteilen und festzustellen, ob eine zusätzliche Wiederherstellung auf Anwendungsebene, eine Dateiextraktion oder ein Wiederaufbau erforderlich ist.
Wenn eine Backup-Anwendung eine Wiederherstellung nicht abschließen kann, können die zugrunde liegenden Daten dennoch auf dem Speicher vorhanden sein. Dieses Repository war verschlüsselt, geleert und anschließend überschrieben worden, bevor es überhaupt einen Wiederherstellungsspezialisten erreichte – und dennoch lieferte die Rekonstruktion auf Blockebene die Systeme zurück, die das Unternehmen am dringendsten benötigte.
Die Wiederherstellung von Daten virtueller Maschinen unter solchen Bedingungen erfordert spezialisiertes Fachwissen, proprietäre Tools und eine speziell auf das betreffende Dateisystem zugeschnittene Entwicklung. Wenn Ransomware gleichzeitig Produktionssysteme und Backup-Infrastruktur trifft, kann eine spezialisierte Ransomware-Datenrettung einen technischen Weg eröffnen, den herkömmliche Wiederherstellungsmethoden nicht bieten können.
Stehen Sie vor einer ähnlichen Situation? Wenden Sie sich an DriveSavers unter 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)