Index Windows Search : traces de fichiers supprimés

En bref. L'index Windows Search ne supprime pas un enregistrement dès qu'un fichier disparaît. On trouve des fichiers supprimés à trois endroits : les enregistrements actifs encore présents dans le magasin de propriétés (chemin, taille, propriétaire, horodatages, heure d'indexation et souvent un extrait de contenu), les différences du WAL sous Windows 11 (un enregistrement présent dans un état de Windows.db et pas dans l'autre), et l'espace libre de la base (entrées ESE « defunct », pages de la freelist SQLite), qui demande du carving. Un élément du magasin de propriétés sans enregistrement gather correspondant est une piste « supprimé ? » solide. L'extrait de contenu de System.Search.AutoSummary est le gros lot : le texte d'un fichier qui n'existe plus, sans carver le disque.

Pourquoi les fichiers supprimés persistent

L'indexeur apprend une suppression par le suivi des modifications du système de fichiers, met le travail en file d'attente et finit par retirer l'élément. Plusieurs facteurs retardent cela :

La machine a été éteinte, mise en veille prolongée ou saisie juste après la suppression.
L'indexeur était en pause, occupé, sur batterie ou en retrait à cause de l'activité de l'utilisateur. Le guide de dépannage de Microsoft liste ces états.
L'élément se trouvait sur un lecteur qui n'est plus connecté : clé USB débranchée ou partage injoignable. Chivers et Hargreaves soulignaient dans leur article de 2011 que les enregistrements de fichiers indisponibles persistent.
Sous Windows 11, la suppression est une transaction validée dans Windows.db-wal jusqu'à ce qu'un checkpoint l'écrive dans Windows.db. L'article de Stroz Friedberg note que l'enregistrement d'un fichier supprimé reste disponible dans la base principale jusqu'à la réécriture des modifications du WAL.

Rien de tout cela n'est garanti. C'est une course que l'on gagne parfois.

Niveau 1 : enregistrements actifs de fichiers disparus

Le cas le plus simple. Le fichier a disparu du disque, mais son enregistrement est toujours une ligne normale du magasin de propriétés. N'importe quel parseur l'affiche, avec l'ensemble des propriétés :

Propriété	Ce qu'elle apprend sur le fichier supprimé
`System.ItemPathDisplay`	Chemin complet, y compris le dossier de préparation
`System.Size`	Taille à l'indexation : à comparer avec des fragments carvés ou des volumes exfiltrés
`System.FileOwner`	Le compte propriétaire
`System.DateCreated` / `DateModified` / `DateAccessed`	Horodatages du système de fichiers vus lors de l'indexation
`System.Search.GatherTime`	Le moment où l'indexeur l'a traité
`System.Search.AutoSummary`	Extrait du contenu

Comment savoir que le fichier est supprimé ? L'index ne le dit pas. Vous comparez avec le système de fichiers de votre image (MFT, arborescence). Ou, plus vite, vous regardez les tables gather.

Le contrôle croisé avec la table gather

Le magasin de propriétés et les tables gather (SystemIndex_Gthr) sont deux vues des mêmes éléments, reliées par WorkId = DocumentID. Quand le gatherer traite une suppression, les deux ne disparaissent pas toujours ensemble. Le Windows Search Index Parser les compare :

Absent de la table gather (supprimé ?) : le magasin de propriétés a encore l'élément, la table gather ne l'a plus. Bon candidat à « supprimé après son indexation ».
Table gather uniquement : le gatherer liste encore le document, mais ses propriétés ont disparu. Fréquent avec les fichiers temporaires, par exemple une archive extraite dans un dossier temporaire puis nettoyée.

Les deux signalements sont des heuristiques. Confirmez avec le système de fichiers, le journal USN (motif FILE_DELETE pour le même nom) ou la Corbeille (les fichiers $I contiennent le chemin d'origine et l'heure de suppression).

Niveau 2 : le journal WAL de Windows 11

Windows.db-wal contient des pages validées plus récentes que les pages correspondantes de Windows.db. Vous disposez donc de deux états de l'index :

La base seule : l'état au dernier checkpoint.
La base plus le WAL : l'état actuel.

Un élément présent dans le premier et absent du second a été retiré par une transaction récente. Un élément présent uniquement dans le second a été ajouté récemment : c'est ce que le parseur signale comme uniquement dans le WAL. Un élément dont les propriétés diffèrent a été réindexé récemment (modifié dans le WAL) : par exemple un fichier écrasé ou exécuté à nouveau. L'analyse approfondie de SQLite et du WAL explique le fonctionnement des trames et des checkpoints, et pourquoi le WAL peut même contenir plusieurs versions anciennes d'une même page.

