VMDK Data Recovery After an Akira Ransomware Attack
VMDK-datagjenoppretting
Miljø:
VMware-miljø sikkerhetskopiert av Nakivo til en 12-bay Synology RS3621RPXs, RAID 5, BTRFS
Angrep:
Akira-løsepengevirus
Data i faresonen:
Cirka 11 TB med krypterte sikkerhetskopier av virtuelle maskiner, resten slettet
Komplikasjon:
Rundt 15 TB skrevet til det samme volumet dagen etter angrepet
Resultat:
99,91 prosent gjenopprettet på den prioriterte databaseserveren
En virksomhet med flere lokasjoner ble utsatt for et Akira-løsepengevirusangrep som forstyrret tilgangen til kritiske virtualiserte systemer og satte betydelige deler av produksjonsmiljøet i fare. Cirka 11 TB med sikkerhetskopier av virtuelle maskiner lagret i kundens Nakivo-repository ble kryptert. De resterende sikkerhetskopiene ble slettet.
Det samme angrepet krypterte de virtuelle produksjonsmaskinene, og etterlot organisasjonen uten dataene som trengtes for å gjenopprette forretningsdriften.
I løpet av noen dager engasjerte organisasjonen sitt cyberforsikringsselskap og et hendelseshåndteringsfirma. Konvensjonelle gjenopprettingsmetoder returnerte deler av miljøet, men klarte ikke å gjenopprette flere prioriterte virtuelle maskiner. Hendelseshåndteringsfirmaet eskalerte saken til DriveSavers Data Recovery for å fastslå om brukbare data fortsatt kunne gjenopprettes fra den berørte lagringen, og om skadede virtuelle maskindisker kunne rekonstrueres.
Da stasjonene nådde DriveSavers, var ikke løsepengevirus-krypteringen lenger det eneste problemet.
Teknisk analyse ved bruk av vårt proprietære verktøy for gjenoppretting av virtuelle disker identifiserte cirka 15 TB med data skrevet til volumet dagen etter angrepet – etter at Nakivo-sikkerhetskopiene allerede var slettet. Disse skriveoperasjonene fikk betydelige konsekvenser.
Å slette en fil på BTRFS sletter ikke innholdet. Filsystemer av denne typen markerer vanligvis de berørte blokkene som tilgjengelige for gjenbruk, mens selve dataene forblir på plass til noe skrives over dem. Skriveoperasjonene som ble utført etter angrepet, ble tildelt blokker som de slettede sikkerhetskopiene hadde okkupert.
Ytterligere teknisk analyse viste at en betydelig større andel av den målrettede informasjonen, og potensielt alt av den, sannsynligvis kunne ha blitt gjenopprettet dersom den berørte lagringen hadde forblitt uendret.
Volumet som ankom DriveSavers, inneholdt derfor en blanding av originale, intakte data, ransomware-krypterte data, slettede og omfordelte data, nylig skrevet informasjon, skadede filsystemstrukturer, og blokker som delvis var overskrevet. Cirka 3600 filer, totalt 16,1 TB, forble aktive, hvorav 99 % var VMware virtuelle disker og øyeblikksbilder med filtyper omskrevet til .AKIRA.
Ett kjennetegn ved angrepet bedret utsiktene. Krypteringsalgoritmen brukt i denne hendelsen krypterte ikke hele filer. Den krypterte cirka 15 % av hver fil i tre bånd, noe som på de store VMDK-filene fremstod som omtrent 5 % front-end-kryptering. Betydelige deler av hver virtuelle disk forble dermed intakte. Analyse på blokknivå var nødvendig for å identifisere disse intakte områdene.
En fjernevaluering bekreftet prosjektets omfang og ble brukt til å avgjøre om gjenopprettingen kunne fullføres eksternt eller ville kreve arbeid i laboratoriet. Å gjenopprette disse dataene betydde å lese alle tolv stasjonene på sektornivå, inkludert områder som filsystemet ikke lenger refererte til, og ekstern tilgang til en kjørende NAS når vanligvis det logiske volumet snarere enn det underliggende fysiske mediet. Fjerngjenoppretting var ikke mulig. En ingeniør hentet stasjonene ved San Francisco International Airport den påfølgende søndag kvelden.
Alle tolv stasjonene ble avbildet innen 24 timer etter ankomst, og hver påfølgende operasjon ble utført mot disse bildene. Det opprinnelige mediet forble slik det ble mottatt gjennom hele prosessen, noe som bevarte bevistilstanden mens analysen pågikk.
Å skanne cirka 120 TB ett bilde om gangen ville ikke ha vært gjennomførbart. Ingeniørene delte arbeidet inn i terabyte-intervaller og kjørte ti skanninger samtidig, noe som presset gjennomstrømningen til grensene for selve maskinvaren. Et andre sett med bilder ble deretter bygget på et andre system, slik at utpakkinger kunne foregå samtidig på begge maskinene.
Etter hvert som data ble slettet, hadde BTRFS begynt å tømme laget som kartlegger lagrede data til deres fysiske plasseringer. Cirka 7 TB av dette kartet var berørt, noe som ga ubrukelig utdata fra ellers lesbar lagring. Ingeniørene fastslo at de berørte områdene hadde blitt sammenhengende tildelt før slettingen, noe som gjorde manuell rekonstruksjon mulig. Å gjenoppbygge kartet for hånd gjenopprettet tilgangen til rundt 5 TB med backup-data som filsystemet allerede hadde frigitt.
En skadet VMDK-fil er sjelden bare rett og slett lesbar eller ulesbar. Ingeniørene skilte intakte områder fra de som var krypterte, skadede, delvis overskrevet eller strukturelt skadet. De tre høyest prioriterte maskinene hadde hver fem eller seks gjenopprettingspunkter, det siste tatt kort tid før angrepet, totalt 35 VMDK-filer. Skaden påvirket 3–5 % av hver av disse filene. På en av de tre hadde krypteringsprogrammet ikke nådd de virtuelle diskfilene i det hele tatt.
Der backup-data alene ikke dekket et datasett, integrerte ingeniørene de ukrypterte områdene av de virtuelle produksjonsdiskene. Denne tilnærmingen var effektiv, men krevde forsiktighet. To av de tre prioriterte maskinene hadde også snapshot-filer, som ikke har et en-til-en-forhold til dataene de representerer. Strukturene som kartla snapshot-filene til dataene de representerte, befant seg innenfor de krypterte områdene. Å bruke de virtuelle produksjonsdiskene til å fylle hull kunne derfor introdusere eldre data og forårsake korrupsjon som ville være vanskelig å spore i ettertid. Ingeniørene vurderte risikoen for hvert datasett i stedet for å slå sammen som standard.
DriveSavers samarbeidet med hendelseshåndteringsfirmaet og kunden for å på forhånd fastslå hvilket miljø diskene skulle importeres til. Utpakkede data på filnivå ble returnert først over nettverket, slik at kunden fikk tilgang til spesifikke filer mens det gjenværende arbeidet fortsatte. Deretter fulgte hele VMDK-filer egnet for reimport.
DriveSavers gjennomførte oppdraget som syv separat avgrensede deloppdrag med flere ingeniører som jobbet parallelt, slik at systemene med høyest prioritet kunne bearbeides og returneres foran resten av miljøet.
DriveSavers informerte hendelseshåndteringsfirmaet og kunden gjennom hele prosessen om at det ikke kunne garanteres at de rekonstruerte VMDK-ene ville starte opp. Minst én gjenopprettet virtuell maskin startet opp. De resterende ble returnert som gjenopprettede data og reparerte disker.
Hver reparerte virtuelle disk ble ledsaget av en rapport på blokknivå som identifiserte hvilke områder av disken som var intakte, og hvilke som bar uopprettelig skade, med antall objekter, filer, kataloger og byte for hver. For tekniske team som gjenoppbygger et miljø, gir denne typen rapportering betydelig mer informasjon enn en betegnelse som gjenopprettet eller ikke gjenopprettet. Den lar administratorer vurdere kvaliteten til et gjenopprettet bilde og fastslå om ytterligere gjenoppretting på applikasjonsnivå, filuttrekking eller gjenoppbygging er nødvendig.
Når en backup-applikasjon ikke kan fullføre en gjenoppretting, kan de underliggende dataene fortsatt være til stede i lagringen. Dette repositoryet hadde blitt kryptert, tømt og deretter overskrevet før det nådde en gjenopprettingsspesialist, og rekonstruksjon på blokknivå returnerte likevel systemene virksomheten trengte mest.
Å gjenopprette data for virtuelle maskiner under slike forhold krever spesialisert kunnskap, proprietære verktøy og skreddersydd utvikling tilpasset det spesifikke filsystemet det gjelder. Når løsepengevirus rammer produksjonssystemer og backup-infrastruktur samtidig, kan spesialisert datagjenoppretting etter løsepengevirus tilby en teknisk vei som konvensjonell gjenoppretting ikke kan.
Står du overfor en lignende situasjon? Ta kontakt med 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)