Data theft: piano di intervento informatico forense

Scenario e obiettivi dell’indagine

Il CSIRT Italia ha segnalato la presenza online di file riservati appartenenti ai clienti di uno studio legale, presumibilmente sottratti dal file server interno dello studio. In qualità di consulente forense incaricato, l’obiettivo primario è preservare e acquisire in modo forense tutte le evidenze digitali rilevanti (server, workstation e dispositivi di rete) garantendone integrità e autenticità, in vista di una possibile indagine giudiziaria. Si seguiranno rigorosamente le best practice internazionali (es. standard ISO/IEC 27037) per identificare, raccogliere, acquisire e conservare le prove digitali. È fondamentale minimizzare qualsiasi alterazione dei dati durante la raccolta e documentare ogni attività svolta, mantenendo una catena di custodia rigorosa delle evidenze.

Assunzioni Operative: si assume che l’incidente sia recente e che i sistemi coinvolti siano ancora disponibili in sede. Il file server Linux è identificato come potenziale fonte dei dati esfiltrati; tuttavia, non si esclude il coinvolgimento di una o più delle 5 workstation Windows (ad esempio come punto d’ingresso iniziale dell’attacco). Il firewall perimetrale potrebbe contenere log utili sulle connessioni di esfiltrazione. Si dispone dell’accesso fisico a tutti i dispositivi e del consenso dello studio per procedere all’acquisizione forense. Si prevede inoltre di avere a disposizione strumenti forensi (hardware e software) adeguati, inclusi supporti di memorizzazione esterni capienti per salvare le immagini acquisite. Ogni attività verrà coordinata in modo da ridurre al minimo l’impatto sull’operatività dello studio, pur privilegiando la preservazione delle prove rispetto alla continuità di servizio.

Identificazione e preservazione delle evidenze

Come primo passo, identifichiamo tutte le potenziali fonti di evidenza digitale nell’infrastruttura compromessa. In questo caso includono:

File server Linux (contenente i dati dei clienti) – sorgente probabile dell’esfiltrazione.
Workstation Windows 10 (5 unità) – potrebbero aver subito compromissioni (ad es. tramite malware o furto credenziali) usate per accedere al server.
Firewall perimetrale – dispositivo di rete con possibili log di traffico in uscita e regole di accesso.
Copie dei file esfiltrati rinvenuti online – per confronti con i dati originali e conferma dell’effettiva violazione.

Una volta identificate, si procede alla preservazione immediata dello stato dei sistemi per evitare alterazioni o perdite di informazioni volatili. In particolare:

Isolamento dei dispositivi dalla rete: scolleghiamo il file server e le workstation dalla rete (cavo Ethernet o Wi-Fi) per impedire ulteriori comunicazioni con l’esterno o possibili azioni di copertura da parte di un eventuale attaccante ancora connesso. Anche il firewall, se compromesso, viene isolato (ad es. rimuovendo temporaneamente la connessione WAN) mantenendolo però acceso se necessario per preservare i log in memoria.
Valutazione dello stato (acceso/spento) dei sistemi: se i computer sono accesi, si considera di eseguire un’acquisizione live di dati volatili. In base all’ordine di volatilità (RFC 3227), le informazioni più volatili come il contenuto della RAM e le connessioni di rete attive vanno acquisite prima di spegnere i sistemi. La memoria RAM può contenere informazioni cruciali (password in chiaro, processi malware in esecuzione, connessioni di rete attive, ecc.) che andrebbero perse allo spegnimento. Dunque, per server e workstation accesi si pianifica di catturare un dump della memoria prima di procedere oltre.
Documentazione della scena: prima di manipolare i dispositivi, si documenta accuratamente la scena: fotografia dei cablaggi, posizione dei dispositivi, stato dei sistemi (acceso/spento, schermate visibili), etichette o seriali. Questo aiuta a ricostruire il contesto e dimostrare che ogni passaggio è stato eseguito correttamente. Ogni attività viene annotata con data, ora, luogo e persone coinvolte, pronto per essere inserita nel registro di catena di custodia.
Stabilizzazione del sistema compromesso: in caso il file server Linux sia in esecuzione e si tema la presenza di malware attivo (es. una backdoor), si valuterà se conviene spegnere immediatamente dopo la raccolta della RAM. Spesso, in incidenti gravi, l’arresto immediato (es. scollegando l’alimentazione) è consigliato dopo la raccolta dei dati volatili, per evitare che malware distruttivi cancellino tracce all’arresto ordinato. Tuttavia, questa decisione va ponderata in base alla situazione (ad esempio, la presenza di servizi critici potrebbe richiedere un arresto controllato). Nel dubbio, è preferibile privilegiare l’integrità delle prove rispetto alla continuità operativa.

Acquisizione forense dei sistemi coinvolti

Dopo aver messo in sicurezza l’ambiente, si procede con l’acquisizione forense bit-a-bit dei supporti di memoria e la raccolta dei log, utilizzando strumenti e procedure tali da garantire copie esatte e immodificabili degli originali. Tutte le acquisizioni avverranno utilizzando strumentazione forense dedicata (write blocker, software di imaging) e seguendo protocolli standard. Di seguito, il dettaglio per ciascun componente:

File server Linux (acquisizione disco e memoria)

Il file server è il principale indiziato da cui sarebbero stati esfiltrati i dati. Le attività previste sono:

