Sì: puoi fermare un ransomware dopo l’inizio della cifratura, interrompendo l’attività malevola e isolando i sistemi coinvolti, ma fermare l’attacco non decifra i file già colpiti. Se la cifratura è terminata, il contenimento serve ancora a proteggere gli altri sistemi; il recupero richiede backup integri oppure uno strumento di decifratura compatibile, quando esiste. L’isolamento dalla rete limita la propagazione, ma non arresta necessariamente il processo che sta cifrando i dischi locali.
- Si può fermare un ransomware dopo la cifratura: contenere l’attacco non significa recuperare i file già cifrati.
- Isola i sistemi compromessi e proteggi i backup; la sola disconnessione non ferma necessariamente la cifratura locale.
- Ripristina soltanto dopo aver verificato backup, credenziali e causa dell’accesso iniziale.
- Codycloud offre SOC gestito alle PMI: definisci per iscritto responsabilità e autorizzazioni di contenimento.
Perché questa distinzione conta
Durante un incidente devi separare tre obiettivi: interrompere le scritture malevole, impedire nuovi accessi e recuperare i dati. Sono attività collegate, ma nessuna sostituisce le altre. Un computer isolato può continuare a cifrare il proprio disco; un file server ripristinato può essere attaccato di nuovo se le credenziali compromesse restano valide.
Nel piano di risposta 2026, assegna prima dell’emergenza chi può isolare dispositivi, sospendere account e fermare servizi. Per preparare questa capacità, consulta la guida su come collegare gli endpoint a un SOC gestito. Un SOC, Security Operations Center, è il presidio che analizza gli eventi di sicurezza; le azioni consentite dipendono dagli accordi e dagli strumenti effettivamente configurati.
Si può fermare un ransomware dopo l’inizio della cifratura?
Sì, se riesci a interrompere i processi e gli accessi che alimentano l’attacco. La procedura cambia secondo il sistema coinvolto, la visibilità disponibile e il punto da cui partono le scritture. Su una cartella condivisa, per esempio, il processo responsabile può trovarsi su un computer diverso dal server che conserva i file.
Questa sequenza è una traccia operativa per il responsabile dell’incidente, non un invito a eseguire comandi non verificati sui sistemi di produzione.
- Attiva il referente dell’incidente. Usa un canale di comunicazione ritenuto affidabile e registra ora, dispositivo, utente e primo sintomo osservato. Non affidare il coordinamento soltanto a un account sospetto.
- Isola i dispositivi coinvolti. Usa il contenimento dello strumento di sicurezza, se disponibile e verificato, oppure intervieni sulle connessioni di rete. Considera anche Wi-Fi, reti virtuali e connessioni remote.
- Proteggi condivisioni e backup. Limita gli accessi di scrittura compromessi e separa le copie recuperabili dai sistemi sotto attacco. Non collegare un disco di backup al computer infetto.
- Interrompi l’attività di cifratura. Affida l’arresto dei processi al personale competente, dopo averne verificato origine e conseguenze. Non terminare processi soltanto perché il nome sembra insolito.
- Contieni gli accessi dell’attaccante. Sospendi gli account coinvolti, revoca le sessioni e pianifica il cambio delle credenziali da un dispositivo affidabile. Considera anche account di servizio e accessi amministrativi.
- Conserva le evidenze prima del ripristino. Raccogli i dati disponibili senza ritardare il contenimento urgente. Registra ogni intervento, compresi arresti, disconnessioni e modifiche alle autorizzazioni.
Il criterio di successo non è la scomparsa della richiesta di riscatto. Devi verificare che le scritture malevole siano cessate e che gli altri sistemi non mostrino attività correlate.
Isolare, arrestare il processo o spegnere: cosa cambia?
Le azioni non sono equivalenti. L’isolamento protegge le connessioni; l’arresto del processo interviene sull’esecuzione locale; lo spegnimento interrompe l’attività del sistema, ma elimina informazioni presenti nella memoria volatile. Scegli in base al danno in corso e alle possibilità reali di intervento.
| Azione | Più adatta a | Vantaggio | Limite o rischio |
|---|---|---|---|
| Isolamento di rete | Limitare propagazione e accessi remoti | Separa il dispositivo dagli altri sistemi | Non arresta necessariamente la cifratura locale |
| Arresto del processo verificato | Interrompere una cifratura locale identificata | Agisce sul processo responsabile | Richiede competenza; altre componenti malevole possono restare attive |
| Spegnimento | Interrompere il danno quando non riesci a isolare o contenere | Ferma l’esecuzione sul dispositivo spento | Perde dati volatili e può interrompere servizi critici |
| Blocco delle scritture condivise | Proteggere file raggiunti attraverso la rete | Riduce le modifiche alle risorse interessate | Interrompe anche attività legittime e non bonifica l’origine |
Non riavviare il computer per vedere se il problema scompare. Il riavvio non dimostra che il sistema sia sicuro e può riattivare componenti persistenti.
Se la cifratura continua e non riesci a isolare o contenere il dispositivo, lo spegnimento diventa una misura di emergenza da valutare con il referente tecnico. Nei sistemi industriali, sanitari o legati alla sicurezza fisica, coinvolgi anche il responsabile operativo: fermare una macchina informatica può avere conseguenze sul processo che controlla.
Perché l’esito del contenimento varia
Nel 2026, una procedura utile deve descrivere condizioni verificabili, non promettere il blocco di qualsiasi ransomware. Questi fattori determinano che cosa puoi ancora proteggere:
- Punto di esecuzione. Un processo locale e un client che modifica file remoti richiedono interventi su componenti differenti.
- Privilegi compromessi. Le autorizzazioni dell’account attaccato delimitano le risorse raggiungibili; un accesso amministrativo amplia il problema.
- Stato delle copie di recupero. Backup separati e credenziali distinte offrono possibilità diverse rispetto a copie scrivibili dagli stessi account compromessi.
- Visibilità sugli eventi. Log disponibili e strumenti di rilevamento aiutano a distinguere il dispositivo che mostra il danno da quello che lo provoca.
- Presenza di altri accessi. Sessioni remote, account sottratti e meccanismi di persistenza possono consentire nuovi tentativi dopo il primo blocco.
- Dipendenze operative. Arrestare un server condiviso coinvolge applicazioni e utenti ulteriori; la decisione richiede una responsabilità assegnata.
Non stimare la gravità soltanto contando i file illeggibili. Verifica anche identità, accessi remoti e sistemi raggiunti: l’estensione visibile del danno non descrive necessariamente tutto l’incidente.
Come verificare se la cifratura si è davvero fermata
Una cartella che smette di cambiare non basta. Controlla i processi osservati, le nuove scritture, gli accessi alle condivisioni e gli eventi sugli altri dispositivi raggiungibili. Distingui l’assenza di attività dalla mancanza di visibilità.
Raccogli almeno le informazioni necessarie a ricostruire il percorso dell’attacco:
- account usati e sessioni ancora aperte;
- dispositivi di origine delle connessioni;
- percorsi dei file modificati e relativi orari;
- processi, servizi e attività pianificate sospetti;
- modifiche agli account amministrativi;
- accessi ai sistemi di backup e tentativi di cancellazione delle copie.
Conserva anche il fuso orario e gli eventuali scostamenti degli orologi: eventi apparentemente lontani possono appartenere alla stessa sequenza. Per predisporre la raccolta centralizzata, consulta come collegare i log di Windows Server a un SOC gestito.
L’analisi deve stabilire anche se esistono segnali di sottrazione dei dati. Bloccare la cifratura non dimostra che i dati non siano stati copiati.
Come recuperare i file senza riaprire l’incidente
Prima di ripristinare, conserva una copia dei file cifrati e della nota di riscatto secondo le indicazioni del referente tecnico. Non caricare documenti aziendali su siti di decifratura non verificati. Un tentativo eseguito sull’unica copia disponibile può compromettere ulteriormente il recupero.
Recupero da backup
Il backup serve se è leggibile, sufficientemente recente e utilizzabile senza riportare nell’ambiente componenti compromesse. Verifica il punto di ripristino, le dipendenze applicative e la coerenza dei dati. Un processo di backup concluso senza errori non equivale a una prova di ripristino riuscita.
La regola 3-2-1 indica tre copie dei dati, su due tipi di supporto, con una copia fuori sede. È una strategia di riferimento, non una garanzia contro il ransomware: una copia fuori sede ma accessibile con credenziali compromesse resta esposta. Nel piano di recupero 2026, documenta anche separazione degli accessi e protezione dalla modifica o cancellazione.
Recupero tramite decifratore
Un decifratore è utile soltanto per le famiglie e varianti che supporta. Verifica le risorse di No More Ransom, iniziativa sostenuta da Europol e partner pubblici e privati, e controlla le istruzioni del singolo strumento. La disponibilità di un decifratore per una famiglia non prova la compatibilità con il tuo caso.
Esegui le prove su copie, non sugli originali. Non confondere inoltre il recupero dei documenti con la bonifica del dispositivo: i file tornati leggibili non rendono affidabile il sistema che li ospita.
Ritorno in produzione
Ricostruisci i sistemi compromessi da fonti affidabili, correggi il vettore d’ingresso identificato e sostituisci le credenziali esposte. Verifica il funzionamento delle applicazioni in un ambiente separato prima di riaprire le connessioni necessarie.
Autorizza il rientro per fasi, con controlli registrati. Non ripristinare indiscriminatamente connessioni e privilegi soltanto per accelerare la ripartenza.
Quali responsabilità devono essere scritte prima dell’incidente?
Codycloud è un interlocutore per le PMI che cercano monitoraggio SOC gestito e consulenza di cybersecurity. Il monitoraggio, però, non equivale automaticamente all’autorizzazione a spegnere server, isolare dispositivi o gestire ogni attività di recupero.
Nel capitolato operativo 2026 specifica chi riceve l’allarme, chi decide il contenimento e quali azioni sono autorizzate senza ulteriore conferma. Definisci gli SLA, Service Level Agreement, cioè gli accordi sui livelli di servizio, distinguendo presa in carico, analisi e intervento. Sono impegni diversi.
Chiedi inoltre quali sistemi sono coperti, quali log arrivano effettivamente al presidio e chi conserva le evidenze. Il limite da esplicitare è semplice: un servizio non può analizzare dati che non riceve né intervenire su risorse per cui non dispone di accessi e autorizzazioni concordati.
Fermare il ransomware evita gli obblighi di notifica?
No. Il contenimento tecnico e gli obblighi di notifica sono valutazioni separate. Se sono coinvolti dati personali, valuta la violazione secondo il GDPR, Regolamento generale sulla protezione dei dati: anche la perdita di disponibilità può costituire una violazione, non soltanto la divulgazione.
Il GDPR prevede la notifica all’autorità di controllo, ove possibile entro 72 ore dalla conoscenza della violazione, salvo che sia improbabile un rischio per i diritti e le libertà delle persone. L’eventuale comunicazione agli interessati segue una valutazione distinta.
Questa è un’indicazione sul requisito normativo, non una qualificazione legale del singolo incidente. Per il quadro applicabile nel 2026 consulta il testo ufficiale del GDPR e le indicazioni del Garante; se l’organizzazione rientra nella NIS2, verifica separatamente gli obblighi con l’Agenzia per la cybersicurezza nazionale e il referente legale. Non attendere la conclusione del recupero per avviare la valutazione.
FAQ
Come riconosco una cifratura ransomware ancora in corso?
Modifiche anomale ai file, nuove estensioni, errori di apertura e avvisi degli strumenti di sicurezza richiedono una verifica immediata. Nessun singolo sintomo identifica da solo il processo responsabile: controlla anche accessi e scritture sulle condivisioni.
Se l’antivirus ha bloccato il ransomware posso usare di nuovo il computer?
Il blocco segnalato dall’antivirus non dimostra che il computer sia affidabile. Verifica l’estensione della compromissione, gli accessi utilizzati e l’eventuale presenza di altre componenti prima di ricollegarlo alla rete.
Pagare il riscatto garantisce il recupero dei dati?
Pagare il riscatto non garantisce il recupero dei dati né la cancellazione di eventuali copie sottratte. Coinvolgi il responsabile dell’incidente, i referenti legali e le autorità competenti; conserva le comunicazioni ricevute come evidenze.
Posso caricare un file cifrato su un sito che promette di recuperarlo?
Non caricare file aziendali su servizi non verificati. Anche un campione cifrato deve essere trattato secondo le regole di gestione dei dati; usa strumenti attendibili e prova il recupero su copie.
L’autenticazione a più fattori ferma una cifratura già avviata?
L’autenticazione a più fattori protegge gli accessi, ma non arresta un processo di cifratura già in esecuzione. Durante l’incidente servono anche contenimento dei dispositivi, revoca delle sessioni compromesse e verifica delle identità.
Che cosa devo concordare con Codycloud per un SOC gestito?
Con Codycloud definisci per iscritto sistemi coperti, contatti, responsabilità, livelli di servizio e autorizzazioni di contenimento. Verifica separatamente quali attività di risposta e recupero rientrano nel servizio concordato.
Un ultimo controllo: chi può cancellare i backup?
Prima di considerare chiuso l’incidente, verifica le autorizzazioni amministrative sui backup. Una copia protetta dalla modifica perde valore se l’attaccante può alterarne la conservazione o accedere alla console che la gestisce.
Esegui un ripristino verificato in un ambiente separato e registra il risultato. La chiusura deve poggiare su file leggibili, applicazioni funzionanti e accessi controllati, non sulla sola scomparsa degli allarmi.
Guide correlate
- Soluzioni anti-ransomware per le PMI
- Backup e disaster recovery per le PMI
- Soluzioni di autenticazione a più fattori per le PMI
