Fuseaux horaires et erreurs d’horloge

Un horodatage peut être décodé parfaitement et rester erroné : enregistré en heure locale et présenté comme étant en UTC, converti selon les règles actuelles plutôt que celles en vigueur le jour concerné, décalé par l’outil de l’analyste ou enregistré par une horloge qui avançait ou retardait de plusieurs minutes, voire de plusieurs années. Cette leçon présente les sources qui enregistrent l’heure UTC et celles qui enregistrent l’heure locale, la conversion des valeurs locales et la manière de mesurer, de documenter et de corriger une erreur d’horloge d’un appareil. Le module 7 traite de la manipulation délibérée de l’horloge ; ici, l’objectif est d’interpréter correctement les horodatages non falsifiés.

Trois horloges dans chaque dossier

Distinguez trois horloges dans vos notes :

1. L’heure réelle (UTC) : le moment où l’événement s’est réellement produit. C’est l’heure que votre rapport doit indiquer.
2. L’horloge système de l’appareil : l’heure que l’ordinateur pensait être la bonne. Les artefacts enregistrent cette horloge, jamais l’heure réelle. Si elle avançait de 7 minutes, chaque horodatage qu’elle a écrit est postérieur de 7 minutes à l’heure réelle.
3. L’horloge d’affichage : la manière dont un outil présente une valeur sur le poste de travail de l’analyste. L’Observateur d’événements, par exemple, affiche les heures EVTX enregistrées en UTC dans le fuseau horaire de l’ordinateur utilisé pour les consulter.

Les erreurs proviennent de leur confusion.

Sources UTC et sources en heure locale

Deux formats se situent entre les deux. exFAT enregistre l’heure locale ainsi qu’un octet de décalage UTC propre à chaque horodatage, utilisable uniquement lorsque son bit de validité est activé (leçon 1.5). EXIF 2.31 et les versions ultérieures peuvent ajouter OffsetTimeOriginal, par exemple -03:00. Un journal texte qui indique un décalage, tel que [14/Mar/2026:09:21:07 -0300] dans Apache, est lui aussi sans ambiguïté. En l’absence d’un tel marqueur, supposez qu’il s’agit de l’heure locale et déterminez de quelle heure locale il s’agit : celle de l’hôte ou celle d’un appareil photo qui n’a jamais été réglé.

L’horloge matérielle temps réel (RTC) ajoute un piège : Windows la conserve en heure locale par défaut, tandis que la plupart des distributions Linux la conservent en UTC. Une machine à double démarrage peut donc présenter une erreur égale au décalage du fuseau jusqu’à sa resynchronisation.

Conversion de l’heure locale en UTC

Windows enregistre les décalages sous la forme d’un biais en minutes, de signe opposé à la notation habituelle « UTC−3 » : biais = −(décalage UTC), et UTC = heure locale + biais. UTC−3 correspond à un biais de +180 ; UTC+1 à −60. Pendant l’heure d’été (DST), le biais effectif est Bias + DaylightBias (généralement −60). Le biais de l’heure d’été d’Europe centrale est donc −60 + (−60) = −120. La leçon 2.2 indique où se trouvent ces valeurs sous TimeZoneInformation.

Heures inexistantes et heures répétées

Lors d’un changement d’heure saisonnier, l’heure locale effectue un saut. En Europe centrale, le 2026-03-29, les horloges sont passées de 01:59:59 CET à 03:00:00 CEST : les heures locales de 02:00 à 02:59 n’existent donc pas ce jour-là. Le 2026-10-25, elles sont revenues de 02:59:59 CEST à 02:00:00 CET : chaque heure locale de 02:00 à 02:59 s’est donc produite deux fois, une fois à UTC+2 et une fois à UTC+1. Une ligne de journal en heure locale à 02:30 ce jour-là présente une ambiguïté d’une heure. Levez-la à l’aide des entrées voisines ou d’une source UTC, et précisez comment vous avez procédé.

