Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
L'articolo analizza la difficile scelta tra spegnere o mantenere accesa una workstation durante un intervento di acquisizione forense. Vengono esaminati i rischi di perdita di dati volatili, l'impatto della cifratura BitLocker, le conseguenze di isolare la rete e le implicazioni di una live acquisition. Si evidenziano le linee guida SWGDE, l'importanza di valutare il contesto e di documentare ogni decisione, fornendo consigli pratici per bilanciare la preservazione delle prove con la sicurezza dell'indagine.
Davanti a un computer acceso potremmo avere ancora accesso a un volume cifrato, a una sessione autenticata o a dati presenti soltanto in memoria. Spegnere, scollegare la rete o avviare un’acquisizione cambia quella situazione. Anche aspettare ha un costo, perché nel frattempo la macchina continua a lavorare.
La prima valutazione riguarda quindi lo stato del sistema e ciò che rischiamo di perdere intervenendo. Il tool viene dopo. Nel decidere contano anche le nostre aspettative: un alert, un’ipotesi investigativa o una procedura che conosciamo bene possono assorbire l’attenzione e farci trascurare qualcosa di meno evidente.
Immaginiamo di arrivare davanti a una workstation Windows accesa. L’utente è autenticato, alcune applicazioni sono aperte e c’è una share di rete montata. BitLocker è attivo, ma il volume è accessibile. Non abbiamo ancora verificato se sia disponibile una recovery key utilizzabile in seguito, indipendentemente dall’accesso attuale.
È una situazione nella quale vengono in mente diverse cose da fare, tutte ragionevoli almeno in apparenza. Isolare la macchina, acquisire la RAM, raccogliere subito i dati leggibili. Oppure spegnere, per fermare le modifiche. Qualcuno potrebbe anche proporre di lasciarla così per qualche minuto, giusto il tempo di capire meglio.
La prima cosa che vorrei sapere è quali di queste possibilità saranno ancora disponibili dopo il prossimo intervento. Se tolgo alimentazione, perdo il contenuto della memoria volatile e interrompo le sessioni. Se mantengo il sistema acceso, conservo almeno per il momento quelle condizioni, ma accetto anche che continuino processi, scritture e comunicazioni. Scollegando la rete posso ridurre l’esposizione a un intervento remoto e, insieme, perdere l’accesso alla share.
Nel frattempo il computer non aspetta la nostra decisione. Anche mentre osserviamo, un’applicazione può aggiornare un file o una sessione può scadere.
Le best practice SWGDE sulle acquisizioni da computer chiedono di valutare gli effetti e i limiti del metodo scelto rispetto alle esigenze dell’indagine. È un’indicazione che trovo molto concreta: il modo di acquisire va deciso sulla base del sistema che abbiamo davanti. [1]
L’Order of Volatility aiuta a stabilire le priorità. Un’informazione che può scomparire a breve merita attenzione prima di una che prevediamo di ritrovare anche in laboratorio. Fin qui il ragionamento è abbastanza intuitivo. Il problema nasce quando dall’ordine di volatilità ricaviamo una sequenza da applicare senza più guardare il contesto.
SWGDE chiarisce che l’ordine di raccolta può cambiare in base al sistema e alla situazione. La RAM è un buon esempio: su alcuni sistemi raccoglierla può introdurre instabilità. Anche quella scelta, dunque, richiede una valutazione. [1]
Torniamo alla workstation con BitLocker. La memoria è volatile, ma è temporanea anche la condizione nella quale riusciamo a leggere il volume. Spegnendo senza aver verificato un’altra possibilità di sblocco, potremmo ottenere più tardi un’immagine integra dei dati cifrati e non essere in grado di accedere al loro contenuto.
Non sto dicendo che, dopo ogni spegnimento, un volume BitLocker diventi irrecuperabile. Il punto è che al momento non lo sappiamo. Finché manca quella verifica, la possibilità di perdere l’accesso deve pesare nella decisione.
In presenza di cifratura, le indicazioni SWGDE considerano sia la cattura della memoria per tentare di recuperare le chiavi, sia l’acquisizione live dei dati disponibili in chiaro. Richiamano inoltre container montati, storage di rete e database che potrebbero non essere più accessibili dopo lo spegnimento. Nessuna di queste opzioni va confusa con una garanzia di successo. [1]
Per questo affiancherei alla domanda sul dato più volatile un’altra domanda: quale perdita avrei più difficoltà a recuperare? Nel nostro esempio, può essere proprio la possibilità di leggere ciò che stiamo cercando di preservare.
Ci sono situazioni nelle quali fermare subito il sistema è necessario. Se vediamo un’attività distruttiva in corso, lasciarla proseguire mentre completiamo ogni verifica può costarci più di quanto riusciremmo a preservare mantenendo la macchina accesa. Le best practice sulla raccolta dell’evidenza digitale richiamano espressamente questa eventualità. [2]
Il costo dello spegnimento resta, però, anche quando la scelta è giustificata. Possiamo perdere dati non salvati, processi, connessioni, materiale crittografico e accessi che dipendono dalla sessione corrente. Vorrei che queste perdite fossero considerate prima, quando possono ancora influire sulla decisione, e poi riportate nella documentazione.
Un rischio di intervento remoto richiede a sua volta di valutare il contenimento. L’isolamento può essere la scelta appropriata, ma una share montata merita almeno di essere riconosciuta per ciò che è: una possibile fonte di dati, oltre che una connessione. Se il tempo e il rischio lo consentono, prima di interromperla cercherei di capire a quale risorsa conduce e se l’accesso potrà essere ristabilito.
Questo non autorizza ad aspettare indefinitamente. Mantenere la rete significa accettare un’esposizione che va valutata per il tempo strettamente necessario. Un pericolo concreto può imporre di isolarla subito, anche sacrificando una risorsa ancora accessibile.
È qui che distinguerei la reversibilità tecnica da quella probatoria. Ricollegare un cavo è semplice. Ritrovare la stessa sessione, con gli stessi permessi e lo stesso stato, potrebbe essere impossibile. Allo stesso modo, riaccendere il computer non restituisce la memoria che conteneva prima dello spegnimento.
Potremmo pensare di risolvere il problema acquisendo tutto a sistema acceso. Ma anche l’acquisizione live modifica ciò che stiamo osservando. Il software occupa memoria, esegue processi e, secondo il metodo usato, può produrre log, accedere a file o utilizzare la rete. Alcuni timestamp possono cambiare. Il sistema, inoltre, continua a svolgere le proprie attività durante la raccolta.
SWGDE ricorda che una live collection può alterare o creare evidenza e che questi effetti devono essere documentati. [2] Parlare di intervento “senza footprint” rischia quindi di farci partire da un’aspettativa sbagliata.
Preferisco chiedermi quali modifiche il metodo possa introdurre e se siano accettabili rispetto alla perdita che sto cercando di evitare. Per rispondere devo conoscere lo strumento e i suoi limiti. Se non riesco a valutare l’impatto sul sistema, quella lacuna può essere un motivo per fermarmi e coinvolgere una persona con competenze specifiche.
La documentazione serve anche a rendere comprensibile questo passaggio. Nelle best practice troviamo lo stato del dispositivo, i file aperti, gli strumenti impiegati, i log e gli screenshot, oltre ai dettagli dei dati raccolti e ai relativi hash. [2] A queste informazioni affiancherei sempre il motivo della scelta.
“RAM acquisita alle 10:42” registra un’operazione. Nel nostro esempio, se abbiamo valutato appropriato raccogliere prima la memoria, potremmo annotare anche: “Sistema acceso, sessione sbloccata, volume BitLocker accessibile, recovery key non ancora verificata. Mantenuta l’alimentazione e acquisita la RAM per preservare i dati volatili e tentare il recupero di materiale crittografico”.
Una nota del genere non sostituisce il resoconto tecnico e non dimostra, da sola, che la decisione fosse corretta. Permette però a chi rileggerà il fascicolo di capire su quali elementi abbiamo ragionato. Mesi dopo, quei dettagli saranno molto meno scontati di quanto sembrino davanti allo schermo.
Una macchina accesa offre molti più stimoli di quanti possiamo seguire contemporaneamente. Ci sono finestre, processi, connessioni, notifiche e servizi in esecuzione. Un alert dell’EDR si fa notare. Una sessione autenticata che sta per scadere, invece, potrebbe non mostrare nulla di particolare.
La visibilità di un elemento finisce facilmente per influenzare il peso che gli attribuiamo. Dedichiamo tempo a ciò che richiama l’attenzione e rischiamo di non vedere una dipendenza meno appariscente, come la cifratura o l’accesso a uno storage remoto.
Anche il risultato di un tool può avere questo effetto. Se ci presenta cento artefatti ben ordinati, siamo portati a lavorare su quelli. È comprensibile: sono già lì, pronti da esaminare. Restano però gli artefatti che quello strumento ha individuato, con quel metodo e in quelle condizioni. Non costituiscono necessariamente tutto ciò che aveva valore preservare.
Per tenere separate le cose, partirei da ciò che posso descrivere come osservazione. “La share è montata” è un fatto rilevato. “Contiene materiale utile all’indagine” è ancora un’ipotesi, finché non abbiamo elementi per sostenerla. La decisione su come trattarla deve considerare questa incertezza.
Se sospetto un ransomware, è facile che inizi a leggere processi e connessioni alla luce di quel sospetto. Se il caso riguarda un’applicazione specifica, guarderò probabilmente prima quella. E se conosco bene una procedura, avrò più facilità a scegliere un percorso che prevede di usarla.
Avere un’ipotesi aiuta a orientarsi. Diventa un problema quando smetto di riconoscerla come ipotesi e lascio che determini da sola l’intervento. Nella first response le conseguenze possono arrivare prima dell’analisi: una convinzione prematura può spingermi a modificare lo stato e a perdere dati che non avevo ancora considerato.
La rete offre di nuovo un esempio. Se la considero esclusivamente una minaccia, l’isolamento mi sembrerà la risposta ovvia. Se mi concentro soltanto sulla risorsa remota che rende accessibile, potrei sottovalutare il pericolo di lasciarla collegata. In entrambi i casi sto guardando una parte del problema.
Un controllo che trovo utile è formulare almeno un’alternativa concreta. Prima di isolare, provo a esplicitare cosa perderò e quale rischio ridurrò. Se decido di aspettare, devo saper dire che cosa intendo preservare in quel tempo e quale esposizione sto accettando.
Non sempre avremo risposte complete. Le domande, però, possono essere brevi:
Quest’ultima domanda mi interessa particolarmente, perché costringe a guardare oltre l’esito immediato. Un’acquisizione può andare a buon fine e lasciare comunque irrisolta una perdita provocata da una decisione precedente.
Con cloud e SaaS cambiano anche i tempi sui quali ragionare. Un log può essere eliminato alla scadenza della retention, un collegamento per scaricare un export può durare pochi giorni, un token può scadere o una sessione essere revocata. A seconda del servizio, la conservazione disponibile può dipendere dalla configurazione e dal piano sottoscritto.
Sono situazioni differenti. In un caso rischiamo di perdere il dato; in un altro il dato potrebbe restare presso il provider, mentre noi perdiamo il modo di raggiungerlo. Trattarle tutte come semplice “volatilità” dell’endpoint può nascondere proprio la differenza che serve per decidere.
Spesso, poi, l’azione necessaria deve essere eseguita da qualcun altro. Possiamo aver individuato con precisione il log da preservare, ma dover coinvolgere l’amministratore del tenant, il team IT o il provider. Sapere chi può intervenire e con quali tempi diventa parte della valutazione, così come verificare che l’attività rientri nell’autorità e nell’ambito dell’incarico.
Le best practice SWGDE dedicano una sezione alle produzioni di terze parti. Ricordano che i dati possono arrivare con formati e caratteristiche differenti, essere raccolti da personale non forense e venire consegnati attraverso link temporanei, non necessariamente riproducibili in seguito. [2] La disponibilità dell’export, dunque, non chiude da sola il problema della preservazione.
Davanti a una risorsa remota cercherei perciò di chiarire anche chi ne controlla la conservazione. La sessione aperta sulla workstation può essere una possibilità di accesso; la conservazione dei dati presso il servizio richiede una valutazione ulteriore.
Macchine virtuali, cifratura, autenticazione a più fattori e sincronizzazioni ricorrono in molti ambienti di lavoro. Le dipendenze fra questi elementi rendono difficile stabilire in anticipo una sequenza valida per qualunque intervento.
Le procedure restano necessarie. Offrono una base comune, aiutano a evitare omissioni e consentono di confrontare il lavoro svolto. Per chi sta imparando, avere un percorso chiaro è anche un modo per gestire l’incertezza. Bisogna però imparare a riconoscere le condizioni che richiedono di adattarlo o di chiedere supporto.
Sulla workstation del nostro esempio, verificare la disponibilità di una recovery key può cambiare la valutazione. Scoprire che la share contiene l’unica copia accessibile di un dato può cambiarla ancora. Lo stesso vale se compaiono segnali di cancellazione in corso: il tempo disponibile per decidere si riduce.
È su questi elementi che vorrei motivare la scelta del metodo. Prima di avviare l’acquisizione, rimane la domanda dalla quale siamo partiti: se intervengo adesso, cosa potrei non riuscire più a recuperare?
[1] SWGDE, Best Practices for Computer Forensic Acquisitions, 17-F-002-2.1, versione 2.1 del 5 agosto 2025.In particolare, sezioni 4, 4.2, 7.3.1-7.3.3 e 9.
[2] SWGDE, Best Practices for Digital Evidence Collection, 18-F-002-2.0, versione 2.0 del 20 novembre 2025. In particolare, sezioni 5, 9, 11, 12 e 14.
È uscito il sesto episodio di Betti-RHC, la serie a fumetti di Red Hot Cyber nata con l'obiettivo di trasformare la cybersecurity awareness in un'esperienza di formazione più semplice, coinvolgente e accessibile. Quello che è nato come un progetto editoriale innovativo è diventato negli anni un vero e proprio corso di cybersecurity awareness a fumetti, adottato da aziende e professionisti per sensibilizzare le persone sui rischi informatici attraverso storie, personaggi ed emozioni. In cinque anni di attività, la serie Betti-RHC ha raggiunto un risultato importante: circa 70.000 copie vendute, a testimonianza dell'interesse crescente delle organizzazioni verso nuovi strumenti per costruire una concreta cultura della sicurezza.
Il sesto episodio porta Betti dentro le nostre case, in un mondo "connesso", dove lampadine, telecamere, assistenti vocali, serrature, sensori ed elettrodomestici intelligenti promettono comfort e sicurezza, ma possono nascondere nuove e insidiose superfici di attacco. Attraverso una nuova avventura, Betti ci accompagna alla scoperta del mondo della domotica e dei dispositivi IoT, mostrando come la poca cautela nell'utilizzo di queste tecnologie possa trasformare oggetti quotidiani in porte d'accesso per chi vuole osservare, controllare o colpire.
Per accompagnare la crescita del progetto abbiamo realizzato il sito ufficiale di Betti-RHC, dove è possibile conoscere meglio la serie, gli episodi e il progetto di cybersecurity awareness sviluppato da Red Hot Cyber. L'obiettivo è continuare a portare la cultura della sicurezza fuori dai tradizionali percorsi formativi standard, utilizzando il linguaggio immediato del fumetto per parlare a dipendenti, professionisti e persone senza competenze tecniche. Per maggiori informazioni su Betti-RHC e sul sesto episodio “Open Mic” è possibile visitare il sito ufficiale: betti.redhotcyber.com.