Dump della memoria RAM: ce il server è ancora acceso, si esegue una copia della memoria volatile. Su sistemi Linux, si può utilizzare ad esempio Linux Memory Extractor (LiME) (modulo kernel) o strumenti come Magnet DumpIt for Linux (tool standalone) per ottenere un file dump della RAM completo. L’operazione viene svolta rapidamente, salvando l’output su un supporto esterno montato in sola lettura. Questa acquisizione live è fondamentale perché la RAM potrebbe contenere indicazioni di processi sospetti, chiavi di cifratura, o connessioni attive dell’attaccante. Si annotano orario e configurazione del sistema al momento del dump (es. elenco processi e connessioni aperte, utilizzando comandi come ps, netstat o tool forensi,se possibile, evitando però alterazioni significative).
Acquisizione forense del disco: successivamente, si procede allo shutdown del server per eseguire l’acquisizione del disco in modo sicuro. Idealmente, il disco fisso del server viene rimosso dalla macchina per evitare qualsiasi modifica dovuta all’avvio del sistema operativo. Il disco viene collegato a una workstation forense tramite un write-blocker hardware (es. un Tableau) che impedisce qualsiasi scrittura accidentale sul supporto originale. In alternativa, se non fosse possibile estrarre il disco (ad es. array RAID complesso in produzione), si potrebbe avviare il server da un bootable USB forense (es. distribuzione CAINE basata su Linux Ubuntu o Kali Linux in modalità forense) che non altera i dischi interni (automount disabilitato, accesso in sola lettura). Avviato l’ambiente forense, si può usare il tool dd o dcfldd per creare un’immagine bitstream di ogni unità logica. Ad esempio: dcfldd if=/dev/sda of=/media/esterna/server-image.img hash=sha256 log=server-img.log (dove si calcola anche l’hash durante la copia). È preferibile usare dcfldd o strumenti analoghi in quanto progettati per scopi forensi (permettono di calcolare direttamente hash MD5/SHA e suddividere l’immagine in segmenti, se necessario). In alternativa, si può impiegare Guymager (tool con interfaccia grafica su Linux) che consente di creare immagini in formato raw E01 con calcolo automatico degli hash. Durante l’acquisizione, non si deve mai salvare l’immagine sullo stesso disco oggetto dell’acquisizione ma su un dispositivo di destinazione separato (ad esempio un drive USB esterno capiente formattato exFAT/NTFS). Si raccomanda il formato E01 (EnCase Evidence File) per il disco del server, poiché comprime i dati e consente di includere metadati (es. informazioni del caso, timestamp di acquisizione, etc.) utili per la catena di custodia. Al termine, viene calcolato e registrato l’hash (tipicamente MD5 e SHA-1) dell’immagine e confrontato con quello calcolato sul disco originale, per verificare la conformità bit-a-bit. Un match degli hash conferma che la copia è identica all’originale e non alterata, garantendo l’autenticità dell’evidenza. Tutte le operazioni vengono registrate nel log di acquisizione (nome del dispositivo, orari di inizio/fine, dimensione dell’immagine, algoritmi di hash utilizzati, ecc.). Il supporto originale (disco server) viene poi sigillato e conservato come evidenza originale.
Raccolta di log e configurazioni: oltre all’immagine completa del file system (che include comunque i log di sistema), si può procedere a estrarre copie logiche di file di log chiave per un’analisi immediata. Ad esempio, i file in /var/log/ (log di autenticazione SSH, log di Samba NFS se il server fungeva da file server di rete, log di sistema) sono cruciali per ricostruire gli accessi e le operazioni avvenute. Tali log, se disponibili, vengono copiati separatamente (sempre tramite strumenti che garantiscano l’integrità, ad es. usando cp in ambiente forense o esportandoli con nc su un’altra macchina) e i loro hash calcolati, così da poterli utilizzare per un’analisi più rapida senza dover montare subito l’intera immagine del disco. Naturalmente l’integrità di questi file è garantita anche dal fatto che provengono da un’immagine forense verificata.

Workstation Windows 10 (acquisizione disco e, se opportuno, memoria)

Le cinque workstation Windows potrebbero aver giocato un ruolo nell’incidente (es. come punto di ingresso iniziale tramite phishing o malware, o come postazioni da cui è partito l’accesso non autorizzato al server). Il piano prevede:

Dump della RAM (se accese): per ogni workstation ancora accesa al momento dell’intervento, si effettua prima la cattura della memoria volatile. Su Windows, uno strumento pratico è Magnet Forensics RAM Capture (DumpIt), eseguibile da chiavetta USB: con un doppio click esegue il dump completo della RAM su un file .raw o .mem. Questo richiede pochi minuti per decine di GB di RAM e fornisce istantanee dei processi in esecuzione, connessioni di rete attive, moduli caricati, ecc. Spesso i ransomware o altri malware lasciano tracce in memoria (processi o librerie iniettate) che possono essere scoperte con analisi successive (es. con Volatility). Anche credenziali o token temporanei possono risiedere in RAM, quindi questa è un’evidenza preziosa. Si salva il dump su un disco esterno, annotando ora e macchina, e si calcola l’hash anche per questi file di memoria.
Spegnimento e rimozione dischi: subito dopo il dump (o immediatamente, se la macchina era spenta), si spengono le workstation. Idealmente, nel caso di sospetto malware attivo, è accettabile uno spegnimento improvviso (staccando l’alimentazione o la batteria) per evitare che eventuali programmi malevoli intercettino la normale procedura di shutdown (p.es. alcuni malware possono cancellare tracce al momento dello spegnimento). Dato che abbiamo già acquisito la RAM, il rischio di perdere dati volatili importanti è mitigato. Una volta spento il sistema, si procede a rimuovere il disco interno (HDD/SSD) dalla workstation.
Imaging forense dei dischi: ogni disco viene etichettato univocamente (es. WS1, WS2, … WS5) e collegato tramite write-blocker a una postazione forense. Su sistemi Windows, useremo FTK Imager (software forense gratuito di AccessData/Exterro) sulla nostra workstation forense per creare immagini bitstream dei dischi. FTK Imager permette di scegliere il formato (raw dd, E01, AFF, etc.) e di calcolare automaticamente hash MD5/SHA1 durante l’acquisizione. Prima di procedere, ci assicuriamo che Windows non effettui mount automatico delle partizioni del disco inserito: infatti Windows tende a montare qualsiasi volume riconosciuto, rischiando di alterare last access time o altri metadata. L’uso del write-blocker hardware previene questo problema, garantendo che il sistema operativo forense veda il disco come sola lettura. In FTK Imager, useremo l’opzione Create Disk Image selezionando la sorgente fisica (Physical Drive) e specificando come destinazione un percorso su un drive esterno. Scegliamo il formato E01 (EnCase Evidence) per coerenza e compressione, inserendo nei metadati dell’immagine i dettagli del caso (nome caso, numero evidenza, esaminatore, etc.). Abilitiamo l’opzione di verifica hash al termine (FTK Imager calcolerà hash MD5/SHA1 e li comparerà automaticamente). Procediamo quindi all’imaging completo. Ad acquisizione terminata, verifichiamo i log di FTK Imager che riporteranno gli hash calcolati; un confronto positivo tra hash di origine e copia conferma la bontà dell’immagine. Ripetiamo questo processo per tutti i dischi delle 5 postazioni.
Acquisizione dati di interesse dalle workstation: le immagini dei dischi Windows conterranno informazioni quali i log di Windows (eventi di sicurezza nel registro eventi), file temporanei, cronologia di navigazione, eventuali malware presenti, ecc. Sebbene l’analisi dettagliata avverrà successivamente in laboratorio, in sede di acquisizione si può già valutare di estrarre rapidamente alcuni artefatti se immediatamente utili. Ad esempio, log di Windows Event Viewer (Security.evtx) per vedere login sospetti, o la lista di utenti e gruppi locali, possono essere esportati usando strumenti come FTK Imager stesso (che consente di sfogliare il file system e salvare file singoli) prima di smontare il disco. Tuttavia, tali operazioni non sono strettamente necessarie in campo se l’obiettivo principale è acquisire tutto per analisi approfondita successiva. L’essenziale è che le immagini siano integre e complete.

Firewall perimetrale (raccolta log e configurazione)

Il firewall costituisce il punto di ingresso/uscita della rete aziendale. Anche se potrebbe non essere opportuno spegnerlo (specie se fornisce connettività Internet allo studio) prima di aver analizzato la situazione, ai fini forensi occorre acquisire i dati che possono testimoniare le connessioni di esfiltrazione. Le azioni prevedono:

