Fuso orario ed errori dell'orologio

Un timestamp può essere decodificato perfettamente ed essere comunque errato: memorizzato nell'ora locale e riportato come UTC, convertito con le regole attuali anziché con quelle in vigore quel giorno, spostato dallo strumento dell'analista oppure registrato da un orologio che presentava uno scarto di minuti o anni. Questa lezione illustra quali fonti memorizzano l'ora UTC e quali l'ora locale, come convertire i valori locali e come misurare, documentare e correggere un errore dell'orologio di un dispositivo. Il Modulo 7 tratta la manipolazione deliberata dell'orologio; qui l'obiettivo è interpretare correttamente i timestamp non manipolati.

Tre orologi in ogni caso

Nelle annotazioni, mantenere distinti tre orologi:

1. Ora reale (UTC): quando l'evento si è effettivamente verificato. È questa l'ora che deve essere indicata nella relazione.
2. L'orologio di sistema del dispositivo: l'ora che il computer riteneva corretta. Gli artefatti registrano questo orologio, mai l'ora reale. Se era avanti di 7 minuti, ogni timestamp scritto indica un'ora successiva di 7 minuti.
3. L'orologio di visualizzazione: il modo in cui uno strumento mostra un valore sulla postazione dell'analista. Visualizzatore eventi, ad esempio, mostra gli orari EVTX memorizzati in UTC nel fuso orario del computer su cui vengono visualizzati.

Gli errori derivano dalla loro confusione.

Fonti UTC e fonti in ora locale

Due formati si collocano in una posizione intermedia. exFAT memorizza l'ora locale più un byte di scostamento UTC per ogni timestamp, utilizzabile soltanto quando il relativo bit di validità è impostato (Lezione 1.5). EXIF 2.31 e versioni successive possono aggiungere OffsetTimeOriginal, ad esempio -03:00. Anche un log testuale che scrive uno scostamento, come [14/Mar/2026:09:21:07 -0300] di Apache, è privo di ambiguità. In assenza di un simile indicatore, presumere che si tratti di ora locale e stabilire di chi: dell'host oppure di una fotocamera la cui ora non è mai stata impostata.

L'orologio hardware in tempo reale (RTC) introduce un'ulteriore insidia: Windows lo mantiene nell'ora locale per impostazione predefinita, mentre la maggior parte delle distribuzioni Linux lo mantiene in UTC; pertanto, un computer con doppio avvio può presentare un errore pari allo scostamento del fuso orario fino alla risincronizzazione.

Conversione dell'ora locale in UTC

Windows memorizza gli scostamenti come bias in minuti, con segno opposto rispetto alla consueta notazione "UTC−3": bias = −(scostamento UTC), e UTC = ora locale + bias. UTC−3 ha un bias di +180; UTC+1 ha un bias di −60. Durante l'ora legale (DST), il bias effettivo è Bias + DaylightBias (solitamente −60), quindi per l'ora legale dell'Europa centrale è −60 + (−60) = −120. La Lezione 2.2 mostra dove si trovano questi valori in TimeZoneInformation.

Ore mancanti e ripetute

Al passaggio da o verso l'ora legale, l'ora locale compie un salto. Nell'Europa centrale, il 2026-03-29 gli orologi sono passati dalle 01:59:59 CET alle 03:00:00 CEST, quindi quel giorno gli orari locali dalle 02:00 alle 02:59 non esistono. Il 2026-10-25 sono tornati dalle 02:59:59 CEST alle 02:00:00 CET, quindi ogni orario locale dalle 02:00 alle 02:59 si è verificato due volte, una a UTC+2 e una a UTC+1. Una riga di log in ora locale alle 02:30 di quel giorno presenta un'ambiguità di un'ora. Risolverla mediante le voci adiacenti o una fonte UTC e indicare come è stata risolta.

Utilizzare la regola in vigore alla data dell'evento

ActiveTimeBias descrive il momento dell'ultima scrittura della chiave, non la data dell'evento in esame. Anche le regole dei fusi orari cambiano per legge. Il Brasile ha abolito l'ora legale nel 2019; il suo ultimo periodo di ora legale è terminato il 2019-02-17. Un host di Brasília acquisito nel 2026 mostra ActiveTimeBias 180, ma una riga di log locale del 2018-12-10 10:00 è stata scritta a UTC−2 e corrisponde alle 12:00Z, non alle 13:00Z. Convertire ogni valore con le regole della relativa data, utilizzando un database dei fusi orari aggiornato (il database tz di IANA) oppure le regole annuali che Windows conserva in SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<zone>\Dynamic DST.

Non lasciare mai che uno strumento scelga il fuso orario

Molti strumenti applicano senza segnalarlo il fuso orario della postazione dell'analista:

