La phrase la plus utile que je puisse offrir à un nouvel examinateur à propos de NTFS : la suppression n'est pas l'effacement. C'est un changement de drapeau et une mise à jour d'index. L'enregistrement MFT du fichier reste en place. Les clusters de données sont marqués libres dans $Bitmap. Rien n'est écrasé jusqu'à ce que quelque chose d'autre réclame cet espace.
Les gens le savent en théorie. L'erreur que je continue à les voir commettre est de supposer que la fenêtre de survie est généreuse sur chaque machine. Elle ne l'est pas. Sur un serveur de fichiers chargé, l'emplacement est réutilisé en quelques minutes. Sur une station que personne n'utilise le week-end, l'enregistrement supprimé peut rester un mois. Vous devez savoir quel type d'hôte vous regardez avant de vous engager sur le fait qu'une chose soit encore récupérable.
Ce que l'enregistrement contient encore
Un enregistrement MFT supprimé est structurellement identique à un enregistrement vivant. Le bit IN_USE (bit 0 dans le champ flags à l'offset 0x16) est effacé. Tout le reste, à moins que l'enregistrement n'ait été réclamé, est ce que NTFS a écrit en dernier :
$STANDARD_INFORMATION(type d'attribut0x10) : les quatre horodatages de SI, les drapeaux DOS, la référence du descripteur de sécurité, l'ID propriétaire, le pointeur USN. Les horodatages survivent intacts à la suppression. Notez que le SI que vous voyez est celui du fichier au moment de la suppression, pas celui de la création initiale (Windows met à jour SI en permanence pendant que le fichier est vivant).$FILE_NAME(0x30) : un par hard link, plus le nom court 8.3 sur les volumes oùdisable8dot3est désactivé. La référence au répertoire parent est le numéro d'enregistrement MFT du répertoire dans lequel vivait le fichier. Cette référence tient même si le répertoire lui-même est supprimé plus tard, ce qui permet àflset MFTECmd de reconstruire les chemins dans les hiérarchies de répertoires supprimés.$DATA(0x80) : pour les fichiers résidents (sous environ 700 octets de données), les octets eux-mêmes restent inline dans l'enregistrement. Pour les fichiers non résidents, la runlist pointe vers les clusters qui étaient le fichier. Ces clusters ne sont plus marqués alloués, mais ils n'ont pas été remis à zéro.$ATTRIBUTE_LIST(0x20) lorsque présent, avec des références à tous les enregistrements d'extension utilisés par le fichier. Ces enregistrements d'extension sont eux-mêmes supprimés mais, jusqu'à récupération, restent parsables.
Le numéro de séquence est ce qui rend défendable l'analyse des fichiers supprimés. Chaque enregistrement porte un numéro de séquence 16 bits qui s'incrémente à chaque réutilisation du slot. Une entrée du journal USN ou une référence $LogFile qui pointe vers l'enregistrement 12345 séquence 3 continue à pointer vers la séquence 3 même après que le slot soit passé à la séquence 4. Cette discordance vous dit que l'emplacement a été réutilisé depuis.
Quand l'emplacement disparaît vraiment
Deux événements mettent indépendamment fin à la récupérabilité :
Le slot d'enregistrement MFT est réutilisé. NTFS n'a pas de stratégie d'allocation fixe ici. En pratique, quand un nouveau fichier a besoin d'un enregistrement, le driver regarde $MFT:$BITMAP pour l'enregistrement libre avec le plus petit numéro et l'utilise. Les enregistrements supprimés sont récupérés à peu près dans l'ordre. Sur un volume très utilisé, cet ordre va vite. La MFT elle-même ne fait que grandir ; elle ne rétrécit jamais, donc d'anciens enregistrements supprimés bien au-dessus de la limite haute actuelle peuvent survivre des années.
Les clusters de données sont écrasés. Indépendamment de l'enregistrement. Les clusters ont été marqués libres dans $Bitmap, donc n'importe quel allocateur peut les réclamer. Sur un fichier fraîchement supprimé, les deux événements doivent se produire avant que la récupération ne devienne impossible. J'ai vu des enregistrements survivre tandis que les clusters étaient depuis longtemps perdus (vous récupérez seulement les métadonnées et les données résidentes), et l'inverse (l'enregistrement a été réutilisé mais les clusters contiennent encore les octets originaux et peuvent être taillés).
Il n'y a pas de minuterie nette pour l'un ou l'autre. « Combien de temps durent les fichiers supprimés sous NTFS » a la même réponse honnête que « combien de temps dure une place libre au bar » : jusqu'à ce que quelqu'un la prenne.
Ce que les journaux ajoutent
La MFT vous montre le présent. Le journal USN vous montre le verbe. Un enregistrement USN FILE_DELETE nomme le fichier, le répertoire parent et l'horodatage de la suppression. Même si le slot MFT a été réutilisé depuis, l'entrée USN préserve toujours l'ancien nom et la paire enregistrement/séquence originale. Couplez les deux et vous obtenez quelque chose comme :
2026-04-12T13:08:11Z USN FILE_DELETE | CLOSE rec=44231 seq=7 path=\Users\bob\Documents\secrets.zip
2026-04-12T13:08:11Z MFT rec=44231 IN_USE=0 seq=7 (encore lisible, supprimé)
2026-04-12T13:08:11Z MFT FN parent=12, name=secrets.zip
C'est une réponse reconstructible à « à quoi ressemblait ce fichier au moment de la suppression » même si le fichier a disparu par ailleurs. $LogFile ajoute du détail au niveau transactionnel dans les secondes qui encadrent : la suppression est entourée par une paire DeleteAttribute et DeallocateFileRecordSegment, et vous pouvez généralement identifier les opérations environnantes.
Si VSS était actif et qu'un snapshot existe d'avant la suppression, le $MFT du snapshot montre toujours IN_USE=1 pour le même enregistrement/séquence, et les clusters de données ont été préservés par copy-on-write. Voir Volume Shadow Copy et $MFT pour les détails d'extraction.
Les cas que les gens se trompent
Outils de suppression sécurisée. SDelete dans son mode par défaut écrase les clusters de données mais ne fait rien à l'enregistrement MFT. Vous obtenez un enregistrement supprimé avec $FILE_NAME complet, $STANDARD_INFORMATION complet et $DATA pointant vers des clusters mis à zéro. Le nom et les horodatages survivent absolument. Cela trompe les utilisateurs qui attendaient que SDelete soit plus complet qu'il ne l'est.
Suppression de fichier via hard link. Supprimer un hard link ne supprime pas le fichier ; l'attribut $FILE_NAME pour ce link est retiré et le compteur de hardlinks baisse. Le fichier lui-même n'est supprimé que lorsque le dernier link est retiré. Si vous voyez un enregistrement MFT supprimé avec hardlink_count à zéro et sans $FILE_NAME restant, le fichier a été réellement supprimé. Si vous voyez un enregistrement avec un compteur de hardlinks non nul et un $FILE_NAME manquant, la suppression était partielle.
Fichiers renommés 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 et RENAME_NEW_NAME, vous pouvez donc retrouver le nom original par là. La MFT seule ne montre que le nom final.
La corbeille n'est pas une suppression. Les fichiers envoyés à la corbeille sont renommés et déplacés dans \$Recycle.Bin\<SID>\. L'enregistrement MFT reste IN_USE=1 et le fichier est intact sous un nom $R<ID>. L'enregistrement compagnon $I<ID> consigne le chemin original. Vider la corbeille supprime ensuite normalement.
Outils qui lisent bien les enregistrements supprimés
Pour le triage, j'utilise l'un des :
- MFTECmd avec
--de 1(drop entries) ou simplement la sortie non filtrée traitée en aval. Marque les données résidentes et vous donne le numéro de séquence. omerbenamram/mft_dumpavec-o json. Numéro de séquence, drapeau résident, liste complète d'attributs. Bon pour piper dans un script qui extrait les enregistrements oùIN_USE=0etseqcorrespond à une référence USN.fls -m -rdu Sleuth Kit pour un bodyfile qui inclut les entrées supprimées. Old-school, ça marche encore.icat -rrécupère les données des fichiers non résidents dont les clusters sont intacts.- analyzeMFT si vous voulez spécifiquement une option pure Python et que la vitesse vous est égale.
Le parser navigateur de ce site filtre vers IN_USE=0 en un clic et fait remonter les données résidentes inline. Si le volume comptait, le fichier était petit et le slot n'a pas été réutilisé, vous avez souvent les octets devant vous dans la table.
Ce que vous ne pouvez toujours pas répondre depuis la seule MFT
La MFT vous dit qu'un enregistrement existe et a été supprimé. Elle ne vous dit pas qui l'a supprimé. Pour cela, vous voulez Security 4663 (accès aux objets) si les SACLs étaient configurées, ou Sysmon Event ID 23 (FileDelete) qui journalise l'utilisateur et le processus. Sur la plupart des hôtes, ni l'un ni l'autre n'est activé. Dans ce cas, vous vous rabattez sur des preuves corroborantes : un hit Prefetch pour un outil de suppression, une entrée Amcache pour un binaire inconnu tournant au bon moment, des entrées Recent File Cache de la même fenêtre.
La MFT est le plancher. Construisez le reste de l'histoire par-dessus.
Lectures complémentaires
- Brian Carrier, File System Forensic Analysis. Les chapitres sur la sémantique de suppression NTFS restent définitifs.
- Documentation de
flsdu Sleuth Kit pour la sortie bodyfile canonique qui inclut les entrées supprimées. - Microsoft, Master File Table. La référence niveau MS pour ce que NTFS garantit et ne garantit pas.