Esportazione dei log di traffico: la maggior parte dei firewall di classe enterprise o SMB consente di esportare i log di sistema (ad esempio file di log di sessione, eventi di intrusion detection se integrato, log VPN, ecc.) tramite interfaccia di amministrazione o SSH. Si accede al firewall (in sola lettura) e si scaricano i log relativi al periodo sospetto dell’incidente. In particolare, interessano log di connessioni uscenti (egress) dal file server o dalle workstation verso l’esterno. Questi log possono rivelare indirizzi IP di destinazione e volumi di dati trasferiti durante l’esfiltrazione. Ad esempio, se i dati sono stati caricati su un sito web o cloud, il firewall potrebbe mostrare un flusso FTP/HTTP/HTTPS anomalo in uscita da un IP interno (quello del server) verso un IP esterno sconosciuto, magari con un volume di svariati gigabyte. Tali evidenze sono cruciali per ricostruire il canale di esfiltrazione. I log vengono salvati (in formato testo o CSV) su supporto forense e ne vengono calcolati gli hash per garantirne l’integrità.
Configurazione e regole: si acquisisce anche la configurazione del firewall (spesso esportabile come file di backup) per vedere che porte/servizi erano aperti verso l’esterno. Ad esempio, se il file server aveva porte aperte (SSH, SMB) o se esistevano regole di port forwarding, ciò può essere rilevante. La config, una volta esportata, viene sottoposta a hash e conservata.
Eventuale immagine del dispositivo: se il firewall è un appliance software (ad es. basato su Linux/BSD come pfSense) con storage interno, e se l’hardware lo permette, si può anche considerare di fare un’immagine forense del suo drive (similmente a quanto fatto per server/PC). Tuttavia, molti firewall commerciali hanno filesystem proprietari o sono crittografati; spesso è sufficiente raccogliere log e config. Nel caso di un firewall standard PC-based, si potrebbe spegnere e clonare il disco con gli stessi metodi (write-blocker, etc.), ma solo dopo aver ottenuto i log volatili se non persistenti.

Evidenze dei file esfiltrati online

Parallelamente all’acquisizione interna, recuperiamo i file trapelati sul sito Internet segnalato dal CSIRT. Questi file costituiscono prova dell’avvenuta violazione e saranno utili per confronti. Le attività sono:

Download dei file dal sito esterno: utilizzando un computer sicuro, si scaricano i file trovati online, preservandone i metadati ove possibile. Ad esempio, se disponibili via web, si può usare wget o browser, evitando di modificarli (impostando l’orario di modifica come originario se indicato). Si registra l’URL e l’ora del download e, se possibile, si fa uno screenshot della pagina web dove erano disponibili, come documentazione.
Calcolo hash e conservazione: su ogni file esfiltrato scaricato, si calcolano hash (MD5/SHA1) per poterli confrontare successivamente con gli hash dei file originali sul server. In ambito forense, il confronto degli hash permetterà di dimostrare che il file online è esattamente uguale a quello presente sul server (qualora nelle immagini acquisite del server sia rinvenuto lo stesso hash), confermando così l’origine dell’esfiltrazione. Questi file scaricati diventano anch’essi evidenze digitali e vengono inseriti nella catena di custodia.
Metadati e attributi: si analizzano brevemente i metadati di tali file (es. proprietà del documento, autore, date di creazione/modifica) poiché potrebbero rivelare informazioni sull’origine (ad es. username del sistema dal quale provengono, versione software, etc.). Tali informazioni, se trovate, saranno poi corroborate con l’analisi interna (ad esempio, se i documenti recano come autore il nome di un dipendente dello studio, ciò può suggerire da quale PC/server provenivano).

Verifica dell’integrità e documentazione della Catena di Custodia

Durante e dopo ogni acquisizione, si verifica l’integrità delle evidenze digitali e si aggiornano i documenti che compongono la Catena di Custodia:

Calcolo e verifica degli hash crittografici: come standard, per ogni immagine forense creata (dischi di server, PC) e per ogni file rilevante copiato (dump di RAM, log, file esfiltrati, ecc.), si calcola almeno un algoritmo di hash (tipicamente MD5 e SHA-1, oppure SHA-256 per maggiore sicurezza). Il valore di hash viene confrontato con quello ricalcolato all’occorrenza sulle stesse evidenze per assicurare che non vi siano alterazioni. Ad esempio, FTK Imager e altri tool riportano automaticamente hash MD5/SHA1 post-acquisizione. Questi hash vengono annotati nel verbale di acquisizione accanto all’identificativo dell’evidenza. La corrispondenza degli hash tra originale e copia forense prova formalmente che la copia è identica al bit all’originale, requisito fondamentale per la validità probatoria.
Documentazione dettagliata: si redige un verbale tecnico di acquisizione in cui per ogni dispositivo analizzato si riportano: descrizione (marca, modello, S/N), identificativo assegnato come evidenza, persona che ha eseguito l’operazione, data/ora di inizio e fine imaging, strumento usato, hash dell’immagine ottenuta, eventuali osservazioni (es. errori di lettura, settori danneggiati se presenti). Inoltre, come previsto dalle linee guida, si documenta ogni operazione svolta su ciascun reperto in ordine cronologico. La Catena di Custodia descrive l’intero ciclo di vita dell’evidenza digitale, dalla raccolta iniziale fino all’eventuale presentazione in tribunale. Ad esempio: “Evidenza E01: Disco fisso server SN… prelevato in data … ore … da Tizio, acquisito in copia forense file XYZ.E01 hash MD5=…, SHA1=…, da Caio con strumento FTK Imager vX, consegnato in custodia a Sempronio alle ore …”. Ogni trasferimento di custodia (passaggi di mano dell’evidenza, spostamento dal luogo di raccolta al laboratorio, etc.) viene parimenti registrato con data, ora, persona che consegna e persona che riceve e firma (quando possibile). Questo garantisce tracciabilità completa: in ogni momento si può stabilire chi ha avuto accesso all’evidenza e quando.
Protezione fisica delle evidenze: dopo l’acquisizione, i supporti originali (dischi rimossi, ecc.) vengono riposti in contenitori sigillati con etichette anti-manomissione (ad es. evidenziatori di apertura). Si appone un sigillo sia sull’originale sia su una delle copie forensi conservate (la seconda copia sarà utilizzata per l’analisi). Eventuali violazioni dei sigilli sarebbero evidenti e renderebbero dubbia l’integrità del reperto. Oltre ai sigilli fisici, si proteggono i dati da fattori esterni: ad esempio, i supporti vengono conservati in ambiente a temperatura e umidità controllata, lontano da campi elettromagnetici che potrebbero danneggiarli. Nel nostro caso, i dischi originali delle workstation e del server, dopo l’imaging, verranno ad esempio inseriti in sacchetti antistatici, sigillati, etichettati e messi in una cassaforte o armadio blindato. Lo stesso per eventuali USB contenenti i dump di RAM o i file scaricati: se tali dati sono salvati su supporti rimovibili (es. SSD esterno), anche questi supporti vengono sigillati e custoditi.
Conservazione delle copie forensi: le immagini forensi acquisite (file .E01, .dd, dump RAM, ecc.) verranno duplicate se possibile: una copia master immutabile, conservata come evidenza intoccabile, e una o più copie di lavoro su cui effettuare l’analisi tecnica. La copia master (ad es. su hard disk dedicato) viene anch’essa sigillata e custodita, mentre la copia di lavoro potrà essere caricata sulle workstation forensi per l’analisi senza rischiare di compromettere l’originale. In caso di contestazioni, la copia master potrà sempre essere riesaminata per verifica indipendente.

Consegna e destinazione delle evidenze

