Les engagements forensiques tournent souvent autour d'une seule question : ce fichier a-t-il été un jour sur cet ordinateur ? Pas « est-il là maintenant » (c'est dir). La question plus difficile : pouvons-nous montrer qu'il y était hier, la semaine dernière, l'année dernière ? Pour les volumes NTFS, la réponse est généralement oui, et $MFT est la source individuelle la plus forte. Souvent, le contenu du fichier revient aussi.
Voici la vision de praticien de ce que vous pouvez prouver à partir des seules métadonnées MFT, quelle corroboration les journaux apportent, et les cas où des affirmations confiantes s'effondrent en revue.
Ce qui survit à une suppression
Quand un fichier est supprimé sous NTFS, le bit IN_USE dans l'en-tête de l'enregistrement est effacé et l'entrée d'index du répertoire parent est retirée. L'enregistrement lui-même reste, contenant :
$FILE_NAMEavec le nom de fichier original et la référence à l'enregistrement MFT du répertoire parent.- Huit horodatages (quatre dans
$STANDARD_INFORMATION, quatre dans$FILE_NAME) gelés au moment de la suppression. - Tailles logique et physique des données du fichier.
- Pour les petits fichiers (~700 octets ou moins de
$DATA), le contenu intégral du fichier stocké en ligne dans l'enregistrement. Voir données résidentes. - Pour les fichiers plus gros, la runlist des clusters qui contenaient les données. Ces clusters peuvent ou non encore contenir les octets originaux.
- Le numéro de séquence de l'enregistrement, qui prouve que vous regardez le fichier qui vivait dans cet emplacement à ce moment-là (pas un occupant ultérieur).
Un enregistrement MFT supprimé avec $FILE_NAME = secret-plan.docx, référence parent résolvant vers \Users\bob\Documents et SI created 2024-11-03T14:02:11Z démontre qu'un fichier portant ce nom a existé dans ce répertoire ce jour-là. L'enregistrement est la preuve, et la preuve est signée par NTFS lui-même au sens où le driver du système de fichiers l'a écrite.
Ce qui rend la preuve défendable
Trois propriétés font que les enregistrements MFT tiennent dans une revue où quelqu'un essaie de casser votre dossier :
- NTFS les écrit lui-même, pas l'utilisateur. Les enregistrements ne sont pas modifiables par l'utilisateur via les API Windows normales. Un défendeur ne peut pas crédiblement prétendre qu'un seul enregistrement a été planté à moins qu'il n'argue que la
$MFTentière a été forgée, ce qui est une barre haute avec les recoupements de journaux ci-dessous. - Huit horodatages se recoupent. La manipulation se montre généralement. SI modifié mais FN inchangé est la signature de timestomping de manuel ; voir les quatre horodatages MFT. SI created antérieur à FN created est naturellement impossible.
$UsnJrnlet$LogFilecorroborent. Si$MFTdit que le fichier a été créé au temps T, le journal USN devrait enregistrerFILE_CREATEau même moment. Les désaccords sont eux-mêmes des preuves (de forgerie ou d'erreur de parser ; dans tous les cas, à poursuivre).- Les snapshots VSS sont indépendants. Un snapshot d'avant la suppression contient une copie MFT où le fichier était
IN_USE=1. Le snapshot a été écrit par VSS à un moment connu. Deux témoins indépendants ($MFTvivante +$MFTdu snapshot) montrant le même fichier sont bien plus forts qu'un seul. Voir Volume Shadow Copy et$MFT.
Ce quatrième point mérite qu'on s'y attarde. Dans les affaires sérieuses, je cherche toujours des snapshots VSS. Ils transforment une seule observation en une série d'observations, chacune à un point différent dans le temps, et ils sont écrits par un chemin de code entièrement différent de la MFT vivante. Difficile à forger les deux de manière cohérente.
Ce que vous ne pouvez pas prouver depuis $MFT seule
La MFT prouve que le fichier a existé dans un répertoire particulier à un moment particulier, avec la taille et les horodatages particuliers dans l'enregistrement. Elle ne prouve pas :
- Qui l'a créé ou y a accédé. Cela requiert des journaux d'événements Security (4663 avec SACL, Sysmon Event ID 11/15 ou 4688 création de processus avec ligne de commande si le fichier a été nommé sur une ligne de commande).
- Quel programme l'a produit. Prefetch, Amcache et Shimcache aident ici. Sysmon Event ID 1 est l'étalon-or s'il était activé.
- Ce que contenait le fichier, pour les gros fichiers, sauf si vous récupérez les clusters de données. Les fichiers résidents vous donnent les octets ; les non-résidents requièrent que la runlist de clusters pointe toujours vers un espace non alloué, non écrasé.
- Si un utilisateur l'a réellement ouvert. Les jump lists, les fichiers LNK et RecentFileCache sont plus utiles ici.
- S'il a été vu par quelqu'un d'autre que l'utilisateur qui possédait le répertoire. Cela nécessite des journaux d'audit ACL.
Une réponse complète fusionne généralement la MFT avec les artefacts environnants. La MFT est la pierre angulaire parce que sans elle, les autres pièces n'ont rien à quoi s'ancrer. Un hit Prefetch pour secret-tool.exe est intéressant ; le même hit couplé à un enregistrement MFT montrant que secret-tool.exe a été déposé dans \Temp\ à la même minute par un processus dont le Sysmon Event ID 1 est dans la timeline est concluant.
Un workflow qui tient en revue
- Acquérez
$MFT,$UsnJrnl:$J,$LogFile, tous les snapshots VSS. Hashez tout (SHA-256). Documentez l'heure d'acquisition. - Parsez la MFT. Trouvez l'enregistrement pour le fichier en question, vivant ou supprimé. Sortez le numéro de séquence, la référence parent, les huit horodatages, le
$DATArésident le cas échéant, et la runlist de clusters sinon. - Résolvez la référence parent en suivant l'enregistrement MFT du parent. Répétez jusqu'à atteindre l'enregistrement 5 (la racine). La chaîne résultante est le chemin du répertoire. Recoupez-la contre tout chemin que vous avez tiré de journaux ou de témoignages.
- Recoupez avec le journal USN. Pour la même paire enregistrement/séquence, listez chaque entrée USN.
FILE_CREATEvous donne la création originale ;FILE_DELETEvous donne la suppression. Les raisons entre sont l'historique du fichier. - Comparez avec les MFT des snapshots VSS. La copie de chaque snapshot du même enregistrement vous donne un point de contrôle. Si trois snapshots montrent l'enregistrement
IN_USE=1avec des horodatages cohérents et que la MFT vivante montreIN_USE=0, vous avez quatre témoins indépendants s'accordant sur l'existence du fichier et un témoin pour sa suppression. - Documentez les impossibilités que vous avez écartées. Divergence SI/FN vérifiée. Numéros de séquence cohérents. Horodatages de snapshot cohérents. Le récit de la défense doit expliquer tout cela pour saper votre conclusion.
La dernière étape est ce qui sépare une conclusion d'un argument. Énumérer ce que vous avez vérifié et ce que vous avez écarté rend la chaîne de raisonnement visible.
Cas limites qui mordent
Hard links. Un fichier avec plusieurs hard links vit à travers plusieurs attributs $FILE_NAME. Supprimer un link ne retire que ce nom ; le fichier reste. Confirmez que la suppression que vous suivez correspond bien à la disparition du fichier, pas à un seul nom retiré.
Fichier renommé avant la suppression. Certains droppers renomment leur fichier de staging vers un nom anodin juste avant la suppression, espérant que le $FILE_NAME survivant paraisse innocent. Le journal USN préserve la paire RENAME_OLD_NAME / RENAME_NEW_NAME. Sortez-la.
Slot d'enregistrement réutilisé. Le slot d'un fichier supprimé a été réclamé par un nouveau fichier. L'enregistrement MFT actuel est le nouveau fichier à la séquence N ; le journal référence l'ancien fichier à la séquence N-1. Utilisez le numéro de séquence pour désambiguïser. Les références qui pointent vers une séquence autre que celle actuelle pointent vers un occupant précédent.
Le fichier n'a jamais existé et quelqu'un ment. Moins courant, mais à savoir. La forgerie pure de métadonnées est dure à faire de manière cohérente à travers MFT, USN et VSS, mais un opérateur déterminé avec un accès administrateur a des outils. Cherchez des incohérences entre artefacts qui devraient s'accorder.
Lectures complémentaires
- Brian Carrier, File System Forensic Analysis. Le chapitre sur la forensique NTFS est la référence standard pour ce que les preuves MFT peuvent étayer.
- SANS, FOR500: Windows Forensic Analysis. Les supports de cours couvrent les preuves d'existence antérieure basées sur la MFT avec des cas travaillés.
- Harlan Carvey, Investigating Windows Systems. Études de cas pratiques montrant le motif de corroboration MFT-plus-journal.