Timeline forense e ricostruzione cronologica degli eventi

Introduzione

Una timeline forense non è un semplice foglio elettronico nel quale le date sono state ordinate dalla più antica alla più recente.

È una ricostruzione tecnica che deve spiegare:

• quale sistema abbia prodotto ogni timestamp;
• che cosa rappresenti quel timestamp;
• quale fuso orario fosse applicato;
• quale precisione possieda realmente;
• se l’orologio fosse corretto;
• se il record sia originario o derivato;
• se l’evento sia stato registrato in tempo reale o acquisito successivamente;
• quali eventi indipendenti confermino la stessa attività;
• quali conclusioni possano essere formulate;
• quali limiti impediscano un’interpretazione più forte.

Un cliente di Roma può chiedere:

“A che ora è stato copiato il file?”

La risposta potrebbe richiedere la correlazione di:

timestamp NTFS
        ↓
evento USB
        ↓
sessione utente
        ↓
record DLP
        ↓
file presente sulla pendrive
        ↓
log cloud
        ↓
orologio del computer

Un’azienda romana può chiedere:

“Qual è stato il primo sistema compromesso dal ransomware?”

La risposta può richiedere:

email
→ login
→ VPN
→ processo
→ connessione
→ creazione servizio
→ movimento laterale
→ accesso backup
→ cifratura

Un avvocato di Roma può chiedere:

“Il messaggio WhatsApp è stato inviato prima o dopo la telefonata?”

Per rispondere occorre distinguere:

• timestamp del database;
• timestamp del server;
• ora visualizzata nell’interfaccia;
• ora del sistema operativo;
• data del backup;
• eventuale modifica manuale dell’orologio;
• precisione e arrotondamento;
• fuso del dispositivo.

Il problema non è soltanto convertire un numero in una data.

Il problema è comprendere che cosa quel numero documenti.

Il NIST descrive la timeline analysis come un’attività interpretativa applicata a insiemi di timestamp e richiama espressamente il rischio di interpretare in modo errato eventi prodotti da un orologio inaccurato o di omettere tale possibilità nella relazione. Un singolo evento di alto livello, come il collegamento di una pendrive, può inoltre derivare dalla convergenza di numerosi record tecnici di livello inferiore. (NIST — An Abstract Model for Digital Forensic Analysis Tools)

Una ricostruzione corretta segue pertanto questa catena:

timestamp grezzo
→ semantica del campo
→ fonte
→ fuso
→ precisione
→ eventuale correzione
→ correlazione
→ evento ricostruito
→ conclusione prudente

Ordinare i valori senza eseguire questi passaggi può produrre una timeline apparentemente precisa ma tecnicamente errata.

Regola fondamentale: la posizione di un record nella timeline non dipende soltanto dal suo valore numerico, ma dalla semantica della fonte, dalla qualità dell’orologio e dal grado di incertezza associato.

Sintesi operativa

1. formalizzare quesito, periodo e sistemi interessati;
2. preservare le fonti prima della rotazione o cancellazione;
3. acquisire ora locale, UTC, fuso e stato di sincronizzazione;
4. identificare tutti gli orologi coinvolti;
5. conservare i timestamp nella forma originaria;
6. documentare formato, epoch, unità e precisione;
7. non sovrascrivere il valore grezzo durante la normalizzazione;
8. distinguere event time, ingest time, processing time ed export time;
9. distinguere istanti, intervalli e date prive di ora;
10. verificare ora legale e ambiguità del fuso;
11. misurare eventuale clock drift;
12. conservare offset e criterio di correzione;
13. acquisire file system, log, database, cloud e rete;
14. registrare per ogni fonte la semantica temporale;
15. creare identificativi univoci dei record;
16. normalizzare gli eventi in UTC;
17. mantenere una vista separata in Europe/Rome;
18. attribuire una classe di precisione e attendibilità;
19. deduplicare soltanto in dataset derivati;
20. correlare account, dispositivo, sessione, IP e oggetto;
21. distinguere record originari ed eventi dedotti;
22. cercare eventi ancora non spiegati;
23. documentare gap, retention e fonti mancanti;
24. verificare possibili alterazioni dei timestamp;
25. costruire una super timeline quando il caso lo richiede;
26. produrre mini-timeline mirate ai singoli quesiti;
27. utilizzare Plaso e Timesketch con versioni documentate;
28. verificare manualmente gli eventi decisivi;
29. evitare la falsa precisione;
30. formulare conclusioni proporzionate alle fonti.

1. Avvertenza preliminare

Le procedure descritte devono essere utilizzate esclusivamente:

• su sistemi propri;
• su dispositivi e account legittimamente amministrati;
• nell’ambito di un incarico professionale;
• con un perimetro definito;
• su copie forensi o raccolte autorizzate;
• nel rispetto della protezione dei dati personali;
• con conservazione proporzionata;
• senza alterare le fonti originarie.

Non è lecito utilizzare il capitolo per:

• accedere ad account di terzi;
• utilizzare credenziali sottratte;
• modificare gli orologi per creare una falsa cronologia;
• alterare timestamp;
• cancellare log;
• installare agenti occulti;
• raccogliere indiscriminatamente dati di tutti i dipendenti;
• accedere a cloud personali senza titolo;
• produrre ricostruzioni accusatorie prive di riscontri;
• presentare eventi dedotti come se fossero record originari.

Le timeline possono contenere email, messaggi, indirizzi IP, spostamenti, documenti, dati sanitari, attività dei dipendenti e informazioni riservate. Il GDPR richiede limitazione della finalità, minimizzazione, limitazione della conservazione e misure di sicurezza adeguate al rischio. (Regolamento UE 2016/679)

2. Che cos’è una timeline forense

Una timeline forense è una rappresentazione ordinata e documentata di eventi ricavati da fonti digitali.

Può comprendere:

- creazione e modifica di file;
- autenticazioni;
- processi;
- connessioni;
- messaggi;
- email;
- download;
- upload;
- installazioni;
- accessi fisici;
- attività cloud;
- acquisizioni;
- interventi del perito.

Può essere utilizzata per ricostruire una sequenza, delimitare un intervallo, verificare una dichiarazione, correlare fonti differenti, individuare lacune e distinguere attività automatica e interattiva.

Plaso è un motore Python progettato per estrarre automaticamente eventi da numerosi artefatti e creare timeline generali o mirate.

3. Evento, record, timestamp e deduzione

Questi termini non sono sinonimi.

Esempio:

evento reale:
un utente collega una pendrive;

record:
Windows configura il dispositivo;

timestamp:
2026-07-14T08:13:42.115+02:00;

correlazione:
SetupAPI + PnP + MountedDevices + sessione utente;

evento dedotto:
pendrive collegata durante la sessione dell’account X.

La relazione deve mantenere visibile la distinzione tra il record e la deduzione.

4. Tipi di timeline

Timeline della singola fonte

Contiene eventi provenienti da un solo sistema, per esempio Windows Event Log, firewall, WhatsApp, Microsoft 365 o file system.

Super timeline

Integra file system, registro, browser, email, log, cloud e dispositivi. Il concetto è centrale nel workflow Plaso.

Mini-timeline investigativa

È una selezione mirata degli eventi pertinenti a un quesito:

07:55 login
08:02 USB montata
08:06 archivio creato
08:09 file scritto
08:11 USB rimossa

Timeline dinamica

Viene aggiornata man mano che emergono nuove fonti.

Timeline di presentazione

Contiene gli eventi necessari per spiegare la ricostruzione al cliente, al legale o al giudice. Non sostituisce il dataset completo.

Timeline delle attività del perito

Documenta acquisizioni, login amministrativi, esportazioni, conversioni, ripristini e contenimenti.

5. Obiettivi della timeline

La timeline può essere finalizzata a:

- individuare l’evento iniziale;
- ricostruire una copia di file;
- verificare un accesso;
- identificare la diffusione di un contenuto;
- ricostruire un ransomware;
- confrontare dichiarazioni;
- verificare la cronologia di una chat;
- determinare la disponibilità di un documento;
- analizzare una truffa;
- ricostruire la pubblicazione di un deepfake.

Ogni obiettivo richiede fonti differenti. Una timeline non dovrebbe essere costruita raccogliendo ogni timestamp disponibile senza una domanda tecnica.

6. Che cosa può dimostrare una timeline

Nei limiti delle fonti, può documentare che:

• un record precede un altro;
• due attività sono temporalmente compatibili;
• un account era autenticato;
• un dispositivo era collegato;
• un file esisteva entro un certo momento;
• una connessione era attiva;
• un contenuto è stato pubblicato;
• una procedura è iniziata o terminata;
• un sistema presenta una lacuna di logging.

7. Che cosa non dimostra automaticamente

Una timeline non dimostra automaticamente:

• causalità;
• intenzione;
• identità della persona fisica;
• completezza delle attività;
• correttezza dell’orologio;
• autenticità del contenuto;
• liceità della condotta;
• assenza di eventi non registrati;
• precisione superiore a quella della fonte.

“La successione temporale documenta che l’evento A precede l’evento B nelle fonti disponibili; non dimostra, da sola, che A abbia causato B.”

8. Domande tipiche del cliente

Un cliente di Roma può chiedere:

• quando è stato creato il documento;
• quando è stata collegata una pendrive;
• quale evento precede un bonifico;
• quando è iniziato un ransomware;
• se un messaggio preceda una telefonata;
• quando sia stata pubblicata una fotografia;
• chi abbia effettuato un download;
• se un account fosse ancora attivo;
• quando sia stato cancellato un file;
• se un timestamp sia stato modificato;
• quale sistema sia il patient zero;
• quanto sia durato un accesso;
• se una telecamera fosse in ritardo;
• se due eventi siano contemporanei.

La risposta deve precisare fonte, tipo di timestamp, fuso, precisione, eventuale scarto, livello di attribuzione e limiti.

9. Mappa generale delle fonti

File system

• NTFS;
• FAT;
• exFAT;
• ReFS;
• ext;
• APFS;
• HFS+;
• file system mobili.

Sistemi operativi

• Windows Event Log;
• Registro;
• Prefetch;
• Amcache;
• SRUM;
• systemd journal;
• auditd;
• Unified Log;
• FSEvents.

Applicazioni e mobile

• browser;
• email;
• PEC;
• chat;
• Office;
• client cloud;
• chiamate;
• SMS;
• fotografie;
• posizione;
• notifiche.

Rete e cloud

• firewall;
• VPN;
• DNS;
• DHCP;
• proxy;
• NAT;
• NetFlow;
• Microsoft 365;
• Google Workspace;
• Dropbox;
• AWS, Azure e Google Cloud.

Fonti fisiche e organizzative

• badge;
• videosorveglianza;
• turni;
• ticket;
• inventario;
• accessi ai locali;
• ordini di servizio.

