Hai pagato il riscatto, ottenuto la chiave o scaricato uno strumento di decrittazione gratuito pubblicato da un ricercatore di sicurezza, e nonostante ciò i tuoi file restano inutilizzabili. Questo scenario è più frequente di quanto si pensi. Su formati complessi come i database SQL o i file di macchine virtuali (VHDX, VMDK), una decrittazione che lascia la struttura interna corrotta è un risultato comune, non un caso isolato: un bug documentato del decrittatore del ransomware Ryuk, ad esempio, troncava di un byte la fine dei file di grandi dimensioni (contenitori VHD/VHDX, database Oracle e SQL Server), il che bastava a impedire qualsiasi montaggio nonostante un contenuto quasi integralmente decrittato. I dati sono tecnicamente decrittati a livello binario, ma la struttura logica del file resta corrotta e il sistema si rifiuta di avviarsi.
Cosa succede concretamente durante un attacco ransomware
Quando un ransomware colpisce un server aziendale, non si limita a bloccare l’accesso a qualche file isolato. Cifra in profondità i dati critici: database SQL, dischi di macchine virtuali, archivi e documenti di produzione. Ogni file viene riscritto secondo un algoritmo di cifratura, spesso in pochi minuti anche per i volumi più pesanti, il che spiega perché i log degli eventi mostrano un’attività disco anomala poco prima che le estensioni dei file cambino.
Una volta terminato l’attacco, una nota di riscatto compare generalmente in più cartelle, con istruzioni di pagamento e talvolta la promessa di uno strumento di decrittazione funzionante una volta versata la somma. È in questo momento che molte aziende pensano di aver trovato una soluzione rapida. La realtà del ripristino è invece decisamente più incerta.
Perché pagare il riscatto non garantisce un recupero completo
Ottenere una chiave di decrittazione, sia tramite il pagamento del riscatto sia grazie a uno strumento pubblicato gratuitamente da un ricercatore di sicurezza, non garantisce mai un ripristino integrale dei dati. Il pagamento non garantisce né la consegna di uno strumento realmente funzionante, né un recupero completo, né tanto meno l’assenza di un nuovo attacco nei mesi successivi. Su file strutturati complessi, il fallimento parziale della decrittazione non è un’eccezione documentata da pochi casi rari: è uno scenario che i laboratori di recupero osservano regolarmente.
Strumenti sviluppati con urgenza, non testati in condizioni reali
Gli strumenti di decrittazione forniti dai criminali informatici dopo il pagamento sono sviluppati rapidamente, sotto pressione, con l’unico obiettivo di dimostrare che la decrittazione è possibile. Sono raramente progettati per gestire correttamente i casi limite: file grandi, formati frammentati, scritture interrotte durante la cifratura. Il risultato è che spesso funzionano correttamente su file semplici (documenti d’ufficio, immagini) ma diventano instabili non appena incontrano strutture dati più complesse.
Il caso particolare dei database e delle macchine virtuali
Un database SQL non è un semplice flusso di dati da decrittare blocco per blocco. Contiene indici, pagine interne, relazioni tra tabelle, che devono restare perfettamente coerenti perché il motore di database possa rileggerlo. Lo stesso vale per un file di macchina virtuale VHDX o VMDK, la cui intestazione e tabella di allocazione devono corrispondere esattamente al contenuto del disco virtuale. Un decrittatore che tratta il file come un blocco binario uniforme, senza rispettare queste strutture interne, può lasciare quasi tutto il contenuto tecnicamente decrittato rendendo però il database o la VM completamente inutilizzabile: un semplice spostamento di un byte nell’intestazione o nella tabella di allocazione basta a rendere il file illeggibile. Alcuni gruppi di criminali informatici offrono un supporto tecnico dopo il pagamento, per una questione di “reputazione” che li spinge a mantenere vittime pagatrici in futuro — ma questo servizio resta a loro totale discrezione, senza alcuna garanzia di risultato né possibilità di ricorso legale se non riesce a risolvere il tuo caso.
Decrittazione e recupero dati: due problemi diversi
È il punto più mal compreso in questo tipo di situazione. La decrittazione consiste nel ritrovare il contenuto in chiaro di un file cifrato: è un problema crittografico. Il recupero dati consiste nel ricostruire una struttura di file utilizzabile dal sistema o dall’applicazione in questione: è un problema di struttura e integrità. Un file può essere perfettamente decrittato in senso crittografico e restare inutilizzabile in senso applicativo, perché le sue intestazioni, i suoi indici o le sue tabelle interne non sono state rimesse in coerenza durante l’operazione. È esattamente ciò che accade sui database SQL e sui file di VM dopo una decrittazione automatizzata mal gestita.
Cosa non fare in caso di decrittazione parziale o fallita
Di fronte a un risultato deludente, il primo riflesso è spesso rilanciare lo strumento più volte sperando in un risultato migliore, o tentare una riparazione con utility SQL generiche trovate online. Entrambi i riflessi aggravano quasi sempre la situazione.
- Non rilanciare il decrittatore più volte di seguito sugli stessi file: ogni passaggio può sovrascrivere le ultime strutture ancora utilizzabili.
- Non cercare di riparare da solo un database danneggiato con uno strumento di riparazione SQL standard: questi strumenti presuppongono una corruzione classica, non una struttura alterata da una decrittazione parziale, e rischiano di eliminare dati ancora recuperabili.
- Clona o salva lo stato attuale dei file prima di qualsiasi nuovo tentativo, inclusi i file parzialmente decrittati: è spesso l’unica copia utilizzabile che resta.
- Conserva anche una copia dei file cifrati originali e della chiave ottenuta, nel caso in cui una nuova versione dello strumento di decrittazione si rendesse necessaria in seguito.
L’approccio professionale di fronte a una decrittazione fallita
Là dove uno strumento di decrittazione automatizzato si arresta, un intervento manuale a livello binario ed esadecimale può prendere il sopravvento. Si tratta di analizzare direttamente la struttura del file: individuare le tabelle SQL, le intestazioni di VM o gli indici che non sono stati correttamente rimessi in coerenza, per poi ricostruire questi elementi uno per uno a partire da ciò che resta utilizzabile nel file parzialmente decrittato. Questo approccio richiede una buona conoscenza del formato file in questione (motore SQL utilizzato, versione del formato VHDX o VMDK) e strumenti adatti a questo livello di analisi, molto diversi dalle utility di riparazione consumer.
Un laboratorio specializzato in recupero dati su server inizia generalmente con una diagnosi per determinare precisamente dove si trova la rottura tra i dati tecnicamente decrittati e la struttura logica attesa. Questa diagnosi permette di sapere se una ricostruzione è possibile prima di intraprendere qualsiasi ulteriore manipolazione sui file, evitando così di perdere tempo su una pista che non porterebbe a nulla.
Cosa bisogna ricordare
Ottenere una chiave di decrittazione, tramite il pagamento di un riscatto o tramite uno strumento gratuito, è solo il primo passo. Su file complessi come database e macchine virtuali, una decrittazione parziale che lascia la struttura interna corrotta è un risultato frequente, non un incidente isolato. Il riflesso giusto non è insistere con lo strumento originale né tentare una riparazione generica, ma preservare lo stato attuale dei file e rivolgersi a una competenza capace di ricostruire le strutture interne a livello binario. È questa fase, distinta dalla decrittazione stessa, a determinare se i tuoi dati diventano realmente di nuovo utilizzabili.