• Impostare la postazione di analisi su UTC, in modo che un eventuale ricorso all'ora "locale" sia innocuo.
• In Plaso, indicare esplicitamente il fuso orario di output: psort.py --output_time_zone UTC. Quando vengono analizzate fonti in ora locale, come i volumi FAT, passare il fuso orario del dispositivo con log2timeline.py --timezone (Lezione 3.3).
• Negli strumenti con interfaccia grafica, controllare le impostazioni di visualizzazione. Le opzioni di visualizzazione di Autopsy selezionano il fuso orario utilizzato per la visualizzazione. Timeline Explorer mostra i timestamp del CSV che apre, quindi produrre tale CSV in UTC e impostarne il formato della data in modo da mostrare secondi e frazioni. Quindi verificare una riga rispetto a un valore decodificato manualmente.
• I fogli di calcolo sono pericolosi. Excel converte il testo che sembra una data in numeri seriali privi di fuso orario, nasconde secondi e frazioni nel formato di visualizzazione predefinito e, con alcune impostazioni internazionali, può invertire giorno e mese nella lettura. Importare le colonne dei timestamp come testo.

Scarto e deriva dell'orologio

Lo scarto è la differenza tra l'orologio del dispositivo e l'ora reale in un determinato momento. La deriva è la velocità con cui tale differenza cambia. Un orologio al quarzo non sincronizzato con un errore di 20 parti per milione guadagna o perde circa 1,7 secondi al giorno (20 × 10⁻⁶ × 86.400 s), quindi un dispositivo non sincronizzato può accumulare uno scarto di minuti dopo alcuni mesi. La sincronizzazione corregge l'orologio mediante correzione graduale (facendolo avanzare leggermente più velocemente o più lentamente fino all'allineamento) oppure mediante correzione a salto istantanea. Solo le correzioni a salto lasciano una registrazione di "modifica dell'ora".

Misurazione dello scarto

Confrontare l'orologio del dispositivo con un riferimento attendibile:

• Registrazioni della sincronizzazione NTP. Gli eventi del provider Microsoft-Windows-Time-Service nel registro Sistema mostrano la sincronizzazione: l'evento 35 indica la fonte oraria con cui il servizio si sta sincronizzando e l'evento 37 indica che il provider NtpClient sta ricevendo dati orari validi. Mostrano che la sincronizzazione funzionava, non l'entità di una correzione.
• Evento 1 di Kernel-General (provider Microsoft-Windows-Kernel-General, registro Sistema): registra una modifica dell'ora di sistema con OldTime e NewTime, entrambi in UTC. La differenza è l'entità del salto.
• Evento di sicurezza 4616, "L'ora di sistema è stata modificata": viene registrato quando è abilitata la sottocategoria di controllo Modifica stato di sicurezza. Aggiunge PreviousTime, NewTime, l'account e il processo. Le correzioni ordinarie eseguite dal servizio Ora di Windows mostrano solitamente l'account LOCAL SERVICE; una modifica tramite un processo dell'utente merita attenzione.
• Timestamp lato server scritti da un orologio sincronizzato in relazione alla stessa azione: le intestazioni Received: aggiunte dai server di posta, il log degli accessi di un server web oppure l'intestazione di risposta HTTP Date: conservata in una voce della cache del browser. L'intestazione Last-Modified: di un server fornisce un limite inferiore: un download non può essere creato localmente prima dell'ultima modifica del contenuto sul server.
• Al momento dell'acquisizione, registrare l'orologio del dispositivo accanto a un riferimento attendibile. Questo misura lo scarto al momento dell'acquisizione, non necessariamente quello precedente.

Documentazione e applicazione di una correzione

Annotare il riferimento, il modo in cui è stato ricavato lo scarto, l'intervallo a cui si applica e l'incertezza residua. Applicare la correzione soltanto tra eventi noti dell'orologio: uno scarto misurato dopo un salto non si applica al periodo precedente. Conservare nella relazione il valore originale accanto a quello corretto.

Eventi fuori ordine

Un salto all'indietro fa sì che un intervallo di letture dell'orologio si presenti due volte, quindi l'ordinamento temporale mescola eventi non correlati; un salto in avanti lascia un vuoto. Dopo un guasto della batteria RTC o un ripristino del firmware (BIOS/CMOS), l'orologio può ripartire da una data predefinita del firmware, producendo eventi "nel 2001" o in un altro anno remoto finché non viene nuovamente impostato; un orologio impostato troppo avanti crea file "nel futuro". Questi schemi sono conseguenze normali di modifiche hardware e manuali, non prove di manipolazione. Cercare l'evento Kernel-General 1 o 4616 che li spiega e ripristinare l'ordine reale mediante numeri di sequenza che non dipendono dall'orologio: EventRecordID di EVTX, numeri di sequenza degli aggiornamenti del journal USN, numeri di sequenza di $LogFile.

Gli orari di acquisizione non sono gli orari delle evidenze

Gli orari prodotti dall'acquisizione stessa, come gli orari del file system dei file copiati in una cartella di triage e l'ora di acquisizione, descrivono il lavoro dell'analista, non quello dell'utente (Lezione 3.3). Escluderli dalla timeline degli eventi e utilizzare il registro di acquisizione per misurare lo scarto e documentare la catena di custodia.

