Falsification des horodatages, effacement des journaux et données cachées

La leçon 7.1 portait sur la destruction de données. Cette leçon présente plutôt trois moyens d'induire un examinateur en erreur : modifier les horodatages, effacer ou modifier les journaux et cacher des données. Chacun laisse une discordance entre des sources qui enregistrent indépendamment le même événement ; le travail de l'examinateur consiste à la trouver, à la mesurer et à indiquer dans quelle mesure elle étaye l'hypothèse d'une manipulation.

Falsification des horodatages

La falsification des horodatages consiste à modifier les horodatages d'un fichier pour qu'il se fonde dans son environnement ou paraisse plus ancien. La plupart des outils ne modifient que les valeurs de $STANDARD_INFORMATION ($SI), au moyen de SetFileTime (création, accès, modification) ou de NtSetInformationFile avec la classe FileBasicInformation (les quatre, y compris l'heure de modification de l'entrée MFT). Aucun des deux ne nécessite de droits d'administrateur, et $FILE_NAME ($FN) est plus difficile à falsifier (leçon 3.2). Certaines techniques publiées alignent également $FN en combinant des modifications de $SI avec un renommage ou un déplacement au sein du volume, au cours duquel NTFS copie les valeurs de $SI dans le nouveau $FN. Cela peut produire des valeurs $SI et $FN identiques, mais ajoute des enregistrements de renommage au journal.

Détection par couches

Aucune vérification ne permet à elle seule de conclure, car les logiciels d'archivage, les programmes d'installation et les clients de synchronisation définissent eux aussi des horodatages. Appliquez les vérifications par couches et indiquez combien concordent.

1. $SI comparé à $FN. Un $SI B antérieur à $FN B, ou un $SI C ne correspondant à aucune opération, constitue une première piste.
2. Fractions de seconde nulles. Un FILETIME compte des intervalles de 100 nanosecondes ; un horodatage authentique ne tombe donc sur une seconde exacte qu'environ une fois sur dix millions. Plusieurs outils écrivent des secondes entières. Les plus récents rendent la fraction aléatoire ; une fraction non nulle ne prouve donc rien.
3. Entrées MFT voisines. Les numéros d'entrée donnent un ordre de création approximatif, car la $MFT s'agrandit à mesure que des fichiers sont ajoutés. Une entrée dont les voisines ont toutes été créées le même jour, mais dont le $SI indique une date antérieure de plusieurs années, est suspecte. Les entrées libérées sont réutilisées ; cela ne fait donc qu'étayer d'autres constatations.
4. Antériorité au système. Comparez $SI B à InstallDate (réinitialisé par les mises à niveau de fonctionnalités) et au $SI B des fichiers de métadonnées propres au volume, tels que $MFT (entrée 0) et $Volume (entrée 3), qui enregistrent normalement le moment où le volume a été formaté. Des fichiers copiés ou extraits peuvent conserver des horodatages plus anciens, mais leurs valeurs $SI C et $FN indiquent alors leur arrivée.
5. $UsnJrnl. La définition des horodatages écrit un enregistrement portant BASIC_INFO_CHANGE (0x00008000) pour le numéro de référence du fichier, horodaté par l'horloge au moment réel de la modification. Cet indicateur couvre aussi les modifications d'attributs ; interprétez-le donc avec les valeurs $SI. Les outils de copie et d'extraction définissent généralement les horodatages alors que le fichier est encore ouvert, dans la même séquence d'activité que FILE_CREATE ; une séquence distincte ultérieure est plus révélatrice. Des enregistrements de renommage à proximité orientent vers la technique visant $FN.
6. $LogFile. Une opération UpdateResidentValue sur l'attribut $SI contient les anciens horodatages dans ses données d'annulation et les nouveaux dans ses données de rétablissement, si le journal couvre encore ce moment (de quelques minutes à quelques heures).
7. Autres artefacts ayant enregistré le fichier. Un fichier LNK conserve les heures de création, d'accès et de modification $SI de la cible, telles qu'elles étaient lors de l'écriture du lien, aux offsets d'en-tête 0x1C, 0x24 et 0x2C (leçon 2.4). Prefetch, Amcache et les Jump Lists indiquent quand le fichier a été utilisé. Si toutes les références datent de 2026, une date de création en 2019 reste isolée.
8. Horodatages internes. Le TimeDateStamp d'un fichier PE (secondes Unix dans l'en-tête COFF, à l'offset e_lfanew + 8 ; affiché sous le nom LinkDate par les analyseurs Amcache) ne peut logiquement pas être postérieur à la création du fichier. Les métadonnées documentaires telles que dcterms:created dans les fichiers Office (onglet Détails de l'Explorateur) fonctionnent de la même manière. Les deux peuvent être falsifiés, et les compilations déterministes placent une empreinte plutôt qu'un horodatage dans TimeDateStamp.