Conséquence pratique : n'analysez jamais un index Windows 11 sans son WAL, et ne laissez jamais un outil ouvrir l'original en lecture-écriture. Un client SQLite classique peut checkpointer à la fermeture, fusionner le WAL et détruire l'état « avant ».

Niveau 3 : les enregistrements dans l'espace libre

Quand la base supprime réellement un enregistrement, les octets ne sont pas effacés tout de suite.

ESE : l'entrée supprimée est marquée « defunct » dans sa page et nettoyée plus tard. Les pages devenues vides retournent à l'espace libre. La documentation du format libesedb décrit les tags de page concernés.
SQLite : les cellules supprimées vont dans des freeblocks au sein de la page, les pages vidées vont dans la freelist, et d'anciennes versions de pages peuvent rester dans des trames WAL écrasées logiquement mais pas physiquement.

Les récupérer exige un outil de carving qui comprend le format. Chivers et Hargreaves en ont construit un (wdsCarve) pour leurs travaux. WinSearchDBAnalyzer récupère des enregistrements supprimés dans Windows.edb. Le Windows Search Index Parser ne fait pas encore de carving : pour ESE, il compte les entrées « defunct » qu'il rencontre et en indique le nombre dans un avertissement, pour que vous sachiez qu'il y a quelque chose à récupérer avec un autre outil.

Les extraits de contenu : la vraie raison de s'y intéresser

System.Search.AutoSummary est décrite par Microsoft comme un résumé automatique du texte intégral d'un document. En pratique, c'est un extrait du début du texte. Les travaux de Stroz Friedberg font état de 1 024 premiers octets au maximum sous Windows 11 et listent les types de fichiers où ils l'ont observé : documents (.txt, .docx, .xlsx, .pdf, .one, .eml), fichiers web et de configuration (.html, .xml, .ini, .reg, .sql, .asp) et scripts (.bat, .cmd, .vbs, .js).

Ce que je cherche dans les extraits :

Identifiants et notes qu'un attaquant a enregistrés sur la machine, puis supprimés.
Scripts : les premières lignes d'un .bat ou d'un .vbs montrent l'intention même quand le fichier a disparu.
Demandes de rançon et leurs coordonnées de contact.
Titres et premières lignes de documents, qui prouvent qu'un document sensible se trouvait dans un dossier de préparation.

Deux précautions :

L'extrait reflète le contenu au moment de l'indexation. Si le fichier a été modifié ensuite sans être réindexé, l'extrait est périmé. Comparez System.DateModified et l'heure d'indexation.
L'indexation du contenu dépend de la configuration. Si un type de fichier est réglé sur « propriétés uniquement » dans les Options d'indexation, ou si l'emplacement n'est pas indexé, il n'y a pas d'extrait. Microsoft documente les deux options. L'absence d'extrait ne prouve rien.

Un exemple rapide

Dans le cas fictif fourni comme exemple avec l'outil, un fichier C:\ProgramData\Intel\creds.txt est supprimé par l'intrus. Le fichier a disparu et la table gather ne le liste plus, mais le magasin de propriétés conserve son chemin, son propriétaire (FIN-WKS-07\svc_backup), sa taille (214 octets), ses horodatages et un extrait contenant les identifiants que l'attaquant avait collectés. Le déroulé complet est dans enquêter sur une intrusion avec l'index Windows Search.

Bien le rédiger dans le rapport

Écrivez « l'index Windows Search contient un enregistrement pour le chemin X, indexé à T ». N'écrivez pas « le fichier a existé jusqu'à T ».
Citez l'extrait comme « contenu indexé », en précisant qu'il reflète le fichier au moment de l'indexation.
Indiquez si le WAL et la base gather étaient disponibles et si une base ESE était « dirty ».
Si vous vous êtes appuyé sur les signalements de l'outil, précisez que ce sont des heuristiques et comment vous les avez confirmés.

FAQ

Combien de temps un fichier supprimé reste-t-il dans l'index Windows Search ?

Il n'y a pas de durée fixe. Cela dépend du moment où l'indexeur traite la suppression, de l'allumage de la machine et de la maintenance de la base. Considérez chaque enregistrement survivant comme une chance, et documentez la date de collecte de l'index.

L'index peut-il me rendre le contenu complet d'un document supprimé ?

En général, non. System.Search.AutoSummary contient un extrait, pas le fichier. Les travaux de Stroz Friedberg décrivent jusqu'aux 1 024 premiers octets sous Windows 11. C'est souvent suffisant pour des identifiants, une demande de rançon ou les premières lignes d'un script.