10. Questionario iniziale

1. Quale evento deve essere ricostruito?
2. Qual è l’intervallo temporale noto?
3. Quali sistemi sono coinvolti?
4. Quali dispositivi?
5. Quali account?
6. Quali sedi?
7. Quali fusi orari?
8. Esistono fonti cloud?
9. Esiste un SIEM?
10. Gli orologi erano sincronizzati?
11. Sono stati eseguiti riavvii?
12. Sono stati cambiati data o fuso?
13. Quali dati sono già stati esportati?
14. Sono disponibili file precedenti e successivi?
15. Quali eventi sono dichiarati dalle parti?

11. Definire il quesito tecnico

Quesito improprio:

“Dimostrare che il dipendente ha copiato il file alle 10:02.”

Quesiti più corretti:

- ricostruire gli eventi relativi al file;
- verificare i dispositivi collegati;
- correlare la sessione utente;
- individuare attività di lettura e scrittura;
- verificare la presenza del file sulla destinazione;
- determinare l’intervallo compatibile con la copia;
- descrivere i limiti dell’attribuzione personale.

“L’accertamento è finalizzato alla ricostruzione cronologica degli eventi tecnici registrati dalle fonti disponibili e non alla qualificazione giuridica della condotta.”

12. Protocollo dei primi trenta minuti

1. identificare le fonti più volatili;
2. verificare retention e rotazione;
3. registrare ora locale e UTC;
4. registrare fuso e stato NTP;
5. documentare eventuale scarto;
6. acquisire log cloud prossimi alla scadenza;
7. preservare dispositivi e account;
8. evitare riavvii non necessari;
9. acquisire i timestamp nella forma nativa;
10. annotare le azioni già eseguite;
11. identificare eventi ancora in corso;
12. aprire il registro cronologico del caso;
13. assegnare identificativi alle fonti;
14. calcolare gli hash degli export;
15. evitare normalizzazioni irreversibili.

13. Cartella del caso

CASO_RM_2026_029/
├── 00_incarico/
├── 01_verbali/
├── 02_registro_fonti/
├── 03_clock_timezone/
├── 04_originali/
├── 05_hash/
├── 06_file_system/
├── 07_windows/
├── 08_linux_macos/
├── 09_mobile/
├── 10_email_chat/
├── 11_browser/
├── 12_network/
├── 13_cloud/
├── 14_media/
├── 15_plaso/
├── 16_timesketch/
├── 17_normalizzati/
├── 18_deduplicati/
├── 19_timeline_complete/
├── 20_timeline_mirate/
├── 21_grafici/
├── 22_report/
└── 23_relazione/

14. Registro delle fonti temporali

Per ogni fonte registrare formato originario, epoch, unità, offset, software di parsing, versione, correzione applicata, fonte della correzione e grado di attendibilità.

15. Catena di custodia

La catena di custodia deve comprendere:

• fonte;
• metodo di acquisizione;
• account utilizzato;
• data e ora dell’export;
• fuso;
• nome originario;
• dimensione;
• hash;
• copie;
• trasformazioni;
• accessi.

L’estrazione di singoli file su un normale file system può generare nuovi timestamp riferiti alla copia di laboratorio; i metadati originari devono pertanto essere acquisiti dall’immagine, dal database o da un formato che ne preservi la provenienza. (NIST — Considerations for File Timestamp Preservation)

16. Vocabolario temporale

Event time

Momento nel quale la fonte dichiara che l’evento sia avvenuto.

Record time

Momento nel quale il record è stato scritto.

Ingest time

Momento nel quale un collector ha ricevuto il record.

Processing time

Momento nel quale il SIEM o il provider lo ha elaborato.

Index time

Momento nel quale il dato è stato indicizzato.

Export time

Momento nel quale il perito ha generato l’export.

Acquisition time

Momento nel quale il reperto è stato acquisito.

Observation time

Momento nel quale una persona o un sistema ha osservato il fatto.

17. Esempio di tempi differenti

08:15:02 — evento sul computer
08:15:07 — log ricevuto dal collector
08:16:11 — regola SIEM elaborata
08:16:20 — alert generato
09:02:00 — analista apre l’incidente
11:30:00 — log esportato

La relazione non dovrebbe utilizzare genericamente “l’evento è delle 08:16”, ma specificare quale tempo viene descritto.

18. Istante e intervallo

Un istante rappresenta un punto temporale.

Un intervallo rappresenta un periodo:

inizio
→ durata
→ fine

Esempi di intervalli: sessione VPN, chiamata, processo, collegamento USB, video, login e trasferimento.

Un record di inizio senza record di fine non consente di determinare con certezza la durata.

19. Precisione, accuratezza, risoluzione e granularità

Precisione espositiva

Numero di cifre mostrate.

Risoluzione

Minima unità rappresentabile dalla fonte.

Accuratezza

Vicinanza del valore al tempo reale.

Granularità

Livello temporale effettivamente significativo.

Un timestamp può mostrare 2026-07-14T08:15:02.1234567Z ma provenire da un sistema il cui orologio era avanti di quattro minuti. Le molte cifre non rendono il dato accurato.

20. Falsa precisione

Esempio:

record:
08:15:02

relazione errata:
08:15:02.000

Il tecnico ha aggiunto una precisione non presente.

“L’evento è registrato alle 08:15:02, con precisione al secondo secondo la fonte.”

Quando un valore è disponibile soltanto come data, non deve essere trasformato in mezzanotte senza indicare che si tratta di una convenzione.

21. Incertezza temporale

Ogni evento può essere rappresentato mediante:

timestamp centrale
+
incertezza precedente
+
incertezza successiva

Esempio:

valore:
10:15:00

risoluzione:
1 minuto

intervallo plausibile:
10:15:00–10:15:59

Oppure:

orologio avanti:
120 ± 3 secondi

Formula:

offset = orologio_sistema - orologio_riferimento

tempo_corretto = tempo_registrato - offset

Se l’orologio era avanti di 120 secondi:

10:15:00 registrato
→
10:13:00 corretto

22. Grado di attendibilità

Il livello non deve essere assegnato automaticamente in base al prodotto. Un log cloud può avere un orologio affidabile ma una semantica incompleta.

23. UTC e ora locale

UTC consente di correlare fonti provenienti da sedi diverse, cloud, smartphone, server e provider.

L’ora locale è utile per comprendere turni, orari di lavoro, testimonianze e comportamento umano.

La buona pratica è conservare entrambe:

timestamp originale:
2026-07-14T10:15:02+02:00

UTC:
2026-07-14T08:15:02Z

timezone:
Europe/Rome

24. RFC 3339 e offset

RFC 3339 rappresenta un istante mediante data, ora e offset numerico.

2026-07-14T10:15:02+02:00

equivale a:

2026-07-14T08:15:02Z

L’offset è calcolato come ora locale meno UTC. RFC 3339 distingue inoltre -00:00, che segnala un offset locale non conosciuto, da Z o +00:00. (RFC 3339)

25. Offset e nome del fuso

Un offset +02:00 non identifica da solo una zona. Molti luoghi possono condividere lo stesso offset.

Il nome Europe/Rome consente di applicare le regole storiche pertinenti alla data. RFC 9557 estende il formato RFC 3339 per associare informazioni aggiuntive, compreso il nome della zona temporale. (RFC 9557)

26. Database IANA dei fusi orari

Il database IANA contiene la storia delle regole di ora civile per numerose località ed è aggiornato quando autorità politiche modificano offset o regole dell’ora legale. (IANA Time Zone Database)

Per Roma è preferibile registrare Europe/Rome e non applicare in modo permanente UTC+1 oppure UTC+2.

27. Ora legale: orari inesistenti e duplicati

Durante il passaggio all’ora legale, alcuni orari locali possono non esistere. Durante il ritorno all’ora solare, alcuni orari possono ripetersi.

02:30 prima del cambio
02:30 dopo il cambio

Senza offset o indicazione della zona, i due valori sono ambigui.

La timeline deve conservare valore locale, offset, UTC, regola applicata e versione del timezone database, quando rilevante.

28. NTP e sincronizzazione

NTPv4 utilizza lo scambio di timestamp per stimare ritardo e offset dell’orologio rispetto alle fonti di sincronizzazione. RFC 5905 definisce valori come system offset e jitter; RFC 8633 raccoglie le best practice operative per un’infrastruttura NTP stabile e sicura. (RFC 5905)

Acquisire:

- server NTP;
- peer;
- offset;
- jitter;
- stratum;
- ultima sincronizzazione;
- stato;
- eventuali errori;
- configurazione.

29. Verifica NTP su Windows

w32tm /query /status
w32tm /query /configuration
w32tm /query /peers

Registrare:

Source:
Stratum:
Last Successful Sync Time:
Phase Offset:
Leap Indicator:

L’output deve essere acquisito prima di modificare la configurazione.

30. Verifica temporale su Linux

systemd-timesyncd

timedatectl status
timedatectl timesync-status

chrony

chronyc tracking
chronyc sources -v

ntpd

ntpq -pn

Registrare versione, comando e output.

31. Clock drift

Il clock drift è la variazione progressiva dello scarto dell’orologio.

08:00 — clock avanti di 30 secondi
12:00 — clock avanti di 50 secondi

Non sempre è corretto applicare un offset fisso all’intera giornata.

Se esistono due misurazioni attendibili, può essere valutata una correzione lineare:

o(t) = o1 + (o2 - o1) × (t - t1) / (t2 - t1)

tempo_corretto = tempo_registrato - o(t)

La linearità deve essere dimostrata o assunta esplicitamente.

32. Clock step e clock slew

Un sistema può correggere l’orologio:

• con un salto immediato;
• mediante una correzione graduale;
• al riavvio;
• dopo il ripristino della rete;
• in seguito a un intervento manuale.

Conseguenze possibili:

• eventi apparentemente fuori ordine;
• timestamp duplicati;
• salto in avanti;
• ritorno indietro;
• durata apparente negativa.

La timeline deve cercare eventi di sincronizzazione e modifiche manuali.

33. Wall clock e tempo monotono

Il wall clock rappresenta data e ora civile e può essere modificato.

Il tempo monotono misura il tempo trascorso dal boot o da un riferimento interno e normalmente non torna indietro durante una correzione dell’ora civile.

Il journal di systemd può includere sia tempo realtime, espresso in microsecondi dall’epoch Unix, sia riferimenti monotoni associati al boot. (systemd journal fields)

La combinazione può aiutare a ricostruire eventi dopo un cambio d’ora, correlare attività nello stesso boot e rilevare salti del wall clock.

34. Boot time e uptime

Fonti utili:

• Event Log;
• systemd journal;
• kernel log;
• uptime;
• crash log;
• process start time;
• sessioni;
• riavvii cloud.

