Ransomware ha criptato tutti i server aziendali stanotte: cosa fare esattamente nelle prime ore?

Staccate subito i cavi ethernet da tutti i PC dell'ufficio e spegnete le reti Wi-Fi. Non staccate la spina né spegnete i computer infetti: limitatevi a isolarli dalla rete. Spegnere completamente le macchine cancellerebbe le chiavi temporanee di cifratura nella RAM e le prove utili per l'analisi forense.

Copiate un paio di file cifrati di esempio e la nota di riscatto su una chiavetta USB pulita e analizzateli da una macchina isolata. È fondamentale identificare la variante di malware utilizzata: in alcune versioni meno recenti la chiave simmetrica resta in memoria, oppure i ricercatori di sicurezza hanno già rilasciato i decryptor pubblici per quel ceppo.

Chi pensa di pagare il riscatto e recuperare i file di solito va incontro a una grandissima delusione. Un'azienda di logistica a Madrid che si è trovata nella stessa situazione ha pagato 30.000 euro; il programma di decifrazione che gli hanno inviato ha corrotto metà dei file e, due settimane dopo, sono rientrati dalla stessa falla chiedendo altri soldi. Non pagate assolutamente.

L'anno scorso abbiamo subito un attacco simile e ci hanno bloccato lo storage. Abbiamo pagato 5.500 euro a uno specialista esterno indipendente di incident response. Avevamo un backup offline su nastro risalente a due settimane prima; siamo ripartiti da lì e abbiamo reinserito a mano le fatture del periodo mancante. In totale siamo rimasti fermi 4 giorni, ma a quegli estorsori non abbiamo dato un solo centesimo.

Avete idea di come siano riusciti a entrare gli aggressori? C'era una porta RDP aperta verso l'esterno o qualcuno del personale ha aperto un allegato arrivato via email? Non avete nessun altro backup completamente isolato dalla rete o su cloud con versioning storico?

Prestate molta attenzione a non superare i termini per la notifica all'Agenzia Spagnola per la Protezione dei Dati (AEPD). La prima notifica va inviata entro il termine di 72 ore anche se l'analisi tecnica non è ancora conclusa; man mano che l'entità del danno e il numero di record coinvolti saranno chiari, si potrà integrare la pratica con un report aggiuntivo.

mi dispiace tantissimo, so fin troppo bene che senso di impotenza si prova ad arrivare la mattina a lavvoro e trovarsi davanti quella schermata. dica al suo team di non farsi prendere dal panico, rassicuri i clienti dicendo che c'è una manutenzione tecnica in corso e cerchi subito di procurarsi un supporto professionale.

Se avete staccato i cavi di rete, non formattate assolutamente nulla e chiamate subito un consulente esperto di incident response.

La mia domanda sarà un po' da principiante scusate. Il vero problema non è il numero, ma su cosa si basa quel numero.

Sono passato da qui, vi racconto. Cercare di farlo da soli è la strada più costosa.

Io seguirei questa strada.

Lascio un avvertimento. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Buon lavoro.

Ha ragione.

C'è un errore comune che si commette facendo questo. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Dopo aver vissuto questa cosa, il mio punto di vista è cambiato. La risposta varia molto in base al settore, non esiste una regola generale.

Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza. Lascio una nota, potrebbe servire.

Per un periodo ci siamo bloccati anche noi nello stesso punto. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Spero che le sia utile.

Mi farebbe piacere se scrivesse il risultato. Non abbiate paura di chiedere chi non chiede paga sempre di più.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Mi chiedo anch'io.

Riassumo l'argomento, perché sono state date diverse risposte. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Confermato dall'esperienza.