Chaque enregistrement MFT stocke quatre horodatages dans deux attributs distincts — $STANDARD_INFORMATION et $FILE_NAME. Les deux enregistrent les mêmes quatre moments :
- Création — première écriture du fichier sur le volume
- Modification — dernière modification du contenu
- Accès — dernière lecture du fichier
- Modification MFT — dernière mise à jour de l'enregistrement lui-même
Cela fait huit valeurs par enregistrement. Elles ne sont pas toujours synchronisées.
Pourquoi deux jeux
$STANDARD_INFORMATION (SI) est mis à jour par chaque opération de fichier de routine. $FILE_NAME (FN) a été ajouté à l'origine pour la compatibilité POSIX et est mis à jour bien plus rarement — typiquement à la création, au renommage ou lors d'un déplacement entre dossiers.
En pratique, les horodatages SI évoluent constamment tandis que les FN restent stables.
Le timestomping laisse une empreinte
Les outils qui modifient les horodatages appellent généralement l'API Windows SetFileTime. Elle écrit dans SI. Elle ne touche pas FN.
Après un timestomping, SI affiche ce que l'attaquant a choisi — souvent antidaté de plusieurs années — tandis que FN reflète encore la véritable date de création, parfois avec un écart important.
Deux motifs à surveiller en triage :
- Création SI antérieure à création FN. Un fichier ne peut pas exister avant d'être nommé : impossible naturellement.
- SI et FN modification diffèrent de plus de quelques secondes pour un fichier qui n'a manifestement été ni renommé ni déplacé.
Chacun est un indicateur fort de manipulation des métadonnées.
La granularité en dit plus
NTFS stocke les horodatages avec une résolution de 100 nanosecondes, mais beaucoup d'outils de timestomping arrondissent à la seconde. Un horodatage se terminant par .0000000 UTC est suspect — l'activité Windows naturelle laisse généralement intacte la précision sous-seconde.