Live acquisition: perché preservare più evidenze potrebbe alterare il sistema

La live acquisition è una tecnica fondamentale della digital forensics per recuperare dati da un computer acceso, comprese informazioni volatili, sessioni attive e volumi cifrati sbloccati. Ma ogni operazione può modificare il sistema. Ecco come valutare priorità, integrità delle prove e rischi durante un'indagine informatica.

Un computer acceso può contenere informazioni che dopo lo spegnimento non saranno più disponibili: memoria volatile, volumi cifrati già sbloccati, applicazioni aperte, sessioni autenticate o risorse remote. Acquisirle può essere necessario.

Ma ogni attività svolta sul sistema introduce anche modificazioni, mentre il sistema stesso continua a cambiare. La decisione quindi non riguarda soltanto cosa possiamo acquisire, ma cosa rischiamo di perdere aspettando, quanto dobbiamo interagire con il sistema e quali conseguenze siamo disposti ad accettare.

Il disco è cifrato, ma adesso è aperto

Arriviamo davanti a un computer acceso. Il volume principale è cifrato, ma l’utente ha già effettuato l’accesso. Sul desktop troviamo alcune applicazioni aperte. Una cartella di rete è montata e un programma sembra avere una sessione ancora attiva verso un servizio remoto.

Spegnere il computer sarebbe semplice. Ma sappiamo che, dopo lo spegnimento, il volume potrebbe tornare cifrato, la memoria verrebbe persa e alcune sessioni potrebbero non essere più recuperabili. Decidiamo quindi di mantenere il sistema acceso.

A questo punto nasce una seconda decisione, forse meno evidente della prima. Quanto dobbiamo fare prima di spegnerlo? Potremmo acquisire la RAM. Raccogliere processi e connessioni. Copiare alcuni file. Acquisire il volume logico. Iniziare un’immagine completa dello storage. Tutte attività potenzialmente utili.

Il problema è che non avvengono fuori dal sistema che stiamo esaminando. Avvengono dentro un computer che continua a funzionare.

Mentre acquisiamo, qualcosa sta già cambiando

Alle 10:12 iniziamo l’acquisizione della memoria. Il software viene eseguito, occupa memoria, apre handle, utilizza CPU e accede allo storage. Intanto il sistema operativo continua a schedulare processi, aggiornare strutture interne, scrivere log e gestire applicazioni e connessioni.

Alle 10:13 un processo termina.
Alle 10:14 una connessione di rete non è più presente.
Alle 10:15 termina l’acquisizione.

Quale dei tre momenti rappresenta il file che abbiamo ottenuto? In realtà nessuno in modo perfetto. Su un sistema attivo, la memoria può cambiare mentre viene letta. È uno dei motivi per cui nelle acquisizioni live si parla di smear: parti dell’immagine possono riflettere stati del sistema appartenenti a istanti leggermente diversi.

Questo non significa che un memory dump sia inutilizzabile. Significa che dobbiamo evitare di attribuirgli una proprietà che non possiede: non è necessariamente una fotografia simultanea e immobile dell’intero sistema. La distinzione diventa ancora più evidente quando l’acquisizione dura molto di più.

Immaginiamo un computer con 2 TB di storage. Avviamo un’acquisizione live completa che richiede alcune ore. Nel frattempo continuano a esistere processi, cache, sincronizzazioni, aggiornamenti di file e altre attività del sistema operativo. Più a lungo restiamo sul sistema, più ampia può diventare la distanza tra lo stato che abbiamo osservato inizialmente e quello che stiamo acquisendo nelle fasi successive.

Eppure interrompere tutto e spegnere potrebbe essere una scelta peggiore.

Alcune evidenze esistono soltanto adesso

Torniamo al volume cifrato. In questo momento è accessibile perché le condizioni necessarie per utilizzarlo sono già presenti nel sistema. Dopo lo spegnimento potremmo ritrovarci con un volume perfettamente acquisibile a livello fisico, ma non necessariamente leggibile.

Potrebbero esserci anche file non salvati, dati mantenuti soltanto nella memoria di un processo, chiavi crittografiche o sessioni autenticate. Una risorsa cloud o una share remota potrebbe essere raggiungibile adesso e non più successivamente.

Sono proprio questi alcuni degli scenari nei quali una live acquisition può diventare necessaria, soprattutto quando sono coinvolti sistemi cifrati o informazioni disponibili soltanto durante l’esecuzione. Quindi la modifica introdotta dall’acquisizione non può essere valutata isolatamente.

Occorre confrontarla con ciò che rischiamo di perdere non intervenendo. Se abbiamo una sessione che potrebbe scadere tra cinque minuti, dedicare prima un’ora a un’altra acquisizione può avere un costo.

Se il volume cifrato rimarrà invece accessibile e non abbiamo dati particolarmente volatili, la stessa sequenza potrebbe essere perfettamente ragionevole. Non cambia il principio. Cambia lo stato dell’evidenza.

Prima la RAM? Dipende da ciò che abbiamo davanti

L’ordine di volatilità rimane un riferimento utile: ciò che può scomparire rapidamente merita normalmente maggiore attenzione. Ma un riferimento non dovrebbe diventare un automatismo. Anche l’ordine delle acquisizioni deve essere valutato sul sistema concreto. In alcune condizioni persino l’acquisizione della memoria può introdurre instabilità o influire sulle altre informazioni che intendiamo preservare.

