La première fois que j'ai construit une timeline Windows depuis $MFT, j'ai émis huit lignes par enregistrement, trié par horodatage, ouvert dans Excel et me suis senti comme si j'avais reconstruit la réalité. Je n'avais pas. J'avais un journal trié de changements de métadonnées NTFS. C'est utile. Ce n'est pas, en soi, une enquête.
Ce billet est ce que j'aurais voulu qu'on me dise sur le timelining MFT avant que je livre mon premier rapport.
Ce qu'est vraiment une timeline MFT
Chaque enregistrement MFT actif ou supprimé porte huit horodatages que vous pouvez extraire de manière fiable : quatre dans $STANDARD_INFORMATION (SI) et quatre dans $FILE_NAME (FN). Créé, modifié, accédé et MFT-modifié, dans les deux attributs. Parcourez la table, émettez une ligne par horodatage non nul, triez par date, et vous avez une timeline indiquant quand NTFS a écrit certains octets de certains enregistrements. C'est le plancher.
Le plafond est une super-timeline qui fusionne la MFT avec le journal USN, $LogFile, Prefetch, Sysmon, Shimcache, Amcache, les hives du registre, l'historique du navigateur et SRUM. La MFT est la colonne vertébrale parce qu'elle est la plus dense et la plus difficile à truquer entièrement pour un attaquant. Tout le reste s'aligne par rapport à elle.
La disposition que j'utilise vraiment
Oubliez mactime comme format de destination. Utilisez-le comme intermédiaire. La forme qui tient devant un tribunal est une ligne par événement, avec une provenance défendable :
timestamp_utc | source | attribute | mft_record | seq | path | event
2026-05-15T10:23:01.123Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | created
2026-05-15T10:23:01.123Z | MFT | FN | 12345 | 3 | /Users/alice/notes.txt | name_created
2026-05-15T10:24:18.456Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | modified
2026-05-15T10:24:18.501Z | USN | - | 12345 | 3 | /Users/alice/notes.txt | DATA_OVERWRITE | CLOSE
source et la paire enregistrement/séquence sont les colonnes que les analystes sautent et regrettent ensuite d'avoir sautées. Le numéro de séquence est ce qui vous dit si deux événements partageant un numéro d'enregistrement se réfèrent à la même incarnation d'un fichier ou à un prédécesseur supprimé dont l'emplacement a été réutilisé. Sans lui, votre timeline les confond silencieusement.
La sortie CSV de MFTECmd est la disposition prête à l'emploi la plus proche de cela. Faites passer ses lignes par un script léger qui ajoute source=MFT et émet une ligne par horodatage, et vous avez un corpus de travail.
Les horodatages, par ordre de mensonge
SI bouge à pratiquement chaque opération que Windows fait sur un fichier. Les lectures mettent à jour accessed si NTFS le veut bien (Windows 7+ par défaut ne met pas à jour accessed pour des raisons de performance, sauf si fsutil behavior set disablelastaccess 0 est positionné). Les écritures mettent à jour modified et MFT-modified. Les renommages mettent à jour MFT-modified. Le timestomping avec SetFileTime met à jour celui des quatre que l'attaquant a visé.
FN est mis à jour au renommage, à la création d'un hard link et à la création initiale du fichier. Après cela, FN reste largement immobile. La granularité des mises à jour FN par Windows est aussi plus grossière ; beaucoup de fichiers terminent légitimement par .0000000 si FN a été positionné à la création et plus jamais touché.
En pratique :
- FN créé est le signal "ce fichier est apparu pour la première fois dans ce répertoire" le plus fiable que vous ayez à partir de la seule MFT.
- SI créé est le plus facile à falsifier. Traitez-le comme un indice, pas un fait.
- SI modifié est le cheval de trait. Combiné au
DATA_OVERWRITEUSN correspondant, il vous dit que les octets du fichier ont réellement changé à cet instant. - SI accédé sous Windows 7+ est désactivé par défaut. Si vous le voyez changer, soit un admin l'a réactivé, soit le volume est sur une SKU Server, soit quelque chose monte les volumes et parcourt les fichiers (logiciel de sauvegarde, scans AV, introspection EDR).
La granularité sous-seconde est le signe. NTFS stocke les horodatages en ticks de 100 nanosecondes. Les opérations natives de Windows laissent du bruit dans les chiffres du bas. La plupart des outils de timestomping comme SetMACE et le bien connu timestomp.exe arrondissent à la seconde. Une colonne de suffixes .0000000 alignés est une empreinte.
Fusion avec le journal USN
La MFT vous montre le présent et un historique figé des métadonnées. Le journal USN vous montre les verbes. Combinez-les et une seule ligne de votre timeline devient une phrase.
Comment je fusionne : parsez $UsnJrnl:$J séparément, émettez une ligne par enregistrement avec source=USN, puis triez le flux combiné par horodatage. Les codes de raison USN (FILE_CREATE, DATA_OVERWRITE, RENAME_OLD_NAME, RENAME_NEW_NAME, FILE_DELETE, CLOSE) vous donnent l'opération ; la MFT fournit l'état résultant. Un RENAME_OLD_NAME USN immédiatement suivi par RENAME_NEW_NAME au même USN révèle le renommage. Sans le journal, un diff MFT entre deux snapshots peut vous dire que le fichier a bougé ; il ne peut pas vous dire l'ordre.
Un piège : les horodatages USN et MFT SI s'écartent de millisecondes pour le même événement. Ne sur-indexez pas sur l'alignement. Triez à la seconde et utilisez le code de raison USN comme départage.
Ce qui ruine les timelines MFT
Acquisition désynchronisée. Si vous collectez MFT et USN à dix minutes d'écart sur un système vivant, le journal a continué. Couplez-les depuis le même point dans le temps, idéalement depuis un snapshot VSS que vous déclenchez vous-même.
Oublier le tableau de fixup. Tout parser qui se respecte gère cela, mais si vous écrivez le vôtre (s'il vous plaît, non, sauf pour apprendre), lire des morceaux bruts de 1 024 octets vous donne des ordures aux offsets 510 et 1022 de chaque enregistrement. Appliquez les fixups d'abord.
Mélanger les numéros d'enregistrement à travers les frontières de séquence. Enregistrement 12345 séquence 3 n'est pas le même fichier qu'enregistrement 12345 séquence 5. L'emplacement a été réutilisé. Si votre timeline regroupe seulement par numéro d'enregistrement, vous confondrez un fichier supprimé avec celui qui a pris sa place.
Faire confiance à SI sur les binaires système. Windows Update touche SI sur les fichiers patchés. Un SI modifié sur C:\Windows\System32\svchost.exe est presque toujours une installation CBS, pas une intrusion. Recoupez avec setupapi.dev.log et CBS.log avant de faire des affirmations.
Traiter la timeline comme la conclusion. C'est l'entrée de l'analyse. Vous devez toujours savoir ce que signifie chaque événement dans le contexte de l'hôte, de l'utilisateur et de l'affaire.
Un workflow qui tient
- Acquérez
$MFT,$UsnJrnl:$J,$LogFileet toutes les copies disponibles dans les snapshots VSS. Hashez tout (SHA-256) immédiatement. - Parsez MFT et USN avec MFTECmd ou
mft_dumpplus un parser USN. Vérifiez que les parsers ont tourné sans avertissements. - Émettez des lignes normalisées : une par horodatage pour la MFT, une par enregistrement pour USN, avec
source,mft_record,seqetpathexplicites. - Triez par horodatage dans un flux unique. Ne dédupliquez pas encore ; les quasi-doublons portent du signal.
- Pivotez sur la période d'intérêt. Tirez une fenêtre de deux heures avant et deux heures après l'événement suspecté.
- Superposez le reste : Prefetch, Amcache, Sysmon 1/11/15, artefacts LNK et jump list, enregistrements
$Ide la corbeille, SRUM pour l'utilisation de ressources réseau et processus. - Cherchez les ordres impossibles. SI créé avant FN créé. Une raison USN
DATA_OVERWRITEsans changement SI modifié correspondant dans la MFT. Deux événementsFILE_CREATEau même numéro d'enregistrement avec la même séquence (le parser est cassé).
Cette dernière étape est là où les timelines MFT gagnent leur pain. Elles exposent les impossibilités. Chaque impossibilité est soit un bug de parser, soit un artefact d'attaquant, et les deux méritent d'être poursuivis.
Ce que la MFT ne peut pas vous dire
Elle ne peut pas vous dire quel processus a touché un fichier. Elle ne peut pas vous dire quel utilisateur. Elle ne peut pas vous dire ce qu'il y avait dans un fichier de plus de quelques centaines d'octets qui a été supprimé et partiellement écrasé. Pour cela, vous avez besoin des artefacts environnants : 4688 avec audit de ligne de commande (ou Sysmon 1), la chaîne d'IDs de logon du journal de sécurité et, un bon jour, un dump RAM qui a attrapé le processus encore résident.
La MFT est la colonne vertébrale. Les autres artefacts sont les muscles. Aucun ne marche sans l'autre.
Lectures complémentaires
- Eric Zimmerman, MFTECmd. La disposition CSV canonique et le parser sur lequel la plupart des équipes IR se standardisent.
- SANS, Windows Forensic Analysis Poster. Replie correctement les événements MFT dans la timeline plus large.
- Harlan Carvey, Investigating Windows Systems. Les chapitres sur la construction de timeline restent la référence pratique.