Guida all'incidente: rilevare un'infezione da ransomware, isolarla e ripristinarla in modo pulito dai backup

Una infezione da ransomware è raramente un ‘singolo server cifrato’, ma di solito un evento a catena: accesso iniziale (es. credenziali rubate), propagazione tramite vie amministrative, manipolazione dei backup e solo alla fine la crittografia visibile. Chi è responsabile in azienda ha quindi meno bisogno di un whitepaper teorico che di una procedura affidabile: Come riconosco l’incidente? Cosa isolo immediatamente? Come ripristino secondo la strategia di backup senza portare con me il malware?

Questa guida è strutturata come un runbook pratico. Spiega non solo i passaggi, ma anche lo scopo che c’è dietro e i punti tipici in cui i ripristini falliscono: riaccensione prematura dei sistemi, identità compromesse (Active Directory), crittografia ‚inclusa‘ negli snapshot, mancanza di validazione del RESTore o gestione delle prove non corretta. Il pubblico target sono amministratori, System Engineers, operatori e fornitori di servizi IT tecnici – con focus su decisioni stabili sotto pressione temporale.

Infezione da Ransomware: 1) Situazione invece di azionismo: cosa si considera un incidente da ransomware?

Operativamente il termine ‚ransomware‘ è ombrello. Si intende in genere malware che cifra dati e richiede un riscatto. Negli ambienti aziendali spesso si aggiunge inoltre Exfiltration (esfiltrazione di dati), cioè il furto di dati a scopo di estorsione. Per la reazione iniziale tre domande sono più importanti della famiglia specifica:

• L’attaccante è ancora attivo? (persistenza, sessioni in corso, comunicazione C2 – ‚Command & Control‘, cioè controllo esterno)
• L’identità è compromessa? (Domain Admin, account amministrativi locali, service account, API-Keys)
• La catena di ripristino è pulita? (backup invariati, ambiente di RESTore separato, credenziali non riutilizzate)

Una conseguenza importante: se si ricopiano solo i file cifrati senza ripristinare identità/fiducia, la recidiva spesso si verifica entro poche ore o giorni.

2) Rilevamento precoce: indicatori tipici in esercizio (senza strumenti speciali)

Molti team notano la presenza di ransomware solo quando gli utenti vedono estensioni dei file o i sistemi non avviano più. È preferibile osservare indicatori che spesso si manifestano prima, utilizzando strumenti di base e il monitoring. Nessuna singola osservazione è probatoria – ma lo sono i pattern.

2.1 File, Shares, Storage: pattern che suggeriscono una cifratura

• Picchi massicci di scrittura file su fileserver/NAS (IOPS/throughput) e moltissime operazioni di ‚rename‘.
• Molti eventi ‚Access denied‘, perché il malware tenta di scrivere in tutti i percorsi.
• Estensioni file insolite o molte dimensioni di file uniformi (blocchi cifrati).
• Attività improvvisa di shadow copy/snapshot o loro cancellazione (l’attaccante elimina le opzioni di recovery).

Trappole: anche job legittimi (indicizzazione, scansione antivirus, import massivi) generano carico. Decisiva è la combinazione con segnali di sicurezza (nuove sessioni admin, esecuzione remota, modifiche GPO).

2.2 Identity & Directory: Active Directory come rischio centrale

In Windows-domini è lo strato centrale di identità e policy. Se Active Directory (AD) è compromesso, il cambio password su ’singoli server‘ è puramente cosmetico. Segnali precoci includono, tra gli altri, nuove appartenenze a gruppi altamente privilegiati, percorsi di accesso sospetti o il rollout di scheduled tasks tramite Group Policy.

Controllabili sono, per esempio, tipologie di accesso anomale (Remote/Batch), nuovi oggetti computer o modifiche alle GPO. Per una triage rapida potete considerare in via prioritaria i DC interessati e i server di management.

2.3 Rete: movimento laterale e „protocolli di gestione“

Gli operatori di ransomware sfruttano spesso percorsi amministrativi standard: SMB (accesso ai file), WinRM (Windows Remote Management), WMI (Windows Management Instrumentation), RDP nonché SSH in Linux-ambienti. Dal lato rete si osservano poi connessioni insolite «trasversali» tra segmenti, numerosi tentativi di autenticazione o nuove connessioni verso target di backup.

Insidia: in molte reti questi protocolli sono comunque «ampiamente aperti». Proprio per questo la microsegmentazione (limitazione mirata del traffico Est-Ovest) è una leva efficace di prevenzione e contenimento – anche dopo l’incidente, per riportare i sistemi online in modo controllato.