Un evento relativo a “15 minuti dopo il boot” può essere correlato con il boot time anche quando l’orologio civile è incerto.

35. Leap second

UTC può includere aggiustamenti di un secondo.

Sistemi differenti possono rappresentare 23:59:60, ripetere 23:59:59, applicare uno smear, ignorare il secondo o normalizzare.

Il NIST segnala che formati numerici basati su secondi da un’epoch possono avere difficoltà a rappresentare direttamente il secondo intercalare. (NIST Internet Time Service)

Per la maggior parte dei casi civili l’effetto è limitato, ma può essere rilevante in analisi ad alta precisione.

36. Epoch e unità

Un numero come:

1720944902

non è interpretabile senza conoscere:

• epoch;
• unità;
• fuso;
• tipo numerico;
• segno;
• eventuale frazione.

Possibili unità:

• secondi;
• millisecondi;
• microsecondi;
• nanosecondi;
• intervalli da 100 nanosecondi;
• giorni frazionari.

37. Unix epoch

Unix time rappresenta normalmente il numero di secondi trascorsi dal:

1970-01-01T00:00:00Z

Può essere memorizzato in secondi, millisecondi, microsecondi o nanosecondi.

SQLite documenta unixepoch() come numero di secondi dall’inizio del 1970 UTC e consente l’uso di frazioni con il modificatore subsec. (SQLite Date and Time Functions)

38. Windows FILETIME

FILETIME utilizza un valore a 64 bit basato su intervalli da 100 nanosecondi.

Nelle conversioni forensi viene normalmente interpretato rispetto all’epoch Windows:

1601-01-01T00:00:00Z

Microsoft documenta differenze sostanziali tra file system: NTFS registra i tempi in UTC, mentre FAT li memorizza in ora locale; risoluzione e comportamento del Last Access variano tra i file system. (Microsoft — File Times)

Formula concettuale:

Unix seconds =
(FILETIME / 10.000.000)
- 11.644.473.600

39. Timestamp WebKit e Chromium

Numerosi artefatti Chromium utilizzano valori in microsecondi rispetto all’epoch Windows del 1601.

Il codice Chromium documenta la necessità di convertire tra epoch Windows 1601, Unix 1970 e Core Foundation 2001. (Chromium time conversion)

Formula concettuale:

Unix seconds =
(WebKit microseconds / 1.000.000)
- 11.644.473.600

Non applicare la formula automaticamente a ogni campo numerico di un database Chromium: verificare la documentazione o il parser dell’artefatto.

40. Epoch Apple

CFAbsoluteTime rappresenta secondi rispetto a:

2001-01-01T00:00:00 GMT

secondo la documentazione Apple. (Apple CFAbsoluteTime)

Formula:

Unix seconds =
Apple absolute time
+ 978.307.200

Applicazioni Apple possono tuttavia utilizzare anche Unix time, nanosecondi, date ISO o formati proprietari.

41. SQLite e Julian day

SQLite può gestire:

• testo ISO 8601;
• Julian day;
• Unix timestamp mediante modificatori.

La funzione julianday() usa un numero di giorni frazionari; unixepoch() usa secondi dal 1970. Il modificatore auto può essere ambiguo per alcuni valori numerici e non dovrebbe essere utilizzato indiscriminatamente in una procedura forense. (SQLite Date and Time Functions)

42. Date seriali Excel

Excel supporta i sistemi data 1900 e 1904.

La stessa data ha valori differenti nei due sistemi, con una differenza di 1.462 giorni. Microsoft documenta inoltre la storica compatibilità per la quale Excel tratta il 1900 come anno bisestile. (Microsoft — Date systems in Excel)

Prima di convertire una colonna:

- verificare il sistema data della cartella;
- conservare il valore numerico;
- conservare il formato cella;
- non affidarsi alla sola visualizzazione.

43. Conversione in Python

from __future__ import annotations

from datetime import datetime, timedelta, timezone
from zoneinfo import ZoneInfo

WINDOWS_EPOCH = datetime(1601, 1, 1, tzinfo=timezone.utc)
APPLE_EPOCH = datetime(2001, 1, 1, tzinfo=timezone.utc)


def unix_seconds_to_utc(value: int | float) -> datetime:
    return datetime.fromtimestamp(value, tz=timezone.utc)


def unix_milliseconds_to_utc(value: int) -> datetime:
    return datetime.fromtimestamp(value / 1_000.0, tz=timezone.utc)


def filetime_to_utc(value: int) -> tuple[datetime, int]:
    """Restituisce datetime e residuo in unità da 100 ns."""
    microseconds, remainder_100ns = divmod(value, 10)
    dt = WINDOWS_EPOCH + timedelta(microseconds=microseconds)
    return dt, remainder_100ns


def webkit_microseconds_to_utc(value: int) -> datetime:
    return WINDOWS_EPOCH + timedelta(microseconds=value)


def apple_absolute_to_utc(value: int | float) -> datetime:
    return APPLE_EPOCH + timedelta(seconds=value)


def utc_to_rome(value: datetime) -> datetime:
    if value.tzinfo is None:
        raise ValueError("Il datetime deve contenere un fuso orario")
    return value.astimezone(ZoneInfo("Europe/Rome"))

Registrare versione Python, sistema operativo, timezone database, script, hash dello script, input e output.

44. Conversione in PowerShell

Unix seconds

$value = 1720944902

[DateTimeOffset]::FromUnixTimeSeconds(
    $value
).UtcDateTime

Unix milliseconds

$value = 1720944902123

[DateTimeOffset]::FromUnixTimeMilliseconds(
    $value
).UtcDateTime

FILETIME

$value = 133654321000000000

[DateTime]::FromFileTimeUtc(
    $value
)

Conversione in ora di Roma su Windows

$utc = [DateTime]::SpecifyKind(
    [DateTime]"2026-07-14T08:15:02",
    [DateTimeKind]::Utc
)

$romeZone = [TimeZoneInfo]::FindSystemTimeZoneById(
    "W. Europe Standard Time"
)

[TimeZoneInfo]::ConvertTimeFromUtc(
    $utc,
    $romeZone
)

Il nome della zona dipende dal sistema operativo. Conservare anche il valore UTC.

45. Conversioni SQLite

Unix seconds

SELECT
    timestamp_raw,
    datetime(timestamp_raw, 'unixepoch') AS timestamp_utc
FROM events;

Unix milliseconds

SELECT
    timestamp_raw,
    datetime(timestamp_raw / 1000.0, 'unixepoch') AS timestamp_utc
FROM events;

Apple absolute time

SELECT
    timestamp_raw,
    datetime(timestamp_raw + 978307200, 'unixepoch') AS timestamp_utc
FROM events;

WebKit microseconds

SELECT
    timestamp_raw,
    datetime(
        (timestamp_raw / 1000000.0) - 11644473600,
        'unixepoch'
    ) AS timestamp_utc
FROM events;

Non modificare il database originale. Eseguire le query su una copia controllata.

46. Formato raccomandato per la normalizzazione

47. Timestamp del file system

I timestamp del file system non documentano tutti la stessa attività.

Possibili categorie:

• creazione;
• ultima modifica del contenuto;
• ultimo accesso;
• modifica dei metadati;
• modifica della directory;
• data del file name;
• transazione del journal.

La semantica dipende da:

• file system;
• sistema operativo;
• applicazione;
• configurazione;
• copia;
• montaggio;
• protocollo.

48. MACE

La sigla MACE viene spesso utilizzata per:

• Modified;
• Accessed;
• Changed;
• Entry created.

Il significato preciso varia tra file system e strumenti.

Non scrivere:

“Il timestamp C indica quando è stato creato il file.”

Su NTFS il change time è riferito alla modifica dei metadati, mentre la creazione è un campo distinto.

49. NTFS

NTFS conserva metadati nella Master File Table.

Un record può includere attributi come:

• $STANDARD_INFORMATION;
• $FILE_NAME;
• $DATA;
• $OBJECT_ID.

Sia $STANDARD_INFORMATION sia $FILE_NAME possono contenere timestamp; la loro semantica e il relativo aggiornamento devono essere interpretati nel contesto delle operazioni effettuate. (The Sleuth Kit Wiki — NTFS)

50. $STANDARD_INFORMATION e $FILE_NAME

Una timeline NTFS può contenere due insiemi di tempi riferiti allo stesso file.

Questi valori possono divergere a causa di:

• rinomina;
• spostamento;
• copia;
• operazioni del sistema;
• modifica manuale;
• tunneling;
• parser;
• file recuperato.

La divergenza non dimostra automaticamente timestomping.

Deve essere correlata con:

• $UsnJrnl;
• $LogFile;
• directory;
• LNK;
• Prefetch;
• applicazione;
• altri file.

51. MFT, USN Journal e $LogFile

MFT

Descrive lo stato dei file e delle directory.

USN Journal

Documenta modifiche del file system mediante reason code e identificativi.

$LogFile

Conserva transazioni recenti dei metadati NTFS.

Una sequenza può essere:

FILE_CREATE
→
DATA_EXTEND
→
CLOSE
→
RENAME
→
FILE_DELETE

Il journal non documenta necessariamente:

• contenuto;
• persona;
• destinazione esterna;
• intenzione.

52. FAT ed exFAT

Microsoft documenta che FAT conserva i tempi in ora locale e utilizza granularità differenti: creazione a 10 millisecondi, ultima scrittura a 2 secondi e accesso a un giorno. NTFS registra invece i tempi in UTC e può ritardare o disabilitare l’aggiornamento dell’ultimo accesso. (Microsoft — File Times)

exFAT può aggiungere campi relativi al fuso, ma implementazioni e sistemi differenti possono gestirli in modo non uniforme. (The Sleuth Kit — exFAT Implementation Notes)

La timeline deve indicare:

- file system;
- sistema che ha scritto il volume;
- timezone;
- precisione;
- conversione eseguita.

53. Linux

Fonti principali:

• inode;
• ext journal;
• systemd journal;
• auditd;
• auth log;
• shell history;
• package manager;
• cron;
• application log.

Possibili timestamp:

• mtime;
• atime;
• ctime;
• birth time, se disponibile;
• realtime journal;
• monotonic journal.

Il significato di ctime nei file system Unix riguarda la modifica dei metadati, non la creazione.

54. systemd journal

journalctl consente di consultare i record raccolti dal journal.

journalctl \
  --utc \
  --since "2026-07-14 00:00:00" \
  --until "2026-07-15 00:00:00" \
  --output json \
  --no-pager \
  > journal.json

Il journal può includere un timestamp realtime in microsecondi dall’epoch UTC e riferimenti monotoni associati al boot. (systemd — Journal fields)

55. macOS

Fonti utili:

