RAM e volatile evidence: quando vale la pena acquisire prima di tutto il resto?

L'articolo analizza la decisione di acquisire la RAM di un computer acceso durante un'indagine forense, evidenziando i vantaggi di preservare dati volatili come processi, connessioni e chiavi crittografiche, ma anche i rischi di introdurre instabilità o modificare l'evidenza. Viene discusso il concetto di "order of volatility" e il fenomeno dello "smear" durante il dump, sottolineando l'importanza di valutare caso per caso quale informazione sia più critica da salvare prima di intervenire. Si conclude con linee guida operative per documentare e giustificare le scelte di acquisizione.

Davanti a un computer acceso, acquisire subito la RAM sembra spesso la scelta più prudente: ciò che è in memoria può cambiare o scomparire e, dopo uno spegnimento, parte di quelle informazioni potrebbe non essere più recuperabile. Ma acquisire la memoria significa anche intervenire su un sistema ancora in esecuzione.

Il tool deve essere caricato, vengono utilizzate risorse, alcuni dati possono cambiare mentre li stiamo acquisendo e, in certe condizioni, possiamo persino introdurre instabilità. La domanda quindi non è semplicemente se la RAM sia volatile. È capire quale evidenza rischiamo concretamente di perdere, quanto è importante per il caso e quale effetto avrà il tentativo di preservarla.

Il portatile è acceso. Sul desktop c’è un browser aperto. Il volume di sistema risulta accessibile, anche se sappiamo che il dispositivo utilizza BitLocker. Ci sono diversi processi in esecuzione e alcune connessioni di rete attive. Non sappiamo ancora se siano rilevanti. Sappiamo però una cosa: se spegniamo la macchina, lo stato che stiamo osservando non sarà più lo stesso.

A questo punto la scelta può sembrare quasi automatica.

Prima la RAM. Poi il disco.

È una sequenza che ha una logica evidente. La memoria è volatile e lo storage, almeno in linea generale, lo è molto meno. RFC 3227 ha formalizzato da tempo il principio dell’order of volatility: raccogliere prima ciò che rischia di cambiare più rapidamente. Ma tra un principio e una decisione operativa c’è ancora parecchio spazio. Perché acquisire la RAM significa modificare proprio il sistema che stiamo cercando di osservare.

Prima di acquisirla, dobbiamo sapere cosa stiamo cercando di salvare

Prendiamo una macchina con 32 o 64 GB di memoria. Se decidiamo di acquisirla, non stiamo semplicemente aggiungendo un altro file alla nostra copia forense. Stiamo cercando di preservare una parte dello stato corrente del sistema. In memoria possiamo trovare informazioni sui processi in esecuzione, connessioni, dati utilizzati dalle applicazioni, porzioni di file, strutture del sistema operativo e altri elementi che possono non essere più disponibili dopo lo spegnimento.

In alcuni casi il valore è molto più concreto. Un malware potrebbe esistere o essere interpretabile soprattutto attraverso ciò che sta accadendo in memoria. Un browser potrebbe avere una sessione ancora attiva. Un wallet potrebbe essere aperto. Un volume cifrato potrebbe essere in quel momento accessibile.

Anche le chiavi crittografiche possono rendere la situazione particolarmente delicata.SWGDE osserva che, quando è presente cifratura, può essere necessario acquisire la memoria prima dell’immagine del disco proprio per tentare di ottenere le chiavi e utilizzare successivamente l’acquisizione dello storage.

Qui il rischio diventa immediatamente comprensibile. Se spegniamo quel computer e perdiamo l’unico stato nel quale il volume era accessibile, potremmo ottenere un’acquisizione perfettamente integra di dati che non siamo più in grado di leggere. Ma immaginiamo un caso diverso.