Una volta concluse le acquisizioni, le evidenze dovranno essere consegnate e/o conservate in modo appropriato in vista di procedimenti futuri:

Reportistica e verbali ufficiali: si consegna allo studio legale un rapporto forense preliminare che elenca tutte le evidenze raccolte e descrive sinteticamente le modalità di acquisizione seguite, certificando che sono stati rispettati i protocolli per assicurare conformità degli originali e immodificabilità delle copie. Questo rapporto include in allegato i verbali di cui sopra e i documenti costituenti la Catena di Custodia firmati dal consulente.
Consegna a autorità inquirenti (se previsto): se lo studio intende sporgere denuncia o se l’incidente configura reati perseguibili d’ufficio, le evidenze digitali dovranno essere messe a disposizione dell’Autorità Giudiziaria. In tal caso, si preparano i reperti secondo le regole richieste: ogni evidenza viene identificata con un numero di repertazione, descritta nel verbale di consegna e consegnata (es. alla Polizia Postale o altra forza di polizia competente). I rappresentanti dell’autorità firmano per ricevuta, entrando così loro nella catena di custodia come nuovi custodi dell’evidenza. Da quel momento, ogni accesso ai dati dovrà avvenire sotto il loro controllo o con la loro autorizzazione. È importante evidenziare che la documentazione della Catena di Custodia accompagna le evidenze: fornisce al giudice la garanzia che dal momento della raccolta alla presentazione in giudizio non vi siano state manomissioni.
Conservazione a lungo termine: sia lo studio sia l’autorità (se coinvolta) dovranno conservare le evidenze digitali in modo sicuro fino alla conclusione di ogni procedura legale, ed anche oltre se richiesto. Ciò significa storage in ambienti controllati, con accesso limitato solo a personale autorizzato. Ad esempio, i supporti sigillati possono essere custoditi in una sala prove dedicata con registro accessi, e le copie digitali possono essere conservate anche in cassaforte ignifuga (per prevenire perdita in caso di incendio). Si ricorda che anche i dati digitali soffrono il passare del tempo (bit rot, obsolescenza hardware): pertanto, per conservazioni prolungate, si potrebbero effettuare periodiche verifiche dell’integrità (ricalcolando gli hash a distanza di tempo per verificare che coincidano ancora) e migrazioni su nuovi supporti in caso di necessità, sempre documentando ogni passaggio.

Strumentazione e tecniche utilizzate

Di seguito un riepilogo degli strumenti specifici impiegati e la motivazione della loro scelta, in accordo con le best practice forensi:

Write Blocker Hardware (es. Tableau, Digital Intelligence UltraBay): dispositivo essenziale che si interpone tra il supporto originale (es. SATA/SAS/USB) e la macchina forense, consentendo solo comandi di lettura. Ciò previene modifiche accidentali ai dati originali durante l’imaging . L’uso del write blocker garantisce l’immodificabilità del reperto originale in linea con i requisiti legali (copia conforme e non alterata). Abbiamo utilizzato write blocker per tutti i dischi rimossi prima di leggerli sui nostri sistemi di acquisizione.

Software di imaging forense

FTK Imager: scelto per l’acquisizione delle workstation Windows. È uno strumento gratuito e affidabile, in grado di creare immagini forensi (raw, E01, AFF) e di calcolare hash integrati. Supporta anche la cattura della RAM su macchine Windows con pochi click. Lo abbiamo usato per comodità e per mantenere un formato standard (E01) ampiamente accettato nelle corti. Inoltre FTK Imager genera un log dettagliato utile per testimoniare la correttezza delle operazioni.
dd/dc3dd: utilizzato in ambienti Linux per la sua ubiquità e controllo. dc3dd in particolare è una variante di dd orientata al digital forensics, che permette hashing on the fly e log avanzati. È stato impiegato per duplicare il disco del server Linux in maniera forense.
Guymager: alternativa GUI su Linux per imaging, scelta nel caso di acquisizioni tramite live CD CAINE. Genera direttamente file .E01 e calcola hash, semplificando l’operatività.
Tableau TD3/TX1 Forensic Imager (opzionale): si tratta di unità hardware dedicate che clonano dischi a livello hardware senza bisogno di PC. Se disponibile, avremmo potuto usarla per velocizzare l’acquisizione dei dischi grandi (soprattutto il server) con copia diretta disk-to-disk. Tali dispositivi garantiscono velocità ottimizzata e logging automatico, con verifica hash in hardware. Nel nostro scenario, abbiamo ipotizzato l’uso prevalente di software, ma è menzionato per completezza.

Strumenti per il dump della memoria volatile

Magnet RAM Capture (DumpIt): utilizzato per dump veloci della RAM sulle macchine Windows. Scelto per la sua semplicità (eseguibile portabile) e velocità. Il dump risultante è compatibile con i più diffusi framework di analisi della memoria (Volatility, Rekall).
LiME (Linux Memory Extractor): modulo kernel per Linux usato per dump di RAM del server. Scelto perché consente di ottenere un dump consistente direttamente da kernel space, con un impatto minimo sul sistema. Richiede preparazione (compilazione modulo ad hoc per la versione di kernel), perciò si potrebbe optare in alternativa per AVML (Azure VM Memory Leaker) di Microsoft, un tool user-space che non necessita compilazione. In ogni caso, l’importante è aver ottenuto la memoria prima dello spegnimento.
Volatility Framework (analisi post acquisizione): citato come strumento che useremo successivamente per analizzare i dump di memoria e cercare indizi (processi anomali, moduli sospetti, connessioni residue, credenziali in chiaro, ecc.).

Utilities di sistema e log collection

Comandi come ifconfig/ipconfig, netstat, tasklist/ps, wmic etc., possonoessere stati eseguiti durante la fase live (se fatta) per raccogliere informazioni di stato (es. elenco connessioni di rete, processi attivi, utenti loggati). Tali informazioni sono state annotate e salvate come parte delle evidenze (es. reindirizzando l’output su file di testo).
Per il firewall, l’interfaccia di amministrazione web/SSH integrata è stata lo strumento per estrarre i log e configurazioni. In mancanza di esportazione diretta, si poteva eseguire uno script o screenshot.
Hashing tools: utilizzo di algoritmi MD5, SHA-1, SHA-256 tramite tool integrati (ad es. md5sum/sha1sum su Linux, o utilità come HashCalc su Windows) per calcolare le impronte digitali delle evidenze.

In sintesi, la combinazione di questi strumenti e tecniche è stata scelta per massimizzare l’affidabilità e la completezza della raccolta delle prove, minimizzando al contempo il rischio di alterazione dei dati originali. Ogni scelta (dall’uso del write blocker all’acquisizione della RAM) è motivata da esigenze probatorie: garantire che ogni bit di informazione utile venga conservato e possa essere presentato in giudizio con adeguato fondamento di autenticità.

Conclusione