3) Misure immediate (0–30 Minuten): contenere senza compromettere il ripristino

I primi 30 minuti spesso decidono se l’incidente rimane locale o se si estende agli strati di backup e identità. L’obiettivo è il contenimento (Containment), non la «bonifica». La bonifica viene dopo – e si basa su un quadro della situazione stabile.

3.1 Principio: isolamento prima della perfezione forense – ma con giudizio

Il caso ideale sarebbe la completa acquisizione delle prove (dump di memoria, immagine disco). Nella pratica non è sempre immediatamente possibile. Tuttavia: evitate azioni che distruggono tracce o peggiorano la situazione. Errori tipici sono:

• Riavvio dei sistemi infetti «per vedere se torna a funzionare» (aggrava la cifratura, distrugge tracce volatili).
• Disattivazione alla cieca di AV/EDR perché dà fastidio (vi priva del sistema di allerta precoce).
• Spegnimento di rete troppo esteso che colpisce anche l’infrastruttura di backup e gli accessi out-of-band.

3.2 Isolamento prioritario: quali sistemi separare per primi?

Una prioritizzazione pragmatica:

1. Endpoint/server interessati che mostrano cifratura o sono fortemente sospetti: isolare dalla rete (porta switch/VLAN), disattivare il Wi‑Fi, per le VM scollegare la vNIC.
2. Vie di gestione privilegiate: Jump Hosts, workstation amministrative, server di Remote-Management. Questi sono spesso la «leva» per la diffusione.
3. Accessi e target di backup: server di backup, repository, gestione dello storage. Obiettivo: impedire che i backup vengano cancellati/o cifrati.
4. Nucleo identity: considerare isolati i Domain Controller e i componenti Federation/SSO, ma non spegnerli senza valutazione (dipendenze!).

Perché questa sequenza funziona: interrompe prima la diffusione attiva e poi protegge la catena di ripristino. Se i backup vengono compromessi, RTO/RPO (tempo di ripristino/perdita di dati accettabile) aumentano immediatamente in modo drastico.

3.3 Misure rapide di rete: „Bloccare“ invece di „Indovinare“

Se potete gestire centralmente firewall/ACL, blocchi mirati sono spesso preferibili a un blackout di rete completo. Le misure minime sono: blocco di SMB/WinRM/RDP tra reti client e zone server, limitazione delle reti admin, blocco delle connessioni in uscita verso destinazioni sconosciute (Egress Filtering), e soprattutto: separare rigorosamente le reti di backup.

Se nel vostro ambiente implementate microsegmentazione o principi Zero-Trust, queste regole sono predisposte in esercizio normale. Per l’incidente vi servirà allora solo una „Incident-Policy“, non un insieme di regole frenetico sotto pressione.

4) Triage e Scope: Come delimitare in modo affidabile i sistemi coinvolti

Dopo il primo contenimento sorge la domanda: Cos’è realmente interessato? Lo Scope è determinante per il ripristino: se ripristinate in modo „pulito“, ma un Service-Account compromesso RESTa attivo, l’attaccante tornerà nella rete.

4.1 Dati minimi che dovRESTe raccogliere immediatamente

• Cronologia: Quando sono state osservate le prime anomalie? (monitoring, ticket, segnalazioni degli utenti)
• Host coinvolti: elenco con hostname, IP, ruolo, criticità, sede/segmento
• Identità: account sospetti, modifiche ai gruppi privilegiati, nuove sessioni admin
• Stato dei backup: ultimo punto di ripristino noto valido, immutabilità, percorsi di accesso

Se centralizzate il logging (SIEM/Logserver), proteggete le fonti di log contro la manipolazione (Read-only, Snapshot). Senza una cronologia affidabile l’analisi della causa principale diventa speculazione.

4.2 Windows-Controlli rapidi (log eventi, sessioni, servizi sospetti)

Su server Windows sospetti potete verificare i primi indicatori con PowerShell. Importante: eseguite queste verifiche preferibilmente da un sistema amministrativo isolato o direttamente alla console, non tramite percorsi di gestione compromessi.

# Laufende Remote-Sessions (Hinweis auf aktive Steuerung) – lokal ausführen
quser

# Kürzlich installierte Services (häufig als Persistenz genutzt)
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 50 |
  Select-Object TimeCreated, Message

# Auffällige geplante Tasks (nur Überblick)
Get-ScheduledTask | Select-Object TaskName, State, Author | Sort-Object TaskName

# SMB-Sessions (bei Fileservern besonders relevant)
Get-SmbSession | Select-Object ClientComputerName, ClientUserName, NumOpens, ConnectedTime

