VMDK Data Recovery After an Akira Ransomware Attack
Recupero dati VMDK
Ambiente:
Ambiente VMware sottoposto a backup tramite Nakivo su un Synology RS3621RPXs a 12 alloggiamenti, RAID 5, BTRFS
Attacco:
Ransomware Akira
Dati a rischio:
Circa 11 TB di backup di macchine virtuali crittografati, il resto eliminato
Complicazione:
Circa 15 TB scritti sullo stesso volume il giorno successivo all'attacco
Risultato:
99,91% recuperato sul server database prioritario
Un'organizzazione aziendale multi-sede ha subito un attacco ransomware Akira che ha compromesso l'accesso a sistemi virtualizzati critici e ha messo a rischio porzioni significative del proprio ambiente di produzione. Circa 11 TB di backup di macchine virtuali conservati nel repository Nakivo del cliente sono stati crittografati. I backup rimanenti sono stati eliminati.
Lo stesso attacco ha crittografato le macchine virtuali di produzione, lasciando l'organizzazione priva dei dati necessari per ripristinare le operazioni aziendali.
Nel giro di pochi giorni, l'organizzazione ha coinvolto la propria compagnia assicurativa informatica e una società di incident response. I metodi di ripristino convenzionali hanno recuperato porzioni dell'ambiente, ma non sono riusciti a ripristinare diverse macchine virtuali prioritarie. La società di incident response ha coinvolto DriveSavers Data Recovery per stabilire se fosse ancora possibile recuperare dati utilizzabili dallo storage interessato e se i dischi delle macchine virtuali danneggiati potessero essere ricostruiti.
Nel momento in cui i dischi sono arrivati a DriveSavers, la crittografia del ransomware non era più l'unico problema.
L'analisi tecnica condotta con il nostro strumento proprietario di recupero dei dischi virtuali ha identificato circa 15 TB di dati scritti sul volume il giorno dopo l'attacco, ovvero dopo che i backup Nakivo erano già stati eliminati. Queste scritture si sono rivelate determinanti.
L'eliminazione di un file su BTRFS non ne cancella il contenuto. I file system di questo tipo generalmente contrassegnano i blocchi interessati come disponibili per il riutilizzo, mentre i dati stessi rimangono al loro posto finché qualcosa non viene scritto sopra di essi. Le scritture eseguite dopo l'attacco sono state assegnate ai blocchi occupati dai backup eliminati.
Un'ulteriore analisi tecnica ha indicato che una porzione sostanzialmente maggiore delle informazioni interessate, e potenzialmente la totalità, avrebbe probabilmente potuto essere recuperata se lo storage interessato fosse rimasto invariato.
Il volume arrivato a DriveSavers conteneva pertanto un mix di dati originali intatti, dati crittografati dal ransomware, dati eliminati e riallocati, informazioni scritte di recente, strutture del file system danneggiate, e blocchi parzialmente sovrascritti. Circa 3.600 file, per un totale di 16,1 TB, sono rimasti attivi, di cui il 99% erano dischi virtuali e snapshot VMware con estensioni riscritte in .AKIRA.
Una caratteristica dell'attacco ha migliorato le prospettive. L'algoritmo di crittografia utilizzato in questo incidente non crittografava interi file. Crittografava circa il 15% di ciascun file in tre fasce, il che sui grandi VMDK si traduceva in circa il 5% di crittografia front-end. Ampie porzioni di ogni disco virtuale sono quindi rimaste intatte. È stata necessaria un'analisi a livello di blocco per identificare tali regioni intatte.
Una valutazione remota ha confermato l'ambito del progetto ed è stata utilizzata per determinare se il recupero potesse essere completato da remoto o richiedesse un intervento in laboratorio. Recuperare questi dati significava leggere tutte e dodici le unità a livello di settore, comprese le regioni non più referenziate dal file system, e l'accesso remoto a un NAS in funzione raggiunge generalmente il volume logico piuttosto che il supporto fisico sottostante. Il recupero remoto non è stato possibile. Un ingegnere ha ritirato le unità all'Aeroporto Internazionale di San Francisco la domenica sera successiva.
Tutte e dodici le unità sono state sottoposte a imaging entro 24 ore dall'arrivo, e ogni operazione successiva è stata eseguita su tali immagini. I supporti originali sono rimasti nello stato in cui erano stati ricevuti per tutta la durata del processo, il che ha permesso di preservare lo stato probatorio durante lo svolgimento dell'analisi.
Effettuare la scansione di circa 120 TB un'immagine alla volta non sarebbe stato praticabile. Gli ingegneri hanno suddiviso il lavoro in intervalli da un terabyte ed eseguito dieci scansioni simultaneamente, portando il throughput ai limiti dell'hardware stesso. Successivamente è stato costruito un secondo set di immagini su un secondo sistema, in modo che le estrazioni potessero proseguire contemporaneamente su entrambe le macchine.
Man mano che i dati venivano eliminati, BTRFS aveva iniziato a cancellare il livello che mappa i dati memorizzati sulle rispettive posizioni fisiche. Circa 7 TB di quella mappa sono stati interessati, producendo output inutilizzabile da uno storage altrimenti leggibile. Gli ingegneri hanno stabilito che le regioni interessate erano state allocate in modo contiguo prima dell'eliminazione, il che ha reso possibile la ricostruzione manuale. Ricostruire la mappa manualmente ha ripristinato l'accesso a circa 5 TB di dati di backup che il file system aveva già rilasciato.
Un file VMDK danneggiato è raramente semplicemente leggibile o illeggibile. Gli ingegneri hanno separato le regioni intatte da quelle crittografate, corrotte, parzialmente sovrascritte o strutturalmente danneggiate. Le tre macchine a priorità più alta avevano ciascuna cinque o sei punti di ripristino, il più recente effettuato poco prima dell'attacco, per un totale di 35 file VMDK. Il danno ha interessato dal 3 al 5% di ciascuno di questi file. Su una delle tre, il criptatore non aveva affatto raggiunto i file dei dischi virtuali.
Laddove i soli dati di backup non coprivano un set di dati, gli ingegneri hanno integrato le regioni non crittografate dei dischi virtuali di produzione. Questo approccio si è rivelato efficace, sebbene richiedesse cautela. Due delle tre macchine prioritarie disponevano anche di file snapshot, che non hanno una relazione uno a uno con i dati che rappresentano. Le strutture che mappavano i file snapshot ai dati che rappresentavano si trovavano all'interno delle regioni crittografate. Utilizzare i dischi virtuali di produzione per colmare le lacune poteva quindi introdurre dati più vecchi e produrre corruzione difficile da rintracciare in seguito. Gli ingegneri hanno valutato il rischio per ciascun set di dati anziché unire per impostazione predefinita.
DriveSavers ha collaborato con la società di incident response e con il cliente per stabilire in anticipo in quale ambiente sarebbero stati reimportati i dischi. I dati estratti a livello di file sono stati restituiti per primi attraverso la rete, in modo che il cliente potesse accedere a file specifici mentre il resto del lavoro proseguiva. Sono seguiti i file VMDK completi, idonei alla reimportazione.
DriveSavers ha condotto l'incarico suddividendolo in sette sotto-incarichi con ambiti definiti separatamente, con più ingegneri che lavoravano in parallelo, in modo che i sistemi a priorità più alta potessero essere lavorati e restituiti prima del resto dell'ambiente.
DriveSavers ha informato costantemente la società di incident response e il cliente sul fatto che non si poteva garantire l'avvio dei VMDK ricostruiti. Almeno una macchina virtuale recuperata si è avviata correttamente. Le restanti sono state restituite come dati recuperati e dischi riparati.
Ogni disco virtuale riparato era accompagnato da un report a livello di blocco che identificava quali regioni del disco fossero integre e quali presentassero danni irrecuperabili, con conteggi di oggetti, file, directory e byte per ciascuna. Per i team tecnici che ricostruiscono un ambiente, questo tipo di reportistica fornisce informazioni notevolmente più dettagliate rispetto a una semplice indicazione di recuperato o non recuperato. Consente agli amministratori di valutare la qualità di un'immagine recuperata e di stabilire se sia necessario un ulteriore recupero a livello applicativo, un'estrazione di file o una ricostruzione.
Quando un'applicazione di backup non riesce a completare un ripristino, i dati sottostanti potrebbero comunque essere ancora presenti sullo storage. Questo repository era stato crittografato, svuotato e poi sovrascritto prima di arrivare a uno specialista del recupero, eppure la ricostruzione a livello di blocco è comunque riuscita a restituire i sistemi di cui l'azienda aveva più bisogno.
Recuperare dati di macchine virtuali in tali condizioni richiede competenze specializzate, strumenti proprietari e sviluppo personalizzato in base al file system specifico coinvolto. Quando il ransomware colpisce contemporaneamente i sistemi di produzione e l'infrastruttura di backup, il recupero dati specializzato da ransomware può offrire una via tecnica che il ripristino convenzionale non è in grado di fornire.
Ti trovi ad affrontare una situazione simile? Contatta DriveSavers al numero 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)