forumApri un argomento

Abbiamo subito un attacco ransomware — vi racconto il processo e le lezioni imparate

OOrhan17 giorni fa·37 messaggi·81,2K visualizzazioni#gestione incidenti#backup#lezione
OOrhanPartecipante
Ruolo
Azienda IT
Iscrizione
ott 2023
Messaggio
132

Doki · Scansione vulnerabilità · 2026

#1

È successo un incidente presso un nostro cliente, scrivo con la sua autorizzazione e senza fare nomi. Non voglio spaventare nessuno, l'obiettivo è mostrare come funziona il processo.

L'incidente è stato notato un venerdì sera. Le estensioni dei file sul server erano cambiate e in ogni cartella era stato lasciato un file di testo.

La prima cosa che abbiamo fatto è stata quella giusta: non abbiamo spento i sistemi, li abbiamo isolati dalla rete. Spegnere cancella le prove nella memoria, isolare dalla rete ferma la diffusione.

Poi abbiamo risposto in ordine a tre domande: da dove sono entrati, quanto si è diffuso, il nostro backup è pulito.

La risposta alla prima domanda non è stata quella che ci aspettavamo. Non c'erano vulnerabilità. C'era una connessione desktop remoto esposta all'esterno e la password di un utente era stata compromessa altrove. Quindi non un bug tecnico, ma una porta lasciata aperta.

La questione del backup ci ha salvati, ma per un pelo. Venivano fatti backup giornalieri, però il server di backup era sulla stessa rete e accessibile con le stesse credenziali. Il fatto che non fosse criptato dipende solo dal fatto che quella notte l'operazione è stata interrotta prima di finire.

DDefnePartecipante
Ruolo
Analista SOC
Tipo di organizzazione
azienda all'interno di un gruppo
Iscrizione
feb 2024
Messaggio
146
Più utile#2

Grazie per questo post, le testimonianze dirette di incidenti sono rare e sono quelle che insegnano di più.

La vostra decisione di intervento iniziale è stata corretta. Vi spiego: su un sistema attivo, nella memoria possono esserci processi in esecuzione, connessioni di rete e a volte la chiave di crittografia stessa. Se spegni, perdi tutto. Isolare dalla rete ferma la propagazione e preserva le prove.

Anche l'ingresso tramite desktop remoto con password compromessa non è un'eccezione, anzi è uno degli scenari più comuni. Quindi vale la pena ripetere questi tre punti: non lasciate desktop remoto esposto all'esterno, se dovete farlo mettete assolutamente la 2FA, non usate gli account admin per il lavoro quotidiano.

La parte del backup è la vera lezione. Gran parte dei ransomware ormai cerca i backup come prima cosa. Avere il backup sulla stessa rete e accessibile con la stessa identità rende il backup parte del bersaglio.

Regola pratica: tenete almeno una copia del backup separata, in modo che non sia accessibile né modificabile con le credenziali del sistema principale. Inoltre testate regolarmente il ripristino del backup, non basta vedere che viene fatto.

İİsmailPartecipante
Ruolo
System administrator
Iscrizione
dic 2023
Messaggio
128
#3

Abbiamo subito lo stesso incidente due anni fa. Con una differenza: il nostro backup non era pulito.

La produzione si è fermata per tre giorni. Ora la copia del backup è separata e immutabile. È stata una lezione costosa.

YYavuzEsperto
Ruolo
Direttore sicurezza informatica
Iscrizione
lug 2023
Messaggio
168
#4

Vorrei aggiungere alcuni punti sull'aspetto gestionale della risposta all'incidente, perché questo lato determina il processo tanto quanto l'intervento tecnico.

Primo, deve essere deciso in anticipo chi prende le decisioni. Se al momento dell'incidente non è chiaro a chi chiedere "spegniamo il sistema?", si perdono ore.

Secondo, il piano di comunicazione. Cosa dire ai dipendenti, quando informare i clienti, come adempiere agli obblighi di notifica legale se necessario, tutto questo deve essere scritto in anticipo. Se sono stati coinvolti dati personali, fate riferimento alla normativa e al vostro ufficio legale per i tempi e le modalità di notifica; i tempi sono brevi.

Terzo, la decisione di pagare il riscatto. Vorrei sottolineare che questa non è una decisione tecnica, ma di alta direzione e legale. Pagare non garantisce il recupero dei dati e può comportare rischi legali separati.

Quarto, il report post-incidente. Dopo i giorni caldi tutti tornano alla normalità e le lezioni non vengono scritte. Un report sull'incidente che non viene scritto entro una settimana, non viene mai scritto.

OOnurEsperto
Ruolo
Sviluppatore sicurezza
Iscrizione
ott 2023
Messaggio
196
#5

Vorrei approfondire un punto: dite che "non c'erano vulnerabilità". Come lo avete verificato?

La mia domanda non nasce da cattive intenzioni. Nella maggior parte dei casi, il primo vettore d'accesso trovato viene considerato quello corretto e lì finisce l'indagine. Invece gli attaccanti di solito lasciano più di un metodo di persistenza.

Domanda concreta: dopo la sessione dell'utente entrato con la password compromessa, sono stati creati altri account nel sistema, aggiunti task pianificati o installati strumenti di accesso remoto — avete controllato tutto questo? Non sono pochi i casi in cui si è ri-entrati in un sistema ritenuto pulito dopo tre settimane.

