MACB sur NTFS : $SI et $FN

Chaque fichier d'un volume NTFS possède au moins huit horodatages, et la qualité d'une chronologie dépend de la connaissance qu'a l'examinateur de ce qui fait évoluer chacun d'eux. Cette leçon explique la notation MACB utilisée dans les chronologies, l'emplacement des huit valeurs, le composant qui les met à jour, la manière dont les opérations normales telles que la copie, le renommage et la modification les font évoluer, ainsi que la façon de reconnaître les valeurs qui ne correspondent pas à ces schémas. Le module 7 traite de la falsification des horodatages comme technique anti-forensique ; ici, l'objectif est de lire correctement une chronologie.

Notation MACB

Les chronologies associent à chaque horodatage du système de fichiers l'une des quatre lettres suivantes :

C est le piège : sur NTFS, il signifie que l'entrée MFT (les métadonnées) a changé, et non « créé ». L'Explorateur Windows ne l'affiche pas du tout.

Les outils de chronologie regroupent les valeurs identiques sur une seule ligne et affichent les lettres sous la forme d'un code à quatre positions, avec des points pour celles qui ne s'appliquent pas. Dans la sortie de mactime de The Sleuth Kit, m.c. signifie que cet horodatage correspond à la fois à la modification du contenu et au changement de l'entrée MFT, .a.. correspond uniquement à un accès, et macb signifie que les quatre valeurs sont égales, ce qui est normal à la création. Le fichier bodyfile de TSK (fls -m) présente les valeurs $FN dans une entrée distincte dont le nom se termine par ($FILE_NAME) ; un même fichier peut donc produire des lignes pour les deux ensembles. La sortie l2tcsv de Plaso comporte une colonne MACB avec les mêmes lettres en majuscules (leçon 3.3).

Où se trouvent les huit horodatages

La leçon 1.3 a présenté les deux attributs. Leurs horodatages se trouvent aux décalages suivants dans le contenu de l'attribut :

$FN commence par la référence au parent sur 8 octets, ce qui explique pourquoi ses horodatages commencent à 0x08. Les huit sont des valeurs FILETIME : des compteurs sur 64 bits d'intervalles de 100 nanosecondes depuis 1601-01-01 00:00:00 UTC (leçon 3.1). Elles sont stockées en UTC, quel que soit le fuseau horaire du système.

Un fichier possède un seul $SI, mais un $FN par nom. Lorsque les noms courts 8.3 sont activés, Quarterly Report.xlsx possède un $FN Win32 et un $FN DOS (QUARTE~1.XLS), chacun contenant ses propres quatre horodatages, généralement identiques. Les liens physiques ajoutent d'autres attributs $FN. L'entrée de l'index $I30 du répertoire parent contient une autre copie du $FN, horodatages compris, qui peut différer de l'enregistrement ; les entrées laissées dans l'espace résiduel de l'index peuvent conserver les horodatages de fichiers supprimés ou renommés.

Qui les met à jour

$SI est géré par NTFS lors des opérations normales sur les fichiers, et tout processus disposant du droit d'écriture des attributs du fichier peut également le définir depuis le mode utilisateur. SetFileTime définit les horodatages de création, d'accès et de modification ; l'appel natif NtSetInformationFile avec la classe FileBasicInformation (ainsi que SetFileInformationByHandle) peut définir les quatre, y compris l'horodatage de modification de l'entrée MFT. Aucun droit d'administrateur n'est nécessaire. Les logiciels légitimes utilisent constamment ces appels : les logiciels d'archivage, les outils de copie et de sauvegarde, les programmes d'installation et les clients de synchronisation cloud rétablissent volontairement les horodatages.

$FN est écrit par le pilote NTFS dans le noyau lorsqu'un nom est créé, ce qui se produit principalement lors d'une création, d'un renommage ou d'un déplacement. Il n'existe aucune API documentée permettant de définir directement $FN. C'est pourquoi $FN est plus difficile à falsifier et pourquoi il est utile de le comparer à $SI. Plus difficile ne signifie pas impossible : comme un renommage ou un déplacement copie généralement les valeurs $SI dans le nouveau $FN, une personne peut définir $SI puis déplacer le fichier, et des écritures brutes sur le disque peuvent tout modifier (module 7).

Le dernier accès est un indice faible