• APFS;
• Unified Log;
• FSEvents;
• Spotlight;
• quarantine events;
• browser;
• plist;
• Time Machine;
• file recenti;
• database delle applicazioni.

Possibili epoch:

• Unix;
• Apple 2001;
• testo ISO;
• nanosecondi;
• formati applicativi.

L’analisi forense di macOS e Linux deve preservare la semantica del singolo artefatto.

56. Windows Event Log

Ogni record può includere:

• TimeCreated;
• Event ID;
• Record ID;
• provider;
• computer;
• account;
• Activity ID;
• Logon ID;
• process ID.

Un Event ID non costituisce un evento completo senza:

• campi XML;
• versione del provider;
• sistema;
• contesto;
• correlazione.

L’analisi forense di Windows deve conservare l’EVTX nativo.

57. Registro di Windows

La LastWrite di una chiave documenta la modifica della chiave.

Non documenta necessariamente:

• quale valore sia cambiato;
• chi abbia effettuato la modifica;
• ogni lettura;
• la prima creazione;
• l’ultimo utilizzo dell’oggetto rappresentato.

“Il timestamp documenta la modifica della chiave di registro e non coincide automaticamente con l’evento applicativo dedotto.”

58. Prefetch, Amcache e UserAssist

Prefetch

Può supportare l’esecuzione di un programma.

Amcache

Può documentare file eseguibili osservati dal sistema.

UserAssist

Può documentare l’interazione dell’utente con applicazioni o collegamenti supportati.

I relativi timestamp devono essere distinti da:

• installazione;
• prima presenza;
• ultima esecuzione;
• modifica del file;
• attività automatica.

59. LNK e Jump List

Possono collegare:

utente
→ applicazione
→ file
→ volume
→ intervallo

Un LNK può contenere timestamp riferiti:

• al file destinazione;
• al volume;
• al collegamento;
• alla creazione del link.

Non devono essere riuniti in un solo valore generico.

60. Browser

Possibili tempi:

• visita;
• download;
• inizio download;
• fine download;
• cookie creation;
• cookie expiry;
• cache;
• form submission;
• session restore;
• sincronizzazione.

Chrome e applicazioni Chromium possono utilizzare timestamp WebKit; Firefox e altri browser possono usare Unix in microsecondi o millisecondi.

La timeline del browser deve mantenere:

• URL;
• visit ID;
• transition;
• source;
• profilo;
• account sync;
• semantica del campo.

61. Email

Distinguere:

• header Date;
• header Received;
• data interna della mailbox;
• data di consegna;
• data di sincronizzazione;
• data del file EML o MSG;
• data di export.

RFC 5321 richiede ai server SMTP che ricevono un messaggio di aggiungere informazioni di traccia Received con timestamp; queste righe descrivono i passaggi dei server, mentre il campo Date appartiene al messaggio originato dal client. (RFC 5322 — Internet Message Format)

La perizia di email e header deve ricostruire ogni hop separatamente.

62. PEC

Fonti temporali:

• messaggio originario;
• accettazione;
• avvenuta consegna;
• mancata consegna;
• busta di trasporto;
• log del gestore;
• marca o riferimento temporale;
• conservazione.

La PEC deve essere ricostruita come catena di eventi e non mediante la sola data visualizzata dal client.

63. Messaggistica

Possibili timestamp:

• creazione locale;
• invio;
• ricezione server;
• consegna;
• lettura;
• modifica;
• cancellazione;
• download allegato;
• backup;
• sincronizzazione.

Per WhatsApp, Telegram e Signal occorre distinguere:

record del database
≠
ora mostrata
≠
ora del file allegato
≠
data del backup

64. Android

Fonti possibili:

• SMS;
• chiamate;
• notifiche;
• utilizzo app;
• logcat;
• file system;
• fotografie;
• GPS;
• database delle app;
• backup.

Molti valori utilizzano Unix time in millisecondi, ma non esiste una regola universale per ogni applicazione.

Plaso include parser dedicati a numerosi artefatti Android, tra cui app usage, chiamate, SMS e logcat. (Plaso — Parsers and plugins)

65. iPhone e iPad

Possibili fonti:

• SMS e iMessage;
• call history;
• KnowledgeC;
• fotografie;
• notifiche;
• Safari;
• app;
• backup;
• Unified Log;
• file system.

Possibili formati temporali:

• Apple absolute time;
• Unix;
• nanosecondi;
• testo;
• database proprietari.

L’acquisizione forense di iPhone e iPad deve documentare il tipo di estrazione e la semantica di ogni campo.

66. Cloud

Distinguere:

event time
ingest time
processing time
version time
deletion time
export time

Un audit cloud può essere:

• immediato;
• ritardato;
• aggregato;
• segmentato;
• limitato dalla retention.

La cloud forensics deve conservare:

• raw event;
• event ID;
• correlation ID;
• session ID;
• object ID;
• query;
• intervallo;
• account di acquisizione.

67. Rete

Fonti:

• firewall;
• proxy;
• VPN;
• DNS;
• DHCP;
• NAT;
• NetFlow;
• IDS;
• packet capture.

Un record firewall può rappresentare:

• inizio sessione;
• fine sessione;
• tentativo;
• traffico consentito;
• traffico bloccato;
• aggregazione.

L’analisi dei log aziendali deve indicare la semantica del record.

68. DHCP e NAT

Per collegare un IP interno a un dispositivo:

timestamp
+ IP
+ lease
+ MAC
+ scope
+ hostname

Per correlare un IP pubblico:

timestamp
+ porta pubblica
+ protocollo
+ traduzione NAT
+ host interno

Senza porta e intervallo temporale sufficientemente preciso, un IP pubblico condiviso può non consentire l’identificazione del dispositivo.

69. Fotografie

Possibili date:

• EXIF DateTimeOriginal;
• CreateDate;
• ModifyDate;
• GPSDateStamp;
• XMP;
• file system;
• cloud;
• chat;
• pubblicazione.

La perizia sulle immagini deve distinguere la data dichiarata dal file e la data dell’evento fotografato.

70. Audio e video

Possibili tempi:

• durata del contenitore;
• timestamp dei pacchetti;
• PTS;
• DTS;
• timecode;
• data di acquisizione;
• data di export;
• data di pubblicazione.

L’autenticità audio e l’autenticità video richiedono la distinzione tra tempo del contenuto e tempo del file.

71. Fonti fisiche e organizzative

La timeline digitale può essere correlata con:

• badge;
• tornelli;
• accessi a edifici;
• videosorveglianza;
• turni;
• ticket;
• telefonate;
• documenti cartacei;
• ricevute;
• registri di consegna.

Una corrispondenza temporale può rafforzare l’ipotesi.

Non identifica automaticamente la persona che utilizzava il computer.

72. Anchor event

Un anchor event è un evento noto o fortemente documentato utilizzato come riferimento.

Esempi:

• bonifico registrato dalla banca;
• telefonata del centralino;
• frame con orologio verificato;
• email ricevuta da server indipendente;
• intervento del tecnico;
• riavvio.

Gli anchor event possono essere utilizzati per:

• misurare lo scarto;
• allineare fonti;
• delimitare intervalli;
• verificare dichiarazioni.

73. Costruzione guidata dal quesito

Non partire da:

“Esportiamo tutti i timestamp e vediamo.”

Partire da:

1. quale evento devo spiegare;
2. quali fonti dovrebbero registrarlo;
3. quali fonti indipendenti possono confermarlo;
4. quale precisione è necessaria;
5. quali gap sono prevedibili;
6. quali ipotesi alternative esistono.

74. Timeline grezza

La timeline grezza deve mantenere:

• tutti gli eventi;
• valori originari;
• duplicati;
• errori;
• record non interpretati;
• riferimenti alla fonte.

Non utilizzarla direttamente nella relazione ordinaria.

75. Timeline normalizzata

La normalizzazione converte eventi differenti in uno schema comune.

Non deve:

• eliminare il raw;
• modificare il significato;
• aggiungere precisione;
• nascondere il fuso;
• sostituire l’evento originario.

Ogni riga normalizzata deve puntare al record sorgente.

76. Eventi dedotti

Esempio:

record 1:
login riuscito;

record 2:
VPN aperta;

record 3:
IP assegnato;

record 4:
accesso al server;

evento dedotto:
sessione remota associata all’account.

Contrassegnare l’evento come:

derived_event = true

e indicare i record che lo supportano.

77. Correlation keys

Possibili chiavi:

• account;
• SID;
• UPN;
• IP;
• porta;
• MAC;
• hostname;
• device ID;
• session ID;
• Logon ID;
• correlation ID;
• process GUID;
• file ID;
• hash;
• Message-ID;
• object ID;
• request ID.

La coincidenza del solo nome non è sufficiente quando:

• l’account è condiviso;
• il dispositivo è rinominato;
• l’IP è dinamico;
• il file è duplicato.

78. Deduplicazione

Duplicati possono derivare da:

• più copie dello stesso log;
• VSS;
• backup;
• collector ridondanti;
• export sovrapposti;
• parser differenti;
• record ripetuti.

Plaso può rimuovere eventi duplicati nell’output di psort; la documentazione indica l’opzione -a o --include_all per conservare tutti gli eventi e mostra il numero di duplicati rimossi. (Plaso — Using psort)

Per un accertamento:

1. conservare l’output completo;
2. creare una copia deduplicata;
3. documentare la chiave;
4. non eliminare gli originali.

79. Eventi simultanei

Due eventi visualizzati alle:

10:15:02

potrebbero essere:

• realmente simultanei;
• separati da millisecondi non mostrati;
• arrotondati;
• prodotti da fonti differenti;
• influenzati dal drift.

Non imporre un ordine quando la fonte non lo consente.

“I due eventi ricadono nello stesso intervallo di precisione e il loro ordine relativo non è determinabile.”

80. Ordine temporale e causalità

La sequenza:

A
→
B

dimostra che A precede B, se gli orologi sono comparabili.

Non dimostra che A abbia causato B.

Esempio:

USB collegata
→
file cancellato

Non dimostra che la pendrive abbia causato la cancellazione.

81. Gap temporali

Un gap può derivare da:

• logging disattivato;
• retention;
• rotazione;
• sistema spento;
• rete interrotta;
• collector indisponibile;
• fuso errato;
• filtro;
• cancellazione;
• attività non registrata.

Registrare:

inizio gap;
fine gap;
fonti coinvolte;
fonti alternative;
causa nota o ipotizzata.

82. Evidenza negativa

L’assenza di un evento è significativa soltanto se:

1. la fonte avrebbe dovuto registrarlo;
2. il logging era attivo;
3. la retention copre il periodo;
4. l’export è completo;
5. l’orologio è correttamente interpretato;
6. il parser supporta il record;
7. il canale corretto è stato esaminato.

