Anti-forensique NTFS : tactiques des attaquants

Réponse courte : les techniques anti-forensiques sur NTFS visent à cacher ce qu'est un fichier, quand il a été touché, ou qu'il a même existé. Aucune des techniques courantes n'est propre — chacune laisse un artefact différent dans $MFT, $UsnJrnl, $LogFile ou les snapshots VSS. Cet article catalogue les techniques et les indices qui les trahissent.

Timestomping

Le classique. Des outils comme SetMACE, timestomp et des one-liners PowerShell intégrés appellent SetFileTime ou écrivent directement $STANDARD_INFORMATION pour faire paraître un fichier plus ancien ou plus récent qu'il ne l'est.

Ce que cela laisse :

• Les horodatages $STANDARD_INFORMATION et $FILE_NAME divergent — SetFileTime ne met à jour que SI. Voir les quatre horodatages MFT.
• La précision sous-seconde est souvent mise à zéro. L'activité Windows naturelle laisse des fractions de seconde ; beaucoup d'outils de timestomping arrondissent à la seconde.
• Un créé $STANDARD_INFORMATION plus ancien que le créé $FILE_NAME est impossible — les fichiers ne peuvent pas exister avant d'avoir été nommés.

Comment le repérer : analysez $MFT et marquez chaque enregistrement où SI et FN divergent de plus de quelques secondes, ou où SI précède FN tout court. Le parseur navigateur de ce site expose les deux jeux d'horodatages par enregistrement.

Flux de données alternatifs (ADS)

NTFS permet à un fichier de porter plusieurs attributs $DATA. Celui sans nom est le « vrai » fichier ; les nommés (file.txt:hidden) sont des flux de données alternatifs — invisibles à l'Explorateur, invisibles à dir, et régulièrement utilisés pour cacher des charges utiles.

Ce que cela laisse :

• Un ADS n'est qu'un autre attribut $DATA dans le même enregistrement MFT. Tout parseur qui parcourt le flux d'attributs les liste.
• L'ADS Zone.Identifier, ajouté automatiquement par les navigateurs, survit souvent sur les charges téléchargées — prouvant que le fichier vient d'internet et de quelle zone de sécurité.

Comment le repérer : dir /R depuis cmd.exe liste les ADS sur un système vivant. streams.exe de Sysinternals les énumère. Le parseur MFT les affiche en ligne avec l'enregistrement. Voir flux de données alternatifs.

Effacer un fichier précis

Les wipers sophistiqués écrasent les clusters du fichier puis suppriment l'enregistrement MFT. Les moins sophistiqués (del /f, SDelete par défaut) écrasent les données mais laissent l'enregistrement MFT en place.

Ce que cela laisse :

• Un enregistrement MFT supprimé avec $FILE_NAME et $STANDARD_INFORMATION intacts — le nom et les horodatages survivent même si les données ont disparu. Voir ce qui survit à la suppression d'un fichier NTFS.
• Souvent un enregistrement $UsnJrnl pour la création originale et la suppression.
• Des entrées $LogFile pour les opérations de métadonnées.
• Un snapshot VSS d'avant l'effacement contenant encore le fichier complet.

Comment le repérer : même un fichier « effacé » laisse un nom, un chemin et des horodatages dans $MFT. Combinez avec les snapshots VSS (snapshots et $MFT) et vous récupérez souvent le contenu aussi.

Effacer l'enregistrement MFT lui-même

Un attaquant plus agressif écrit un nouveau fichier pour réutiliser délibérément l'emplacement, écrasant l'enregistrement supprimé. Cela réussit — l'emplacement est perdu — mais la suppression est elle-même un événement.

Ce que cela laisse :

• Le numéro de séquence de l'enregistrement a été incrémenté. Une référence depuis $UsnJrnl ou $LogFile vers l'ancien numéro de séquence est désormais obsolète et vous indique que l'emplacement a été réutilisé.
• $UsnJrnl enregistre toujours la création/suppression originale et la création du nouveau fichier, y compris un dossier parent différent si le nouveau fichier vit ailleurs.
• Les copies snapshot de $MFT d'avant la réutilisation contiennent encore l'enregistrement original.

Comment le repérer : croisez $UsnJrnl avec la $MFT courante. Une entrée $UsnJrnl dont le numéro de séquence cible est désormais supérieur à celui référencé indique une réutilisation.

Troncature de $UsnJrnl

Le journal de changements est fini. Un attaquant qui lance des opérations bruyantes (beaucoup d'écritures de fichiers) peut forcer $UsnJrnl à boucler, évinçant les entrées anciennes.

Ce que cela laisse :

• Un $UsnJrnl qui commence plus tard que son paramètre $Max ne le suggérerait est suspect.
• $LogFile ne tourne pas de la même manière et enregistre souvent encore les opérations qui ont poussé $UsnJrnl dehors.
• Les opérations bruyantes elles-mêmes laissent des milliers d'enregistrements MFT — visibles.

Suppression de $UsnJrnl

fsutil usn deletejournal /D C: supprime entièrement le journal. Les journaux recréés repartent d'un compteur USN frais.

Ce que cela laisse :

• Un $UsnJrnl dont le premier USN est suspicieusement haut, ou dont le premier enregistrement est des heures ou minutes avant l'incident.
• Une entrée de dossier $Extend dont le numéro de séquence de l'enregistrement MFT a été incrémenté.
• Les snapshots VSS d'avant la suppression contenant encore le journal complet.

Renommer en fichier système

Cacher un malware en svchost.exe, lsass.exe ou un autre binaire Windows familier. Pas techniquement de l'anti-forensique MFT, mais c'est le tour le plus courant en milieu naturel pour tromper l'analyste.

Ce que cela laisse :

• Un $FILE_NAME dont la référence de dossier parent n'est pas C:\Windows\System32.
• Un attribut $DATA dont la taille et l'entropie ne correspondent pas à la distribution du binaire légitime.
• Un ADS Zone.Identifier issu du téléchargement.

Griffonnages MFT par ransomware

Certaines familles de ransomware (Petya, NotPetya, et une poignée depuis) corrompent délibérément $MFT pour rendre le volume non montable. C'est destructeur plutôt qu'évasif.

Ce que cela laisse :

• Des enregistrements BAAD là où devraient figurer FILE.
• Un système non bootable, mais une image forensiquement riche — scannez le volume à la recherche de signatures FILE et la majeure partie de la table reste lisible.

Voir motifs ransomware dans la MFT pour les détails.

Le principe général

Chaque technique anti-forensique sur NTFS laisse un artefact. La raison est structurelle : $MFT, $UsnJrnl, $LogFile et VSS enregistrent chacun une vue différente des mêmes événements, et modifier l'un d'eux est lui-même un événement que les autres enregistrent. Un triage qui parcourt les quatre ensemble est difficile à défaire.