La valeur de registre NtfsDisableLastAccessUpdate, sous HKLM\SYSTEM\CurrentControlSet\Control\FileSystem, contrôle les mises à jour de A. Depuis Windows Vista, elles sont désactivées par défaut. À partir de Windows 10 version 1803, la valeur peut aller de 0x80000000 à 0x80000003 : le bit 0x2 activé signifie « Géré par le système », mode dans lequel Windows décide et active les mises à jour sur les volumes système de 128 GB ou moins, et le bit 0x1 activé signifie qu'elles sont désactivées. fsutil behavior query disablelastaccess affiche le paramètre sur un système en fonctionnement. La mise à jour de A dépend donc de la version et du volume : ne présumez jamais qu'elle est activée ou désactivée. Même lorsqu'elle est activée, NTFS peut retarder jusqu'à une heure l'écriture sur disque d'un nouvel horodatage d'accès. Considérez A comme un indice faible : un A ancien ne prouve pas que le fichier n'a pas été ouvert, et un A récent peut provenir d'une analyse antivirus, de l'indexation ou d'une sauvegarde. Utilisez Prefetch, les fichiers LNK et les Jump Lists pour montrer qu'un fichier ou un programme a été ouvert (module 2).

Règles pratiques sur Windows 10 et 11

Des recherches sur NTFS sous Windows 10 et 11 ont permis de mettre en tableau les effets des opérations courantes sur les huit valeurs. Le tableau présente le résultat habituel ; le comportement varie selon la build de Windows et le programme qui effectue l'opération. Testez donc sur la même version avant de vous appuyer sur une règle dans un rapport.

« Nouveau » désigne l'horodatage de l'opération, « – » signifie inchangé, « Source » signifie hérité du fichier d'origine, et « Depuis $SI » signifie que le nouveau $FN reprend les valeurs $SI présentes juste avant l'opération. Un déplacement vers un autre volume est une copie suivie d'une suppression : le nouvel enregistrement reçoit de nouveaux horodatages $FN comme lors d'une copie, mais un couper-coller dans l'Explorateur conserve aussi le $SI B de la source ; M et B paraissent donc tous deux anciens.

Trois conséquences sont particulièrement importantes :

• Indicateur de copie. Une copie conserve le M de la source, mais reçoit un nouveau B ; M antérieur à B est donc le signe normal d'un fichier copié, et non d'une manipulation.
• Archives et téléchargements. Les outils d'extraction définissent généralement M à partir de l'horodatage stocké dans l'archive, et certains rétablissent aussi B et A ; les fichiers extraits peuvent donc sembler dater de plusieurs années. Un téléchargement par navigateur reçoit normalement B lors de la création initiale du fichier et M à la fin de l'écriture ; certains outils de téléchargement définissent M à partir de l'en-tête Last-Modified du serveur. Un flux de données alternatif Zone.Identifier aide à identifier les téléchargements.
• Applications à enregistrement sécurisé. De nombreux éditeurs, dont les suites bureautiques, enregistrent en écrivant un fichier temporaire, puis en le renommant pour remplacer l'original. Le fichier occupe alors un nouvel enregistrement MFT, tandis que le tunneling NTFS (un cache, de 15 secondes par défaut, indexé par nom) attribue au nouveau fichier l'ancien horodatage de création $SI. Un B stable ne prouve pas que l'enregistrement est le même.

Exemple détaillé : budget-q3.xlsx

(a) Copié depuis un support USB. Le support FAT32 contenait budget-q3.xlsx, dont la dernière modification datait de 2026-07-28T16:42:10Z. Il a été copié vers C:\Users\ana\Documents\. L'enregistrement (par exemple dans la sortie de istat) indique :

Raisonnement : $SI M précède $SI B de 5 jours, 16 heures et 33 minutes, ce qui correspond au schéma d'une copie (la colonne Copied de MFTECmd le signale). $SI B est égal à $FN B ; rien ne suggère donc une antidatation. La partie fractionnaire de seconde de $SI M est nulle, car FAT32 stocke les horodatages de modification par pas de 2 secondes et la copie l'a conservée ; 16:42:10 correspond à une seconde paire. FAT stocke l'heure locale ; la conversion en UTC a donc utilisé le fuseau horaire du système ayant effectué la copie (leçon 3.5). Le fichier est arrivé à 09:15:42Z ; corroborez l'identification du périphérique USB à l'aide des artefacts de la leçon 2.6.

(b) Modifié et enregistré sur place à 2026-08-04T22:31:07.4410023Z. $SI M et $SI C deviennent 2026-08-04T22:31:07.4410023Z. $SI B reste à 09:15:42.6183420Z, et $SI A demeure inchangé, car les mises à jour du dernier accès sont désactivées. Les quatre valeurs $FN restent à 2026-08-03T09:15:42.6183420Z. M est désormais postérieur à B ; l'indicateur de copie a donc disparu de $SI, mais l'horodatage d'arrivée subsiste dans $SI B et dans les quatre valeurs $FN. Si un éditeur à enregistrement sécurisé avait été utilisé, vérifiez le numéro d'enregistrement par rapport aux artefacts antérieurs avant de supposer qu'il s'agit du même enregistrement.

Interprétation des anomalies

Les schémas qui ne correspondent pas au tableau méritent un examen plus approfondi :