La macchina è accesa, il disco non è cifrato, non abbiamo elementi che facciano pensare a malware fileless o processi particolari, l’utente non è collegato a servizi di interesse e il quesito riguarda alcuni documenti già memorizzati localmente. La RAM può comunque contenere informazioni utili. È però la stessa priorità del caso precedente? Probabilmente no.

La volatilità ci dice quanto facilmente un’informazione può cambiare. Non ci dice, da sola, quanto quell’informazione sia importante per il nostro caso. Ed è qui che la regola “prima la RAM” comincia a diventare troppo semplice.

Mentre acquisiamo la memoria, la memoria continua a cambiare

C’è poi un problema meno evidente. Un memory dump non congela il computer. Se dobbiamo acquisire 64 GB di RAM, il sistema non sospende la propria attività mentre il tool legge sequenzialmente quella memoria. Il sistema operativo continua a lavorare. I processi vengono schedulati. Una pagina può essere modificata dopo che un’altra è già stata acquisita. Una connessione può chiudersi. Un processo può terminare o generarne un altro.

L’immagine risultante non rappresenta quindi necessariamente lo stato dell’intera memoria in un unico istante. SWGDE richiama espressamente questo fenomeno parlando di smear: il tempo necessario all’acquisizione può permettere al sistema in esecuzione di modificare dati mentre vengono raccolti, producendo possibili incoerenze interne nell’immagine. Non significa che il dump non sia utilizzabile.

Significa che dobbiamo sapere che cosa abbiamo realmente ottenuto. Se nell’immagine troviamo un processo, possiamo sostenere che informazioni riconducibili a quel processo erano presenti nella memoria acquisita. Ma la ricostruzione temporale di ciò che stava accadendo richiederà comunque l’interpretazione di più artefatti. Allo stesso modo, se non troviamo qualcosa che ci aspettavamo, l’assenza dal dump non dimostra automaticamente che quell’informazione non sia mai stata presente.

Potrebbe essere scomparsa prima dell’acquisizione. Potrebbe essere cambiata durante il dump. Potrebbe non essere stata recuperata correttamente. Oppure la nostra ipotesi iniziale potrebbe semplicemente essere sbagliata. Sono conclusioni molto diverse.

E il nostro tool entra nella stessa RAM che vogliamo preservare

Per acquisire un sistema live dobbiamo interagire con lui. Colleghiamo un dispositivo. Il sistema può riconoscerlo. Avviamo un programma. Il programma viene caricato in memoria. Possiamo aver bisogno di privilegi amministrativi. Il tool utilizzerà CPU, memoria e I/O. Scriverà il risultato da qualche parte. Il sistema potrà aggiornare timestamp, log o altre strutture interne.

SWGDE lo tratta come un limite normale della live acquisition: l’accesso può modificare date e orari dei file, i processi possono interferire tra loro, il sistema può diventare instabile e l’acquisizione può essere soggetta a smear. Non è un’anomalia. È il costo tecnico dell’operazione.

Un vecchio modello proceduraleSWGDE sulla live memory lo descriveva in termini molto concreti: eseguire il programma di acquisizione sovrascrive necessariamente una piccola parte della RAM, ma quella modifica può essere accettata se consente di preservare gigabyte di informazioni che altrimenti andrebbero persi. Ed è probabilmente questo il modo più utile di guardare al problema.

Non chiedersi se possiamo acquisire senza modificare nulla. Su un sistema live sarebbe un obiettivo poco realistico. La domanda è se la modifica introdotta sia proporzionata a ciò che possiamo preservare. Se per recuperare una possibile chiave BitLocker dobbiamo caricare un memory acquisition tool affidabile da un supporto controllato, il bilancio può essere favorevole.

Se non abbiamo ancora osservato lo stato della macchina, non abbiamo documentato le applicazioni aperte e non sappiamo neppure che cosa stiamo cercando, lanciare immediatamente il primo tool disponibile è una decisione molto più difficile da difendere.

Ma allora qual è davvero la prima cosa da acquisire?