“L’assenza del record nelle fonti disponibili non dimostra necessariamente che l’attività non sia avvenuta.”

83. Timestamp manipulation

Possibili tecniche:

• modifica dell’orologio;
• SetFileTime;
• timestomping;
• copia con preservazione;
• sostituzione del database;
• importazione di un file;
• modifica dei metadati;
• ricreazione del log.

Microsoft documenta che le API di sistema possono impostare i timestamp di un file senza modificare il contenuto. (Microsoft — File Times)

La presenza di un timestamp non prova che sia stato generato naturalmente dall’evento dichiarato.

84. Indicatori di timestomping

Possibili indicatori:

• $STANDARD_INFORMATION e $FILE_NAME divergenti;
• timestamp anteriori all’installazione;
• precisione anomala;
• file creato prima del volume;
• tempi identici su molti file;
• USN incompatibile;
• Prefetch successivo;
• log di copia;
• metadata applicativi contraddittori.

Nessun indicatore deve essere utilizzato isolatamente.

85. Sequenze impossibili

Esempi:

file modificato prima della creazione;
messaggio letto prima della consegna;
processo terminato prima dell’avvio;
foto pubblicata prima dello scatto dichiarato;
account usato dopo cancellazione senza ripristino;
video esportato prima dell’evento rappresentato.

Possibili spiegazioni:

• clock drift;
• timezone;
• timestamp derivato;
• importazione;
• copia;
• errore del parser;
• manipolazione.

86. Plaso: funzione

log2timeline.py estrae eventi da file, directory, dispositivi o immagini forensi e produce un file di storage Plaso; pinfo.py descrive il contenuto e i parametri della raccolta; psort.py filtra, ordina, analizza ed esporta gli eventi. (Plaso — Using log2timeline)

Plaso supporta parser per numerosi artefatti, tra cui:

• MFT;
• USN Journal;
• EVTX;
• registro;
• browser;
• Android;
• iOS;
• cloud audit;
• systemd journal;
• Unified Log. (Plaso — Parsers and plugins)

87. Verificare la versione di Plaso

log2timeline.py --version
pinfo.py --version
psort.py --version

Conservare:

- versione;
- sistema operativo;
- immagine o pacchetto;
- hash dell’ambiente, se containerizzato;
- comando;
- log.

88. Creare una timeline Plaso

log2timeline.py \
  --logfile "log2timeline-case.log" \
  --storage-file "timeline.plaso" \
  "/evidence/computer.E01"

La sintassi ufficiale prevede il file di storage e la sorgente; il file .plaso conserva gli eventi estratti e metadati sul processo di raccolta. (Plaso — Using log2timeline)

Per sorgenti cifrate o immagini con più volumi possono essere necessarie ulteriori selezioni e credenziali autorizzate.

89. Esaminare lo storage Plaso

pinfo.py \
  -v \
  "timeline.plaso" \
  > "pinfo-verbose.txt"

pinfo.py può documentare:

• comando;
• versione;
• fonte;
• sistema rilevato;
• timezone;
• parser;
• numero di eventi;
• report dei plugin.

(Plaso — Using pinfo)

Calcolare l’hash del file Plaso e del report.

90. Esportare la timeline in UTC

psort.py \
  -o dynamic \
  --output-time-zone UTC \
  -w "timeline-utc.csv" \
  "timeline.plaso"

psort utilizza UTC come default per l’output e può produrre formati dynamic, JSON, JSONL, XLSX e altri moduli disponibili nell’installazione. (Plaso — Using psort)

91. Esportare una vista Europe/Rome

psort.py \
  -o dynamic \
  --output-time-zone Europe/Rome \
  -w "timeline-roma.csv" \
  "timeline.plaso"

Prima dell’uso verificare:

psort.py --output-time-zone list

Conservare comunque l’output UTC come riferimento principale. (Plaso — Using psort)

92. Conservare tutti i duplicati

psort.py \
  -a \
  -o dynamic \
  --output-time-zone UTC \
  -w "timeline-all-events.csv" \
  "timeline.plaso"

Produrre successivamente una versione deduplicata documentata.

93. Time slice con psort

Quando esiste un timestamp di interesse:

psort.py \
  -q \
  --slice "2026-07-14T08:15:02" \
  --slice_size 15 \
  -w "slice-081502.csv" \
  "timeline.plaso"

La documentazione indica che --slice accetta un timestamp ISO 8601 e che la dimensione dell’intervallo può essere regolata con --slice_size. (Plaso — Using psort)

Verificare il significato dell’unità nella versione installata tramite --help.

94. Event filter Plaso

Esempio documentato:

data_type is 'syslog:line'
and
message_body contains 'root'

I filtri Plaso possono essere utilizzati per selezionare eventi, analizzarli o applicare tag; il helper DATETIME() accetta timestamp POSIX in microsecondi o stringhe ISO compatibili, con granularità massima al microsecondo. (Plaso — Event filters)

Prima di applicare filtri complessi:

• verificare i nomi dei campi;
• conservare l’output completo;
• registrare la stringa;
• contare gli eventi esclusi.

95. Tagging

psort.py \
  -o null \
  --analysis tagging \
  --tagging-file "tagging-rules.txt" \
  "timeline.plaso"

Esempi di tag:

- Initial Access;
- USB Activity;
- File Staging;
- Cloud Download;
- Privilege Escalation;
- Ransomware Impact;
- Investigative Action.

Conservare:

• file delle regole;
• versione;
• hash;
• report;
• numero di tag.

96. Timeline mirata

La super timeline può contenere milioni di eventi.

Per il quesito:

“Che cosa è accaduto tra le 08:00 e le 09:00?”

creare una timeline mirata con:

- accessi;
- processi;
- USB;
- file;
- browser;
- rete;
- cloud;
- interventi tecnici.

Non eliminare dal caso la super timeline originaria.

97. The Sleuth Kit e mactime

The Sleuth Kit può produrre body file e timeline del file system.

tsk_gettimes \
  "computer.E01" \
  > "bodyfile.txt"

mactime \
  -b "bodyfile.txt" \
  -d \
  -y \
  "2026-07-14..2026-07-15" \
  > "mactime.csv"

mactime crea una timeline ASCII o CSV a partire da body file prodotti da strumenti come fls, ils o tsk_gettimes; supporta intervalli di date e opzioni relative al fuso. (The Sleuth Kit — mactime)

98. Plaso e mactime non sono equivalenti

mactime è focalizzato principalmente sui tempi del file system.

Plaso integra:

• file system;
• log;
• applicazioni;
• browser;
• cloud;
• database;
• registry;
• mobile.

Possono essere utilizzati congiuntamente per:

• controllo incrociato;
• validazione;
• analisi mirata;
• confronto dei parser.

99. Timesketch

Timesketch è uno strumento open source per l’analisi collaborativa di timeline.

Consente di organizzare gli eventi in sketch, aggiungere più timeline, effettuare ricerche, creare viste, tag, commenti e storie investigative. (Timesketch — sito ufficiale)

Non è principalmente un parser.

L’estrazione può essere effettuata mediante Plaso o strumenti dedicati.

100. Importare dati in Timesketch

Timesketch accetta, secondo la documentazione:

• file Plaso;
• CSV;
• JSONL.

L’importer CLI può essere installato con:

pip3 install timesketch-import-client

e avviato mediante:

timesketch_importer.py \
  "timeline.plaso"

La documentazione descrive opzioni per sketch, nome della timeline e filtri Plaso durante l’import. (Timesketch — Upload Data)

101. Organizzare uno sketch

Esempio:

Sketch:
CASO RM 2026 029

Timeline:
- Computer Windows
- Smartphone Android
- Microsoft 365
- Firewall e VPN
- Acquisizioni del perito

Creare viste come:

• eventi critici;
• USB;
• autenticazioni;
• file contestato;
• pubblicazioni;
• attività amministrative.

102. Ricerca in Timesketch

Timesketch utilizza OpenSearch e supporta query semplici o avanzate.

Esempio concettuale:

{
  "query": {
    "bool": {
      "must": [
        {
          "query_string": {
            "query": "utente AND download"
          }
        }
      ]
    }
  },
  "sort": {
    "datetime": "asc"
  }
}

La sintassi e i campi devono essere verificati rispetto alla timeline importata. (Timesketch — Basic concepts)

103. Annotazioni

Timesketch consente di aggiungere tag e commenti agli eventi.

Esempio CLI:

timesketch events annotate \
  --timeline-id <TIMELINE_ID> \
  --event-id <EVENT_ID> \
  --tag "evento-chiave,usb" \
  --comment "Correlato al reperto RM29-004"

La funzionalità è documentata dal client ufficiale. (Timesketch — CLI client)

104. Timesketch e funzioni AI

Le funzioni AI non devono essere abilitate senza una verifica privacy e di riservatezza.

La documentazione corrente dell’Investigation View avverte che, quando l’utente avvia la generazione del rapporto iniziale tramite il log analyzer, tutti i dati della timeline possono essere inviati al servizio AI esterno configurato dall’amministratore; la funzione è descritta come sperimentale. (Timesketch — Investigation View setup)

Prima dell’uso verificare:

- provider;
- endpoint;
- categorie di dati;
- trasferimenti;
- retention;
- segreti;
- autorizzazione;
- possibilità di elaborazione locale.

105. Timeline manuale in CSV

Schema minimo:

event_id,evidence_id,timestamp_raw,timestamp_utc,timezone,precision,source,event_type,actor,device,object,action,result,confidence,raw_reference,notes

Esempio:

EVT-001,RM29-004,2026-07-14 10:15:02+02:00,2026-07-14T08:15:02Z,Europe/Rome,second,EVTX,login,user01,PC01,,success,elevata,Security.evtx:14502,

Impostare le colonne data come testo quando occorre preservare:

• offset;
• zeri;
• frazioni;
• valori non standard.

Excel può convertire automaticamente stringhe o utilizzare sistemi data differenti; conservare sempre un CSV UTF-8 originario e documentare eventuali importazioni. (Microsoft — Date systems in Excel)

106. Ordinamento stabile

Quando più eventi hanno lo stesso timestamp, definire un ordinamento secondario:

1. timestamp UTC;
2. precisione;
3. source priority;
4. evidence ID;
5. record ID;
6. event ID.

Non usare l’ordinamento secondario per affermare che un evento sia avvenuto prima.

Serve soltanto a rendere stabile la tabella.

107. Timeline a intervalli

Quando la precisione è insufficiente, rappresentare:

Questa rappresentazione evita la falsa precisione.

108. Timeline grafica

Possibili visualizzazioni:

• asse lineare;
• swimlane;
• Gantt;
• grafico per fonte;
• grafico per account;
• grafo causale;
• istogramma degli eventi;
• mappa temporale.

Esempio di swimlane:

PC01       login ─ process ─ file ─ USB
VPN        connect ───────────── disconnect
Cloud              download ─ share
Perito                                      acquisition

La grafica deve rimandare ai record originari.

109. Caso pratico 1 — Copia di file su USB

Scenario

Un’azienda romana sospetta che un dipendente abbia copiato un elenco clienti.

Fonti

- MFT;
- USN Journal;
- USBSTOR;
- SetupAPI;
- MountedDevices;
- MountPoints2;
- DLP;
- immagine della pendrive;
- logon.

Timeline

08:41:12 — account effettua login
08:43:09 — dispositivo configurato
08:43:14 — volume assegnato a E:
08:47:33 — archivio clienti.zip creato
08:49:02 — DLP registra scrittura su E:
08:49:08 — file presente sul supporto
08:51:44 — dispositivo rimosso

Conclusione prudente

“La convergenza tra sessione, collegamento del volume, creazione dell’archivio, evento DLP e presenza del file sul supporto risulta compatibile con una copia eseguita nell’intervallo indicato. L’attribuzione personale richiede la valutazione degli accessi fisici e dell’eventuale uso delle credenziali da parte di terzi.”

L’analisi si collega al capitolo su dipendente infedele, sottrazione dati e uso di USB.

110. Caso pratico 2 — Accesso abusivo a un account

Scenario

Un professionista di Roma riceve una notifica di accesso sospetto.

Fonti

• Entra ID;
• email;
• VPN;
• smartphone;
• cambio password;
• revoca sessioni.

Timeline

21:04 — phishing ricevuto
21:09 — link aperto
21:12 — login esterno
21:13 — MFA approvata
21:18 — regola email creata
22:02 — password cambiata
22:05 — sessioni revocate

Conclusione

“L’accesso esterno segue temporalmente l’apertura del link e precede la creazione della regola. La sequenza è compatibile con una compromissione delle credenziali, senza consentire di identificare la persona che ha controllato la sessione.”

Vedere il capitolo sugli accessi abusivi ad account email, social e cloud.

111. Caso pratico 3 — Ransomware

Scenario

Un’impresa romana subisce la cifratura dei server.

Timeline

giorno -7 — login VPN anomalo
giorno -6 — nuovo account
giorno -5 — movimento laterale
giorno -2 — accesso ai backup
giorno -1 — staging dati
02:11 — EDR disattivato
02:34 — cifratura iniziata
03:02 — alert SOC
03:18 — rete isolata

Limite

Il primo evento osservato non coincide necessariamente con il primo accesso assoluto.

Vedere il Capitolo 21 — Incident response forense e ransomware.

112. Caso pratico 4 — WhatsApp e telefonata

Scenario

Un cliente romano sostiene che un vocale sia stato inviato dopo una telefonata.

Risultati

• database WhatsApp in Unix ms;
• registro chiamate;
• smartphone avanti di 92 secondi;
• server telefonico in UTC;
• chat mostrata in ora locale.

Ricostruzione

Dopo la correzione:

telefonata terminata:
09:14:18 UTC

vocale inviato:
09:14:41 UTC

Conclusione

“Il vocale risulta inviato circa 23 secondi dopo la conclusione della telefonata, con un’incertezza stimata di ±2 secondi.”

113. Caso pratico 5 — Email e PEC

Scenario

Un avvocato di Roma deve verificare se una PEC preceda una comunicazione ordinaria.

Fonti

- EML;
- Received;
- ricevuta di accettazione;
- ricevuta di consegna;
- mailbox;
- file system.

Conclusione

“La ricevuta di accettazione e la successiva consegna documentano la sequenza PEC indicata. Il campo Date dell’email ordinaria è stato valutato insieme ai relativi header Received e non isolatamente.”

114. Caso pratico 6 — Download da SharePoint

Scenario

Un dipendente dimissionario scarica documenti da SharePoint.

Timeline

17:20 — login dispositivo
17:24 — sync OneDrive avviata
17:31 — eventi FileSyncDownloadedFull
17:48 — archivio locale creato
18:02 — browser apre servizio esterno
18:07 — proxy registra upload

Conclusione

“La sequenza è compatibile con una sincronizzazione dei documenti, la successiva creazione dell’archivio e un trasferimento verso il servizio esterno indicato.”

115. Caso pratico 7 — Videosorveglianza con clock drift

Scenario

Un DVR di un condominio romano mostra un evento alle 18:14:20.

Misurazioni

12:00 — DVR avanti di 3m52s
20:00 — DVR avanti di 4m08s

Correzione

È stata applicata una stima lineare documentata.

Conclusione

“Il tempo reale stimato dell’evento è 18:10:20, con incertezza di ±5 secondi derivante dalla misura dello scarto e dalla granularità del sistema.”

116. Caso pratico 8 — Fotografia e pubblicazione

Scenario

Una fotografia viene dichiarata scattata a Roma dopo un determinato evento.

Fonti

• EXIF;
• file system;
• cloud;
• post social;
• file RAW;
• immagini adiacenti.

Risultati

RAW acquisito:
14:02:11

upload cloud:
14:02:38

pubblicazione:
14:05:04

Conclusione

“Le fonti risultano temporalmente coerenti con uno scatto precedente alla pubblicazione di circa tre minuti. La data EXIF è stata confermata dalle fonti del dispositivo e del cloud.”

117. Caso pratico 9 — Bonifico fraudolento

Scenario

Una società romana riceve una falsa comunicazione di cambio IBAN.

Timeline

09:03 — email ricevuta
09:06 — allegato aperto
09:14 — telefonata del falso fornitore
09:21 — disposizione inserita
09:24 — secondo approvatore conferma
09:31 — banca registra esecuzione
10:02 — fornitore reale contattato

Conclusione

“La disposizione è stata inserita dopo la ricezione dell’email e la telefonata sospetta. La timeline documenta la sequenza tecnica, ma non attribuisce l’autore materiale delle comunicazioni.”

Il caso si collega a truffe online, bonifici fraudolenti e financial cybercrime.

118. Caso pratico 10 — Deepfake pubblicato online

Scenario

Un falso video viene attribuito a un professionista romano.

Fonti

• video autentico;
• deepfake;
• account;
• post;
• archive web;
• file system;
• C2PA.

Timeline

giorno -3 — video autentico pubblicato
giorno -1 — file scaricato da account anonimo
10:12 — deepfake creato o esportato, secondo metadata
10:28 — primo post
10:36 — ricondivisione
11:04 — acquisizione forense

Conclusione

“Il video contestato è successivo al contenuto autentico dal quale deriva. La data di creazione esatta del deepfake non è determinabile dal solo file; la prima pubblicazione osservabile è quella indicata.”

119. Caso pratico 11 — Dipendente e account condiviso

Scenario

Tre tecnici utilizzano lo stesso account amministrativo.

Risultati

• operazione registrata;
• jump server;
• badge di due tecnici;
• turno sovrapposto;
• nessun PAM;
• account condiviso.

Conclusione

“La timeline documenta l’operazione e la presenza contemporanea di due operatori autorizzati. L’organizzazione delle credenziali non consente di individualizzare l’autore.”

120. Caso pratico 12 — Evento assente

Scenario

Un’azienda sostiene che un file non sia mai stato scaricato perché il SIEM non contiene il relativo evento.

Verifica

- audit non abilitato sul workload;
- SIEM riceveva soltanto alert;
- retention scaduta;
- endpoint non disponibile.

Conclusione

“L’assenza del record non è significativa, poiché le fonti disponibili non garantivano la registrazione dell’operazione nel periodo.”

121. Errori da evitare

Errore 1 — Ordinare date senza comprenderne la semantica

Lo stesso valore può rappresentare creazione, importazione o visualizzazione.

Errore 2 — Convertire tutto in UTC eliminando l’originale

Si perde il contesto.

Errore 3 — Utilizzare soltanto l’ora locale

Si complicano le correlazioni tra sistemi.

Errore 4 — Applicare sempre UTC+1 o UTC+2 a Roma

L’offset dipende dalla data.

Errore 5 — Ignorare l’ora legale

Alcuni orari sono ambigui o inesistenti.

Errore 6 — Confondere offset e timezone

+02:00 non identifica da solo Europe/Rome.

Errore 7 — Aggiungere millisecondi inesistenti

Si crea falsa precisione.

Errore 8 — Confondere risoluzione e accuratezza

Un valore a 100 ns può provenire da un clock errato.

Errore 9 — Non verificare NTP

La correlazione può essere sbagliata.

Errore 10 — Applicare un offset fisso quando il drift varia

La correzione diventa inaccurata.

Errore 11 — Correggere silenziosamente i timestamp

La trasformazione deve essere visibile.

Errore 12 — Confondere wall clock e monotonic time

Hanno funzioni differenti.

Errore 13 — Ignorare i riavvii

Il tempo monotono riparte.

Errore 14 — Applicare la prima epoch plausibile

Un numero può usare unità differenti.

Errore 15 — Confondere Unix secondi e millisecondi

La data risultante può essere assurda.

Errore 16 — Confondere FILETIME e WebKit time

Usano unità differenti.

Errore 17 — Usare il modificatore SQLite auto indiscriminatamente

Può interpretare male alcuni valori.

Errore 18 — Ignorare il sistema data Excel

Si introducono differenze di 1.462 giorni.

Errore 19 — Considerare ctime Unix creazione

Indica modifica dei metadati.

Errore 20 — Considerare Last Access sempre aggiornato

Può essere ritardato o disabilitato.

Errore 21 — Ignorare la granularità FAT

La precisione può essere di due secondi o un giorno.

Errore 22 — Confondere $STANDARD_INFORMATION e $FILE_NAME

Sono insiemi di timestamp differenti.

Errore 23 — Considerare ogni divergenza NTFS timestomping

Può avere spiegazioni normali.

Errore 24 — Non acquisire USN Journal

Si perde la sequenza delle modifiche.

Errore 25 — Non acquisire file e log adiacenti

Si perde il contesto.

Errore 26 — Considerare il campo Date dell’email ora di consegna

È distinto dai Received.

Errore 27 — Ordinare i Received nel verso errato

I server aggiungono le righe in testa.

Errore 28 — Confondere ora visualizzata nella chat e database

L’interfaccia può applicare il fuso locale.

Errore 29 — Confondere data del file allegato e invio del messaggio

Sono eventi differenti.

Errore 30 — Considerare event time e ingest time equivalenti

Il collector può ricevere il record in ritardo.

Errore 31 — Usare soltanto il SIEM

Il dato normalizzato può perdere campi.

Errore 32 — Non acquisire il raw event

La verifica non è riproducibile.

Errore 33 — Eliminare i duplicati dagli originali

Si altera il dataset.

Errore 34 — Non documentare la chiave di deduplicazione

