A cura di Alessio Cuomo

Nel lavoro quotidiano di chi si occupa di Digital Forensics e Incident Response, una delle domande ricorrenti è sempre la stessa: cosa è successo, e in quale ordine?

La Timeline Analysis nasce proprio per rispondere a questo interrogativo, trasformando una moltitudine di tracce digitali sparse in una ricostruzione temporale coerente, verificabile e tecnicamente sostenibile.

In contesti di incident response, la timeline permette di comprendere la dinamica di un attacco, individuarne l’origine, seguirne l’evoluzione e delimitare l’impatto reale sull’organizzazione. In ambito di perizia informatica, invece, diventa uno strumento centrale per la ricostruzione dei fatti, il confronto con le dichiarazioni delle parti e la valutazione delle responsabilità.

Questo articolo propone una panoramica della timeline analysis, pensata per professionisti di analisi di incidenti informatici e consulenti tecnici di informatica forense, che tramite una ricostruzione chiara degli eventi temporali riescono a esplicare in modo semplice e diretto gli avvenimenti accaduti anche ad un interlocutore poco avvezzo in questo campo tecnico.

Partendo dalle basi concettuali, verranno analizzate le principali tipologie di timeline, le criticità metodologiche più comuni e l’utilizzo di strumenti consolidati come log2timeline/Plaso, con esempi concreti prevalentemente riferiti a sistemi Windows.

Cos’è una timeline

In informatica forense, una timeline è una rappresentazione strutturata degli eventi ordinati nel tempo, costruita a partire da metadati. Ogni evento non è semplicemente una data e un’ora, ma l’espressione temporale di un’azione: l’esecuzione di un programma, la creazione di un file, un accesso utente, una connessione di rete.

Il valore della timeline non risiede nella mera sequenza cronologica, bensì nella possibilità di correlare eventi provenienti da fonti diverse, evidenziando relazioni causali, sovrapposizioni sospette o assenze significative.

In altre parole, la timeline è uno strumento di analisi, non solo di rappresentazione.

La costruzione di una timeline affidabile si fonda sulla corretta interpretazione delle fonti informative disponibili. Nei sistemi Windows, queste fonti sono numerose e spesso complementari.

Dati e metadati alla base della costruzione di una timeline

Timestamp

Il primo punto di partenza per costruire una timeline riguarda la corretta interpretazione dei timestamp. Nei sistemi Windows, si parte quasi sempre dal file system. Il file system è il modo in cui il sistema operativo organizza e tiene traccia dei file archiviati all’intero del dispositivo informatico, conservando, tra i tanti dati, i riferimenti temporali comunemente noti come MACB:

• M (Modified): indica l’ultima modifica al contenuto del file;
• A (Accessed): indica l’ultimo accesso in lettura. Nei sistemi moderni questo valore è spesso disabilitato per ottimizzare le prestazioni, rendendolo poco affidabile;
• C (Changed): si riferisce al cambiamento dei metadati nella Master File Table (MFT), come i permessi o il nome del file;
• B (Birth/Created): indica il momento della creazione del file sul volume corrente. Questo timestamp viene registrato solo nei file system di tipo NTFS.

Il poster SANS “Windows Forensic Analysis” ben descrive come interpretare gli eventi che scaturiscono la modifica dei timestamp MACB.

I timestamp quindi, permettono di ricostruire l’evoluzione di un file nel tempo, ma non devono mai essere interpretati in modo isolato, poiché possono essere influenzati da operazioni legittime del sistema operativo o manipolati deliberatamente.

Per questo motivo, chi svolge analisi forense deve sempre incrociare i dati del file system con altre fonti meno soggette a manipolazione. Una di queste fonti può essere sicuramente identificata nei log di sistema e di sicurezza.

Windows Event Log

I Windows Event Log (file .evtx) rappresentano la cosiddetta “scatola nera” del sistema operativo.

Mentre i timestamp MACB permettono di identificare quando un file è stato “toccato”, gli Event Log permettono di capire chi ha eseguito una operazione e come questa sia stata eseguita.

Questi forniscono informazioni dettagliate su avvii, arresti, autenticazioni, errori applicativi ed eventi di sicurezza.

Quando disponibili e integri, costituiscono una delle fonti più affidabili per l’analisi temporale, grazie alla loro natura esplicita e strutturata.

Tra quelli più importanti troviamo sicuramente:

• Security.evtx: contiene i log di autenticazione (login/logout), l’uso di privilegi e i tentativi di accesso alle risorse;
• System.evtx: registra gli avvii, gli arresti del sistema e le installazioni dei servizi;
• Application.evtx: fornisce dettagli sugli errori applicativi e sul comportamento dei software installati.