Utilisez la règle en vigueur à la date de l’événement

ActiveTimeBias décrit le moment de la dernière écriture de la clé, et non la date de votre événement. Les règles relatives aux fuseaux horaires changent également par la loi. Le Brésil a supprimé l’heure d’été en 2019 ; sa dernière période d’heure d’été s’est terminée le 2019-02-17. Un hôte de Brasília collecté en 2026 affiche un ActiveTimeBias de 180, mais une ligne de journal locale du 2018-12-10 10:00 a été écrite à UTC−2 et correspond à 12:00Z, et non à 13:00Z. Convertissez chaque valeur selon les règles propres à sa date, à l’aide d’une base de données de fuseaux horaires à jour (la base tz de l’IANA) ou des règles annuelles conservées par Windows sous SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<zone>\Dynamic DST.

Ne laissez jamais un outil choisir votre fuseau horaire

De nombreux outils appliquent silencieusement le fuseau du poste de travail de l’analyste :

• Réglez le poste d’analyse sur UTC afin qu’un recours à l’heure « locale » soit sans conséquence.
• Dans Plaso, indiquez explicitement le fuseau de sortie : psort.py --output_time_zone UTC. Lors de l’analyse de sources en heure locale, telles que les volumes FAT, transmettez le fuseau de l’appareil avec log2timeline.py --timezone (leçon 3.3).
• Dans les outils à interface graphique, vérifiez les paramètres d’affichage. Les options d’affichage d’Autopsy permettent de choisir le fuseau utilisé pour l’affichage. Timeline Explorer affiche les horodatages du fichier CSV qu’il ouvre : produisez donc ce CSV en UTC et définissez son format de date de façon à afficher les secondes et leurs fractions. Vérifiez ensuite une ligne par rapport à une valeur décodée manuellement.
• Les tableurs sont dangereux. Excel convertit les textes ressemblant à des dates en nombres de série dépourvus de fuseau horaire, masque les secondes et leurs fractions dans son format d’affichage par défaut et peut inverser le jour et le mois selon certains paramètres régionaux. Importez les colonnes d’horodatage en tant que texte.

Décalage et dérive de l’horloge

Le décalage est la différence entre l’horloge de l’appareil et l’heure réelle à un instant donné. La dérive est la vitesse à laquelle ce décalage évolue. Une horloge à quartz fonctionnant librement avec une erreur de 20 parties par million avance ou retarde d’environ 1,7 seconde par jour (20 × 10⁻⁶ × 86 400 s) : un appareil non synchronisé peut donc présenter une erreur de plusieurs minutes au bout de quelques mois. La synchronisation corrige l’horloge par ajustement progressif (en la faisant fonctionner légèrement plus vite ou plus lentement jusqu’à concordance) ou par saut immédiat. Seuls les sauts laissent une trace de « changement d’heure ».

Mesure du décalage

Comparez l’horloge de l’appareil à une référence fiable :

• Enregistrements de synchronisation NTP. Les événements du fournisseur Microsoft-Windows-Time-Service dans le journal Système indiquent la synchronisation : l’événement 35 nomme la source de temps avec laquelle le service se synchronise, et l’événement 37 indique que le fournisseur NtpClient reçoit des données horaires valides. Ils montrent que la synchronisation fonctionnait, mais pas l’ampleur d’une correction.
• L’événement 1 de Kernel-General (fournisseur Microsoft-Windows-Kernel-General, journal Système) enregistre un changement de l’heure système avec OldTime et NewTime, tous deux en UTC. La différence correspond à l’ampleur du saut.
• L’événement de sécurité 4616, « L’heure système a été modifiée », est enregistré lorsque la sous-catégorie d’audit Modification de l’état de la sécurité est activée. Il ajoute PreviousTime, NewTime, le compte et le processus. Les corrections courantes effectuées par le service Temps Windows indiquent généralement le compte LOCAL SERVICE ; une modification par un processus utilisateur mérite votre attention.
• Les horodatages côté serveur écrits par une horloge synchronisée pour la même action : les en-têtes Received: ajoutés par les serveurs de messagerie, le journal d’accès d’un serveur web ou l’en-tête de réponse HTTP Date: conservé dans une entrée du cache du navigateur. L’en-tête Last-Modified: d’un serveur fournit une borne inférieure : un téléchargement ne peut pas être créé localement avant la dernière modification du contenu sur le serveur.
• Lors de la collecte, consignez l’heure de l’appareil à côté d’une référence fiable. Cela mesure le décalage au moment de la collecte, mais pas nécessairement auparavant.