Il risultato non è verificabile.

Errore 35 — Interpretare eventi con lo stesso secondo come ordinati

La fonte può non avere precisione sufficiente.

Errore 36 — Confondere successione e causalità

A prima di B non significa A causa B.

Errore 37 — Ignorare i gap

La timeline appare falsamente completa.

Errore 38 — Trattare l’assenza di evento come prova negativa

Il logging potrebbe non coprirlo.

Errore 39 — Non separare eventi originari e dedotti

La relazione diventa fuorviante.

Errore 40 — Non registrare le attività del perito

Si confondono eventi investigativi e precedenti.

Errore 41 — Usare un solo parser

Un errore può non essere rilevato.

Errore 42 — Non conservare le versioni degli strumenti

L’analisi non è riproducibile.

Errore 43 — Non conservare il file Plaso

Si perde il dataset strutturato.

Errore 44 — Esportare soltanto una timeline filtrata

Potrebbero mancare eventi correlati.

Errore 45 — Non verificare gli eventi decisivi manualmente

Il parser può avere limiti.

Errore 46 — Importare in Timesketch dati non minimizzati

Si espongono informazioni estranee.

Errore 47 — Attivare funzioni AI esterne senza verifica

La timeline può lasciare l’ambiente controllato.

Errore 48 — Affidare l’interpretazione all’AI

Il risultato deve essere verificato dal perito.

Errore 49 — Utilizzare Excel come unica copia della timeline

Può convertire automaticamente date e identificativi.

Errore 50 — Ordinare stringhe non normalizzate

10/11/2026 può essere ambiguo.

Errore 51 — Non conservare il timezone database usato

Le regole storiche possono essere aggiornate.

Errore 52 — Non indicare l’incertezza

La conclusione appare più precisa della fonte.

Errore 53 — Trasformare intervalli in istanti

Si perde la durata.

Errore 54 — Attribuire un account a una persona

Le credenziali possono essere condivise o compromesse.

Errore 55 — Attribuire un IP a una persona

Può essere dinamico, NAT o VPN.

Errore 56 — Confondere dispositivo e utilizzatore

Il dispositivo può essere controllato da terzi.

Errore 57 — Considerare la prima evidenza come patient zero assoluto

Può esistere un evento precedente non registrato.

Errore 58 — Correggere il drift sulla base di un solo punto

Manca la variazione nel tempo.

Errore 59 — Applicare una regressione complessa senza dati sufficienti

Si crea precisione artificiale.

Errore 60 — Ignorare l’orologio del DVR

Il timestamp visibile può essere errato.

Errore 61 — Confondere il tempo del media con il tempo dell’evento

PTS e data del file sono differenti.

Errore 62 — Confondere data EXIF e pubblicazione

Sono eventi distinti.

Errore 63 — Non acquisire il cloud originario

Può contenere versioni precedenti.

Errore 64 — Non preservare i log prima della scadenza

La ricostruzione può diventare impossibile.

Errore 65 — Presentare milioni di eventi nella relazione

Serve una selezione motivata.

Errore 66 — Omettere il dataset completo

La selezione deve restare verificabile.

Errore 67 — Utilizzare colori o grafici senza legenda

La presentazione può confondere.

Errore 68 — Non distinguere fatti e dichiarazioni

Una testimonianza non è un log.

Errore 69 — Non considerare fonti indipendenti

Una sola infrastruttura può condividere lo stesso errore.

Errore 70 — Formulare conclusioni giuridiche

Il perito deve restare nell’ambito tecnico.

122. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] incarico;
[ ] quesito;
[ ] periodo;
[ ] sistemi;
[ ] soggetti;
[ ] privacy;
[ ] limiti;
[ ] legale.

Fase 2 — Preservazione

[ ] dispositivi;
[ ] account;
[ ] log;
[ ] cloud;
[ ] database;
[ ] file system;
[ ] media;
[ ] backup.

Fase 3 — Clock inventory

[ ] UTC;
[ ] ora locale;
[ ] timezone;
[ ] NTP;
[ ] offset;
[ ] drift;
[ ] boot time;
[ ] modifiche manuali.

Fase 4 — Registro delle fonti

[ ] evidence ID;
[ ] fonte;
[ ] formato;
[ ] epoch;
[ ] unità;
[ ] precisione;
[ ] semantica;
[ ] retention.

Fase 5 — Acquisizione

[ ] formato nativo;
[ ] raw event;
[ ] export;
[ ] query;
[ ] hash;
[ ] errori;
[ ] conteggio;
[ ] account di acquisizione.

Fase 6 — Interpretazione temporale

[ ] event time;
[ ] ingest time;
[ ] processing time;
[ ] export time;
[ ] istante;
[ ] intervallo;
[ ] incertezza;
[ ] offset.

Fase 7 — Normalizzazione

[ ] valore grezzo;
[ ] formato;
[ ] timezone;
[ ] UTC;
[ ] correzione;
[ ] precisione;
[ ] raw reference;
[ ] parser.

Fase 8 — Correlazione

[ ] account;
[ ] dispositivo;
[ ] sessione;
[ ] IP;
[ ] porta;
[ ] file ID;
[ ] hash;
[ ] correlation ID.

Fase 9 — Super timeline

[ ] file system;
[ ] Windows;
[ ] Linux/macOS;
[ ] mobile;
[ ] browser;
[ ] chat;
[ ] rete;
[ ] cloud.

Fase 10 — Mini-timeline

[ ] quesito;
[ ] eventi chiave;
[ ] intervallo;
[ ] fonti;
[ ] spiegazioni;
[ ] alternative;
[ ] limiti.

Fase 11 — Verifica

[ ] record originari;
[ ] parser alternativo;
[ ] duplicati;
[ ] gap;
[ ] clock;
[ ] fonti indipendenti;
[ ] eventi impossibili;
[ ] anti-forensics.

Fase 12 — Presentazione

[ ] tabella;
[ ] grafico;
[ ] legenda;
[ ] UTC;
[ ] ora Roma;
[ ] precisione;
[ ] confidence;
[ ] riferimenti.

Fase 13 — Relazione

[ ] materiale;
[ ] metodo;
[ ] fonti;
[ ] normalizzazione;
[ ] clock correction;
[ ] risultati;
[ ] limiti;
[ ] conclusioni.

123. Checklist finale

Fonti

[ ] tutte le fonti censite;
[ ] formati nativi;
[ ] retention verificata;
[ ] query conservate;
[ ] hash calcolati;
[ ] errori registrati.

Tempo

[ ] timestamp grezzi;
[ ] epoch;
[ ] unità;
[ ] timezone;
[ ] offset;
[ ] UTC;
[ ] precisione;
[ ] incertezza.

Clock

[ ] NTP;
[ ] drift;
[ ] step;
[ ] riavvii;
[ ] modifica manuale;
[ ] fonte di riferimento.

Timeline

[ ] super timeline;
[ ] mini-timeline;
[ ] duplicati;
[ ] deduplicazione documentata;
[ ] eventi dedotti contrassegnati;
[ ] gap indicati.

Correlazione

[ ] account;
[ ] sessione;
[ ] dispositivo;
[ ] IP;
[ ] file;
[ ] cloud;
[ ] fonte fisica;
[ ] alternative.

Strumenti

[ ] Plaso;
[ ] pinfo;
[ ] psort;
[ ] Timesketch;
[ ] TSK;
[ ] versioni;
[ ] comandi;
[ ] log.

Relazione

[ ] fatti distinti dalle deduzioni;
[ ] successione distinta dalla causalità;
[ ] account distinto dalla persona;
[ ] false precisioni eliminate;
[ ] limiti dichiarati;
[ ] allegati verificabili.

124. Output minimo dell’accertamento

1. incarico;
2. verbale;
3. registro delle fonti;
4. inventario degli orologi;
5. timezone e configurazioni;
6. output NTP;
7. misure di clock drift;
8. reperti originari;
9. manifesti SHA-256;
10. file system timeline;
11. MFT;
12. USN Journal;
13. Windows Event Log;
14. Registro;
15. Prefetch;
16. Amcache;
17. browser;
18. email;
19. PEC;
20. chat;
21. smartphone;
22. log di rete;
23. cloud audit;
24. file multimediali;
25. Plaso storage;
26. pinfo report;
27. psort UTC;
28. psort Europe/Rome;
29. output completo con duplicati;
30. output deduplicato;
31. file di tagging;
32. export Timesketch;
33. query;
34. timeline grezza;
35. timeline normalizzata;
36. timeline corretta;
37. mini-timeline;
38. tabella dei gap;
39. tabella delle incertezze;
40. matrice delle evidenze;
41. grafici;
42. relazione tecnica;
43. allegati;
44. manifesto finale degli hash.

125. Struttura della relazione tecnica

125.1 Incarico

• committente;
• quesito;
• periodo;
• sistemi;
• limiti.

125.2 Materiale

• reperti;
• log;
• database;
• account;
• cloud;
• hash.

125.3 Orologi

• timezone;
• UTC;
• NTP;
• offset;
• drift;
• riavvii;
• modifiche.

125.4 Fonti temporali

Per ciascuna:

• formato;
• epoch;
• unità;
• precisione;
• semantica;
• retention;
• affidabilità.

125.5 Metodo

• acquisizione;
• strumenti;
• versioni;
• parser;
• normalizzazione;
• correzioni;
• deduplicazione.

125.6 Timeline

• eventi;
• fonti;
• timestamp grezzi;
• UTC;
• ora locale;
• confidence;
• collegamenti.

125.7 Correlazioni

• account;
• dispositivo;
• rete;
• file;
• cloud;
• fonti fisiche.

125.8 Gap

• intervallo;
• fonte;
• causa;
• conseguenza;
• alternativa.

125.9 Ipotesi

• ricostruzione principale;
• spiegazioni alternative;
• elementi favorevoli;
• elementi contrari;
• dati mancanti.

125.10 Conclusioni

Risposte tecniche proporzionate al quesito.

126. Modelli di frasi tecniche

126.1 Timestamp originario

“Il valore è riportato nella forma originariamente memorizzata dalla fonte.”

126.2 Normalizzazione

“Il timestamp è stato convertito in UTC mantenendo separatamente il valore grezzo, il fuso e l’offset originari.”

126.3 Precisione

“La fonte registra il tempo con precisione al secondo; non sono pertanto significative ulteriori frazioni.”

126.4 Falsa precisione

“La visualizzazione con millisecondi deriva dal formato di output e non dalla precisione originaria del record.”

126.5 UTC

“UTC è stato utilizzato quale riferimento comune per la correlazione tra sistemi.”

126.6 Ora di Roma

“La vista locale è stata calcolata secondo la zona Europe/Rome e le regole applicabili alla data.”

126.7 Offset sconosciuto