Artefatti di sistema

Oltre ai log, Windows genera e conserva automaticamente “artefatti” che riflettono il comportamento dell’utente e del sistema stesso.

Questi diventando di fondamentale importanza quando i log contenuti all’interno dei file .evtx sono incompleti oppure sono stati cancellati.

Tra i vari artefatti creati dal sistema operativo, quelli sicuramente più importanti e utili alla costruzione di una time line sono:

• LNK file e JumpList: mostrano quali file sono stati aperti di recente dall’utente, fornendo il contesto umano dietro l’attività tecnica;
• Prefetch file e Amcache: tengono traccia dell’esecuzione dei programmi installati all’interno del dispositivo oppure traccia dell’esecuzione da dispositivi removibili come chiavette USB. Il Prefetch, che ha il compito principale di velocizzare l’avvio delle applicazioni, tiene traccia della data di ultima esecuzione, mentre l’Amcache fornisce dettagli ancora più specifici, come il percorso completo del programma avviato e l’hash SHA1 dell’eseguibile, molto utile per individuare malware che sono stati rinominati con denominazioni generiche;
• Registry Hive (Registro di Sistema): conserva tracce di dispositivi USB collegati, reti Wi-Fi a cui ci si è connessi e programmi configurati per l’esecuzione automatica.

Simulando un esempio pratico, nel caso in cui gli Event Log dovessero venire a mancare, è comunque possibile ricostruire buona parte degli avvenimenti nel seguente modo:

Artefatto	Ora	Evento
LNK	10:01	viene creato un collegamento per copia_silenziosa.exe
Amcache/Prefetch	10:02	copia_silenziosa.exe viene eseguito per la prima volta
Registry (USBSTOR)	10:05	viene inserita la chiavetta USB “Kingston”
LNK	10:06	accesso al file E:\esfiltrazione.zip sulla chiavetta

Come riportato in tabella, anche se gli eventi di sistema (Event Log) dovessero venire a mancare poiché cancellati manualmente, tramite gli artefatti creati automaticamente dal sistema operativo Windows è possibile comunque ricostruire parte degli eventi accaduti.

Tipologie di timeline e differenze operative

Nell’ambito forense non esiste un’unica timeline ideale per qualsiasi tipo di evenienza. Esistono invece diverse tipologie di timeline, ciascuna con un obiettivo analitico specifico.

La timeline basata sul file system (Timestamp), come abbiamo visto, è spesso il punto di partenza.

La timeline basata sui timestamp del file system fornisce una visione ampia delle modifiche avvenute su un supporto di memorizzazione, ma soffre di limiti evidenti in termini di contesto e affidabilità. Questo tipo di timeline è utile quando si vuole eseguire uno screening rapido delle modifiche accadute.

Le timeline basate sugli eventi (Windows Event Log), costruite a partire da log e artefatti strutturati, offrono una precisione maggiore e una migliore interpretabilità. Consentono di rispondere a domande del tipo “chi ha fatto cosa e quando”, ma dipendono fortemente dalla disponibilità delle fonti.

Un livello ulteriore è rappresentato dalle timeline di attività dell’utente (artefatti), che mirano a ricostruire il comportamento umano dietro agli eventi tecnici. Questo tipo di timeline è particolarmente rilevante nelle perizie informatiche e nei casi insider threat, ossia quando qualcuno legato all’azienda sfrutta i propri privilegi di accesso per compromettere i sistemi e le informazioni sensibili dell’azienda stessa.

La forma più completa è la “super timeline”, che integra file system, event log, artefatti, cronologia browser web e molti altri eventi in un’unica vista normalizzata. Data la grande mole di dati che si vanno a considerare, è ovviamente anche la timeline più complessa da costruire e interpretare, ma allo stesso tempo quella più autorevole poiché consente di individuare incongruenze temporali e rafforzare le conclusioni investigative.

Quindi, se ad esempio si costruisse una timeline basata solo sui timestamp MACB, si avrebbe un risultato del genere.

Tuttavia, come spiegato questo tipo di timeline è utile solo per una prima analisi superficiale. L’analista forense ha bisogno di una super timeline per ricostruire con la maggiore precisione possibile il susseguirsi degli avvenimenti. In questo caso, il risultato che si otterrebbe sarebbe come quello riportato di seguito.

Problemi e insidie della timeline analysis