Perché questo aiuta: il ransomware viene spesso propagato tramite esecuzione remota e installazione di servizi. ID 7045 (Service installiert) non è una prova, ma un forte segnale nella cronologia. Può fallire se i log sono già stati ripuliti o l’inoltro non è attivo.

4.3 Linux-Controlli rapidi (processi, cron, log di autenticazione)

In Linux-Umgebungen sind SSH, Cron/systemd Timer und manipulierte Binaries typische Hebel. Achten Sie auf neue Benutzer, unbekannte Keys und Prozesse mit ungewöhnlichen Parent/Paths.

# Ultimi accessi e tentativi falliti (a seconda della distro/config)
last -a | head -n 20
sudo grep -iE "failed|invalid|accepted" /var/log/auth.log 2>/dev/null | tail -n 50

# Processi in esecuzione e connessioni di rete
ps auxfww | head -n 40
ss -tulpen | head -n 40

# Panoramica di Cron e timer
sudo ls -la /etc/cron.* /var/spool/cron 2>/dev/null
systemctl list-timers --all | head -n 30

Insidia: i percorsi dei log possono differire (p.es. /var/log/secure). Inoltre gli host che eseguono container sono speciali: i processi possono sembrare “normali” perché girano in namespace. Le decisioni sullo scope non dovrebbero quindi basarsi su un singolo host.

5) Strategia di backup sotto attacco: ciò che conta davvero adesso

Il ripristino dopo un'infezione da ransomware non è un «pulsante di RESTore». Avete bisogno di una fonte di ripristino affidabile e di un ambiente dove poter testare senza reinfettare.

5.1 RTO/RPO in pratica: quali punti di ripristino sono effettivamente utilizzabili?

RPO (Recovery Point Objective) è la perdita massima di dati accettabile, RTO (Recovery Time Objective) è il tempo massimo di ripristino accettabile. In un incidente entrambi si allungano a causa di passaggi aggiuntivi: scansioni, validazione, ricostruzione delle identità, sequenziamento delle dipendenze (p.es. AD → DNS → DB → applicazione).

Pragmaticamente significa: dovete decidere quale punto di ripristino sia sicuro, non solo «vicino al presente». Se non conoscete il momento della compromissione, l'«ultimo backup» è rischioso.

5.2 Backup immutabili/air-gapped: perché «immutabile» non significa automaticamente «pulito»

Backup immutabili sono copie che non possono essere cancellate o sovrascritte per un periodo di retention (logica WORM). Questo protegge dalla cancellazione dei backup, ma non dal fatto che dati già compromessi o cifrati siano stati salvati. Per questo sono importanti i test di RESTore e le marcature „Known-Good“.

Air-gapped significa separazione fisica o logica, ossia non raggiungibile permanentemente dalla rete di produzione. Una condivisione di rete accessibile con credenziali di dominio non è un air gap.

5.3 Credenziali di backup: una delle cause più comuni di guasti totali

Molti sistemi di backup dipendono da account di dominio, usano condivisioni amministrative o possiedono token API ad elevati privilegi. Se queste credenziali vengono compromesse, l'attaccante può cifrare, cancellare o manipolare i punti di ripristino. La misura immediata è quindi spesso: isolare i server di backup e i repository in un segmento separato, ruotare le credenziali, ricreare gli accessi amministrativi.

6) Wiederherstellung (Recovery): saubere Reihenfolge, isolierte Tests, kontrolliertes Hochfahren

Recovery è un piano a fasi. L’obiettivo è costruire un Clean Room: un ambiente isolato (rete, identità, management) in cui verificare i ripristini e rimettere in esercizio i sistemi in modo „pulito“. Questo riduce significativamente il rischio di ricadute, richiede comunque tempo — ed è comunque solitamente più rapido rispetto a reinfezioni ripetute.

6.1 Principio di base: validare prima il ripristino in una zona isolata

Se possibile, ripristinate inizialmente i sistemi critici in un VLAN/rete isolata, senza routing verso la rete di produzione. Verificate:

• Avviabilità e stato dei servizi
• Integrità dei dati critici (controlli DB, self-test delle applicazioni)
• Assenza di servizi/task sconosciuti, assenza di connessioni outbound sospette
• Scan di signature/EDR (se disponibile) e revisione dei log

Perché funziona: disaccoppiate il „recupero dei dati“ dall'“andare nuovamente in produzione“. Può fallire se dipendenze (p. es. server di licenze, SSO, sorgente di tempo) mancano nella zona isolata. In tal caso dovrete ripristinare minimamente queste dipendenze o adattare i criteri di test.

