Recupero Dati SQL Server installato su HYPER-V vhdx in seguito ad attacco Lockbit

Recupero Dati da SQL Server in HYPER-V Colpita da Ransomware LockBit

Il caso di C.D.S. è tanto significativo da far scuola nelle strategie di recovery e apre nuovi orizzonti nelle tecniche utilizzate per risolvere i casi di attacco Ransomware e di corruzione di file system.

Introduzione : L’attacco su HYPER-V

Nel caso C.D.S la partizione contenente le Virtual Machine HYPER-V VHDX è stata colpita da attacco hacker che come di consueto ha rinominato i file e danneggiato il datastore.

Le macchine VM in particolare sono state criptate e danneggiate severamente in diverse posizioni del file tra cui l’elemento più importante , la BAT ( BLOCK ALLOCATION TABLE )

HYPER-V BAT, Metadati Essenziali

Le VM HYPER-V VHDX sono progettate con una tecnologia denomitata COW, Commit on Write.

Semplificando il file virtuale cresce di dimensione allocata con l’utilizzo della Macchina Virtuale alla quale vengono letteralmente accodati blocchi di settori.

La tecnologia COW implica necessariamente che tutti i blocchi memorizzati vengano gestiti da un indice in quanto il loro allineamento non è contiguo come in un hard disk tradizionale.

Tale metodo è comune in VMWARE e nei NAS che implementano il THIN Provisioning.

Analisi Forense delle Virtual Machine Attaccate

La diagnosi delle VM ha evidenziato che il ransomware utilizzato nell’attacco risultava essere progettato per colpire la VM nei primi settori e poi ciclicamente tutti i settori del virtual drive utilizzando un vettore di jump specifico.

La ragione per cui viene utilizzato un jump durante l’encryption è chiarissima, l’obiettivo è danneggiare in modo orizzontale e completo il datastore nel minor tempo possibile.

Se l’attacco avesse dovuto interessare tutto il disco virtuale, avrebbe significato impegnare in I/O intensivo un singolo file per molte ore.

Se l’obiettivo è criptare un file per chiederne poi un ransom è necessario che il flusso debba essere prima letto, cifrato e riscritto nuovamente implicando necessariamente il doppio dell’impegno I/O.

Un singolo Virtual Disk di 1 TB per essere criptato integralmente impiegherebbe troppo tempo, probabilmente ore, e oltre al rischio di essere sorpresi dalla vittima durante un attacco prolungato, magari insospettita dal degrado di performance dei propri servers, potrebbe accadere di non riuscire a criptare tutto e forse di aver tralasciato elementi strategici per l’organizzazione attaccata.

E’ dunque pratica comune in tutti gli attacchi “colpire” le virtual machine in posizioni strategiche, rendendole irrecuperabili e inutilizzabili nel minor tempo possibile.

Nel caso C.D.S le B.A.T. risultavano essere danneggiate senza alcuna possibilità di recupero o backup locale presente.

Il backup nello specifico non veniva prodotto a causa della dimensione della VM, un Database SQL Server con SHAREPOINT, contenente milioni di documenti achiviati.

Pianificazione Strategia di Recovery

Essendo una Virtual Machine vhdx allocata con modalità COW con blocchi di dimensione predefinita ed essendo l’indice danneggiato non risulta possibile in alcun modo utilizzare software di data recovery, in quanto qualsiasi file recuperato risulterebbe inevitabilmente corrotto.

I software di recupero dati, nel tentativo di ricostruire il file system, analizzano i settori e localizzano le entries MFT, ricostruendone la struttura utilizzando i valori di parentela tra i records localizzati.

Al termine di una analisi il file system originale viene certamente ricostruito, ma la posizione dei file relativa non puo’ che essere errata con l’impossibilità di poter estrarre elementi validi.

Essendo obiettivo del recovery i database di SQL Server abbiamo pianificato una strategia basata sulla localizzazione delle pagine di SQL Server stesso e sviluppato un algoritmo euristico in grado di ricostruire i blocchi contigui appartenenti ai database presenti originariamente nel server.

Note sul funzionamento di SQL Server

Un database di SQL Server memorizza i propri record in pagine da 16 Settori ( 8K )

Ogni pagina è costituita da un Header da 96 bytes che contiene elementi essenziali per l’identificazione e per i check di consistenza interni del database stesso.

Utilizzando i metadati presenti nei settori della VM Danneggiata è stato possibile creare un database di tutte le pagine di SQL Server presenti.

Un algoritmo di associazione probabilistica basata sui metadati contenuti negli headers delle pagine MS SQL Server è stato in grado di determinare gli elementi contigui e le interruzioni dei flussi senza alcun falso positivo.

A partire dall’elemento 0 ( la prima pagina del Database ) in sequenza è stato possibile calcolare tutte le sequenze di pagine appartenenti ad ogni singolo database utilizzando le interruzioni sistematiche dovute alla frammentazione sul file system e successivamente alla allocazione bat nella VM stessa .

Una volta creata la mappa delle sequenze è stato possibile salvare i settori in sequenze ricostruendo gli mdf originali.

Gli MDF Recuperati sono stati sottoposti ad una analisi ulteriore per la ricostruzione completa delle tabelle, data view e stored procedures.

La procedura viene ultimata eseguendo una BULK Insert dei records recuperati su una istanza di SQL Server locale.

Il recovery ha consentito un restore operativo completo di un gestionale erp consistente in circa 1000 tabelle e di un database sharepoint contenente 6.000.000 di documenti.