VMDK Data Recovery After an Akira Ransomware Attack
VMDK-dataåterställning
Miljö:
VMware-miljö som säkerhetskopieras av Nakivo till en 12-bay Synology RS3621RPXs, RAID 5, BTRFS
Attack:
Akira-utpressningstrojan
Data i riskzonen:
Cirka 11 TB krypterade säkerhetskopior av virtuella maskiner, resten raderad
Komplikation:
Cirka 15 TB skrevs till samma volym dagen efter attacken
Resultat:
99,91 procent återställt på den prioriterade databasservern
En flerplatsverksamhet drabbades av en Akira-utpressningstrojanattack som störde åtkomsten till kritiska virtualiserade system och satte betydande delar av dess produktionsmiljö i riskzonen. Cirka 11 TB säkerhetskopior av virtuella maskiner som fanns i kundens Nakivo-arkiv krypterades. De återstående säkerhetskopiorna raderades.
Samma attack krypterade de virtuella produktionsmaskinerna, vilket lämnade organisationen utan den data som krävdes för att återställa verksamheten.
Inom några dagar engagerade organisationen sitt cyberförsäkringsbolag och ett incidenthanteringsföretag. Konventionella återställningsmetoder gav tillbaka delar av miljön, men kunde inte återställa flera prioriterade virtuella maskiner. Incidenthanteringsföretaget eskalerade ärendet till DriveSavers Data Recovery för att fastställa om användbar data fortfarande kunde återställas från den drabbade lagringen, och om skadade virtuella maskindiskar kunde återuppbyggas.
När diskarna nådde DriveSavers var inte utpressningstrojanens kryptering längre det enda problemet.
Teknisk analys med vårt egenutvecklade verktyg för återställning av virtuella diskar identifierade cirka 15 TB data som skrevs till volymen dagen efter attacken – efter att Nakivo-säkerhetskopiorna redan hade raderats. Dessa skrivningar visade sig få avgörande konsekvenser.
Att radera en fil på BTRFS raderar inte dess innehåll. Filsystem av denna typ markerar vanligtvis de berörda blocken som tillgängliga för återanvändning, medan själva datan finns kvar tills något skrivs över den. De skrivningar som utfördes efter attacken allokerades till block som de raderade säkerhetskopiorna hade upptagit.
Ytterligare teknisk analys visade att en betydligt större andel av den berörda informationen, och potentiellt allt av den, sannolikt hade kunnat återställas om den drabbade lagringen hade förblivit oförändrad.
Volymen som anlände till DriveSavers innehöll därför en blandning av ursprungliga intakta data, ransomware-krypterade data, raderade och omallokerade data, nyligen skriven information, skadade filsystemsstrukturer, och block som delvis skrivits över. Cirka 3 600 filer, totalt 16,1 TB, förblev aktiva, varav 99 % var VMware-virtuella diskar och ögonblicksbilder med filtillägg omskrivna till .AKIRA.
En egenskap hos attacken förbättrade utsikterna. Krypteringsalgoritmen som användes i denna incident krypterade inte hela filer. Den krypterade cirka 15 % av varje fil i tre band, vilket på de stora VMDK-filerna visade sig som ungefär 5 % front-end-kryptering. Betydande delar av varje virtuell disk förblev därmed intakta. Analys på blocknivå krävdes för att identifiera dessa intakta områden.
En fjärrutvärdering bekräftade projektets omfattning och användes för att avgöra om återställningen kunde slutföras på distans eller skulle kräva arbete i laboratoriet. Att återställa dessa data innebar att läsa alla tolv enheter på sektornivå, inklusive områden som filsystemet inte längre refererade till, och fjärråtkomst till en aktiv NAS når i allmänhet den logiska volymen snarare än det underliggande fysiska mediet. Fjärråterställning var inte möjlig. En ingenjör hämtade enheterna på San Francisco International Airport följande söndag kväll.
Alla tolv enheterna avbildades inom 24 timmar efter ankomst, och varje efterföljande operation kördes mot dessa avbildningar. Originalmediet förblev i det skick det mottogs i under hela processen, vilket bevarade bevisläget medan analysen pågick.
Att skanna cirka 120 TB en avbildning i taget hade inte varit genomförbart. Ingenjörerna delade upp arbetet i terabyte-intervall och körde tio skanningar samtidigt, vilket drev genomströmningen till gränsen för själva hårdvaran. Ett andra set med avbildningar byggdes därefter på ett andra system, så att extraktioner kunde pågå samtidigt på båda maskinerna.
Allteftersom data raderades hade BTRFS börjat tömma det lager som mappar lagrad data till dess fysiska platser. Cirka 7 TB av den kartan var berörd, vilket gav oanvändbar output från annars läsbar lagring. Ingenjörerna fastställde att de berörda områdena hade allokerats sammanhängande före raderingen, vilket gjorde manuell rekonstruktion möjlig. Att återuppbygga kartan för hand återställde åtkomsten till ungefär 5 TB säkerhetskopierad data som filsystemet redan hade frigjort.
En skadad VMDK-fil är sällan enbart läsbar eller oläsbar. Ingenjörerna separerade intakta områden från dem som var krypterade, skadade, delvis överskrivna eller strukturellt skadade. De tre högst prioriterade maskinerna hade vardera fem eller sex återställningspunkter, den senaste tagen strax före attacken, totalt 35 VMDK-filer. Skadan påverkade 3–5 % av var och en av dessa filer. På en av de tre hade krypteringsprogrammet inte alls nått de virtuella diskfilerna.
Där enbart backupdata inte täckte en datamängd integrerade ingenjörerna de okrypterade områdena på de virtuella produktionsdiskarna. Detta tillvägagångssätt var effektivt, men krävde försiktighet. Två av de tre prioriterade maskinerna hade också ögonblicksbildfiler, som inte har en en-till-en-relation till de data de representerar. De strukturer som mappade ögonblicksbildfilerna till de data de representerade fanns inom de krypterade områdena. Att använda de virtuella produktionsdiskarna för att fylla luckor kunde därför introducera äldre data och orsaka skador som skulle vara svåra att spåra i efterhand. Ingenjörerna bedömde risken för varje datamängd i stället för att slå samman som standard.
DriveSavers samarbetade med incidenthanteringsföretaget och kunden för att i förväg fastställa vilken miljö diskarna skulle importeras till. Extraherad data på filnivå returnerades först över nätverket, så att kunden kunde få tillgång till specifika filer medan resten av arbetet fortsatte. Kompletta VMDK-filer lämpade för återimport följde därefter.
DriveSavers genomförde uppdraget som sju separat avgränsade deluppdrag med flera ingenjörer som arbetade parallellt, så att de mest prioriterade systemen kunde bearbetas och återlämnas före resten av miljön.
DriveSavers informerade incidenthanteringsföretaget och kunden genomgående om att det inte kunde garanteras att de återuppbyggda VMDK-filerna skulle starta. Minst en återställd virtuell maskin startade. Resten återlämnades som återställd data och reparerade diskar.
Varje reparerad virtuell disk åtföljdes av en rapport på blocknivå som identifierade vilka delar av disken som var oskadade och vilka som bar oåterkallelig skada, med objekt-, fil-, katalog- och bytevärden för respektive del. För tekniska team som bygger upp en miljö igen ger denna typ av rapportering avsevärt mer information än en enkel beteckning som återställd eller inte återställd. Den låter administratörer bedöma kvaliteten på en återställd avbildning och avgöra om ytterligare återställning på applikationsnivå, filutvinning eller återuppbyggnad krävs.
När en backupapplikation inte kan slutföra en återställning kan den underliggande datan fortfarande finnas i lagringen. Detta arkiv hade krypterats, tömts och sedan skrivits över innan det nådde en återställningsspecialist, och rekonstruktion på blocknivå gav ändå tillbaka de system som företaget behövde mest.
Att återställa data för virtuella maskiner under sådana förhållanden kräver specialiserad kunskap, egenutvecklade verktyg och skräddarsydd utveckling anpassad till det specifika filsystemet i fråga. När utpressningstrojaner drabbar både produktionssystem och backupinfrastruktur samtidigt kan specialiserad dataåterställning efter utpressningstrojaner erbjuda en teknisk väg som konventionell återställning inte kan.
Befinner du dig i en liknande situation? Kontakta DriveSavers på 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)