6.2 Reihenfolge für Windows-Domänen (bewährte Praxis)

Una sequenza tipica che rispetta le dipendenze:

1. Base di management e amministrazione: workstation amministrative pulite/Jump Host, account separati, MFA dove possibile.
2. Identity/DNS/DHCP: Domain Controller (o ricostruzione), zone DNS, tempo (NTP). Il tempo è critico perché Kerberos (sistema di autenticazione basato su ticket) fallisce in caso di deriva temporale.
3. PKI/SSO (se presente): servizi di certificati, federation — solo se realmente necessari.
4. Basi dati: prima ripristinare/ri-provisionare i server DB, poi ripristinare i dati (eventualmente PITR, cioè Point-in-Time-Recovery, se predisposto).
5. Server applicativi: software di business e soluzioni vicine ai processi, solo dopo che la base dati è assicurata.
6. Servizi file: condivisioni per ultime, perché spesso contengono grandi volumi di dati e aree utente estese.

Trappola: se ripristinate semplicemente l’AD, potete reinserire stati compromessi preesistenti (p. es. ACL modificate, nuovi amministratori, GPO manomesse). A seconda della situazione, una ricostruzione con migrazione pulita (utenti, gruppi, servizi core) può essere l’opzione più solida. È una decisione di management, ma deve essere preparata tecnicamente.

6.3 Beispiel: Wiederherstellungs-Checkliste als kopierbares Runbook

La checklist seguente è volutamente generica, in modo che possiate integrarla nel vostro sistema di ticket/runbook.

RECOVERY-CHECKLISTE (versione breve)

[ ] 1. Clean-Management disponibile (dispositivo amministrativo separato/Jump Host, account separati)
[ ] 2. Segmento di rete per incidenti attivo (VLAN isolata, regole firewall RESTrittive)
[ ] 3. Repository di backup protetto (immutable/air-gapped verificato, accessi admin limitati)
[ ] 4. Punto di RESTore selezionato (giustificato, documentato, timeline considerata)
[ ] 5. Ripristino eseguito nella zona isolata
[ ] 6. Verifiche di integrità: servizi, log, traffico outbound, task/service pianificati
[ ] 7. Credenziali ruotate (Domain Admin, amministratori locali, service account, token API)
[ ] 8. Avvio graduale in produzione con monitoring
[ ] 9. Strategia di fallback pronta (punto di rollback, snapshot, freeze delle modifiche)
[ ] 10. Follow-up: hardening, lessons learned, regole di detection, pianificare test di RESTore

6.4 Datenbanken und transaktionale Systeme: Konsistenz schlägt Geschwindigkeit

Nelle basi di dati „copiare i file“ raramente è corretto. Utilizzare meccanismi nativi del DB (per es. RESTore da dump, snapshot con garanzie di consistenza o PITR). PITR (ripristino a un punto nel tempo) è il recupero a un istante precedente l’evento dannoso tramite i log delle transazioni (per es. WAL in PostgreSQL). Questo è particolarmente utile quando la compromissione può essere circoscritta nel tempo.

Trappola: la retention dei log spesso non è sufficiente, oppure gli archivi di log risiedono su storage compromesso. Inoltre le applicazioni dopo il RESTore possono trovarsi in stati incoerenti (elaborazione delle code, job duplicati). Pianificate quindi anche interventi lato applicazione (reindicizzazione, riconciliazione, rielaborazione).

7) Insidie tipiche nella pratica (e come evitarle)

7.1 “RESTore riuscito” – ma la malware è tornata con esso

Succede quando si ripristinano solo i dati, ma rimangono meccanismi di persistenza compromessi: attività pianificate, script di avvio, GPO manipolate, account di servizio compromessi o installer trojanizzati nelle condivisioni di deployment. Contromisure:

• Allineare i punti di ripristino con la timeline; in caso di dubbio tornare più indietro nel tempo.
• Nella zona isolata verificare: servizi/attività, account nuovi, connessioni outbound.
• Trattare separatamente le condivisioni di deployment e gli share amministrativi (non rimetterli online alla cieca).

7.2 Software di backup come “Super-Admin”: percorsi di accesso progettati male

Se i sistemi di backup operano con account Domain-Admin o con privilegi estesi, diventano un moltiplicatore per gli aggressori. Operativamente gli account di backup devono avere privilegi minimi, devono esistere livelli amministrativi separati e la gestione del backup non deve essere raggiungibile dalla rete client generale.

7.3 Ricollegare segmenti di rete troppo pRESTo