Al termine di queste operazioni, lo studio legale disporrà di copie forensi integre di tutti i sistemi coinvolti, pronte per l’analisi approfondita. Nelle fasi successive, in laboratorio, si potranno esaminare le immagini acquisite con software di analisi forense (come Autopsy, EnCase, X-Ways o altri) per ricostruire la timeline dell’intrusione, identificare l’eventuale malware o tecnica di attacco utilizzata, e confermare quali dati sono stati esfiltrati e come. I log di firewall e di sistema aiuteranno a determinare quando e verso dove sono stati trasmessi i dati rubati . Tutto questo, unito alle evidenze conservate in modo corretto, permetterà eventualmente di presentare una prova tecnica solida alle autorità competenti e in sede legale, sostenendo le azioni che lo studio legale deciderà di intraprendere a tutela dei propri clienti e contro gli autori della violazione.

Fonti e riferimenti: le procedure adottate seguono gli standard riconosciuti in ambito digital forensics e incident response, tra cui le linee guida ISO/IEC 27037:2012 per la gestione delle evidenze digitali. Strumenti come FTK Imager e write-blocker hardware sono prassi comune per garantire copie forens affidabili, così come l’uso di hash crittografici per assicurare la conformità delle copie. La catena di custodia e la sigillatura dei reperti vengono gestite secondo le indicazioni della migliore dottrina forense 19 21 , assicurando in ogni momento l’integrità e l’autenticità del materiale probatorio raccolto. Con questo approccio metodico e documentato, l’indagine potrà proseguire sapendo di avere solide basi probatorie su cui fare affidamento.

Pillole di Digital Forensics

La digital forensics è una branca della Criminalistica caratterizzata dall’adozione di metodi scientificamente derivati finalizzati all’identificazione, acquisizione e/o repertamento, preservazione, validazione, verifica, analisi, l’interpretazione, documentazione e presentazione del contenuto informativo di sistemi informatici o telematici, al fine di evidenziare l’esistenza di fonti di prova digitali resistenti ad eventuali contestazioni circa la propria attendibilità e capacità probatoria sia in ambito civile che penale.

Corte di Cassazione (Sez. VI n. 3067 del 14.12.1999; Sez. V n. 31135 del 6.7.2007)

«… deve ritenersi “sistema informatico”, … , un complesso di apparecchiature destinate a compiere una qualsiasi funzione utile all’uomo, attraverso l’utilizzazione (anche parziale) di tecnologie informatiche, che sono caratterizzate – per mezzo di un’attività di “codificazione” e “decodificazione” – dalla “registrazione” o “memorizzazione”, per mezzo di impulsi elettronici, su supporti adeguati, di “dati”, cioè di rappresentazioni elementari di un fatto, effettuata attraverso simboli (bit), in combinazione diverse, e dalla elaborazione automatica di tali dati, in modo da generare “informazioni”, costituite da un insieme più o meno vasto di dati organizzati secondo una logica che consenta loro di esprimere un particolare significato per l’utente …».

«… è “sistema telematico” l’insieme di più sistemi informatici collegati tra loro per lo scambio di informazioni, purché siano connessi in modo permanente, e purché lo scambio di informazioni sia il mezzo necessario per conseguire i fini operativi del sistema. …»

Digital Investigation: si attua prima (attività preventiva volta all’acquisizione di elementi indiziari), durante il fatto reato (possono richiedere garanzie difensive);

Digital Forensics: si attua dopo il fatto reato, ossia il dispositivo scientifico arriva sempre a fatto compiuto (c.d. post-mortem) e concentra la sua azione su un specifico evento al fine di determinarne le cause. Essa può essere a sua volta in modalità:

Live: il sistema informatico non si può spegnere, quindi si è costretti ad operare sulla scena del crimine;

Dead o Static: il sistema informatico è spento, quindi cristallizzato e si può operare in laboratorio.

Ruoli e responsabilità

DEFR (Digital Evidence First Responder) ISO 27037:2012 Pt. 3.7

Definito a volte come Addetto ai Rilievi Tecnici, questi viene coinvolto nelle fasi di identificazione, repertamento e/o acquisizione e preservazione della fonte di prova digitale. Tale figura professionale non dovrebbe necessariamente svolgere un’attività di analisi.

DES (Digital Evidence Specialist) ISO 27037:2012 Pt. 3.8

Definito a volte come “Analista”, questi fornisce supporto tecnico al DEFR nelle fasi di identificazione, repertamento e/o acquisizione e preservazione delle fonti di prova digitale. Il DES deve essere caratterizzato da una formazione di tipo accademico e di comprovata esperienza nel settore tecnico-investigativo.

Il dato è la rappresentazione oggettiva di un fatto o evento che consenta la sua trasmissione oppure interpretazione da parte di un soggetto umano o di uno strumento informatico.

L’informazione è l’interpretazione e il significato assegnato a uno o più dati.

Le fasi

Identificazione (ISO 27037:2012 pt. 3.12): ricerca, riconoscimento e documentazione della fonte di prova digitale e rispettiva pertinenza (priorizzare le attività sulla base dell’ordine di volatilità dei dati, mitigare l’impatto sia sul sistema che sulle fonti di prova digitali).

Acquisizione (ISO 27037:2012 pt. 3.1): duplicazione del contenuto informativo della fonte di prova digitale. Consiste nell’adozione di misure tecniche, il più possibile riproducibili e/o verificabili, dirette alla duplicazione del contenuto informativo, o parte di esso, di sistemi informatici e/o telematici su adeguati supporti, tale che assicuri la conformità della copia all’originale.

Con il termine “duplicato informatico” (art. 1 lett. i-quinquies D. Lgs. 7 marzo 2005, n. 82 – C.A.D.) s’intende l’operazione di memorizzazione, su dispositivi diversi, della medesima sequenza di valori binari del dato informatico originario.

Affinché il dato non sia condizionato dal nuovo ambiente di lavoro, vi è la necessità che questi venga memorizzato all’interno di un c.d. “forensic container”, creando così un vero e proprio “reperto virtuale”.

Repertamento (ISO 27037:2012 pt. 3.3.): attività volta ad assicurare la fonte di prova digitale e la rispettiva pertinenza, consiste nella rimozione della fonte di prova digitale e sue pertinenze dall’ambiente originario ad uno controllato (es. un laboratorio) per la successiva acquisizione ed analisi. Non sempre è possibile repertare.

Preservazione (ISO 27037:2012 p.t. 3.15): attività volta a garantire l’integrità e/o le condizioni originali della fonte di prova digitale mediante misure tecniche dirette ad: assicurare la conservazione e l’immodificabilità (conservazione dello stato dei luoghi) e impedire l’alterazione (dolo) e l’accesso incontrollato (colpa).

Validazione (ISO 27037:2012 pt. 3.24): attività di valutazione del rapporto di “pertinenzialità” tra gli elementi assicurati ed il contesto investigativo (ISO / IEC 27004: 2016).

Verifica (ISO 27041:2015 pt. 3.20): si accerta che la fonte di prova digitale ha conservato la sua integrità (ISO / IEC 27004: 2016).

Analisi (ISO 27042:2015 pt. 3.1 and ISO 27043:2015 pt. 3.3): il processo di valutazione oggettiva delle fonte di prova digitali a finché queste possano confermare, o confutare, un tesi accusatoria.

Interpretazione (ISO 27042:2015 pt. 3.9): è il processo in cui si contestualizzano le risultanze oggettive derivate dall‘attività di analisi e le si proietta in più ampio quadro accusatorio (es. Correlazione tra risultanze di più dispositivi informatici analizzati e dati forniti da terze parti).