Documentation et application d’une correction

Consignez la référence, la manière dont vous avez déterminé le décalage, l’intervalle auquel il s’applique et l’incertitude restante. N’appliquez la correction qu’entre des événements d’horloge connus : un décalage mesuré après un saut ne s’applique pas avant celui-ci. Conservez la valeur d’origine dans votre rapport à côté de la valeur corrigée.

Événements dans le désordre

Un saut en arrière fait apparaître deux fois une plage de valeurs d’horloge : un tri chronologique entrelace alors des événements sans rapport entre eux ; un saut en avant laisse un intervalle vide. Après une défaillance de la pile RTC ou une réinitialisation du micrologiciel (BIOS/CMOS), l’horloge peut repartir d’une date par défaut du micrologiciel, produisant des événements « en 2001 » ou dans une autre année ancienne jusqu’à son nouveau réglage ; une horloge réglée trop loin en avant crée des fichiers « dans le futur ». De telles configurations sont des conséquences normales du matériel et des modifications manuelles, et non une preuve de manipulation. Recherchez l’événement Kernel-General 1 ou 4616 qui les explique, et rétablissez l’ordre réel à l’aide de numéros de séquence qui ne dépendent pas de l’horloge : EventRecordID des EVTX, numéros de séquence de mise à jour du journal USN, numéros de séquence de $LogFile.

Les heures de collecte ne sont pas celles des éléments de preuve

Les heures produites par la collecte elle-même, telles que les horodatages du système de fichiers des fichiers copiés dans un dossier de triage et l’heure d’acquisition, décrivent votre travail, et non celui de l’utilisateur (leçon 3.3). Excluez-les de la chronologie des événements et utilisez le journal de collecte pour mesurer le décalage et documenter la chaîne de conservation.

Précision et rapprochement

Une valeur DOS marque un pas de deux secondes. Selon le logiciel qui l’a écrite, l’heure réelle a été tronquée à la seconde paire inférieure ou arrondie à la seconde paire supérieure ; elle peut donc se situer jusqu’à 2 secondes de part et d’autre de la valeur enregistrée. Lorsque vous comparez une valeur DOS à un FILETIME, tenez compte de cette fenêtre ; une différence de 1 seconde ne correspond pas à deux événements. Les questions de l’examen CFX donnent les horodatages au format ISO 8601 UTC avec Z, tel que 2026-03-16T09:20:14Z, tronqués à la seconde entière sauf indication contraire. Indiquez la valeur de l’artefact nommé dans la tâche, convertie exactement, et ne l’arrondissez pas pour la rapprocher d’une autre source.

Exemple détaillé 1 : un fichier FAT32 et la $MFT de l’hôte

Une image de clé USB FAT32 contient plan.docx (nom court PLAN~1.DOC). Dans son entrée de répertoire, le mot d’heure à l’offset 0x16 est 87 32 et le mot de date à 0x18 est 70 5C :

