Cosa fare con un ransomware nelle prime 24 ore
Un file condiviso che improvvisamente non si apre, estensioni sconosciute sui documenti, una richiesta di riscatto sul desktop: quando questi segnali compaiono, il tempo conta più della velocità con cui si cerca una soluzione. Sapere cosa fare con un ransomware significa limitare la propagazione, preservare le prove e mantenere aperte le opzioni di ripristino.
Per una PMI, un attacco ransomware non riguarda solo i PC cifrati. Può bloccare il gestionale, l'e-commerce, il CRM, i servizi di posta, le integrazioni con fornitori e la produzione. Se sono stati sottratti dati prima della cifratura, entra in gioco anche la gestione di un possibile data breach. L'obiettivo iniziale non è “tornare online a ogni costo”, ma fermare l'incidente senza compromettere ulteriormente sistemi, backup e informazioni.
Cosa fare in caso di ransomware: isolare subito
Il primo dispositivo su cui compare la nota di riscatto o un comportamento sospetto va isolato immediatamente dalla rete. Scollegare il cavo Ethernet, disattivare Wi-Fi e VPN: non spegnere automaticamente il computer, salvo indicazioni del team tecnico. Una macchina ancora accesa può conservare informazioni utili per capire come è avvenuto l'accesso e quali processi sono coinvolti.
L'isolamento deve estendersi con criterio. Se il ransomware ha raggiunto cartelle condivise, server file o account amministrativi, limitarsi al PC iniziale può essere insufficiente. Il responsabile IT o il fornitore incaricato deve verificare rapidamente endpoint, server, NAS, hypervisor, condivisioni di rete e accessi remoti. In presenza di segnali di compromissione, è preferibile segmentare o disconnettere temporaneamente le aree coinvolte piuttosto che lasciare al malware il tempo di espandersi.
In questa fase non bisogna avviare pulizie improvvisate, reinstallare sistemi o cancellare file sospetti. Sono azioni comprensibili, ma possono eliminare log e tracce necessarie alla ricostruzione dell'attacco. Annotare orari, utenti collegati, messaggi comparsi, sistemi interessati e prime anomalie osservate aiuta a costruire una cronologia affidabile.
Attivare la risposta all'incidente
Un ransomware richiede una catena decisionale chiara. Serve una persona che coordini l'incidente, autorizzi le azioni critiche e tenga aggiornati direzione, IT, operations ed eventuali fornitori. Senza questa regia, il rischio è che qualcuno ripristini un sistema infetto mentre un altro modifica credenziali o riattiva servizi esposti, allungando il fermo.
Il team tecnico deve stabilire l'estensione reale del danno. Questo significa verificare quali host sono stati cifrati, quali account hanno avuto accessi anomali, se sono presenti connessioni remote non autorizzate e quando sono comparsi i primi indicatori. I log di firewall, VPN, Active Directory, posta, endpoint protection, server applicativi e piattaforme cloud sono fondamentali. Anche un'attività apparentemente marginale, come un login amministrativo da un indirizzo insolito, può indicare il punto di ingresso.
Nel frattempo, è opportuno sospendere le credenziali potenzialmente esposte e revocare le sessioni attive. Gli account con privilegi amministrativi meritano priorità. La modifica delle password va pianificata: farla senza aver prima contenuto l'accesso dell'attaccante può dare una falsa sensazione di sicurezza, perché una persistenza già installata potrebbe consentire un nuovo ingresso.
Gestire comunicazioni e continuità operativa
La comunicazione interna deve essere essenziale e basata sui fatti. Informare i dipendenti che i sistemi sono in verifica, chiedere di non accendere dispositivi spenti e di segnalare anomalie è utile. Non servono dettagli tecnici prematuri o ipotesi sulla causa dell'attacco.
Se il fermo impatta clienti, ordini, pagamenti o servizi regolati, occorre definire procedure temporanee. Per esempio, un'azienda può dover raccogliere ordini con modalità controllate fuori dal gestionale, rimandando l'inserimento nel sistema al termine del ripristino. La continuità operativa non è solo disponibilità tecnica: è la capacità di mantenere attivi i processi prioritari senza creare nuovi problemi di sicurezza o di qualità del dato.
Backup: verificarli prima di ripristinare
Il backup è utile solo se è integro, accessibile e separato dall'ambiente compromesso. Molti ransomware cercano esplicitamente repository, snapshot e credenziali di backup prima di cifrare i dati di produzione. Per questo non va dato per scontato che l'ultima copia disponibile sia sicura.
Prima di ripristinare, bisogna identificare un punto temporale antecedente alla compromissione e testarlo in un ambiente isolato. Il test serve sia a controllare l'integrità dei dati sia a escludere che nel backup siano presenti file dannosi, configurazioni alterate o persistenze. Il ripristino diretto in produzione, senza una verifica, può reintrodurre il problema.
La priorità dipende dall'operatività dell'impresa. Di solito si parte da identità e servizi di autenticazione, connettività, sistemi di sicurezza e dati core, per poi passare ad applicazioni gestionali, file server, e-commerce e servizi secondari. Non esiste un ordine universale: un'azienda manifatturiera, uno studio professionale e una farmacia hanno dipendenze operative diverse. L'ordine corretto è quello definito in anticipo da un piano di disaster recovery, non quello deciso sotto pressione.
Pagare il riscatto non è una strategia di ripristino
La richiesta di riscatto crea una pressione concreta, soprattutto quando il fermo produce perdite ogni ora. Tuttavia, il pagamento non garantisce la consegna di una chiave funzionante, il recupero completo dei dati né la cancellazione delle copie sottratte. Può inoltre esporre l'organizzazione a ulteriori richieste e a rischi legali da valutare con consulenti specializzati.
La decisione non dovrebbe essere presa da una sola persona né sulla base della nota di riscatto. Occorre confrontare tempi e qualità del recupero da backup, impatto del fermo, natura dei dati coinvolti, eventuale esfiltrazione e indicazioni delle autorità competenti. Anche quando alcuni file vengono decifrati, resta necessario bonificare l'infrastruttura: ripristinare i documenti senza rimuovere la causa dell'accesso prepara il terreno a un secondo attacco.
Data breach e obblighi di notifica
La cifratura non prova da sola che i dati siano stati sottratti, ma molti gruppi ransomware adottano la doppia estorsione: copiano documenti, database o archivi prima di bloccarli. Se sono coinvolti dati personali, l'azienda deve valutare il rischio per gli interessati e gli obblighi previsti dal GDPR, incluso il possibile coinvolgimento del Garante per la protezione dei dati personali entro le tempistiche applicabili.
Questa valutazione richiede evidenze tecniche e competenze legali. Bisogna capire quali dati sono stati potenzialmente esposti, chi può esserne impattato, se l'esfiltrazione è confermata o plausibile e quali misure sono state già adottate. Conservare log, immagini dei sistemi e documentazione delle attività svolte è utile sia per la gestione dell'incidente sia per dimostrare un approccio diligente.
Dopo il ripristino: chiudere il punto di ingresso
Tornare operativi non chiude l'incidente. Prima della piena riattivazione, serve una revisione tecnica dell'ambiente: aggiornamenti mancanti, servizi remoti esposti, configurazioni deboli, account inutilizzati, privilegi eccessivi, software non supportato e assenza di autenticazione a più fattori. Sono spesso queste condizioni, più che un singolo errore umano, a rendere possibile un attacco con impatto esteso.
La protezione efficace combina più livelli. Endpoint aggiornati e monitorati, MFA per accessi remoti e amministrativi, segmentazione di rete, backup separati e testati, gestione centralizzata delle patch e controllo dei privilegi riducono sia la probabilità di compromissione sia la portata del danno. Per applicazioni web, e-commerce e gestionali su misura, vanno verificati anche dipendenze software, credenziali applicative, pannelli di amministrazione e configurazioni server.
È utile trasformare l'incidente in un test concreto del piano di risposta. Quanto tempo è servito per isolare i sistemi? I contatti erano aggiornati? I backup erano ripristinabili? Le dipendenze tra applicazioni erano documentate? Le risposte permettono di correggere processi e investimenti con priorità reali, non teoriche.
Un ransomware non si gestisce con un singolo prodotto né con una checklist compilata dopo l'attacco. Si gestisce costruendo nel tempo controllo su infrastruttura, codice, accessi e backup. Quando arriva l'emergenza, avere un partner tecnico che conosce davvero questi elementi riduce l'incertezza e permette di prendere decisioni basate sui fatti.