Documentazione (es. artt. 136, 137 e 357 c.p.p.): insieme di atti e documenti in genere volti a storicizzare le attività svolte

Presentazione (es. artt. 196-198 c.p.p.): è l’esposizione, generalmente orale, delle risultanze tecnico-investigative in ambito processuale

La Catena di Custodia (CoC – ISO 27037:2012 pt. 6.1) è un documento o una serie di questi che attesta, in un dato arco temporale, la responsabilità di un soggetto nella gestione di uno o più reperti. Essa ha inizio con l’esercizio dell’attività assicurativa e si conclude con la confisca e distruzione, ovvero la restituzione all’avente diritto del reperto.

Principi (ISO 27037):

Gli attori che intervengono sulla scena del crimine informatico, dovranno garantire i seguenti principi comuni alla maggior parte dei sistemi giurisdizionali internazionali:

Rilevanza/Pertinenza (Relevance): secondo cui bisogna dimostrare di aver acquisito e/o repertato solo elementi di pertinenza con il contesto d’indagine, avendo cura di motivarne le ragioni.

Affidabilità/Attendibilità (Reliability): secondo cui ogni processo che caratterizza la scena del crimine informatico dovrebbe essere verificabile e ripetibile. L’attuazione di tali processi dovrebbe garantire l’intera riproducibilità dell’attività tecnico-investigativa.

Sufficienza/Proporzionalità (Sufficiency): in cui il DEFR si assicura di avere a disposizione sufficiente materiale su cui svolgere le indagini.

I requisiti:

Verificabilità (Auditability): secondo cui dovrebbe essere possibile per una parte terza, indipendente alla componente di Polizia Giudiziaria ed autorizzata dall’A.G. (es. il Consulente Tecnico), poter accertare tutte le attività poste in essere sia dal DEFR che dal DES sulla scena del crimine informatico.

Ripetibilità (Repeatability): secondo cui si producono gli stessi risultati con lo stesso test nello stesso ambiente.

Riproducibilità (Riproducibility): secondo cui si producono gli stessi risultati al variare sia dell’ambiente che degli strumenti.

Giustificabilità (Justifiability): secondo cui il DEFR dovrebbe essere in grado di poter giustificare la metodologia attuata per quel particolare contesto investigativo caratterizzato da vincoli giuridici, tecnologici e logistici, oltreché di competenze tecniche dello stesso operatore.

Hashing

Nel linguaggio scientifico, l’hash (ISO/IEC 10118-3:2018) è una funzione «one way», ossia che non può essere invertita, atta alla trasformazione di un testo di lunghezza arbitraria in una stringa di lunghezza fissa, relativamente limitata.

Tale stringa rappresenta una sorta di «impronta digitale» (o «sigillo elettronico») del contenuto di un file, e viene comunemente denominata come:

codice di hash;
checksum crittografico;
message digest.

Il codice hash, riportato nel report del Forensic Container, fa riferimento al contenuto informativo del dispositivo acquisito e non al container stesso.

Tipi di acquisizione

Acquisizione manuale: consiste nella documentazione realizzata mediante rilievi descrittivi e tecnici (foto e video)

Acquisizione logica: consente di estrarre dati allocati e che sono accessibili tipicamente tramite:

API del sistema operativo (c.d. logica semplice);
File system (c.d. logica avanzata).

Sono da considerarsi dati allocati tutti quelli non cancellati ed accessibili tramite file system.

Un’eccezione a questa definizione è che alcuni file, come ad esempio un database SQLite, possono essere assegnate e ancora contengono record eliminati nel database.

Siamo in grado di eseguire due tipi di acquisizione logica:

semplice, che viene effettuata per mezzo di una acquisizione selettiva sui dati specifici dell’area utente (ad esempio contatti, agenda, registri chiamate e così via). Il risultato di questo tipo di acquisizione è simile a sistemi di backup (ad esempio iTunes, Kies, …) che usano le API specifiche e non ha bisogno di privilegi amministrativi;
avanzata (o del file system), che necessita il più delle volte di privilegi amministrativi, in quanto consente di estendere il suo raggio di azione non soltanto ad ristretto numero di file, ma ad una o più partizioni di un volume.

Acquisizione fisica: un’acquisizione c.d. «fisica» fornisce l’accesso integrale al contenuto informativo del supporto di memorizzazione, consentendo così di recuperare anche i dati non più allocati (cancellati o obsoleti) e ottenere un dump esadecimale.

Tali tecniche possono essere attuate tramite soluzioni:

software, i quali vengono eseguiti con privilegi amministrativi al fine di ottenere un’estrazione integrale dei dati presenti nella memoria di massa;
hardware, che consistono in un collegamento o estrazione fisica della memoria di massa.

La vera difficoltà di questa tipologia di acquisizione consiste nel riuscire a decodificare, e quindi ricostruire, i dati acquisiti.

In ambito di accertamenti tecnici può accadere che quella che è considerata un’attività ripetibile, spesso non lo è in termini giuridici

La disciplina normativa sugli atti non ripetibili (art. 360 c.p.p. ed art. 117 disp. att. c.p.p.) tende a:

evitare che le prove “urgenti” vengano disperse;
garantire il rispetto del principio del contraddittorio (art. 111 Cost.);

Presupposti:

indifferibilità = ora o mai più (art. 354 c.p.p.) “se non lo fai subito non lo puoi più fare”, cioè l’inerzia la prova andrebbe comunque dispersa;
non reiterabilità = ora e mai più (art. 360 c.p.p.) “se lo fai non lo puoi più fare”, cioè l’attività che si compie comporta, necessariamente o con un’elevata probabilità, l’alterazione o la distruzione della fonte di prova.

dd vs dcfldd vs dc3dd

Un “prontuario” pratico su dd, dcfldd e dc3dd per l’uso in digital forensics: differenze, buone prassi e comandi pronti all’uso.

Cos’è e cosa cambia

dd (GNU coreutils)

Strumento standard Unix/Linux per copiare e convertire file, ma privo di funzionalità avanzate come il calcolo di checksum multipli, più file di output o una modalità di verifica. In pratica:

copia byte-per-byte da/un device o file (immagini “raw” .dd);
è ovunque (Linux, macOS, molti live-CD);
fa poche cose, bene: per hashing, split, log ecc. bisogna usare altri tool (es. sha256sum, split, pv).

dcfldd (forensic dd)

dcfldd è un fork avanzato di dd, sviluppato dal Dipartimento della Difesa degli Stati Uniti per scopi di informatica forense. Le differenze chiave sono che dcfldd offre la possibilità di specificare più file di output, calcola checksum multipli simultaneamente, include una modalità di verifica per confrontare file e visualizza una percentuale di avanzamento del processo, tutte funzionalità non disponibili in dd. Quindi, in pratica:

hashing on-the-fly (hash=sha256/sha1/md5/sha512) con salvataggio automatico (hashlog=);
log degli errori e dei settori danneggiati (errlog=);
progress/stato periodico (statusinterval=);
split automatico in chunk forensi (ofsplit=) e output multipli (più of= nella stessa acquisizione);
verifica post-acquisizione contro l’originale (vf=/verifyfile=);
pattern write (es. bonifica con pattern=00) — utile per sanificare dischi di destinazione, non per l’evidenza.

