Errori di fuso orario e dell'orologio

Un timestamp può essere decodificato perfettamente ed essere comunque errato: memorizzato in ora locale e riportato come UTC, convertito con le regole odierne anziché con quelle in vigore nel giorno in questione, alterato dallo strumento dell'analista oppure registrato da un orologio con uno scarto di minuti o anni. Questa lezione illustra quali fonti memorizzano l'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 intenzionale dell'orologio; qui l'obiettivo è interpretare correttamente i timestamp non manipolati.

Tre orologi in ogni caso

Nelle annotazioni, tenere distinti tre orologi:

1. Ora reale (UTC): quando l'evento si è effettivamente verificato. È ciò che deve essere indicato 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. Il Visualizzatore eventi, ad esempio, mostra gli orari EVTX memorizzati in UTC nel fuso orario del computer su cui vengono visualizzati.

Gli errori derivano dalla confusione tra questi orologi.

Fonti UTC e fonti in ora locale

Due formati si collocano in una posizione intermedia. exFAT memorizza l'ora locale più un byte di offset UTC per ciascun timestamp, utilizzabile solo 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 riporta un offset, come [14/Mar/2026:09:21:07 -0300] di Apache, è privo di ambiguità. In assenza di un indicatore di questo tipo, presumere che si tratti di ora locale e individuare a quale dispositivo si riferisca: all'host oppure a una fotocamera il cui orologio non è mai stato impostato.

L'orologio hardware in tempo reale (RTC) introduce un'ulteriore insidia: Windows lo mantiene per impostazione predefinita in ora locale, mentre la maggior parte delle distribuzioni Linux lo mantiene in UTC; pertanto, una macchina con avvio doppio può presentare uno scarto pari all'offset del fuso fino alla risincronizzazione.

Conversione dell'ora locale in UTC

Windows memorizza gli offset come bias in minuti, con segno opposto rispetto alla consueta notazione "UTC−3": bias = −(offset 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

Durante un passaggio da o verso l'ora legale, l'ora locale subisce 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 volta a UTC+2 e una volta a UTC+1. Una riga di log in ora locale alle 02:30 di quel giorno presenta un'ambiguità di un'ora. Risolverla utilizzando le voci adiacenti o una fonte UTC e indicare come è stata risolta.

Usare 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 si è concluso 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 applicando le regole relative alla sua data, utilizzando un database dei fusi orari aggiornato (il database tz di IANA) oppure le regole annuali conservate da Windows 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, specificare esplicitamente il fuso di output: psort.py --output_time_zone UTC. Quando si analizzano fonti in ora locale, come i volumi FAT, passare il fuso 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 consentono di scegliere il fuso orario utilizzato per la visualizzazione. Timeline Explorer mostra i timestamp del CSV che apre; pertanto, produrre quel CSV in UTC e impostarne il formato della data in modo da mostrare secondi e frazioni. Quindi verificare una riga confrontandola con un valore decodificato manualmente.
• I fogli di calcolo sono pericolosi. Excel converte il testo che assomiglia a 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 durante la 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 dato 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 tramite regolazione graduale (facendolo avanzare leggermente più velocemente o più lentamente finché non coincide con l'ora corretta) oppure tramite salto immediato. Solo i salti 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 temporale con cui il servizio si sta sincronizzando e l'evento 37 indica che il provider NtpClient sta ricevendo dati temporali validi. Dimostrano 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 sicurezza. Aggiunge PreviousTime, NewTime, l'account e il processo. Le correzioni ordinarie del 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 per la 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 file scaricato non può essere creato localmente prima dell'ultima modifica del contenuto sul server.
• Al momento della raccolta, registrare l'orologio del dispositivo accanto a un riferimento attendibile. Ciò misura lo scarto al momento della raccolta, 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 solo tra eventi noti dell'orologio: uno scarto misurato dopo un salto non si applica al periodo precedente. Nella relazione, conservare il valore originale accanto a quello corretto.

Eventi fuori ordine

Un salto all'indietro fa sì che un intervallo di letture dell'orologio si ripeta due volte, quindi l'ordinamento temporale mescola eventi non correlati; un salto in avanti lascia una lacuna. 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 dell'hardware e delle modifiche manuali, non prove di manipolazione. Cercare l'evento Kernel-General 1 o 4616 che li spiega e ripristinare l'ordine reale con numeri di sequenza che non dipendono dall'orologio: EventRecordID di EVTX, numeri di sequenza degli aggiornamenti del journal USN, numeri di sequenza di $LogFile.

I tempi della raccolta non sono i tempi delle evidenze

Gli orari prodotti dalla raccolta stessa, come i tempi 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 sequenza temporale degli eventi e utilizzare il registro di raccolta per misurare lo scarto e documentare la catena di custodia.

Precisione e corrispondenza

Un valore DOS indica un incremento di due secondi. A seconda del software che lo scrive, l'ora reale è stata troncata al secondo pari inferiore oppure arrotondata a quello superiore, quindi può trovarsi fino a 2 secondi prima o dopo il valore memorizzato. Quando si confronta un valore DOS con un FILETIME, ammettere tale intervallo; una differenza di 1 secondo non indica due eventi. Le domande dell'esame CFX forniscono timestamp in formato ISO 8601 UTC con Z, come 2026-03-16T09:20:14Z, troncati ai secondi interi salvo diversa indicazione. 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; minuto = (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. Il Brasile non applicava l'ora legale nel 2026, quindi 180 si applica a quella data: 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 una sola modifica: una copia conserva 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 dell'ora del dispositivo. Dall'avvio non risulta alcuna modifica precedente dell'ora, quindi lo scarto si applica all'intera mattinata.

Confermare 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, un risultato compatibile con uno scarto di 7 minuti più 2 secondi di trasferimento. Documentare l'ID del record dell'evento, lo scarto, il suo intervallo e i due valori per ciascuna riga.

Focus sull'esame: È prevista 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, oppure PreviousTime e NewTime 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

• Distinguere l'ora UTC reale, l'orologio del dispositivo e la visualizzazione dello strumento; gli artefatti registrano solo l'orologio del dispositivo.
• I tempi 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 un offset UTC valido.
• UTC = ora locale + bias, con bias = −(offset UTC) e con le regole sull'ora legale e le disposizioni di legge della data dell'evento, non con l'ActiveTimeBias odierno.
• Impostare forzatamente 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 raccolta) e applicare le correzioni solo nell'intervallo a cui si riferiscono.
• Tenere conto della risoluzione: gli orari di modifica DOS sono valori con risoluzione di 2 secondi, quindi una differenza inferiore a 2 secondi rispetto a un FILETIME non indica un evento diverso.