Supponiamo di trovare due computer. Nel primo abbiamo un volume cifrato aperto, nessuna connessione particolarmente interessante e un sistema apparentemente stabile. Nel secondo troviamo un’applicazione attiva collegata a una risorsa remota, dati non salvati e un processo che potrebbe essere centrale per l’indagine. “Prima acquisire la memoria” può essere una scelta corretta in entrambi i casi.

Ma non necessariamente per le stesse ragioni. E non necessariamente deve essere la prima attività in assoluto. Forse nel secondo sistema è più importante documentare immediatamente una determinata connessione o preservare una specifica informazione che potrebbe scomparire prima ancora che il dump sia terminato. La domanda utile diventa quindi più concreta:

se eseguo adesso questa acquisizione, cosa preservo e cosa potrebbe cambiare mentre aspetto che finisca?

Più dati non significa automaticamente migliore acquisizione

A questo punto potrebbe sembrare prudente raccogliere tutto. Più dati abbiamo, meno rischiamo di lasciarci qualcosa alle spalle. Ma anche questa scelta ha un costo. Un’acquisizione completa può durare ore. Durante quel periodo il sistema continua a evolvere e noi continuiamo a interagirvi.

Una raccolta mirata può essere molto più rapida. Potremmo acquisire memoria, alcuni file particolarmente rilevanti, informazioni sul sistema e solo successivamente passare allo storage completo. Ma selezionare significa anche escludere.

Un file che oggi sembra irrilevante potrebbe diventare importante domani. Una copia logica potrebbe non conservare automaticamente tutti i metadati che ci servono. Un criterio troppo stretto potrebbe lasciare fuori evidenza che ancora non sappiamo di dover cercare.

La targeted collection può essere appropriata quando quantità di dati, tempi, limiti tecnici o perimetro dell’attività rendono poco praticabile una raccolta completa, ma introduce inevitabilmente una scelta su cosa includere e cosa lasciare fuori.

Non abbiamo quindi una scelta tra “acquisizione completa, corretta” e “acquisizione parziale, sbagliata”. Abbiamo due strategie che preservano cose diverse e introducono rischi diversi. La scelta deve essere coerente con ciò che sappiamo in quel momento.

E l’hash?

Al termine dell’acquisizione calcoliamo l’hash dell’immagine. Otteniamo lo stesso valore durante la verifica successiva. Abbiamo quindi dimostrato l’integrità del dato acquisito. Ma che cosa abbiamo dimostrato esattamente?

Che il file che analizziamo successivamente corrisponde al dato che abbiamo prodotto durante l’acquisizione. Non che il computer sia rimasto immutato mentre lo stavamo acquisendo. Se il sistema ha continuato a modificare memoria, file o altri dati durante una raccolta durata due ore, l’hash non elimina quelle modificazioni.

Protegge un altro passaggio della catena: ci consente di verificare che il risultato ottenuto non sia stato successivamente alterato. È una distinzione piccola soltanto in apparenza. Dire che un’immagine è integra non equivale a dire che rappresenta uno stato perfettamente statico della sorgente.

Quello che dobbiamo riuscire a ricostruire dopo

Torniamo ancora una volta al computer iniziale. Volume cifrato aperto. Sessione autenticata. Risorsa remota montata. Abbiamo acquisito prima alcune informazioni volatili, poi la memoria e infine lo storage. Durante queste attività il sistema è inevitabilmente cambiato. La domanda, a quel punto, non è se siamo riusciti a evitare qualsiasi modifica.

È se sappiamo spiegare quelle rilevanti. Qual era lo stato osservato quando siamo intervenuti? Che cosa rischiava di scomparire? Perché abbiamo scelto quella sequenza? Quali strumenti abbiamo eseguito sul sistema? Quanto è durata l’acquisizione? Sono comparsi errori o condizioni anomale? Che cosa abbiamo deciso di rinviare o di non acquisire?

Le best practice sulla raccolta di evidenze digitali richiamano l’uso, sui sistemi live, della tecnica meno invasiva compatibile con l’obiettivo e la necessità di documentare le alterazioni introdotte durante l’attività. Lo stesso principio generale ricorre nelle linee guida per identificazione, raccolta, acquisizione e preservazione dell’evidenza digitale.

È probabilmente questo il modo più realistico di affrontare una live acquisition. Non cercare una procedura che non modifichi nulla. Cercare di preservare ciò che rischiamo realmente di perdere, introducendo soltanto le modificazioni che possiamo giustificare. Perché davanti a un sistema acceso non stiamo scegliendo tra intervenire e lasciare l’evidenza immobile.

Stiamo scegliendo quale cambiamento accettare per evitare una perdita potenzialmente più importante. E quella scelta, più ancora della quantità di dati che saremo riusciti a copiare, è ciò che dovremo essere in grado di documentare.

Riferimenti essenziali

[1] Scientific Working Group on Digital Evidence (SWGDE), Best Practices for Computer Forensic Acquisition, SWGDE 17-F-002-2.1.
https://www.swgde.org/documents/published-complete-listing/17-f-002-2-1/

[2] Scientific Working Group on Digital Evidence (SWGDE), Best Practices for Digital Evidence Collection, SWGDE 18-F-002-2.0.
https://www.swgde.org/documents/published-complete-listing/18-f-002-2-0/

[3] ISO/IEC 27037:2012, Information technology – Security techniques – Guidelines for identification, collection, acquisition and preservation of digital evidence.
https://www.iso.org/standard/44381.html

[4] NIST, SP 800-86 – Guide to Integrating Forensic Techniques into Incident Response, 2006.
https://csrc.nist.gov/pubs/sp/800/86/final

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