“La fonte non consente di determinare l’offset locale originario; il valore non è stato convertito in modo assertivo.”

126.8 Ora legale

“L’orario locale ricade nell’intervallo ambiguo del cambio stagionale e richiede l’offset per distinguere le due occorrenze.”

126.9 Clock drift

“L’orologio presentava lo scarto indicato rispetto alla fonte di riferimento.”

126.10 Correzione

“La timeline conserva sia il valore registrato sia il valore corretto secondo il criterio descritto.”

126.11 Incertezza

“Il tempo reale dell’evento è stimato nell’intervallo indicato, tenendo conto di risoluzione e scarto.”

126.12 Event time

“Il record documenta il tempo dichiarato dell’evento e non il momento di ricezione da parte del collector.”

126.13 Ingest time

“Il valore rappresenta l’ingestione nel sistema centrale e può essere successivo all’evento.”

126.14 File system

“Il timestamp documenta una proprietà del file system e non identifica automaticamente l’operazione applicativa che l’ha prodotta.”

126.15 Last Access

“L’ultimo accesso non è stato utilizzato quale indicatore autonomo, considerati configurazione e comportamento del file system.”

126.16 Registro

“La LastWrite documenta la modifica della chiave e non necessariamente l’utilizzo dell’oggetto rappresentato.”

126.17 Email

“Il campo Date è stato valutato congiuntamente alle informazioni Received e alla data interna della mailbox.”

126.18 Chat

“L’ora visualizzata nell’interfaccia è stata distinta dal timestamp memorizzato nel database.”

126.19 Cloud

“L’evento è quello reso disponibile dal provider secondo configurazione, licenza e retention applicabili.”

126.20 Eventi simultanei

“I record ricadono nello stesso intervallo di precisione e il loro ordine relativo non è determinabile.”

126.21 Successione

“L’evento A precede temporalmente l’evento B nelle fonti normalizzate.”

126.22 Causalità

“La successione temporale non dimostra autonomamente un rapporto causale.”

126.23 Correlazione

“La convergenza tra identificativi, account e intervallo supporta l’associazione dei record alla stessa sessione.”

126.24 Evento dedotto

“L’evento di alto livello è una ricostruzione derivata dai record elencati e non un singolo log originario.”

126.25 Gap

“La ricostruzione presenta la lacuna temporale indicata, dovuta alla mancata disponibilità della fonte.”

126.26 Evidenza negativa

“L’assenza dell’evento non dimostra che l’attività non sia avvenuta, poiché il logging non garantiva la relativa registrazione.”

126.27 Primo evento osservato

“Il record rappresenta il primo evento individuato nelle fonti disponibili e non necessariamente il primo evento assoluto.”

126.28 Timestomping

“Le divergenze temporali sono compatibili con un’alterazione dei timestamp, ma richiedono correlazione con journal e fonti applicative.”

126.29 Account

“L’evento è associato all’utenza informatica e non identifica autonomamente la persona che ne controllava le credenziali.”

126.30 IP

“L’indirizzo IP identifica la connessione osservata nel momento indicato, non automaticamente una persona fisica.”

126.31 Plaso

“La super timeline è stata prodotta mediante la versione e i parser indicati; gli eventi decisivi sono stati verificati sulle fonti originarie.”

126.32 Timesketch

“Timesketch è stato utilizzato per ricerca, annotazione e correlazione, senza sostituire i reperti e gli export originari.”

126.33 Conclusione prudente

“Nei limiti delle fonti disponibili, la sequenza risulta compatibile con la ricostruzione indicata, senza escludere le alternative tecnicamente plausibili descritte.”

127. Immagini e figure suggerite

128. Riferimenti tecnici e normativi esterni

1. NIST — An Abstract Model for Digital Forensic Analysis Tools — timeline analysis, inaccurate clocks e rischi interpretativi.
2. NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response — raccolta, esame, analisi e reporting.
3. Plaso — User’s Guide e log2timeline — estrazione automatica degli eventi e storage strutturato.
4. Plaso — psort — output, timezone, filtri, deduplicazione e analisi.
5. Plaso — pinfo — metadati della raccolta e conteggio dei parser.
6. Plaso — Event filters — sintassi e helper temporale DATETIME().
7. Timesketch — Basic concepts — timeline collaborative, viste e annotazioni.
8. Timesketch — Upload Data — import di Plaso, CSV e JSONL.
9. Timesketch — Investigation View — trattamento dei dati tramite servizi AI esterni configurati.
10. The Sleuth Kit — mactime — timeline del file system.
11. RFC 3339 — formato e offset numerici.
12. RFC 9557 — informazioni aggiuntive sul fuso.
13. IANA Time Zone Database — storia delle regole locali e dell’ora legale.
14. RFC 5905 — NTPv4 — offset, jitter e sincronizzazione.
15. RFC 8633 — Network Time Protocol Best Current Practices.
16. Microsoft — File Times e FILETIME — UTC, FAT, NTFS e granularità.
17. Microsoft — NTFS Attribute Types — struttura degli attributi del file system.
18. systemd — Journal fields — realtime e monotonic timestamps.
19. Apple — CFAbsoluteTime — epoch del 1° gennaio 2001.
20. SQLite — Date and Time Functions — Unix time, Julian day e caveat di conversione.
21. Microsoft — Date systems in Excel — sistemi 1900 e 1904.
22. RFC 5322 — Date e Received nelle email.
23. SWGDE — Best Practices for Computer Forensic Examinations — integrità e analisi dei supporti.
24. SWGDE — Digital Evidence Collection — preparazione, perimetro e conservazione.
25. GDPR — Regolamento UE 2016/679 — principi e sicurezza del trattamento.
26. Garante privacy — Regole deontologiche per investigazioni difensive.

129. Collegamenti interni consigliati

Capitolo precedente

• Immagini, fotografie manipolate e contenuti generati con AI

Capitolo successivo

• Relazione tecnica, CTP informatico e contestazione delle prove digitali

Capitoli correlati

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Copia forense di hard disk, SSD, pendrive e NAS
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp: messaggi, vocali e allegati
• Telegram, Signal e app di messaggistica forensics
• Recupero dati cancellati per fini probatori
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• PDF, firme digitali e marche temporali
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Diffamazione online, cyberbullismo, stalking digitale e revenge porn
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Analisi di log aziendali, firewall, VPN e sistemi cloud
• Incident response forense e ransomware
• Dipendente infedele, sottrazione dati e uso di USB
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Autenticità audio: tagli, montaggi e ricodifiche
• Voice cloning e audio generati con intelligenza artificiale
• Autenticità video: frame, codec, tagli e montaggi
• Analisi video deepfake e face swapping

130. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/incident-response-forense/
/servizi/analisi-smartphone-computer/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

Anchor text consigliati

timeline forense a Roma
ricostruzione cronologica di eventi informatici
analisi dei timestamp digitali
super timeline Plaso
analisi timeline con Timesketch
correlazione di log e dispositivi
ricostruzione di accessi informatici
timeline di un ransomware
timeline WhatsApp e smartphone
timeline cloud Microsoft e Google
verifica del clock drift
perizia cronologica digitale
consulente informatico forense per timeline a Roma

[ ] ricostruzione di accessi informatici;
[ ] timeline di computer Windows;
[ ] timeline macOS e Linux;
[ ] timeline Android e iPhone;
[ ] cronologia WhatsApp, Telegram e Signal;
[ ] timeline di email e PEC;
[ ] analisi dei log firewall e VPN;
[ ] correlazione Microsoft 365 e Google Workspace;
[ ] ricostruzione di ransomware;
[ ] analisi di copie su USB;
[ ] timeline di pubblicazioni web e social;
[ ] verifica delle date di fotografie, audio e video;
[ ] analisi UTC, fusi e ora legale;
[ ] misurazione del clock drift;
[ ] super timeline con Plaso;
[ ] analisi collaborativa con Timesketch;
[ ] relazione tecnica e supporto CTP.

132. Conclusione del capitolo

La timeline forense non è un elenco di date.

È una ricostruzione che deve collegare:

fonte
→ timestamp
→ semantica
→ fuso
→ clock
→ precisione
→ correlazione
→ evento
→ conclusione

Un file creato alle 10:15 non dimostra da solo che sia stato copiato in quel momento.

Un messaggio visualizzato alle 09:30 può essere stato memorizzato in UTC, convertito dall’app e mostrato secondo il fuso corrente.

Un accesso cloud può essere registrato secondo l’ora del provider mentre il computer locale presenta uno scarto.

Un evento con sette cifre decimali può essere meno accurato di un record al secondo proveniente da un server sincronizzato.

Un gap non dimostra una cancellazione intenzionale.

L’assenza di un log non dimostra l’assenza dell’attività.

La prima evidenza individuata non coincide necessariamente con il primo evento assoluto.

Formula da ricordare: una timeline affidabile conserva il tempo originario, esplicita ogni trasformazione, misura l’incertezza e distingue i record osservati dagli eventi dedotti.

Una relazione tecnicamente corretta deve indicare:

- quali fonti sono state acquisite;
- quali orologi erano coinvolti;
- quali fusi sono stati applicati;
- quali epoch sono state convertite;
- quale precisione possiede ogni fonte;
- quali correzioni sono state eseguite;
- quali eventi sono originari;
- quali eventi sono dedotti;
- quali gap sono presenti;
- quali alternative restano plausibili;
- quali limiti impediscono conclusioni più forti.

Il compito dell’informatica forense non è produrre una sequenza apparentemente perfetta.

È costruire una cronologia:

• verificabile;
• riproducibile;
• trasparente;
• prudente;
• proporzionata alle fonti disponibili.

133. Anticipazione del capitolo successivo

Capitolo 30 — Relazione tecnica, CTP informatico e contestazione delle prove digitali

Il prossimo e ultimo capitolo del manuale tratterà:

• definizione dell’incarico;
• quesito tecnico;
• ruolo del CTP;
• differenza tra CTP, CTU e consulente stragiudiziale;
• acquisizione del materiale;
• verbali;
• catena di custodia;
• struttura della relazione;
• metodo;
• strumenti e versioni;
• risultati;
• allegati;
• hash;
• timeline;
• formule tecniche prudenti;
• distinzione tra fatti e deduzioni;
• valutazione delle ipotesi alternative;
• limiti dell’accertamento;
• contestazione di screenshot;
• contestazione di chat;
• contestazione di email;
• contestazione di file e metadati;
• contestazione di copie forensi;
• contestazione di audio, video, deepfake e immagini AI;
• osservazioni alla CTU;
• note critiche;
• contraddittorio tecnico;
• udienza;
• deposito;
• protezione dei dati;
• gestione dei reperti;
• casi pratici ambientati a Roma;
• checklist finale dell’intero manuale.