VMDK Data Recovery After an Akira Ransomware Attack
VMDK-dataherstel
Omgeving:
VMware-omgeving geback-upt door Nakivo naar een Synology RS3621RPXs met 12 bays, RAID 5, BTRFS
Aanval:
Akira-ransomware
Gegevens in gevaar:
Ongeveer 11 TB aan versleutelde back-ups van virtuele machines, de rest verwijderd
Complicatie:
Ongeveer 15 TB naar hetzelfde volume geschreven op de dag na de aanval
Resultaat:
99,91 procent hersteld op de prioritaire databaseserver
Een organisatie met meerdere vestigingen kreeg te maken met een Akira-ransomware-aanval die de toegang tot kritieke gevirtualiseerde systemen verstoorde en aanzienlijke delen van de productieomgeving in gevaar bracht. Ongeveer 11 TB aan back-ups van virtuele machines, opgeslagen in de Nakivo-repository van de klant, werden versleuteld. De resterende back-ups werden verwijderd.
Dezelfde aanval versleutelde ook de virtuele machines in productie, waardoor de organisatie niet meer beschikte over de gegevens die nodig waren om de bedrijfsvoering te herstellen.
Binnen enkele dagen schakelde de organisatie haar cyberverzekeraar en een incident response-bedrijf in. Conventionele herstelmethoden brachten delen van de omgeving terug, maar konden meerdere prioritaire virtuele machines niet herstellen. Het incident response-bedrijf schaalde het probleem op naar DriveSavers Data Recovery om te bepalen of er nog bruikbare gegevens uit de getroffen opslag konden worden hersteld, en of beschadigde schijven van virtuele machines konden worden gereconstrueerd.
Tegen de tijd dat de schijven bij DriveSavers aankwamen, was de ransomware-versleuteling niet langer het enige probleem.
Technische analyse met onze eigen tool voor het herstellen van virtuele schijven identificeerde ongeveer 15 TB aan gegevens die de dag na de aanval naar het volume waren geschreven — nadat de Nakivo-back-ups al waren verwijderd. Die schrijfacties bleken ingrijpende gevolgen te hebben.
Het verwijderen van een bestand op BTRFS wist de inhoud ervan niet. Bestandssystemen van dit type markeren de betreffende blokken doorgaans als beschikbaar voor hergebruik, terwijl de gegevens zelf op hun plaats blijven totdat er iets overheen wordt geschreven. De na de aanval uitgevoerde schrijfacties werden toegewezen aan blokken die de verwijderde back-ups eerder in beslag namen.
Verdere technische analyse wees uit dat een aanzienlijk groter deel van de gerichte informatie, en mogelijk zelfs alles ervan, waarschijnlijk hersteld had kunnen worden als de getroffen opslag ongewijzigd was gebleven.
Het volume dat bij DriveSavers aankwam, bevatte dus een mix van origineel intacte gegevens, door ransomware versleutelde gegevens, verwijderde en herverdeelde gegevens, nieuw geschreven informatie, beschadigde bestandssysteemstructuren en gedeeltelijk overschreven blokken. Ongeveer 3.600 bestanden, met een totaal van 16,1 TB, bleven actief, waarvan 99% VMware-virtuele schijven en snapshots waren waarvan de extensies waren herschreven naar .AKIRA.
Eén kenmerk van de aanval verbeterde de vooruitzichten. Het bij dit incident gebruikte versleutelingsalgoritme versleutelde geen volledige bestanden. Het versleutelde ongeveer 15% van elk bestand in drie banden, wat zich op de grote VMDK's vertaalde naar ongeveer 5% front-end-versleuteling. Aanzienlijke delen van elke virtuele schijf bleven daardoor intact. Blok-niveau-analyse was nodig om die intacte gebieden te identificeren.
Een evaluatie op afstand bevestigde de omvang van het project en werd gebruikt om te bepalen of herstel op afstand kon worden voltooid of dat werk in het lab nodig was. Deze gegevens herstellen betekende het lezen van alle twaalf schijven op sectorniveau, inclusief gebieden waar het bestandssysteem niet langer naar verwees, en toegang op afstand tot een actieve NAS bereikt over het algemeen het logische volume in plaats van het onderliggende fysieke medium. Herstel op afstand was niet mogelijk. Een ingenieur haalde de schijven op de volgende zondagavond op bij San Francisco International Airport.
Alle twaalf schijven werden binnen 24 uur na aankomst geïmaged, en elke volgende bewerking werd uitgevoerd op die images. De originele media bleven gedurende het hele proces in de staat waarin ze waren ontvangen, waardoor de bewijstoestand behouden bleef terwijl de analyse voortduurde.
Het scannen van ongeveer 120 TB, één image tegelijk, zou niet haalbaar zijn geweest. Ingenieurs verdeelden het werk in terabyte-bereiken en voerden tien scans tegelijkertijd uit, waardoor de doorvoersnelheid de grenzen van de hardware zelf bereikte. Vervolgens werd op een tweede systeem een tweede reeks images opgebouwd, zodat extracties tegelijkertijd op beide machines konden verlopen.
Terwijl gegevens werden verwijderd, was BTRFS begonnen met het wissen van de laag die opgeslagen gegevens toewijst aan hun fysieke locaties. Ongeveer 7 TB van die kaart werd getroffen, wat onbruikbare output opleverde uit een verder leesbare opslag. Ingenieurs stelden vast dat de getroffen gebieden vóór verwijdering aaneengesloten waren toegewezen, wat handmatige reconstructie mogelijk maakte. Het handmatig herbouwen van de kaart herstelde de toegang tot ongeveer 5 TB aan back-upgegevens die het bestandssysteem al had vrijgegeven.
Een beschadigd VMDK-bestand is zelden simpelweg leesbaar of onleesbaar. Ingenieurs scheidden intacte gebieden van gebieden die versleuteld, beschadigd, gedeeltelijk overschreven of structureel beschadigd waren. De drie machines met de hoogste prioriteit hadden elk vijf of zes hersteldata, waarvan de meest recente kort vóór de aanval was gemaakt, wat neerkwam op in totaal 35 VMDK-bestanden. Schade trof 3 tot 5% van elk van die bestanden. Bij één van de drie had de versleutelingssoftware de virtuele schijfbestanden helemaal niet bereikt.
Waar back-upgegevens alleen een dataset niet dekten, voegden ingenieurs de onversleutelde gebieden van de productie-virtuele schijven samen. Deze aanpak was effectief, al vereiste ze voorzichtigheid. Twee van de drie prioritaire machines hadden ook snapshotbestanden, die geen één-op-één-relatie hebben met de gegevens die ze vertegenwoordigen. De structuren die de snapshotbestanden koppelden aan de gegevens die ze vertegenwoordigden, bevonden zich binnen de versleutelde gebieden. Het gebruik van de productie-virtuele schijven om gaten op te vullen kon daardoor oudere gegevens introduceren en corruptie veroorzaken die achteraf moeilijk te traceren zou zijn. Ingenieurs beoordeelden het risico per dataset in plaats van standaard samen te voegen.
DriveSavers werkte samen met het incident response-bedrijf en de klant om vooraf vast te stellen in welke omgeving de schijven opnieuw zouden worden geïmporteerd. Geëxtraheerde gegevens op bestandsniveau werden eerst via het netwerk teruggeleverd, zodat de klant toegang had tot specifieke bestanden terwijl het overige werk doorging. Volledige VMDK-bestanden geschikt voor herimport volgden daarna.
DriveSavers voerde de opdracht uit als zeven afzonderlijk afgebakende deelopdrachten, waarbij meerdere ingenieurs parallel werkten, zodat de meest prioritaire systemen konden worden bewerkt en geretourneerd vóór de rest van de omgeving.
DriveSavers heeft het incident response-bedrijf en de klant gedurende het hele traject erop gewezen dat niet kon worden gegarandeerd dat de gereconstrueerde VMDK's zouden opstarten. Ten minste één herstelde virtuele machine startte succesvol op. De rest werd geretourneerd als herstelde gegevens en gerepareerde schijven.
Elke gerepareerde virtuele schijf ging vergezeld van een rapport op blokniveau dat aangaf welke gebieden van de schijf intact waren en welke onherstelbare schade vertoonden, met object-, bestands-, map- en byte-aantallen voor elk gebied. Voor technische teams die een omgeving herbouwen, biedt dit soort rapportage aanzienlijk meer informatie dan een simpele aanduiding van hersteld of niet hersteld. Het stelt beheerders in staat de kwaliteit van een herstelde image te beoordelen en te bepalen of aanvullend herstel op applicatieniveau, bestandsextractie of herbouw nodig is.
Wanneer een back-uptoepassing een herstel niet kan voltooien, kunnen de onderliggende gegevens nog steeds op de opslag aanwezig zijn. Deze repository was versleuteld, geleegd en vervolgens overschreven voordat deze bij een herstelspecialist terechtkwam, en toch bracht reconstructie op blokniveau de systemen terug die het bedrijf het hardst nodig had.
Het herstellen van gegevens van virtuele machines onder dergelijke omstandigheden vereist gespecialiseerde kennis, eigen tools en maatwerkontwikkeling voor het specifieke betrokken bestandssysteem. Wanneer ransomware tegelijkertijd productiesystemen en back-upinfrastructuur treft, kan gespecialiseerd ransomware-dataherstel een technische weg bieden die conventioneel herstel niet biedt.
Staat u voor een vergelijkbare situatie? Neem contact op met DriveSavers via 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)