In breve: dd è minimale e universalmente disponibile; dcfldd riduce gli errori operativi e velocizza le procedure forensi (hash, log, split, verifica) in un solo passaggio.

Buone prassi prima di acquisire

Write-blocker hardware (preferibile). Se non disponibile, montare read-only:

# 1) Elenca dischi con flag RO
lsblk -o NAME,RO,SIZE,TYPE,MODEL,SERIAL

# 2) Imposta sola lettura (sul device intero, non sulla partizione)
sudo blockdev --setro /dev/sdX

# 3) Verifica che sia in sola lettura (1 = RO abilitato)
sudo blockdev --getro /dev/sdX

# 4) Rivedi lo stato
lsblk -d -o NAME,RO,SIZE,MODEL,SERIAL
----
Per tornare R/W:
sudo blockdev --setrw /dev/sdX

Identifica il device giusto e fotografa lo stato: sudo fdisk -l /dev/sdX
Prepara la cartella di caso con naming coerente (case ID, data ISO, operatore).
Registra in un log: modello/seriale supporto, hash pre/post, tool/parametri, orari, errori e contromisure.

Esempi con dd (baseline)

1) Acquisizione raw con gestione errori e progresso

sudo dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync status=progress iflag=fullblock

conv=noerror,sync: ignora errori di lettura e riempie con zeri per mantenere allineamento;
iflag=fullblock: evita letture parziali (utile con pipe/stream);
status=progress: barra di avanzamento (GNU dd).

2) Hash post-acquisizione (consigliato SHA-256)

cd /evidence/Caso123
sha256sum disk.dd | tee disk.dd.sha256.txt

Esempi con dcfldd (forensic-friendly)

1) Acquisizione + hash on-the-fly + log

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  errlog=/evidence/Caso123/dcfldd.errors.log \
  statusinterval=30

un unico passaggio produce immagine + hash + log errori;
statusinterval=30: stampa stato ogni 30 s.

2) Doppia destinazione (originale + copia di lavoro)

sudo dcfldd if=/dev/sdX \
  of=/evidence/Caso123/disk.dd \
  of=/lab/Caso123/disk_working.dd \
  bs=4M conv=noerror,sync \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  errlog=/evidence/Caso123/dcfldd.errors.log \
  statusinterval=30

Riduce l’eventuale rischio di divergenze tra “master” e “working copy” in caso di dispositivi danneggiati.

3) Split automatico in chunk (es. 2 GiB) per storage/FAT32

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=4M conv=noerror,sync \
  ofsplit=2G \
  hash=sha256 hashlog=/evidence/Caso123/disk.dd.sha256.txt \
  statusinterval=30
# Ricomposizione:
cat /evidence/Caso123/disk.dd.* > /restore/disk.dd

4) Verifica che immagine e device coincidano

# A freddo, con il device ancora in sola lettura:
sudo dcfldd if=/dev/sdX vf=/evidence/Caso123/disk.dd \
  hash=sha256 statusinterval=30

vf= (verify file) confronta i flussi (utile anche dopo trasferimenti/copie disk).

5) Log dettagliato dei settori danneggiati

sudo dcfldd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  bs=512 conv=noerror,sync \
  errlog=/evidence/Caso123/badsectors.log \
  statusinterval=30

Con bs=512 ottieni il dettaglio settore-per-settore (più lento ma più preciso per i bad blocks).

Note operative e suggerimenti

Dimensione blocco (bs): 4M è un buon compromesso prestazioni/affidabilità. Per supporti instabili puoi scendere (1M o 512B) per aumentare la granularità dei retry/riempimenti;
cache OS: in alcuni contesti si usa oflag=direct/iflag=direct per bypassare la cache. Verifica che il tuo dd li supporti e valuta l’impatto sulle performance;
formati: dd/dcfldd producono RAW. Se il tuo flusso richiede E01/Ex01 (metadata + compressione + segmentazione nativa), usa gli strumenti libewf (ewfacquire) in alternativa;
conservazione: mantieni master immodificato; lavora sempre su una working copy verificata e documenta ogni passaggio;
sanificazione dei dischi di destinazione prima del riuso (non dell’evidenza!): # Esempio: azzera un disco di DESTINAZIONE sudo dcfldd if=/dev/zero of=/dev/sdY bs=4M pattern=00 statusinterval=30
ambienti non Linux: su Windows è comune operare da live Linux o appliance forense. In alternativa, considera tool dedicati (FTK Imager, ecc.) quando la policy lo consente.

Mini “cheat-sheet”

dd, acquisizione rapida + progress dd if=/dev/sdX of=case/img.dd bs=4M conv=noerror,sync status=progress iflag=fullblock sha256sum case/img.dd > case/img.dd.sha256.txt
dcfldd, acquisizione completa (hash+log) dcfldd if=/dev/sdX of=case/img.dd bs=4M conv=noerror,sync \ hash=sha256 hashlog=case/img.dd.sha256.txt errlog=case/errors.log statusinterval=30
dcfldd, split + doppia uscita + verifica dcfldd if=/dev/sdX of=case/img.dd of=/backup/img.dd \ ofsplit=2G bs=4M conv=noerror,sync \ hash=sha256 hashlog=case/img.dd.sha256.txt statusinterval=30 dcfldd if=/dev/sdX vf=case/img.dd hash=sha256 statusinterval=30

Cos’è dc3dd

dc3dd è una versione di dd patchata dal DoD Cyber Crime Center (DC3) pensata per la forensics. Aggiunge funzioni native come hashing on-the-fly (MD5/SHA-1/SHA-256/SHA-512), log dettagliati (anche machine-readable), split in segmenti, progress, error-logging raggruppato e funzioni di wipe/verify.

In più, a differenza di dcfldd (che è un fork), dc3dd è una patch di dd: in linea di massima segue gli aggiornamenti di dd e ha un set di opzioni diverso (non 1:1 con dcfldd).

Differenze chiave (dd vs dcfldd vs dc3dd)

dd (baseline): minimale e ovunque; per hash/split/log serve combinarlo con altri tool.
dcfldd (fork): pensato per DFIR; hash=… + hashlog=…, errlog=…, ofsplit=…, vf= per verifica contro l’originale; output multipli ripetendo of=.
dc3dd (patch): comandi e nomi opzioni propri:
Hashing: hash=md5|sha1|sha256|sha512; log in log= e/o hlog= (totali e piecewise), mlog= per log “machine-readable”.
Split: usa set di file con ofs=BASE.FMT + ofsz=BYTES (es. estensioni 0000, 0001, …); diverso da ofsplit= di dcfldd.
Output multipli & verifica: oltre a of= puoi usare hof=/hofs=: l’output viene hashato e verificato confrontando gli hash in/out; fhod= estende l’hash a tutto il device.
Error handling: di default, se l’input è un device, riempie di zeri i settori illeggibili; con rec=off si ferma al primo errore. (In dd/dcfldd l’equivalente pratico è conv=noerror,sync.)
Wipe/sanitize: wipe=/dev/sdY (zerofill o pattern), hwipe= con verifica post-wipe; puoi impostare pattern con pat=/tpat=.
Tuning: ssz= forza la sector size; bufsz= regola il buffer I/O per performance; verb=on per report verboso.