La manipulation de l'horloge est différente

Une personne peut plutôt reculer l'horloge système, créer le fichier, puis rétablir l'horloge. Dans ce cas, $SI, $FN, les enregistrements USN et les journaux d'événements portent tous la fausse heure, avec des fractions de seconde normales. Les signes sont ceux de la leçon 3.5 : événement 1 de Kernel-General dans System (OldTime, NewTime) et événement 4616 de Security (PreviousTime, NewTime), ainsi que des numéros de séquence (USN, EventRecordID) qui augmentent alors que les heures reculent. La falsification des horodatages décale un attribut ; les changements d'horloge décalent tout ce qui est écrit pendant cet intervalle.

Effacement des journaux

Windows

L'effacement du journal Security écrit l'événement Security 1102 (« Le journal d'audit a été effacé ») comme premier enregistrement du nouveau journal ; l'effacement de tout autre journal écrit l'événement System 104, qui nomme le canal. Tous deux proviennent du fournisseur Microsoft-Windows-Eventlog et enregistrent SubjectUserName, SubjectDomainName et, pour 1102, SubjectUserSid et SubjectLogonId. L'effacement de Security nécessite le droit « Gérer le journal d'audit et de sécurité », que les administrateurs détiennent par défaut.

Recherchez aussi le moyen employé : wevtutil cl <log> laisse un fichier Prefetch pour WEVTUTIL.EXE sur les éditions clientes, ainsi qu'un événement 4688 si la création de processus est auditée (avec la ligne de commande uniquement si sa journalisation est également activée) ; Clear-EventLog apparaît dans l'événement 4104 de PowerShell/Operational lorsque la journalisation des blocs de script est activée, et dans ConsoleHost_history.txt.

Autres signes d'altération :

• EventRecordID. Un journal effacé redémarre à 1. Un journal dont les anciens enregistrements ont été normalement remplacés commence à une valeur supérieure et ne présente pas de lacunes internes ; un saut au sein d'un même fichier nécessite donc une explication.
• Période couverte et taille. Un journal Security qui commence quelques minutes avant l'incident sur un système utilisé depuis des mois, ou un fichier dont la taille est très inférieure à son MaxSize, est compatible avec un effacement récent. Les périodes silencieuses alors que d'autres sources montrent une activité comptent également.
• Suppression sélective. Certains outils suppriment ou masquent des enregistrements individuels en réécrivant le fichier. Recherchez des lacunes dans les identifiants, des erreurs de somme de contrôle CRC32 dans les en-têtes du fichier ou des blocs, ainsi que des enregistrements que les analyseurs signalent comme masqués ou endommagés. Traitez ces éléments comme des pistes.
• Altération du service et de la stratégie. Security 1100 (« Le service de journalisation des événements s'est arrêté ») et System 6006 (service de journalisation des événements arrêté) sont normaux lors d'un arrêt du système ; sans démarrage ultérieur (6005), ils suggèrent que le service a été arrêté. Security 4719 enregistre une modification de la stratégie d'audit. Les techniques qui suspendent la journalisation en mémoire n'écrivent rien ; seules les lacunes par rapport à d'autres sources les révèlent.

Les enregistrements effacés sont souvent récupérables : anciennes copies dans les clichés instantanés de volumes (leçon 2.9), blocs ElfChnk de 64 KB récupérés par carving dans l'espace non alloué, dans pagefile.sys ou dans hiberfil.sys (avec EVTXtract, par exemple), et copies transférées vers un collecteur ou un SIEM.

Linux

Comparez les sources qui journalisent les mêmes événements (leçon 6.4). Un /var/log/auth.log tronqué, ou dépourvu de lignes de session que journalctl affiche encore pour sshd, indique une modification. Chaque enregistrement wtmp occupe 384 octets sur Linux x86-64 ; utmpdump /var/log/wtmp affiche un enregistrement mis à zéro comme étant de type 0 avec un horodatage de 1970 (sur les systèmes qui utilisent plutôt wtmpdb, examinez /var/lib/wtmpdb/wtmp.db, leçon 6.4), et un enregistrement supprimé se manifeste par une ouverture de session sans fermeture correspondante ou par une lacune dans la séquence des démarrages. journalctl --verify signale les fichiers de journal endommagés ; les messages « corrompu ou arrêt incorrect » et les fichiers .journal~ ont souvent des causes bénignes. Les noms des fichiers de journal archivés contiennent le numéro de séquence de leur première entrée ; un fichier manquant au milieu de la série se manifeste donc par une lacune ; le nettoyage normal ne supprime que les plus anciens. La leçon 6.3 couvre les astuces concernant l'historique du shell, telles que la suppression de la définition de HISTFILE.

Données cachées

• Flux de données alternatifs (leçon 1.4). Tout flux autre que Zone.Identifier et les flux système connus mérite un examen. MFTECmd (HasAds, IsAds), istat et dir /r les répertorient ; l'ajout d'un flux écrit STREAM_CHANGE.
• Extension comparée à la signature. Comparez les premiers octets à l'extension : 4D 5A (MZ) correspond à un fichier PE, 50 4B 03 04 à un conteneur ZIP (y compris .docx), 25 50 44 46 (%PDF) à un PDF, FF D8 FF à un JPEG. Le module de détection des discordances d'extension d'Autopsy et file automatisent cette opération.
• Espace résiduel et espace non alloué (leçon 1.2). Un espace résiduel RAM non nul sur un volume NTFS moderne, ou des données structurées réparties dans de nombreuses zones d'espace résiduel, suggèrent un placement délibéré.
• Partitions cachées et espaces intercalaires (leçon 1.1). Comparez la table de partitions à la taille du disque et recherchez de l'espace non partitionné au-delà de l'alignement normal de 1 MiB. Sur GPT, les bits d'attribut 62 (masqué) et 63 (sans lettre de lecteur) masquent les partitions de données de base dans l'Explorateur.
• Stéganographie. Les tests statistiques (khi-deux ou analyse RS des bits de poids faible) dans des outils tels que StegExpose ou zsteg signalent des images, avec des faux positifs. Des données ajoutées après le FF D9 d'un JPEG ou le IEND d'un PNG, ou la présence de logiciels de stéganographie dans les artefacts d'exécution, constituent souvent de meilleures pistes.
• Conteneurs chiffrés déguisés en fichiers. Une entropie de Shannon proche de 8,0 bits par octet, l'absence d'en-tête reconnaissable et une taille qui est un multiple exact de 512 octets sont compatibles avec un conteneur (leçon 7.3). Les formats compressés présentent eux aussi une entropie élevée, mais commencent par une signature.
• Attributs et noms. Attributs Masqué et Système, noms Unix commençant par un point, noms imitant ceux de fichiers système dans le mauvais dossier, caractère de forçage de droite à gauche U+202E et sous-dossiers de $Recycle.Bin nommés d'après des SID qui n'existent pas dans la clé ProfileList.

Exemple détaillé : svc.dll et un journal Security effacé

La collecte de triage effectuée sur l'ordinateur portable d'ana montre cette entrée MFT :

Vérification des fractions de seconde. La valeur $SI est 132 073 632 000 000 000 (octets 00 40 8E BF 44 38 D5 01). Divisée par 10 000 000, elle donne 13 207 363 200 secondes, avec un reste de 0. La valeur $FN 134 179 718 913 301 447 ÷ 10 000 000 = 13 417 971 891 avec un reste de 3 301 447, soit 0,3301447 s. La différence, 2 106 086 913 301 447 intervalles, soit 210 608 691,33 s, est de 2 437 jours 14 h 24 min 51,33 s.

Raisonnement. $SI B précède $FN B de 6 ans et 8 mois et est antérieur au formatage du volume ; ses fractions de seconde sont nulles ; les entrées voisines ont été créées quatre secondes avant et 35 secondes après l'heure $FN ; et le journal enregistre une modification d'horodatage dans une séquence d'activité distincte 12 secondes après la création, sans renommage. $LogFile avait bouclé et ne couvrait plus 14:25. L'affirmation défendable est que le nom svc.dll a été créé sur ce volume à 2026-03-14T14:24:51Z, et que ses horodatages $SI ont été définis à 2019-07-12T00:00:00Z vers 14:25:03Z, ce qui est compatible avec une falsification des horodatages. Le journal ne montre pas qui l'a effectuée.

Le journal. Security.evtx commence par EventRecordID 1, un événement 1102 à 2026-03-14T14:38:55Z avec SubjectUserName ana et SubjectUserSid S-1-5-21-…-1001. Le journal Security a été effacé par le compte d'ana 13 min 52 s après la modification des horodatages, et ce compte détenait le droit de le faire. Tout éventuel événement 4616 de changement d'heure a été perdu avec lui ; vérifiez donc la présence d'un événement Kernel-General 1 dans System avant de vous fier à l'heure 14:25:03Z du journal ; il n'y en a aucun. Étapes suivantes : Prefetch pour WEVTUTIL.EXE, 4104, clichés instantanés et blocs récupérés par carving.

Technique, détection et niveau de confiance

Le niveau de confiance concerne la manipulation ; l'identification de son auteur nécessite des éléments distincts, tels que les ouvertures de session et les artefacts d'exécution.

Points clés pour l'examen : Attendez-vous à devoir indiquer l'heure d'arrivée réelle d'un fichier à partir de $FN ou du journal lorsque $SI est falsifié, ainsi que l'heure de la modification à partir d'un enregistrement BASIC_INFO_CHANGE. Préparez-vous à vérifier les fractions de seconde d'un FILETIME brut et à lire les événements 1102 ou 104 pour déterminer qui a effacé quel journal et à quel moment. Les questions peuvent vous demander de distinguer une falsification des horodatages d'un changement d'horloge, ou d'indiquer où récupérer les enregistrements effacés.

Points essentiels

• La falsification des horodatages ne modifie généralement que $SI ; comparez-le à $FN, aux fractions de seconde, aux entrées MFT voisines, à la création du volume, à $UsnJrnl, à $LogFile, aux LNK et aux horodatages internes, et comptez combien concordent.
• BASIC_INFO_CHANGE enregistre le moment réel où les horodatages ou les attributs ont été définis ; une séquence d'activité distincte après la création est plus probante qu'une modification au sein de la séquence de création.
• Un changement d'horloge décale tous les artefacts ensemble et laisse un événement Kernel-General 1 ou 4616 ; la falsification des horodatages décale un attribut.
• Les événements 1102 (Security) et 104 (System) nomment le compte qui a effacé un journal ; les identifiants d'enregistrement redémarrent à 1, et d'anciens enregistrements peuvent subsister dans les clichés instantanés, les blocs récupérés par carving et les copies transférées.
• Sous Linux, comparez les journaux textuels au journal, lisez wtmp avec utmpdump et vérifiez les numéros de séquence du journal.
• Les données cachées se révèlent par leur structure : attributs $DATA supplémentaires, discordances de signature, espace résiduel inhabituel, espace non partitionné et fichiers à forte entropie sans en-tête.