Qui compare un particolare interessante. Nella sua guida sulle acquisizioni forensi dei computer,SWGDE propone come ordine generalmente raccomandato: processi in esecuzione, connessioni di rete, RAM, impostazioni del sistema, chiavi di cifratura, artefatti applicativi e infine storage. E aggiunge una precisazione ancora più importante: su alcuni sistemi l’acquisizione della RAM può provocare instabilità e, proprio per questo, può essere opportuno eseguirla più tardi.

Quindi nemmeno l’order of volatility dice realmente “RAM sempre per prima”. Dice qualcosa di più utile: dobbiamo considerare insieme la volatilità dell’informazione e l’effetto della raccolta sul sistema. Torniamo allora al nostro portatile. È acceso. BitLocker è sbloccato. Vediamo una sessione autenticata. C’è un processo che non riconosciamo e una connessione verso un indirizzo remoto.

Potremmo iniziare documentando ciò che è immediatamente osservabile e raccogliendo alcune informazioni che possono cambiare molto rapidamente: processi, connessioni, configurazione essenziale. Poi acquisire la memoria. Ma se abbiamo motivo di ritenere che un’azione possa far terminare il processo, bloccare la sessione o perdere l’accesso al volume, la sequenza potrebbe cambiare ancora.

Non esiste necessariamente una lista valida per tutte le macchine. Esiste lo stato concreto che abbiamo davanti. Ed esistono informazioni che, dopo la nostra prossima azione, potrebbero non esserci più.

Dieci minuti dopo potremmo avere più evidenza. Oppure meno.

Immaginiamo due decisioni. Nel primo caso lasciamo il sistema acceso e iniziamo l’acquisizione della RAM. Nel secondo decidiamo di spegnerlo per procedere direttamente con una tradizionale acquisizione dello storage. Se la macchina conteneva semplicemente documenti non cifrati, entrambe le strade potrebbero consentirci di rispondere al quesito investigativo, anche se con quantità e tipi di informazioni differenti.

Ma se nella memoria era presente una chiave necessaria per accedere a un volume cifrato, lo spegnimento potrebbe aver eliminato qualcosa che non possiamo più ricostruire. E se il computer era compromesso da un malware residente principalmente in memoria, una parte rilevante dello stato dell’incidente potrebbe essere scomparsa con lui. Invertiamo però la situazione.

Supponiamo che il sistema sia instabile e che il memory acquisition tool disponibile richieda un driver che non abbiamo validato su quella specifica configurazione. L’acquisizione potrebbe causare un crash prima che riusciamo a preservare altre informazioni essenziali. In quel caso “salvare la RAM” potrebbe farci perdere qualcos’altro. Questo è il passaggio che rende la decisione forense diversa dall’applicazione di una procedura meccanica. Ogni azione ha un possibile guadagno e una possibile perdita. Anche non fare nulla.

Il dump è un’evidenza. Non è ancora la conclusione

Dopo l’acquisizione otteniamo un file. Ne calcoliamo l’hash, documentiamo il tool utilizzato e conserviamo l’immagine per l’analisi. Poi iniziamo a cercare. Troviamo un processo sospetto. Una connessione. Alcune stringhe. Forse materiale crittografico. È facile, a questo punto, spostare inconsapevolmente il significato del risultato. Il tool mostra un artefatto compatibile con un determinato processo. Questo non equivale ancora a dimostrare tutto ciò che quel processo ha fatto.

Troviamo un indirizzo IP associato a una struttura di rete. Non significa automaticamente che possiamo attribuire un’attività a chi controllava quell’indirizzo. Recuperiamo una possibile chiave di cifratura e riusciamo ad aprire un volume. Possiamo dimostrare l’efficacia di quella chiave su quel volume, ma il significato investigativo dei dati contenuti richiederà altri passaggi.

Anche qui conviene mantenere separati il risultato tecnico e la conclusione dell’analista. Il memory dump ci permette di osservare una parte dello stato volatile che siamo riusciti a preservare. Non ci restituisce automaticamente la storia completa di ciò che è avvenuto.