OOrhanPartecipante
Ruolo
Azienda IT
Iscrizione
ott 2023
Messaggio
132

Doki · Scansione vulnerabilità · 2026

#6

Domanda legittima, rispondo.

Controllato. Un team indipendente ha analizzato tutto per due settimane. Sono stati trovati due task pianificati e un account amministratore locale creato successivamente. Entrambi erano sfuggiti alla prima pulizia.

Per questo vorrei aggiungere una cosa: la decisione sulla pulizia non dovrebbe essere presa dal team che ha vissuto l'incidente. Il team, stanco e nel bel mezzo dell'evento, tende a confermare le proprie scoperte. Se possibile, fate intervenire un occhio esterno.

Alla fine abbiamo reinstallato da zero le macchine colpite. Era la strada più lenta ma più sicura.

KKaan B***Partecipante
Ruolo
Ingegnere infrastrutturale
Iscrizione
mar 2024
Messaggio
108
#7

Dal punto di vista infrastrutturale, vi suggerisco una struttura concreta per i backup, perché "restare separati" resta un po' vago.

La configurazione comune ed efficace è questa: almeno tre copie dei dati, mantenute in almeno due ambienti diversi e almeno una copia conservata completamente altrove. Inoltre, che quella copia separata sia immutabile dopo la scrittura è determinante nello scenario ransomware.

Misurate anche il tempo di ripristino. La frase "abbiamo un backup" non vale quanto "ripartiamo in otto ore". Se non sapete quest'ultima, provate un sabato.

ZZeynep K***PartecipanteMembro della community
Iscrizione
feb 2024
Messaggio
41
#8

Sono una piccola impresa, vi parlo dal mio punto di vista. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Un report di scansione automatica e un penetration test non sono la stessa cosa. Confermato dall'esperienza.

EEmre G***EspertoMembro della community
Iscrizione
lug 2024
Messaggio
409
#9

Grazie per averlo scritto, è proprio così. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Correggetemi se sbaglio.

DDoruk Y***VeteranMembro della community
Iscrizione
dic 2023
Messaggio
69
#10

Ha ragione. Se permessi e ambito non sono scritti, quel test non deve iniziare.

Naturalmente cambia se la vostra situazione è diversa.

MMeryem Ö***Partecipante
Ruolo
Responsabile export
Settore
Servizi di pulizia
Tipo di organizzazione
Azienda di produzione da 40 persone
Iscrizione
feb 2024
Messaggio
13
#11

Come avete risolto questo? Un backup non testato non è un backup.

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

YYusuf Y***Partecipante
Ruolo
Responsabile social media
Settore
Immobiliare
Tipo di organizzazione
azienda all'interno di un gruppo
Iscrizione
set 2024
Messaggio
79
#12

Questo thread è archiviato.

PPerihan K***Partecipante
Ruolo
Product manager
Settore
Catering
Tipo di organizzazione
Azienda di 20 persone
Iscrizione
feb 2024
Messaggio
220

Doki · Sito web aziendale · 2024

#13

Corretto.

BBurcu N***Partecipante
Ruolo
Membro del consiglio di amministrazione
Settore
Cosmetica
Tipo di organizzazione
Azienda di 20 persone
Iscrizione
nov 2025
Messaggio
2
#14

Mi farebbe piacere se scrivesse il risultato.

ÖÖzge Y***PartecipanteMembro della community
Iscrizione
feb 2023
Messaggio
110
#15

Dopo aver vissuto questa cosa il mio punto di vista è cambiato. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

È tutto scusate se mi sono dilungato.

KKORİTeam Doki
Ruolo
Moderatore del forum
Settore
Sicurezza informatica e digitale
Tipo di organizzazione
Doki
Iscrizione
gen 2023
Messaggio
2840
Sentinella#16

Piccolo avvertimento: il metodo condiviso sopra va testato sul proprio sistema, non su quello altrui. Testare senza permesso smette di essere una questione tecnica.

CCanPartecipante
Ruolo
SEO Specialist
Iscrizione
mar 2024
Messaggio
172
#17

Sono passato da qui, vi racconto. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Se avete domande, scrivete, rispondo per quanto possibile.

MMehmet M***Partecipante
Ruolo
Esperto di marketing digitale
Settore
Formazione
Tipo di organizzazione
distributore di zona
Iscrizione
nov 2025
Messaggio
302
#18

Mi sono rilassato leggendo questa risposta, quindi non succede solo a me. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Correggetemi se sbaglio.

SSedaNuovo membro
Ruolo
Insegnante · secondo lavoro
Tipo di organizzazione
cooperativa
Iscrizione
ott 2024
Messaggio
42
#19

sono una piccola impresa, vi parlo dal mio punto di vista. comunque i pimi tre mesi vanno bene, i problemi emergono al quarto mese.

la risposta varia molto in base al settore non eiste una regola generale.

FFatma U***Partecipante
Ruolo
Capocantiere
Settore
Sport e fitness
Tipo di organizzazione
attività con due sedi
Iscrizione
gen 2025
Messaggio
96
#20

Lascio un avvertimento. Se permessi e ambito non sono scritti, quel test non deve iniziare.

Non fidatevi di una sola misura di sicurezza; procedete per livelli. Se avete domande, scrivete, rispondo per quanto possibile.

Rispondi