• Heure 0x3287 : heure = 0x3287 >> 11 = 6 ; minute = (0x3287 >> 5) & 0x3F = 20 ; secondes = (0x3287 & 0x1F) × 2 = 7 × 2 = 14, soit 06:20:14.
• Date 0x5C70 : année = (0x5C70 >> 9) + 1980 = 46 + 1980 = 2026 ; mois = (0x5C70 >> 5) & 0x0F = 3 ; jour = 0x5C70 & 0x1F = 16, soit 2026-03-16.

Le TimeZoneKeyName de l’hôte est E. South America Standard Time et son ActiveTimeBias est 180. Le Brésil n’appliquait pas l’heure d’été en 2026 ; 180 s’applique donc à cette date : 06:20:14 + 180 minutes = 2026-03-16T09:20:14Z.

La $MFT de l’hôte contient C:\Users\ana\Desktop\plan.docx avec une heure de modification $SI de 2026-03-16T09:20:12.7Z. La différence est de 1,3 seconde, inférieure à la résolution DOS de 2 secondes : les valeurs sont donc compatibles avec une seule modification. Une copie conserve l’heure de modification du fichier, et Windows l’arrondit à la seconde paire supérieure sur FAT. Pour la clé USB, la réponse à indiquer est 2026-03-16T09:20:14Z.

Exemple détaillé 2 : une horloge qui avance de 7 minutes

Sur un autre hôte, le journal Système contient un événement 1 de Kernel-General avec OldTime à 2026-03-18T13:47:31.5Z et NewTime à 2026-03-18T13:40:31.5Z. Le saut est de 13:47:31.5 − 13:40:31.5 = −7 min 00 s : l’horloge avançait de 7 minutes avant 13:47:31.5 à l’heure de l’appareil. Aucun changement d’heure antérieur n’apparaît depuis le démarrage ; le décalage s’applique donc à toute la matinée.

Corroborez avec une horloge indépendante : l’entrée du cache du navigateur correspondant au téléchargement conserve l’en-tête Date: du serveur, 13:22:03Z. Heure de l’appareil 13:29:05 − 13:22:03 = 7 min 02 s, ce qui est compatible avec un décalage de 7 minutes et 2 secondes de transfert. Documentez l’identifiant d’enregistrement de l’événement, le décalage, son intervalle et les deux valeurs pour chaque ligne.

Points clés pour l'examen : Attendez-vous à convertir en UTC des artefacts en heure locale, tels que des horodatages FAT, des lignes de setupapi.dev.log ou des dates EXIF, à l’aide du biais et des règles en vigueur à la date de l’événement. Préparez-vous à lire OldTime et NewTime dans l’événement 1 de Kernel-General, ou PreviousTime et NewTime dans l’événement 4616, et à corriger les horodatages antérieurs en fonction du saut. Les questions de rapprochement peuvent associer une valeur DOS de 2 secondes à un FILETIME ; une différence inférieure à 2 secondes ne correspond pas à un événement différent.

Points essentiels

• Distinguez l’heure UTC réelle, l’horloge de l’appareil et l’affichage de votre outil ; les artefacts n’enregistrent que l’horloge de l’appareil.
• Les heures FILETIME, Unix et APFS sont en UTC ; FAT/DOS, de nombreux journaux texte, certaines valeurs SYSTEMTIME et EXIF DateTimeOriginal sont en heure locale ; exFAT peut contenir un décalage UTC valide.
• UTC = heure locale + biais, avec biais = −(décalage UTC), en appliquant les règles d’heure d’été et les règles légales à la date de l’événement, et non l’ActiveTimeBias actuel.
• Imposez UTC dans chaque outil et empêchez les tableurs de réinterpréter les horodatages.
• Mesurez le décalage par rapport à des références fiables (Kernel-General 1, 4616, en-têtes de serveur, notes de collecte) et n’appliquez les corrections que dans l’intervalle qu’elles couvrent.
• Tenez compte de la résolution : les heures de modification DOS sont des valeurs de 2 secondes ; une différence inférieure à 2 secondes par rapport à un FILETIME ne correspond donc pas à un événement différent.