Il modello di reinfezione più comune: si ripristina „un server“ e lo si rimette immediatamente in rete di produzione per testare dipendenze. Se l’attaccante ha ancora accesso, l’host diventa subito di nuovo un bersaglio. Meglio: fornire le dipendenze in modo mirato nella zona isolata o testarle tramite regole temporanee e strettamente controllate.

7.4 Mancanza di consistenza temporale: NTP come ostacolo sottovalutato

Dopo il ripristino di controller di dominio, virtualizzazione o appliance l’orario spesso non è corretto. Kerberos, certificati e correlazione dei log sono sensibili a questo. Assicuratevi che le sorgenti NTP siano raggiungibili e che la gerarchia sia corretta. Non è un „nice-to-have“, ma accelera le indagini e previene guasti di autenticazione.

8) Strategia di fallback: cosa fare se il punto di RESTore era comunque compromesso?

Una buona procedura per gli incidenti contiene sempre un piano B. Fallback non significa „rifare tutto“, ma tornare in modo controllato a uno stato definito, senza peggiorare la situazione.

8.1 Definire punti tecnici di fallback

• Snapshot dei sistemi appena ripristinati nella zona isolata, prima di metterli in produzione.
• Backup delle configurazioni di firewall, bilanciatori di carico, VPN, storage, hypervisor.
• Lista di cambi documentata: cosa è stato modificato quando? chi ha approvato?

Perché funziona: se dopo la messa in produzione si osservano anomalie, potete tornare in modo mirato – invece di applicare patch freneticamente e rendere lo stato difficile da comprendere.

8.2 Regole decisionali per “tornare più indietro”

Trigger pratici per spostare il punto di RESTore più indietro:

• Ripetute connessioni outbound sospette o nuovi servizi/attività.
• Modifiche dei privilegi in AD inspiegabili dopo la riconnessione.
• Nuova crittografia/modifiche di massa, anche su scala ridotta.

In tal caso: richiudere il segmento, isolare nuovamente i sistemi interessati, eseguire una nuova triage, rivalutare il punto di ripristino, ruotare nuovamente le credenziali (poiché si deve presumere una nuova esfiltrazione).

9) Fase successiva (post-incidente): hardening, monitoraggio, test di ripristino come routine operativa

Dopo il riavvio segue la preparazione per il prossimo incidente. Senza un follow-up strutturato l’organizzazione RESTa vulnerabile – e il prossimo attacco sarà più veloce. Particolarmente efficaci sono le misure che migliorano in modo misurabile l’operatività e il ripristino:

• Automatizzare la validazione dei ripristini: test di ripristino regolari, non solo “backup riuscito”.
• Verificare l’architettura di backup: immutabile (air-gapped), livelli amministrativi separati, reti separate, registrazione.
• Rafforzamento delle identità: account amministrativi separati, amministrazione a livelli, MFA dove possibile, delega RESTrittiva.
• Segmentazione: ridurre il traffico est-ovest, in particolare SMB/WinRM/RDP/SSH.
• Rilevamento: regole di allarme per installazioni di servizi, modifiche massicce ai file, modifiche dei privilegi, accessi amministrativi insoliti.

Se desiderate approfondire temi come microsegmentazione, consistenza NTP o analisi del traffico più dettagliata, vale la pena inserire link interni alle relative guide operative (Firewall/Zero-Trust, NTP, Wireshark/analisi TCP) – proprio perché la gestione degli incidenti spesso fallisce per problemi di rete e di tempo apparentemente „banali“.

Conclusione: un buon Ransomware-Runbook protegge da un secondo attacco

La risposta più efficace a un’infezione da ransomware è la combinazione tra isolamento rapido e mirato e un ripristino che tratti sullo stesso piano identità, canali di gestione e fiducia nei backup. Chi si limita a “copiare i dati indietro” rischia la reinfezione. Chi invece valida in una zona isolata, sceglie consapevolmente i punti di ripristino, ruota sistematicamente le credenziali e sequenzia correttamente le dipendenze, riporta i sistemi in esercizio in modo controllato – riducendo in modo significativo il rischio di ricaduta.

Nella pratica quotidiana ripaga ciò che raramente è glamour: backup testati, confini di rete chiari, livelli amministrativi netti e un runbook compreso dal team. Proprio questa disciplina operativa decide, in caso di emergenza, tra ore e giorni.

Anche il rilevamento della ransomware e l’isolamento dei sistemi sono importanti per questo tema. L’articolo contestualizza chiaramente questi aspetti e mostra cosa conta nella pratica quotidiana.