{"id":2457,"date":"2025-09-05T19:39:41","date_gmt":"2025-09-05T17:39:41","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=2457"},"modified":"2025-09-05T19:41:08","modified_gmt":"2025-09-05T17:41:08","slug":"acquisizione-forense-principi-metodologie-e-strumenti-per-la-gestione-degli-incidenti-informatici","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2025\/09\/05\/acquisizione-forense-principi-metodologie-e-strumenti-per-la-gestione-degli-incidenti-informatici\/","title":{"rendered":"Acquisizione forense: principi, metodologie e strumenti per la gestione degli incidenti informatici"},"content":{"rendered":"\n

Introduzione<\/strong><\/p>\n\n\n\n

Nel contesto della sicurezza nazionale, l\u2019acquisizione forense delle evidenze digitali riveste un ruolo cruciale nella gestione degli incidenti informatici. Un CSIRT\/SOC <\/strong>(Computer Security Incident Response Team\/Security Operations Center) deve assicurare che ogni fase \u2013 dalla profilazione del sistema e triage iniziale<\/strong>, fino alla copia forense dei dati \u2013 sia condotta in modo rigoroso e conforme agli standard. Tali pratiche garantiscono sia la continuit\u00e0 operativa <\/strong>degli enti coinvolti che la valorizzazione probatoria <\/strong>delle informazioni raccolte, permettendo eventuali azioni legali. In questo articolo esamineremo le principali metodologie di acquisizione forense, distinguendo tra scenari live <\/em>e post-mortem<\/em>, le tecniche di copia bitstream di dischi e dump di RAM, gli artefatti tipici dei sistemi Windows e Linux, nonch\u00e9 gli strumenti hardware\/software disponibili. Faremo riferimento ai principali standard internazionali <\/strong>(ad es. ISO\/IEC 27037, NIST SP 800-86, RFC 3227) e con esempi concreti in contesto italiano.<\/p>\n\n\n\n

System Profiling e Triage<\/strong><\/p>\n\n\n\n

La fase di triage forense <\/strong>consiste nel valutare rapidamente uno scenario compromesso e dare priorit\u00e0<\/strong> alle evidenze digitali <\/strong>in base alla loro rilevanza e urgenza. In pratica, significa eseguire una profilazione del sistema <\/strong>coinvolto nell\u2019incidente: identificare il tipo di host (es. server, workstation), il sistema operativo e versione, i servizi attivi, gli utenti connessi e altri elementi chiave, ancor prima di procedere all\u2019acquisizione completa. Lo scopo del triage \u00e8 individuare subito i dati pi\u00f9 critici \u2013 ad esempio processi sospetti in esecuzione, connessioni di rete attive verso IP anomali, file di log che mostrano segni di manomissione \u2013 che richiedono azione immediata <\/strong>o conservazione urgente. Questa rapida valutazione permette al responsabile di decidere i passi successivi: ad esempio, se isolare il sistema <\/strong>dalla rete per contenere una minaccia in corso, oppure se mantenere la macchina accesa per acquisire dati volatili (RAM, processi, ecc.) prima che vadano persi.<\/p>\n\n\n\n

Durante il triage, \u00e8 fondamentale rispettare il principio dell\u2019ordine di volatilit\u00e0 <\/strong>indicato dall\u2019RFC 3227: occorre procedere raccogliendo prima i dati pi\u00f9 volatili e soggetti a cambiamento, per poi passare a quelli meno volatili. Ci\u00f2 significa, ad esempio, che su un sistema attivo si dovrebbero salvare immediatamente informazioni come il contenuto della memoria RAM, la tabella dei processi e le connessioni di rete, prima di acquisire i dati persistenti su disco. Allo stesso tempo, bisogna evitare manovre che possano alterare o distruggere le evidenze: non spegnere il sistema prematuramente<\/strong> (l\u2019attaccante potrebbe aver impostato script di wipe all\u2019arresto), e utilizzare strumenti \u201cpuliti\u201d (da supporti esterni) invece di quelli presenti sul sistema compromesso, che potrebbero essere stati modificati dall\u2019attaccante. Il responsabile forense deve istruire i primi soccorritori digitali (first responder) a seguire procedure codificate \u2013 spesso definite in playbook di incidente <\/strong>\u2013 per effettuare un triage metodico. Ad esempio, pu\u00f2 essere prevista una checklist: identificare e fotografare la schermata attiva, annotare o esportare rapidamente la lista dei processi e delle connessioni (usando tool come netstat <\/em>o PowerShell <\/em>in modalit\u00e0 forense), verificare la presenza di dispositivi USB collegati, e controllare il clock di sistema (per future correlazioni temporali). Queste attivit\u00e0 di profilazione iniziale <\/strong>forniscono un quadro dello stato del sistema utile per orientare l\u2019indagine e decidere quali evidenze raccogliere con priorit\u00e0. In sintesi, system profiling e triage <\/strong>rappresentano la prima linea di azione di un responsabile CSIRT nella fase di Preparation\/Identification <\/strong>di un incidente, gettando le basi per un\u2019acquisizione forense mirata ed efficace.<\/p>\n\n\n\n

Processo di acquisizione: modalit\u00e0 live <\/em>vs post-mortem<\/em><\/strong><\/p>\n\n\n\n

Una volta completato il triage, si passa al processo di acquisizione delle evidenze digitali <\/strong>vero e proprio, che pu\u00f2 avvenire in due modalit\u00e0 principali: live <\/strong>(a sistema acceso) o post-mortem <\/strong>(a sistema spento). La scelta dipende dalla situazione: in molti casi di risposta a incidenti, \u00e8 necessario operare live forensics <\/em>per catturare dati volatili critici; altre volte, soprattutto in scenari di analisi forense tradizionale (es. sequestro di un computer in un\u2019indagine giudiziaria), si opta per spegnere il sistema e lavorare su copie a freddo per minimizzare modifiche.<\/p>\n\n\n\n

Acquisizione live<\/strong><\/p>\n\n\n\n

In questa modalit\u00e0 si raccolgono evidenze a sistema funzionante. I vantaggi sono evidenti: si possono preservare informazioni che altrimenti andrebbero perse con lo spegnimento \u2013 ad esempio il contenuto della RAM, le chiavi di cifratura in uso, processi e connessioni attive, ecc. Tuttavia, l\u2019acquisizione live comporta inevitabilmente qualche alterazione <\/strong>dello stato del sistema (ogni comando eseguito pu\u00f2 modificare dati, come i timestamp di ultimo accesso) e va quindi condotta con strumenti e metodologie che riducano al minimo tale impatto. Best practice in questo ambito (formalizzate in ISO 27037 e RFC 3227) includono: usare tool forensi dedicati eseguendoli da supporti in sola lettura (per non introdurre nuovi file sul disco target) e documentare ogni operazione compiuta. Un esempio tipico di acquisizione live \u00e8 il dump della memoria RAM <\/strong>(vedi sezione dedicata) oppure l\u2019estrazione di informazioni volatili tramite script di risposta all\u2019incidente. In situazioni dove si sospetta la presenza di malware avanzati o tecniche anti-forensi <\/strong>(come il timestomping o la cancellazione dei log di evento), l\u2019analisi live pu\u00f2 rivelare indizi (processi anomali in esecuzione, moduli kernel caricati in memoria) che un\u2019analisi post-mortem potrebbe non evidenziare. \u00c8 importante anche valutare i rischi: ad esempio, scollegare la rete <\/strong>di una macchina compromessa pu\u00f2 essere opportuno per isolarla, ma va fatto in modo controllato (un malware potrebbe monitorare la connettivit\u00e0 e reagire cancellando tracce se \u201cperde\u201d la rete ). Il responsabile deve quindi decidere, caso per caso, quali step eseguire live e in che sequenza, bilanciando la conservazione massima delle prove <\/strong>con la stabilizzazione dell\u2019incidente <\/strong>(es. evitare che l\u2019attacco prosegua).<\/p>\n\n\n\n

Acquisizione post-mortem<\/strong><\/p>\n\n\n\n

Consiste nell\u2019acquisire le evidenze a sistema spento, tipicamente tramite la rimozione dei supporti di memoria (hard disk, SSD) e la successiva copia forense bitstream <\/strong>in laboratorio. Questo approccio ha il vantaggio di assicurare che il supporto originale non venga modificato ulteriormente <\/strong>dal momento del sequestro in poi. Nel momento in cui si spegne un computer, per\u00f2, si perde tutto il contenuto volatile<\/strong>: memoria RAM, stato dei processi, informazioni non salvate su disco, ecc. Pertanto, la decisione di spegnere dovrebbe essere ponderata: ad esempio, se si ritiene che le informazioni critiche risiedano su disco (non volatile) <\/strong>e non vi sia particolare interesse per lo stato attuale della RAM, pu\u00f2 essere preferibile rimuovere l\u2019alimentazione immediatamente per congelare la situazione. Al contrario, se si sospetta che informazioni vitali (come chiavi di cifratura, malware in RAM o volumi cifrati aperti) siano presenti in memoria, \u00e8 fondamentale lasciare il sistema acceso <\/strong>finch\u00e9 non si sia effettuato un dump della memoria e di eventuali dati volatili. L\u2019ISO\/IEC 27037 fornisce linee guida proprio per decidere queste priorit\u00e0: \u201cse dati volatili di rilievo sono presenti, raccoglierli prima di rimuovere l\u2019alimentazione; se invece il focus \u00e8 sui dati non volatili su disco, si pu\u00f2 procedere allo spegnimento in sicurezza\u201d. In modalit\u00e0 post-mortem, l\u2019operatore pu\u00f2 impiegare tecniche come il \u201cpull the plug\u201d <\/strong>(scollegare brutalmente l\u2019alimentazione anzich\u00e9 seguire la normale procedura di shutdown, per evitare che eventuali routine di spegnimento dell\u2019attaccante distruggano dati). Naturalmente ci\u00f2 potrebbe generare qualche inconsistenza nei file (es. journal non \u201cpuliti\u201d), ma si preferisce questo rischio piuttosto che perdere prove volatili preziose. Una volta spento e messo in sicurezza il sistema, si passa all\u2019imaging forense dei supporti (illustrato nella sezione successiva). L\u2019acquisizione post-mortem \u00e8 tipica nelle operazioni di polizia giudiziaria (sequestri) e nelle analisi che non richiedono intervento immediato sul campo. Un responsabile CSIRT deve saper indicare quando \u00e8 appropriato seguire l\u2019una o l\u2019altra modalit\u00e0, spesso anche combinandole (es.: acquisizione ibrida<\/strong>, dove prima si esegue un dump di RAM live e poi si spegne per copiare il disco). In ogni caso, che l\u2019acquisizione sia live o a freddo, vanno seguiti i protocolli di documentazione e catena di custodia <\/strong>per garantire integrit\u00e0 e autenticit\u00e0 delle evidenze raccolte.<\/p>\n\n\n\n

Acquisizione bitstream di memorie di massa<\/strong><\/p>\n\n\n\n

La copia forense bitstream <\/strong>di un supporto di memoria di massa (dischi fissi, SSD, memorie esterne) \u00e8 un processo centrale nell\u2019informatica forense. A differenza di una normale copia file-per-file, l\u2019imaging bitstream duplica bit a bit <\/em>l\u2019intero contenuto del supporto \u2013 includendo settori non allocati, spazio slack, aree nascoste \u2013 in modo da ottenere un clone esatto dell\u2019originale               . Questo \u00e8 fondamentale perch\u00e9 file cancellati o metadata residuali, non visibili al file system attivo, possono contenere informazioni cruciali in un\u2019indagine.<\/p>\n\n\n\n

Procedura di imaging: <\/strong>il processo standard prevede di collegare il supporto originale a una workstation forense <\/strong>(o a un dispositivo duplicatore) in modalit\u00e0 read-only <\/em>e creare un file immagine o una copia clonata su un supporto di destinazione pulito. Una misura imprescindibile \u00e8 l\u2019uso di un write-blocker<\/strong>, un dispositivo hardware (o software) che si interpone tra il drive di origine e il sistema di acquisizione, e impedisce qualsiasi comando di scrittura verso il dispositivo sorgente. In questo modo, si pu\u00f2 leggere ogni settore del disco senza rischiare modifiche accidentali (ad esempio aggiornamenti di timestamp di accesso, incrementi di contatori SMART, ecc.). I write-blocker hardware sono tipicamente connessi via USB\/SATA o tramite dock, e devono essere verificati <\/strong>prima dell\u2019uso; molti modelli forniscono indicatori che confermano lo stato di sola lettura. \u00c8 importante che il personale ricontrolli che il blocco in scrittura sia attivo per tutti <\/em>i dispositivi connessi e che i blocker siano periodicamente testati (come raccomandato anche dai laboratori NIST). In alternativa o in aggiunta, su sistemi nix si pu\u00f2 montare il supporto in modo da non scrivere journal (opzione <\/em>ro,noload* per NTFS, ad es.), ma il dispositivo hardware \u00e8 preferibile perch\u00e9 pi\u00f9 affidabile.<\/p>\n\n\n\n

Durante l\u2019imaging, si genera di solito un hash crittografico <\/strong>(tipicamente MD5 e\/o SHA-1\/SHA-256) sia del contenuto originale che della copia, per poter verificare in ogni momento la corrispondenza (integrit\u00e0) tra i due. Un responsabile deve esigere che al termine dell\u2019acquisizione questi hash combacino e che vengano registrati nei verbali. Come sottolineato da NIST, se si prevede un possibile uso probatorio, \u00e8 opportuno conservare l\u2019originale intatto come evidenza <\/em>(ad esempio sigillando il disco originale) ed effettuare tutte le analisi successive sulla copia<\/strong>. L\u2019ISO 27037 e le best practice internazionali insistono molto su questo punto: l\u2019originale diventa evidence master <\/strong>conservato a fini legali, mentre la copia forense (opportunamente verificata) \u00e8 quella su cui gli analisti lavorano, eventualmente potendone fare ulteriori copie di lavoro. Ogni passo eseguito deve essere documentato dettagliatamente<\/strong>: oltre ai comandi o software utilizzati per l\u2019imaging, vanno annotati ad esempio il modello e seriale del disco originale, la capacit\u00e0, il nome e versione dello strumento impiegato (software o duplicatore hardware), l\u2019ora di inizio e fine copia, il nome del tecnico operatore e qualsiasi anomalia riscontrata. Queste informazioni supportano la catena di custodia <\/strong>e servono a dimostrare che la procedura \u00e8 stata eseguita correttamente e senza contaminare le prove.<\/p>\n\n\n\n

Formati di output: <\/strong>l\u2019acquisizione bitstream pu\u00f2 produrre sia copie fisiche <\/strong>(disk-to-disk, clonazione diretta su un altro drive) che immagini logiche <\/strong>in un file (disk-to-image). La scelta dipende dalle esigenze e dalle risorse: una copia disk-to-disk permette, ad esempio, di montare immediatamente il clone su un\u2019altra macchina per un\u2019analisi rapida, ma richiede un secondo dispositivo di capacit\u00e0 uguale o maggiore. La copia in un file immagine (spesso con estensione .dd<\/code> se raw o .E01<\/code> se  compressa con formato EnCase) \u00e8 pi\u00f9 flessibile: il file pu\u00f2 essere trasferito, copiato e montato tramite software appositi; di contro, per accedervi occorre utilizzare applicativi forensi o montarlo in un ambiente che supporti tale formato. Molti strumenti consentono anche di comprimere al volo l\u2019immagine, salvando spazio, e di segmentarla in pi\u00f9 file (utile per gestire file system che non supportano file di grandi dimensioni). In contesti operativi, il responsabile deve definire uno schema di nomenclatura <\/strong>per le immagini e un sistema di storage sicuro<\/strong>: ad esempio, archiviare le immagini su NAS forense isolato, con controlli di integrit\u00e0 periodici (ricalcolo hash) e accesso ristretto.<\/p>\n\n\n\n

In conclusione, l\u2019acquisizione bitstream \u00e8 un processo dispendioso in termini di tempo e risorse (copiare centinaia di GB pu\u00f2 richiedere ore), ma \u00e8 indispensabile per garantire un\u2019analisi completa e la validit\u00e0 delle prove in tribunale. Organizzazioni ben preparate adottano linee guida interne <\/strong>per quando e come eseguire imaging completo (ad esempio, pu\u00f2 non essere realistico fermare immediatamente un server critico per copiarlo; vanno stabiliti criteri di impatto). Il responsabile CSIRT bilancia quindi anche l\u2019esigenza di continuit\u00e0 operativa con quella probatoria, pianificando acquisizioni a freddo in orari e modi che riducano il danno, ma senza compromettere la raccolta delle prove necessarie.<\/p>\n\n\n\n

Acquisizione di dump di memoria (RAM)<\/strong><\/p>\n\n\n\n

Le informazioni contenute nella memoria volatile (RAM) <\/strong>di un sistema spesso non hanno equivalenti<\/strong> sul disco <\/strong>e possono rivelare dettagli cruciali di un attacco informatico. La RAM ospita infatti lo stato vivo <\/em>del sistema: processi in esecuzione, moduli di kernel e driver caricati, connessioni di rete aperte, file aperti (che magari non sono mai stati salvati su disco), chiavi di cifratura in uso, password in chiaro temporaneamente in memoria, e molto altro. Tutto questo viene perso definitivamente non appena il sistema viene spento, data la natura volatile della RAM. Per tale ragione, acquisire un dump di<\/strong> memoria <\/strong>\u00e8 una fase fondamentale nella risposta agli incidenti live: consente di \u201ccongelare\u201d lo stato runtime del sistema al momento dell\u2019incidente per analizzarlo successivamente in laboratorio.<\/p>\n\n\n\n

Dal punto di vista pratico, un dump di RAM <\/strong>si ottiene tramite appositi strumenti che copiano byte per byte tutto il  contenuto della memoria in un file (spesso chiamato memory.dmp<\/code> con estensione .raw\/.bin<\/code>). Su sistemi Windows, esistono utilit\u00e0 consolidate come Magnet RAM Capture <\/em>(fornito da Magnet Forensics) o Belkasoft Live RAM Capturer<\/em>, nonch\u00e9 tool open-source come WinPmem <\/em>(facente parte del progetto Rekall) e DumpIt<\/em>. Questi programmi, tipicamente eseguiti dal tecnico sul sistema target (idealmente da una chiavetta USB, per ridurre scritture su disco), producono un file immagine della RAM che pu\u00f2 poi essere scaricato per l\u2019analisi. Su Linux, l\u2019operazione richiede spesso il caricamento di un modulo kernel dedicato <\/strong>come LiME (Linux Memory Extractor) <\/em>o l\u2019utilizzo di interfacce \/dev\/mem (se abilitate) e utility dd<\/em>. L\u2019immagine di memoria cos\u00ec ottenuta viene poi analizzata con framework di memory forensics <\/strong>quali Volatility <\/em>o Rekall<\/em>, che permettono di estrarre dalle strutture binarie informazioni intelligibili: ad esempio la lista dei processi e dei relativi segmenti di memoria, le connessioni di rete attive, le DLL\/caricate nei processi, eventuale codice iniettato, e persino di ricostruire contenuti testuali (come chat, email, cronologia web) presenti in memoria. Un\u2019analisi approfondita della RAM pu\u00f2 rivelare malware fileless <\/strong>(cio\u00e8 che risiedono solo in memoria), evidenze di attacchi \u201cpass the hash\u201d o credenziali rubate in cleartext, e tante altre informazioni essenziali per capire come \u00e8 avvenuta la compromissione <\/strong>e cosa sta facendo l\u2019attaccante.<\/p>\n\n\n\n

Vale la pena evidenziare due aspetti: temporalit\u00e0 e integrit\u00e0<\/strong>. La RAM \u00e8 estremamente dinamica: anche in pochi secondi lo stato pu\u00f2 cambiare (processi che terminano, nuovi che si avviano, allocazioni che si spostano). Pertanto, l\u2019operatore deve eseguire il dump il prima possibile <\/strong>durante il triage, minimizzando ritardi. Inoltre, va considerato che il processo di dumping stesso consuma un po\u2019 di RAM e altera alcuni contenuti (ad esempio, parte della RAM viene occupata dal buffer di copia); questo \u00e8 inevitabile, ma accettabile se si utilizzano strumenti progettati per minimizzare l\u2019impatto. Si documenta in ogni caso quale tool \u00e8 stato usato e in che orario. Sul fronte integrit\u00e0, bench\u00e9 non sia possibile calcolare un hash prima <\/em>(dato che la RAM \u00e8 mutevole), si calcola almeno l\u2019hash del file di dump generato e lo si conserva per verifiche future, trattandolo poi con la stessa cura di un\u2019immagine disco.<\/p>\n\n\n\n

Un altro motivo critico per effettuare il dump di RAM \u00e8 la presenza di chiavi di cifratura <\/strong>o altri segreti volatili. Se un sistema impiega dischi cifrati (es. BitLocker su Windows, LUKS su Linux) o connessioni VPN cifrate attive, spesso la chiave di decrittazione risiede in RAM <\/strong>mentre il volume \u00e8 montato o la sessione attiva. Estrarre la RAM pu\u00f2 consentire di recuperare tali chiavi \u2013 tramite specifici plugin di Volatility \u2013 e quindi di accedere a dati altrimenti indecifrabili. ISO 27037 infatti avverte di considerare l\u2019acquisizione di dati volatili prima dello shutdown proprio perch\u00e9 \u201cchiavi di cifratura e altri dati cruciali<\/em> potrebbero risiedere in memoria attiva\u201d<\/em>. Un caso concreto \u00e8 quello dei ransomware: alcuni memorizzano la chiave di cifratura in RAM; se si interviene rapidamente e si cattura la memoria, si potrebbe estrarre la key e decriptare i file senza pagare riscatti.<\/p>\n\n\n\n

In sintesi, l\u2019acquisizione della memoria volatile <\/strong>\u00e8 un tassello irrinunciabile nelle indagini su incidenti moderni. Un responsabile SOC deve prevedere nel piano di risposta la raccolta di dump di RAM per ogni server o endpoint compromesso (quando fattibile in sicurezza) e garantire che il personale sia addestrato all\u2019uso degli strumenti di memory dump. Solamente catturando questa dimensione \u201ceffimera\u201d dell\u2019attacco si ottiene una visione completa dell\u2019accaduto, che combini stato dinamico e dati statici.<\/p>\n\n\n\n

Artefatti di sistemi operativi Microsoft Windows<\/strong><\/p>\n\n\n\n

I sistemi Windows conservano una vasta gamma di artefatti forensi <\/strong>\u2013 file di log, voci di registro, cache di sistema \u2013 che possono fornire preziose evidenze sulle attivit\u00e0 avvenute prima, durante e dopo un incidente informatico. Un responsabile forense deve conoscere questi artefatti e includerne la raccolta nel processo di acquisizione. Ecco i principali artefatti Windows da considerare e il loro significato:<\/p>\n\n\n\n