Esempi pratici con dc3dd (DFIR)

1) Imaging + hash + log (singolo file)

sudo dc3dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  hash=sha256 log=/evidence/Caso123/logs/dc3dd.log \
  hlog=/evidence/Caso123/logs/dc3dd.hashlog

Calcola SHA-256 on-the-fly e scrive log e hash (totali + piecewise).

2) Split in chunk da 2 GiB (naming automatico)

sudo dc3dd if=/dev/sdX ofs=/evidence/Caso123/disk.dd.0000 \
  ofsz=2G hash=sha256 \
  log=/evidence/Caso123/logs/dc3dd.log hlog=/evidence/Caso123/logs/dc3dd.hashlog

Usa ofs=BASE.FMT (qui 0000) e ofsz=2G per segmentare in disk.dd.0000, 0001, …

3) Master + working copy con verifica automatica

sudo dc3dd if=/dev/sdX \
  of=/evidence/Caso123/disk_master.dd \
  hof=/lab/Caso123/disk_working.dd \
  hash=sha256 log=/evidence/Caso123/logs/dc3dd.log hlog=/evidence/Caso123/logs/dc3dd.hashlog

hof= produce una copia con calcolo e verifica dell’hash rispetto all’input nella stessa passata.

4) Acquisizione con dischi “difficili” (settori e buffer)

sudo dc3dd if=/dev/sdX of=/evidence/Caso123/disk.dd \
  hash=sha256 ssz=512 bufsz=1M log=/evidence/Caso123/logs/dc3dd.log

Forza sector size a 512 B e limita il buffer per aumentare la resilienza su device instabili.

5) Sanificazione del disco di destinazione (non dell’evidenza!)

# Zero-fill con verifica
sudo dc3dd hwipe=/dev/sdY

# Wipe con pattern 0x00 (senza verifica)
sudo dc3dd wipe=/dev/sdY pat=00

Utile per preparare/bonificare i supporti di destinazione prima del riuso.

Quando preferirlo

Vuoi split flessibile con naming prevedibile (ofs + ofsz) e verifica integrata sugli output (hof/hofs).
Cerchi log ricchi (anche piecewise e machine-readable via mlog=) direttamente dal tool.

Note operative

Come per dcfldd, mantieni master e working copy separati e documenta hash/log nel fascicolo.
Puoi sostituire dcfldd con dc3dd mantenendo le stesse prassi (hash, split, log), adattando però i nomi opzione (ofsplit → ofs+ofsz, hashlog → hlog, verifica: vf → hof/hofs).

Confronto operativo (dd vs dcfldd vs dc3dd)

Attività / Feature	dd (baseline)	dcfldd (forensic fork)	dc3dd (patch DC3)
Imaging RAW	`dd if=/dev/sdX of=img.dd bs=4M conv=noerror,sync status=progress`	`dcfldd if=/dev/sdX of=img.dd bs=4M conv=noerror,sync statusinterval=30`	`dc3dd if=/dev/sdX of=img.dd`
Hash on-the-fly	— (usa `sha256sum` dopo)	`hash=sha256 hashlog=img.sha256.txt`	`hash=sha256 hlog=hashes.txt` (+ `log=` opzionale)
Log dettagliati	reindirizza std{out,err}	`errlog=errors.log` + output stato	`log=dc3dd.log` (testuale), `mlog=machine.log` (machine-readable)
Split immagine	esterno: `split -b 2G`	`ofsplit=2G` → `img.dd.000`, `.001`…	`ofs=img.dd.0000 ofsz=2G` → `.0000`, `.0001`…
Doppia uscita in una passata	— (fai copia dopo)	ripeti più `of=` nella stessa riga	`hof=working.dd` (output con hash & verifica)
Verifica contro sorgente	esterno: ricalcolo hash	`vf=img.dd`	con `hof=` verifica automaticamente la corrispondenza degli hash
Gestione settori danneggiati	`conv=noerror,sync`	`conv=noerror,sync`	riempie con zeri per default; puoi cambiare politica (fermarsi al primo errore)
Wipe/sanitize (solo dischi di destinazione)	`dd if=/dev/zero of=/dev/sdY`	`pattern=00` su destinazione	`wipe=/dev/sdY` (o `hwipe=` con verifica post-wipe)

Regola pratica: dd = portabilità + minimalismo; dcfldd = “tutto-in-uno” semplice (hash/log/split/verify); dc3dd = control-freak con log ricchi, split robusto e verifica integrata dell’output (hof).

Esempi pratici

1) Imaging con hash e log

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk.dd bs=4M conv=noerror,sync \
  hash=sha256 hashlog=case/logs/disk.sha256.txt errlog=case/logs/errors.log \
  statusinterval=30

dc3dd

sudo dc3dd if=/dev/sdX of=case/disk.dd \
  hash=sha256 hlog=case/logs/dc3dd.hashlog log=case/logs/dc3dd.log

2) Split a 2 GiB

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk.dd ofsplit=2G \
  hash=sha256 hashlog=case/logs/disk.sha256.txt
# join:  cat case/disk.dd.* > case/disk.dd

dc3dd

sudo dc3dd if=/dev/sdX ofs=case/disk.dd.0000 ofsz=2G \
  hash=sha256 hlog=case/logs/dc3dd.hashlog
# join:  cat case/disk.dd.0* > case/disk.dd

3) Master + working copy, una sola passata

dcfldd

sudo dcfldd if=/dev/sdX of=case/disk_master.dd of=lab/disk_working.dd \
  hash=sha256 hashlog=case/logs/disk.sha256.txt

dc3dd (con verifica integrata dell’output)

sudo dc3dd if=/dev/sdX of=case/disk_master.dd \
  hof=lab/disk_working.dd \
  hash=sha256 hlog=case/logs/dc3dd.hashlog log=case/logs/dc3dd.log

4) Bonifica del destinazione (non dell’evidenza!)

dcfldd

sudo dcfldd if=/dev/zero of=/dev/sdY bs=4M pattern=00 statusinterval=30

dc3dd

sudo dc3dd hwipe=/dev/sdY    # wipe + verifica
# oppure:
sudo dc3dd wipe=/dev/sdY     # wipe senza verifica

“Option mapping” veloce

Hashing

dd → sha256sum img.dd > img.dd.sha256.txt (post-acq)
dcfldd → hash=sha256 hashlog=FILE
dc3dd → hash=sha256 hlog=FILE (+ log=/mlog=)

Split

dd → split -b 2G img.dd img.dd.
dcfldd → ofsplit=2G → img.dd.000, .001…
dc3dd → ofs=img.dd.0000 ofsz=2G → .0000, .0001…

Doppia uscita

dd → cp/rsync dopo
dcfldd → più of= nella stessa riga
dc3dd → hof= / hofs= (con hashing/verifica)

Verifica

dd → ricalcolo hash device vs file
dcfldd → vf=img.dd
dc3dd → con hof= l’output è verificato contro l’input

Errori lettura

dd / dcfldd → conv=noerror,sync
dc3dd → default riempie gli errori con zeri; modalità “stop on first error” selezionabile