Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
L'articolo analizza le scelte da compiere quando si trova un computer acceso durante un'indagine forense. Prima di spegnere, isolare o acquisire la RAM, è fondamentale osservare lo stato del sistema: volumi cifrati, sessioni autenticate, connessioni di rete e processi in esecuzione. Ogni azione può alterare le evidenze disponibili. Vengono illustrate le implicazioni della cifratura, della rete e della volatilità della memoria, con riferimento alle linee guida SWGDE e ISO/IEC 27037, per giustificare decisioni basate sul rischio di perdita di dati.
Troviamo un computer acceso durante un’attività di digital forensics. La tentazione è decidere subito cosa fare: acquisire la RAM, scollegare la rete, iniziare una live acquisition oppure spegnere.
Ma prima c’è un problema più semplice e, spesso, più importante: capire in quale stato si trova realmente quel sistema.
Un volume cifrato può essere già accessibile. Una sessione autenticata può essere ancora valida. Una risorsa remota può essere montata. Alcune informazioni possono esistere soltanto in memoria.
Ogni azione modifica almeno in parte questo equilibrio. Per questo la scelta dovrebbe partire da ciò che osserviamo e da ciò che rischiamo di perdere, non da una sequenza prestabilita di operazioni.
Immaginiamo di entrare in una stanza e trovare una workstation accesa. Il monitor è attivo. C’è una sessione utente aperta, alcune applicazioni sono visibili e il computer è collegato alla rete. Sul desktop compare anche una finestra che sembra mostrare file presenti su una cartella condivisa.
A prima vista la situazione sembra semplice. Il computer è acceso, quindi potremmo acquisire la RAM. Oppure scollegare immediatamente il cavo di rete per evitare modifiche dall’esterno. Oppure spegnerlo e procedere successivamente con un’acquisizione tradizionale del disco.
Tutte e tre le scelte possono avere senso. Il problema è che non sappiamo ancora abbastanza per decidere quale abbia senso in quel caso. Non sappiamo se il disco sia cifrato. Non sappiamo se la cartella che vediamo risieda sul computer oppure su un server remoto. Non sappiamo se siano presenti volumi cifrati già montati, sessioni autenticate, processi che ci interessano o dati non ancora scritti sul disco. Sappiamo soltanto che il sistema è acceso.
Ed è molto meno di quanto ci serva.
Un sistema in esecuzione non è semplicemente la versione accesa dello stesso sistema che potremo esaminare domani. Alcune condizioni esistono solo mentre sta funzionando. Pensiamo a un volume protetto da cifratura completa del disco. In quel momento il sistema operativo sta lavorando normalmente e i file sono accessibili. Dopo lo spegnimento potremmo trovarci davanti a un volume cifrato senza disporre subito delle credenziali o della recovery key necessaria.
Può accadere qualcosa di simile con un container cifrato già aperto. Oppure con una sessione autenticata verso un servizio remoto. O con una VPN attiva. O ancora con un’applicazione nella quale l’utente ha già effettuato l’accesso. SWGDE richiama espressamente questi problemi nelle proprie best practice. Prima dell’acquisizione invita a considerare dati volatili, chiavi di cifratura e altre informazioni necessarie ad accedere ai dati; per i sistemi cifrati contempla sia l’acquisizione della memoria sia la possibilità di acquisire logicamente i dati mentre risultano decifrati.
Questo non ci dice ancora cosa fare. Ci dice però qualcosa di importante: spegnere può cambiare non soltanto lo stato del computer, ma anche quello che saremo materialmente in grado di acquisire dopo.
Torniamo alla workstation. Prima di avviare un programma o digitare un comando possiamo documentare ciò che abbiamo davanti. Lo schermo, le applicazioni visibili, eventuali finestre aperte, i dispositivi collegati, supporti esterni, cavi, monitor aggiuntivi, periferiche e più in generale la configurazione della postazione possono già fornire informazioni utili. C’è però una cautela che vale la pena mantenere.
Quello che osserviamo non coincide necessariamente con quello che possiamo concludere. Una finestra con una cartella aperta non dimostra da sola dove siano fisicamente conservati quei file. Un’applicazione aperta non ci dice automaticamente se la sessione sia ancora autenticata. La presenza di un software di cifratura non dimostra che esista un volume cifrato attualmente montato. Sono indizi sullo stato del sistema.
Per andare oltre dovremo probabilmente interagire con la macchina. Ed è proprio lì che cambia la natura dell’attività. Se eseguiamo un comando per vedere le connessioni di rete, lanciamo un tool per acquisire la memoria o interroghiamo il sistema per conoscere i volumi montati, non stiamo più soltanto osservando. Stiamo modificando, almeno in parte, l’ambiente che vogliamo esaminare.
Questo non rende l’attività sbagliata. In una live acquisition è inevitabile che accada qualcosa del genere. La questione è capire se ciò che possiamo ottenere giustifica quel cambiamento.
La cifratura è probabilmente uno degli esempi più chiari. Supponiamo di verificare che il sistema utilizzi full-disk encryption e che, in quel momento, il volume sia accessibile. Abbiamo una condizione favorevole. Potremmo avere anche una recovery key disponibile altrove e quindi essere ragionevolmente certi di poter riaprire il volume successivamente. In un ambiente aziendale, per esempio, potrebbe essere conservata attraverso un sistema di gestione centralizzato.
Ma potremmo anche non averla. SWGDE osserva proprio che le chiavi di recupero possono trovarsi su supporti locali, servizi cloud o sistemi enterprise e che, in altri casi, può essere necessario valutare l’acquisizione della memoria oppure una live acquisition del contenuto decifrato. La differenza è sostanziale.
Nel primo scenario lo spegnimento potrebbe chiudere temporaneamente una possibilità che sappiamo di poter recuperare. Nel secondo potrebbe chiuderne una senza sapere se riusciremo a riaprirla. Lo stesso ragionamento vale per un container cifrato montato. SWGDE include espressamente i mounted encryption containers tra i dati che possono essere acquisiti da un sistema live e che potrebbero non essere accessibili dopo lo shutdown.
Per questo “è cifrato” non basta come informazione. Ci interessa sapere in quale stato si trova quella cifratura e quali alternative avremo dopo.
Guardiamo di nuovo il cavo Ethernet collegato alla workstation. Lasciare una macchina connessa può essere rischioso. Un soggetto remoto potrebbe modificarla, un processo potrebbe continuare a comunicare, una sincronizzazione potrebbe cambiare file che ci interessano.
In presenza di un’attività distruttiva evidente, la priorità può cambiare molto rapidamente. Le best practice SWGDE sulla raccolta delle evidenze invitano a verificare anche la presenza di attività distruttive e, quando appropriato, a isolare il sistema dalla connettività di rete.
Ma immaginiamo un caso diverso. La cartella visibile sul desktop non si trova sul disco locale. È una share di rete. Oppure il computer è collegato tramite VPN a un sistema aziendale e quella sessione consente di raggiungere risorse che altrimenti non avremmo davanti. Staccare il cavo elimina un rischio, ma cambia anche quello che possiamo osservare.
SWGDE include infatti network storage e database tra i dati che una live file-system acquisition può consentire di raggiungere mentre il sistema è operativo. Non significa che quelle risorse possano automaticamente essere acquisite. La possibilità tecnica e l’autorità per farlo sono due problemi diversi.
Significa però che, prima di interrompere una connessione, dovremmo almeno avere un’idea di cosa stiamo interrompendo. Altrimenti potremmo scoprire soltanto dopo che parte di ciò che avevamo davanti non era affatto dentro quel computer.
Davanti a un sistema acceso l’acquisizione della memoria è spesso una delle prime possibilità che vengono considerate. Il motivo è evidente. Nella RAM possiamo trovare informazioni sui processi in esecuzione, sulle connessioni, sulle applicazioni e sullo stato corrente del sistema. In determinate condizioni può contenere anche materiale utile rispetto alla cifratura.
Sono dati che lo spegnimento farebbe scomparire. Ma da questo non deriva necessariamente che “RAM prima di tutto” sia una regola valida in ogni situazione. Le attuali best practice SWGDE affrontano il tema in modo più prudente. L’ordine di volatilità deve tenere conto sia di quanto rapidamente l’informazione può cambiare sia dell’effetto che la raccolta produce sul computer. L’ordine può quindi cambiare in funzione del sistema; lo stesso documento osserva che, su alcune macchine, l’acquisizione della RAM può provocare instabilità e può essere opportuno effettuarla più tardi.
C’è poi un altro limite. Mentre acquisiamo la memoria, il computer continua a funzionare. Processi vengono eseguiti, aree di memoria cambiano, altre vengono allocate o liberate. L’immagine che otteniamo non è necessariamente la fotografia perfettamente simultanea di un singolo istante.
È il problema dello smear, richiamato anche da SWGDE: durante il tempo necessario all’acquisizione il sistema continua a modificare la memoria e questo può creare incoerenze nei dati raccolti. Non è una ragione per rinunciare all’acquisizione. È una ragione per non descriverla come un’operazione priva di conseguenze.
Questo vale più in generale per tutta la live acquisition. Eseguire un tool significa avviare nuovo codice sul sistema. Verranno utilizzate CPU e memoria. Alcuni timestamp possono cambiare. Possono essere creati artefatti. Un processo già attivo potrebbe reagire. In alcuni casi il sistema potrebbe diventare instabile.
SWGDE lo indica chiaramente: l’accesso live può modificare date e orari di sistema o dei file, i processi possono entrare in conflitto e l’acquisizione può essere soggetta a smear. La stessa guida pone come principio generale dell’acquisizione la minimizzazione, per quanto possibile, delle modifiche ai dati sorgente. Questo è uno dei motivi per cui trovo poco utile contrapporre in astratto “acquisizione forense” e “alterazione”.
Su un sistema spento possiamo lavorare cercando di evitare scritture sul supporto originale. Su un sistema live la situazione è diversa. Una parte dell’ambiente continuerà inevitabilmente a cambiare e noi stessi, se decidiamo di interagire con la macchina, contribuiremo a quel cambiamento.
Il problema diventa allora più concreto: cosa stiamo modificando, per ottenere cosa? Se l’interazione ci permette di preservare un volume decifrato che altrimenti rischieremmo di non poter più leggere, quel footprint può essere giustificato. Se stiamo eseguendo numerosi comandi soltanto perché “si fa così”, molto meno.
Riprendiamo per l’ultima volta il computer della nostra scena iniziale. Durante l’osservazione scopriamo che il disco è cifrato, il volume è accessibile e non abbiamo ancora individuato una recovery key. In quel caso preservare ciò che è disponibile nello stato corrente acquista un peso particolare. Cambiamo un elemento.
La recovery key è disponibile e verificata, ma sul sistema osserviamo un processo che sembra cancellare dati. Il problema principale potrebbe non essere più conservare lo stato di sblocco del disco, ma interrompere rapidamente la perdita di informazioni. Cambiamolo ancora.
Nessuna attività distruttiva, ma la workstation ha una VPN attiva e alcuni file rilevanti sembrano provenire da uno storage remoto. Isolare immediatamente la macchina potrebbe farci perdere una parte del contesto che stavamo cercando di comprendere. Sono sempre un computer acceso, un disco, una rete e una memoria RAM. Quello che cambia è lo stato dell’evidenza. Ed è quello stato che modifica il valore delle alternative disponibili.
Molto tempo dopo quella prima decisione, qualcuno potrebbe leggere la nostra relazione e chiedere perché abbiamo acquisito la memoria prima di spegnere. Oppure perché abbiamo lasciato temporaneamente il sistema collegato alla rete. O perché lo abbiamo isolato immediatamente.
Scrivere soltanto ciò che abbiamo fatto non basta a rispondere. Serve poter ricostruire cosa avevamo osservato in quel momento, quali informazioni ritenevamo a rischio e quali conseguenze avevamo considerato.
ISO/IEC 27037 colloca identificazione, raccolta, acquisizione e preservazione nello stesso processo di gestione della potenziale evidenza digitale. Lo standard comprende espressamente anche computer collegati a reti e sistemi basati su protocolli di rete. In pratica, documentare la decisione significa conservare anche il ragionamento che l’ha resa necessaria.
Non occorre dimostrare che fosse l’unica scelta possibile. Occorre poter spiegare perché, nello stato che avevamo davanti, quella scelta era ragionevole. Davanti a un computer acceso non sappiamo ancora se la decisione migliore sarà acquisire la RAM, interrompere la rete, effettuare una live acquisition o spegnere.
Possiamo però evitare di scegliere al buio. Prima osserviamo cosa è disponibile adesso, cosa potrebbe scomparire e quali modifiche introdurranno le alternative che abbiamo. Solo dopo decidiamo cosa vale la pena preservare. E soprattutto cosa non possiamo permetterci di perdere.
Sono aperte le iscrizioni al corso in Live Class “AGENTIC AI CYBER OPERATIONS (AACO)”. La cybersecurity sta entrando nell'era degli AI Agent: sistemi capaci di ragionare, utilizzare strumenti, orchestrare attività e portare avanti operazioni complesse. Ma come funzionano davvero dal punto di vista tecnico? Con AACO, Red Hot Cyber porta i professionisti della cybersecurity a toccare con mano gli strumenti agentici, attraverso una Live Class in italiano con 15 ore di formazione, laboratori pratici e scenari reali. Agentic AI, Tool Calling, MCP, orchestrazione di agenti, OSINT, Threat Intelligence, vulnerability assessment e automazione delle operazioni di cybersecurity. Non un corso per imparare a usare un chatbot, ma un percorso per capire, costruire e governare sistemi agentici applicati alla sicurezza informatica.
Partenza: Sabato 7 novembre
Programma completo e iscrizioni: https://www.redhotcyber.com/linksSk2L/academy-agentic-ai
Per info: 379 163 8765 [email protected]