La scelta importante avviene prima di premere “Acquire”

Forse il modo più semplice per decidere è partire da una domanda diversa.

Che cosa posso perdere nei prossimi minuti?

Se la risposta è una sessione autenticata che non sappiamo se potremo ristabilire, una chiave crittografica, lo stato di un processo sospetto o dati che esistono soltanto nella memoria del sistema, l’acquisizione della RAM acquista immediatamente peso.

Poi arriva la seconda domanda.

Che cosa rischio di alterare o perdere tentando di acquisirla?

A quel punto possiamo valutare il tool disponibile, i privilegi necessari, la stabilità della macchina, dove scriveremo il dump, quanto dovremo interagire con il sistema e quali altre informazioni volatili sarebbe opportuno raccogliere prima.

NIST raccomanda da tempo di considerare i volatile OS data tra le fonti forensi perché possono contenere informazioni sui processi, sulle connessioni, sui file aperti e sullo stato corrente delle applicazioni. SWGDE aggiunge il passaggio operativo decisivo: qualsiasi raccolta live può modificare o creare evidenza e deve essere documentata.

Questo non rende la live acquisition un’eccezione da evitare.

La rende una decisione da spiegare.

Alla fine potremmo documentare di aver acquisito immediatamente la RAM perché il sistema presentava un volume cifrato già accessibile e perché lo spegnimento avrebbe potuto compromettere la possibilità di recuperarne le chiavi.

Oppure potremmo documentare di aver raccolto prima processi e connessioni perché erano altamente volatili e perché il memory acquisition tool presentava un rischio noto di instabilità su quella configurazione.

In un altro caso ancora potremmo decidere che il valore probabile della memoria non giustificava l’intervento live e procedere in modo diverso.

Tre macchine accese.

Tre decisioni possibili.

Quello che deve rimanere costante non è necessariamente l’ordine delle operazioni.

È la possibilità di ricostruire che cosa abbiamo osservato, che cosa rischiavamo di perdere, quali alternative avevamo, quale footprint abbiamo accettato e perché quella scelta era ragionevole nello stato concreto dell’evidenza.

Perché “la RAM è volatile” è un fatto tecnico.

Decidere se acquisirla prima di tutto il resto è già una conclusione forense.

Riferimenti essenziali

[1] Brezinski D., Killalea T., RFC 3227 – Guidelines for Evidence Collection and Archiving, IETF, 2002.
RFC 3227 – RFC Editor

[2] Scientific Working Group on Digital Evidence (SWGDE), Best Practices for Computer Forensic Acquisition, 17-F-002-2.1.
SWGDE – Best Practices for Computer Forensic Acquisition

[3] Scientific Working Group on Digital Evidence (SWGDE), Model Standard Operation Procedures for Computer Forensics – Scene Module 2: Live Memory Imaging and Analysis.
SWGDE – Model Standard Operation Procedures for Computer Forensics

[4] Kent K., Chevalier S., Grance T., Dang H., NIST SP 800-86 – Guide to Integrating Forensic Techniques into Incident Response, National Institute of Standards and Technology, 2006.
NIST SP 800-86

[5] Scientific Working Group on Digital Evidence (SWGDE), Best Practices for Digital Evidence Collection, 18-F-002-2.0.
SWGDE – Best Practices for Digital Evidence Collection

Lello Molinario

Lello Molinario si occupa di digital forensics, cybersecurity, investigazioni digitali ed ethical hacking. Integra esperienza operativa e ricerca accademica, con particolare attenzione alla digital evidence, alla first response e alla robustezza dei sistemi di AI applicati alla forensics.

Aree di competenza: Digital Forensics, Digital Evidence, Incident Response, Cybersecurity, Ethical Hacking, AI Security, DFIR, OSINT, Forensic Acquisition