• $SI B antérieur à $FN B. Après une création, une copie, un renommage ou un déplacement sur le même volume, $SI B est égal à $FN B. Un couper-coller depuis un autre volume et certaines extractions d'archives produisent également un $SI B plus ancien, mais laissent $SI C à l'horodatage de l'opération.
• Parties fractionnaires de seconde à zéro. Une valeur FILETIME dont la partie en 100 nanosecondes est 0000000. NTFS enregistre avec une précision complète, tandis que de nombreux outils qui définissent les horodatages utilisent des secondes entières.
• Dates $SI antérieures à l'installation du système d'exploitation, en utilisant InstallDate (secondes Unix) sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Les mises à niveau de fonctionnalités réinitialisent cette valeur ; effectuez donc la comparaison avec prudence.

Chacun de ces cas a des causes bénignes possibles : extraction d'archives, programmes d'installation, clients de synchronisation et fichiers provenant de supports FAT. Considérez-les comme des pistes, et non comme des conclusions, et confirmez-les avec $UsnJrnl (un motif BASIC_INFO_CHANGE au moment où les valeurs ont été définies) et $LogFile (leçon 1.4 et module 7). MFTECmd, par exemple, écrit les huit valeurs sous les noms Created0x10, Created0x30, LastModified0x10, LastModified0x30, LastRecordChange0x10, LastRecordChange0x30, LastAccess0x10 et LastAccess0x30 (0x10 correspond à $SI, 0x30 à $FN), et signale les enregistrements avec SI<FN (un horodatage $SI antérieur à l'horodatage $FN), uSecZeros (parties fractionnaires de seconde à zéro) et Copied. Certains outils laissent les colonnes $FN vides lorsque leurs valeurs sont égales à celles de $SI ; vérifiez donc comment votre outil les affiche.

Exemple détaillé : un fichier aux horodatages falsifiés

C:\ProgramData\Intel\igfxupd.exe présente les quatre valeurs $SI à 2019-03-19T04:12:00.0000000Z et les quatre valeurs $FN à 2026-08-05T02:14:48.9917304Z. InstallDate vaut 1 676 037 931, ce qui correspond à 2023-02-10T14:05:31Z.

La valeur brute de création $SI est constituée des 8 octets 00 E8 45 E6 09 DE D4 01, lus en petit-boutiste comme 0x01D4DE09E645E800 = 131 974 423 200 000 000. Divisée par 10 000 000, elle donne 13 197 442 320 secondes avec un reste de 0 : aucune partie fractionnaire de seconde. La valeur $FN de 134 303 696 889 917 304 donne un reste de 9 917 304, soit 0,9917304 s.

Raisonnement : $SI B précède $FN B de sept ans ; la partie fractionnaire de $SI est nulle alors que celle de $FN ne l'est pas ; $SI est antérieur à l'installation ; et $SI C a également été défini, ce que SetFileTime seul ne peut pas faire. Une copie normale attribuerait un nouveau $SI B, et un déplacement depuis un autre volume ou une extraction rétablissant B laisserait malgré tout $SI C à l'horodatage de l'opération. L'affirmation défendable est que le nom de fichier a été créé sur ce volume à 2026-08-05T02:14:48Z et que ses valeurs $SI ont probablement été définies par la suite, sous réserve de confirmation par $UsnJrnl.

Points clés pour l'examen : Attendez-vous à devoir identifier lesquels des huit horodatages une opération modifie, à reconnaître M antérieur à B comme le signe d'une copie, et à privilégier $FN par rapport à $SI lorsque $SI semble manipulé. Les tâches pratiques peuvent vous demander l'horodatage d'arrivée d'un fichier sur un volume, qui provient de B et doit être indiqué en UTC avec une précision complète. Les questions sur le dernier accès vérifient si vous savez que sa mise à jour est généralement désactivée et qu'il constitue donc un indice faible.

Points essentiels

• MACB signifie Modifié, Accédé, entrée MFT Changée et Né ; sur NTFS, C correspond à une modification des métadonnées, et non à la création.
• $SI et chaque $FN contiennent quatre valeurs FILETIME en UTC ; un fichier possède un seul $SI, mais un $FN par nom, ainsi qu'une copie dans l'index $I30 du parent.
• $SI peut être défini depuis le mode utilisateur par tout processus disposant du droit d'écriture des attributs ; $FN est écrit par le noyau lors d'une création, d'un renommage ou d'un déplacement, ce qui le rend plus difficile à falsifier.
• Une copie conserve le M de la source et reçoit un nouveau B ; M antérieur à B est donc normal pour les fichiers copiés.
• La mise à jour du dernier accès dépend de la version et du volume ; considérez A comme un indice faible.
• $SI B antérieur à $FN B, des parties fractionnaires de seconde à zéro et des dates antérieures à l'installation sont des pistes à confirmer avec $UsnJrnl et $LogFile.