Shaun Stockman, direttore senior dello sviluppo commerciale per le Americhe presso Ontrack.
Shaun collabora con compagnie assicurative e team di risposta agli incidenti per il ripristino dei dati in caso di attacchi ransomware, quando i backup sono già stati cancellati, cosa che accade più spesso di quanto la maggior parte dei team IT si aspetti.
Quando il ransomware distrugge i backup insieme ai dati di produzione, il recupero si sposta sul livello di archiviazione stesso. Ciò significa snapshot, dati deduplicati e frammenti rimasti dopo l’esecuzione di un comando di cancellazione. Ho partecipato a riunioni con periti assicurativi e team DFIR in cui la prima reazione era: «I backup sono andati persi, siamo finiti». Capisco perché la gente la pensi così. Ma «andati persi dalla console» non significa «andati persi dal disco».
Perché un’azienda con backup funzionanti non ha bisogno di pagare. Gli autori degli attacchi trascorrono ora in media oltre 70 giorni all’interno dell’ambiente della vittima prima di avviare la crittografia, e gran parte di quel tempo viene impiegato per individuare e disabilitare innanzitutto le opzioni di ripristino. Le piattaforme di backup come Veeam sono un bersaglio allettante perché dispongono delle credenziali per il resto dell’ambiente e conservano una copia non crittografata e ordinata cronologicamente di tutto ciò che l’azienda gestisce.
Ho visto questa strategia concretizzarsi con il furto di credenziali dalla console di backup, seguito dalla cancellazione di snapshot e copie shadow, e solo successivamente viene rilasciato il payload di crittografia. Quando il team IT se ne accorge, i backup sono già andati persi. Alcuni gruppi, come Akira e Fog, avrebbero riorganizzato l’intero loro approccio proprio in base a questo. Invece di colpire prima i server di produzione, puntano direttamente all’infrastruttura di backup, poiché è lì che risiede il vero punto di leva. Questo è uno dei motivi per cui abbiamo descritto la gestione di un attacco ransomware come una sequenza di decisioni, non come un singolo momento. Ciò che si fa nella prima ora dopo la scoperta è comunque importante, anche se i backup non sono stati salvati.
Onestamente, più di quanto ci si aspetti. La cancellazione è solitamente un’operazione di puntatore. Il file system contrassegna lo spazio come disponibile, ma i blocchi di dati effettivi rimangono lì finché non vi viene scritto qualcosa di nuovo. È questa la finestra temporale in cui opera un tecnico di recupero dati.
Le tecniche variano a seconda di ciò che è rimasto:
Sarò onesto, c’è un’eccezione importante. Sugli SSD, il comando TRIM tende a cancellare rapidamente i blocchi eliminati, quindi la finestra di recupero è più ristretta rispetto a quella sui dischi rotanti o sulla maggior parte degli array SAN e NAS. Questo è un altro motivo per cui la prima mossa dopo aver scoperto un attacco è quella di interrompere la scrittura sullo storage interessato, non di iniziare a risolvere i problemi su di esso. Approfondiamo i meccanismi effettivi del recupero dei dati dagli attacchi ransomware, compreso come si presenta tipicamente un intervento di recupero.
Direi di rifletterci bene prima di farlo e di non dare per scontato che questo risolva il problema dei backup, anche se si paga. Dati recenti del settore mostrano che il 97% delle organizzazioni recupera almeno una parte dei dati crittografati dopo un incidente, ma tra coloro che pagano il riscatto, solo circa il 4% recupera tutto. Gli strumenti di decrittografia forniti dagli autori degli attacchi sono spesso inaffidabili e non servono a nulla per gli archivi di backup che l’autore dell’attacco ha già cancellato anziché crittografare.
Si tratta di una decisione in cui assicuratori e consulenti legali devono essere coinvolti sin dall’inizio, non a posteriori. Abbiamo scritto un articolo più approfondito sull’opportunità di pagare il riscatto, che illustra i pro e i contro in modo più dettagliato. La mia opinione personale, per quel che vale: il pagamento a volte è la scelta giusta per motivi di continuità operativa, ma non dovrebbe essere il piano per recuperare i propri backup.
Aggiungete l’immutabilità e i test a qualsiasi cosa stiate già facendo. La vecchia regola 3-2-1 (tre copie, due tipi di supporto, una fuori sede) è stata concepita per i guasti hardware e le catastrofi naturali. Non è stata pensata per un aggressore che rimane all’interno della vostra rete per due mesi studiando la vostra pianificazione dei backup.
La versione aggiornata, talvolta denominata 3-2-1-1-0, aggiunge una copia immutabile o isolata fisicamente (air-gapped) che non può essere modificata o eliminata nemmeno con le credenziali di amministratore, oltre a zero errori di ripristino, il che significa che avete effettivamente testato un ripristino e confermato che funziona. Credo che quest’ultimo aspetto venga spesso trascurato più di quanto si ammetta.
Vorrei anche esprimere qualche riserva sul considerare l’immutabilità come una singola impostazione da attivare una volta sola. Le politiche di blocco degli oggetti, i periodi di conservazione e le autorizzazioni amministrative devono essere tutti allineati, e ho visto repository “immutabili” che si sono rivelati contenere un’eccezione incorporata per un account di servizio di cui nessuno ricordava l’esistenza. Vale la pena verificarlo in modo specifico, non limitandosi a fidarsi dell’etichetta sul livello di archiviazione.
Se siete nel bel mezzo di un incidente: interrompete le operazioni di scrittura sullo storage interessato prima di fare qualsiasi altra cosa, anche prima di iniziare a risolvere i problemi dalla console di backup. Coinvolgete uno specialista nel recupero dei dati insieme al vostro team DFIR, non dopo di loro, poiché la finestra temporale per il recupero dei dati cancellati si restringe rapidamente, specialmente sullo storage flash.
Se non siete nel bel mezzo di un incidente: verificate se la vostra copia di backup “immutabile” sia effettivamente immutabile, o se sia semplicemente contrassegnata come importante in un’impostazione di policy che le credenziali di amministratore possono sovrascrivere. Quindi programmate un vero e proprio test di ripristino entro questo trimestre. Non una verifica del checksum. Un ripristino vero e proprio.
È ancora possibile recuperare i dati se il ransomware cancella i backup?
La cancellazione di solito rimuove il puntatore del file system ai dati, non i dati stessi, quindi i blocchi sottostanti possono talvolta essere recuperati a seconda del tipo di archiviazione e di quanto è stato scritto da allora.
Quanto tempo richiede il recupero quando i backup sono andati persi?
Varia molto, da giorni a qualche settimana, a seconda del volume dei dati, del tipo di archiviazione e di quanta sovrascrittura è già avvenuta. Gli ambienti basati su SSD tendono ad essere più veloci grazie al TRIM, che riduce i tempi di recupero.
Il pagamento del riscatto consente di recuperare i backup cancellati?
Una chiave di decrittografia riguarda i dati di produzione crittografati, non i repository di backup che l’autore dell’attacco ha eliminato definitivamente. Solo circa il 4% delle organizzazioni che pagano recupera tutti i propri dati, quindi il pagamento non è di per sé una strategia affidabile per il recupero dei backup.
Qual è la vera differenza tra un ripristino da backup e un intervento di recupero dati?
Un ripristino attinge da una copia di backup ancora esistente e funzionante. Un intervento di recupero ricostruisce i dati da ciò che è fisicamente rimasto sullo storage dopo che il backup stesso è andato perso, utilizzando tecniche forensi anziché un semplice pulsante di ripristino.
La distruzione dei backup sta diventando una pratica comune e non credo che questa tendenza si invertirà a breve. Le organizzazioni che ne escono meglio sono quelle che considerano l’immutabilità dei backup e i test di recupero come un lavoro continuo, non come una voce da spuntare in un audit di conformità di due anni fa. Ontrack collabora con assicuratori e team DFIR proprio su questo tipo di recupero, e preferirei parlarne con voi prima che si verifichi un incidente piuttosto che durante.