Analizzare la successione degli eventi è molto utile, ma bisogna fare attenzione. Un errore frequente è fidarsi ciecamente delle date e degli orari che troviamo. Questi, infatti, possono essere sbagliati per tanti motivi: impostazioni errate del fuso orario o dell’ora legale, orologi dei computer non precisi, oppure perché qualcuno ha alterato le date intenzionalmente per nascondere le proprie tracce. Ma anche perché possono essere corretti ma fuorvianti a una lettura di un analista poco attento.

Uno dei più grandi errori riguarda proprio i fusi orari. Prima di procedere all’analisi degli eventi individuati infatti, bisogna procedere alla normalizzazione degli orari. Questi, vanno tutti normalizzati ad un unico fuso orario (spesso si sceglie l’UTC) così da non sbagliarsi nell’ordine cronologico dell’avvenimento degli eventi.

Ulteriore insidia, come già accennato precedentemente è il Timestomping. Questa è una delle tecniche più insidiose e diffuse, finalizzata a sviare le indagini manipolando deliberatamente i riferimenti temporali di file o artefatti. Nella creazione di una timeline, questa pratica punta a rompere la coerenza logica degli eventi, facendo apparire un file malevolo come se fosse presente nel sistema da anni o nascondendo attività eseguite di recente da un utente o un’applicazione.

Il Timestomping agisce solitamente sui timestamp MACB (Modified, Accessed, Created, Birth) del file system con lo scopo di sovrascrivere i valori temporali dei file digitali con date arbitrarie o copiate da file di sistema legittimi, così da far “mimetizzare” un attacco (malware) tra i file originali.

I timestamp MACB sono salvati in due attributi distinti presenti all’interno dello stesso record della MFT, ossia $STANDARD_INFORMATION ($SI) e $FILE_NAME ($FN).

All’interno di $SI si trovano i timestamp che si vedono banalmente quando, cliccando con il tasto destro del mouse sopra un file si sceglie l’opzione per mostrarne le proprietà. Questo contiene tutti e quattro i valori MACB, tuttavia, essendo facilmente manipolabile è soggetto spesso alle tecniche do Time Stomping.

L’attributo $FN invece, oltre a contenere il nome del file, conserva anche una propria copia dei timestamp MACB. In questo caso, i timestamp contenuti al suo interno sono aggiornati dal kernel, rendendo la modifica degli stessi molto più difficile per un utente.

Poiché la maggior parte dei tool di manipolazione agisce solo sull’attributo $SI, è fondamentale eseguire il confronto tra i due attributi. Se i timestamp di $SI mostrano una data vecchia ma quelli di $FN mostrano una data recente, si ha la prova tecnica che è stato effettuato un Time Stomping.

Un’altra insidia è la presenza di eventi mancanti. Log ruotati, cancellati o mai generati possono creare vuoti temporali che non devono essere interpretati automaticamente come assenza di attività. In ambito forense è fondamentale distinguere tra assenza di evidenza ed evidenza di assenza.

Esiste poi il rischio di una eccessiva fiducia negli strumenti automatici. La generazione di una timeline non equivale alla sua analisi: senza contesto, correlazione e spirito critico, una timeline può risultare fuorviante o addirittura errata.

Plaso e log2timeline: supporto operativo alla generazione di timeline

Plaso (Pluggable Log Analyzer) è uno degli strumenti più utilizzati per la creazione di super timeline (o timeline multi-sorgente). Il suo componente principale, log2timeline, consente di estrarre eventi temporali da un’ampia varietà di fonti, in particolare da sistemi Windows.

Dal punto di vista operativo, log2timeline analizza un’immagine forense o una directory, identifica automaticamente i file rilevanti (Windows Event Log, Registry Hive, artefatti di sistema) e ne estrae gli eventi temporali, normalizzandoli in un formato comune (solitamente in UTC). Il risultato è una timeline strutturata, interrogabile e filtrabile.

Il funzionamento di Plaso si divide generalmente in tre fasi ognuna gestita da uno specifico tool.

Per la fase di estrazione viene utilizzato il tool log2timeline.py. Questo strumento analizza le sorgenti di dati grezzi, come immagini forensi, cartelle o singoli file, ed estrae gli eventi temporali attraverso specifici moduli di analisi chiamati parser.

Plaso mette a disposizione numerosi parser specializzati, ad esempio per file LNK, MFT, artefatti dei browser web, registri di sistema e altri formati noti. Oltre ai parser individuali, sono disponibili anche preset di parser progettati per determinati ambienti o scenari operativi, che consentono di automatizzare e ottimizzare l’estrazione degli eventi più rilevanti per il contesto di analisi.