Precisione e correlazione

Un valore DOS indica un incremento di due secondi. A seconda del componente che lo ha scritto, l'ora reale è stata troncata al secondo pari precedente oppure arrotondata a quello successivo, quindi può trovarsi fino a 2 secondi prima o dopo il valore memorizzato. Quando si confronta un valore DOS con un FILETIME, considerare tale intervallo; una differenza di 1 secondo non indica due eventi. L'esame pratico CFX accetta una risposta relativa a un timestamp entro ±1 secondo, scritta in UTC con Z, ad esempio 2026-03-16T09:20:14Z. Riportare il valore dell'artefatto indicato nel compito, convertito esattamente, senza arrotondarlo per avvicinarlo a un'altra fonte.

Esempio svolto 1: un file FAT32 e la $MFT dell'host

Un'immagine di un'unità USB FAT32 contiene plan.docx (nome breve PLAN~1.DOC). Nella sua voce di directory, la word dell'ora all'offset 0x16 è 87 32 e la word della data all'offset 0x18 è 70 5C:

• Ora 0x3287: ora = 0x3287 >> 11 = 6; minuti = (0x3287 >> 5) & 0x3F = 20; secondi = (0x3287 & 0x1F) × 2 = 7 × 2 = 14, quindi 06:20:14.
• Data 0x5C70: anno = (0x5C70 >> 9) + 1980 = 46 + 1980 = 2026; mese = (0x5C70 >> 5) & 0x0F = 3; giorno = 0x5C70 & 0x1F = 16, quindi 2026-03-16.

Il valore TimeZoneKeyName dell'host è E. South America Standard Time e ActiveTimeBias è 180. In Brasile non era in vigore l'ora legale nel 2026, quindi a quella data si applica 180: 06:20:14 + 180 minuti = 2026-03-16T09:20:14Z.

La $MFT dell'host contiene C:\Users\ana\Desktop\plan.docx con un'ora di modifica $SI pari a 2026-03-16T09:20:12.7Z. La differenza è di 1,3 secondi, inferiore alla risoluzione DOS di 2 secondi, quindi i valori sono compatibili con un'unica modifica: una copia mantiene l'ora di modifica del file e Windows la arrotonda al secondo pari successivo su FAT. Se ricavata dall'unità USB, la risposta è 2026-03-16T09:20:14Z.

Esempio svolto 2: un orologio avanti di 7 minuti

Su un altro host, il registro Sistema contiene l'evento 1 di Kernel-General con OldTime 2026-03-18T13:47:31.5Z e NewTime 2026-03-18T13:40:31.5Z. Il salto è 13:47:31.5 − 13:40:31.5 = −7 min 00 s: l'orologio era avanti di 7 minuti prima delle 13:47:31.5 secondo l'ora del dispositivo. Non risultano modifiche precedenti dell'ora dall'avvio, quindi lo scarto si applica all'intera mattinata.

Verificare con un orologio indipendente: la voce della cache del browser relativa al download memorizza l'intestazione Date: del server, 13:22:03Z. Ora del dispositivo 13:29:05 − 13:22:03 = 7 min 02 s, compatibile con uno scarto di 7 minuti più 2 secondi di trasferimento. Documentare l'ID del record dell'evento, lo scarto, il relativo intervallo ed entrambi i valori per ogni riga.

Focus sull'esame: È richiesta la conversione in UTC di artefatti in ora locale, come timestamp FAT, righe di setupapi.dev.log o date EXIF, utilizzando il bias e le regole in vigore alla data dell'evento. Occorre saper leggere OldTime e NewTime dall'evento 1 di Kernel-General o dall'evento 4616 e correggere i timestamp precedenti in base al salto. Le domande di abbinamento possono associare un valore DOS con risoluzione di 2 secondi a un FILETIME; una differenza inferiore a 2 secondi non indica un evento diverso.

Punti chiave

• Separare l'ora UTC reale, l'orologio del dispositivo e la visualizzazione dello strumento; gli artefatti registrano soltanto l'orologio del dispositivo.
• Gli orari FILETIME, Unix e APFS sono in UTC; FAT/DOS, molti log testuali, alcuni valori SYSTEMTIME ed EXIF DateTimeOriginal sono in ora locale; exFAT può contenere uno scostamento UTC valido.
• UTC = ora locale + bias, con bias = −(scostamento UTC) e applicando l'ora legale e le regole di legge della data dell'evento, non il valore attuale di ActiveTimeBias.
• Imporre UTC in ogni strumento e impedire ai fogli di calcolo di reinterpretare i timestamp.
• Misurare lo scarto rispetto a riferimenti attendibili (Kernel-General 1, 4616, intestazioni dei server, annotazioni di acquisizione) e applicare le correzioni soltanto nell'intervallo a cui si riferiscono.
• Tenere conto della risoluzione: gli orari di modifica DOS sono valori con risoluzione di 2 secondi e l'esame accetta ±1 s in UTC con Z.