Finita l’estrazione dei dati, questi vengono salvati all’interno di un database proprietario con estensione .plaso.

 Successivamente alla fase di estrazione vi è la fase di verifica. Questa viene eseguita tramite il tool “pinfo.py” che permette di ispezionare quali parser sono stati usati, quanti eventi sono stati estratti e se sono stati generati errori in fase di estrazione. Un esempio tipico di verifica di un database .plaso ottenuto dall’estrazione dati è il seguente.

Infine, vi è la fase di elaborazione e output di quanto estratto tramite log2timeline.py. In questa fase viene utilizzato il tool “psort.py” che permette di filtrare, ordinare e convertire i dati dal database .plaso in formati leggibili come CSV, Excel oppure JSON.

In questo modo, l’’analista può filtrare per intervallo temporale, tipo di evento o fonte, riducendo drasticamente il rumore informativo.

È importante sottolineare che Plaso non “interpreta” gli eventi: fornisce una base solida su cui l’analista costruisce successivamente le proprie conclusioni. In questo senso, lo strumento amplifica le capacità dell’analista, ma non lo sostituisce.

Esempi concreti di utilizzo

La generazione e l’uso di una timeline trova la sua massima efficacia quando applicata a scenari reali. Di seguito, quindi, viene presentato un caso concreto in cui la correlazione temporale fa la differenza tra un’ipotesi e una certezza forense. L’esempio in oggetto tratta il tipico caso denominato Insider Threat mirato al furto di proprietà intellettuale. Di seguito lo scenario:

Un dipendente di un’azienda A si dimette per passare all’azienda concorrente B. L’azienda A sospetta che il lavoratore dimissionario abbia sottratto progetti riservati al fine di portarli e riutilizzarli presso l’azienda B, ma un’analisi superficiale del computer utilizzato durante gli anni di lavoro mostra solo che i file sono stati aperti e consultati (attività giustificabile con il normale lavoro) senza rilevare altri tipi di condotte.

Tramite la ricostruzione degli eventi, incrociando i log di sistema, il registro e gli artefatti del file system, si riesce a generare una super timeline che rivela una sequenza di azioni che dimostra il quadro completo riguardo l’intenzionalità dell’esfiltrazione dei dati.

Ora (UTC)	Fonte	Evento	Interpretazione
09:15:02	Registro di sistema	Device Connected: “SanDisk Ultra 64GB”	Viene inserita una chiavetta USB mai vista prima sul sistema aziendale
09:15:08	Log di sistema	Driver installed for USB Mass Storage	Conferma che il dispositivo è operativo
09:16:30	LNK File	Access to “C:\Projects\Secret_Blueprint.pdf”	L’utente apre il file riservato dal disco locale
09:16:35	File System	File Create: “D:\Secret_Blueprint.pdf”	Un file con lo stesso nome viene creato sull’unità D: (la chiavetta USB)
09:18:22	Log di sistema	Device Eject	La chiavetta viene rimossa in sicurezza.
09:20:14	Prefetch	Execution of “CCleaner.exe”	L’utente lancia un software di pulizia subito dopo la copia, un comportamento anomalo che suggerisce la volontà di cancellare le tracce.

Senza la timeline, o con una basata solo sui timestamp MACB, l’analista forense avrebbe visto solo l’apertura del file (lecito) a cui il dipendente era autorizzato ad accedere. Con la super timeline invece, combinando molteplici eventi generati all’interno del sistema operativo, l’analista è in grado di ricostruire con maggiore dettaglio gli avvenimenti del dipendente malintenzionato così da ottenere la prova della connessione di un device esterno, della copia contestuale e del tentativo di cancellazione massiva.

Il supporto di BIT4LAW nell’analisi forense nell’analisi per timeline

La timeline analysis non è una semplice tecnica di supporto, ma un vero e proprio metodo di ragionamento forense. Se utilizzata correttamente, consente di trasformare dati grezzi e apparentemente scollegati in una ricostruzione strutturata degli eventi, utile tanto nella gestione di un incidente di sicurezza quanto nella redazione di una perizia informatica.

La sua efficacia dipende dalla qualità delle fonti disponibili, dalla consapevolezza delle insidie legate ai timestamp e, soprattutto, dalla capacità dell’analista di interpretare criticamente gli eventi nel loro contesto. Gli strumenti automatici, come Plaso, offrono un grande aiuto agli analisti forensi, ma non sostituiscono comunque il giudizio umano.

In un’epoca in cui gli eventi digitali hanno conseguenze sempre più rilevanti sia sul piano legale che economico e reputazionale, saper costruire e analizzare correttamente una timeline non è solo una competenza tecnica, ma una vera e propria responsabilità professionale.

[recent_post_slider limit=”5″]