Analyse forensique de l'index Windows Search : le guide
Ce que l'index Windows Search enregistre, où se trouvent Windows.edb et Windows.db, ce qui survit à la suppression d'un fichier et comment l'exploiter en DFIR.
En bref. Windows Search tient une base de données de tout ce qu'il indexe : chemin complet, taille, propriétaire, horodatages MAC, heure d'indexation et, pour les documents de type texte, un extrait du contenu. Sous Windows 10 et versions antérieures, cette base s'appelle Windows.edb (ESE). Sous Windows 11, ce sont Windows.db et Windows-gather.db (SQLite, avec journaux WAL). Les deux se trouvent dans C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. L'index n'est pas purgé en temps réel : il conserve régulièrement le chemin, les métadonnées et le texte de fichiers supprimés du disque. C'est l'un des rares artefacts capables de livrer le contenu d'un fichier supprimé sans carving. Considérez-le comme la preuve qu'un fichier a existé et que l'indexeur l'a vu, pas comme la preuve que quelqu'un l'a ouvert.
J'ai vu cet artefact ignoré dans plus de rapports que je ne saurais compter, en général parce que la suite de l'analyste ne le parsait pas, ou parce que Windows.edb ressemblait à une boîte aux lettres Exchange. Dommage : sur un poste de travail classique, c'est un inventaire structuré et horodaté des documents de l'utilisateur, du menu Démarrer et, selon la version de Windows, de l'historique web et de l'activité.
Qu'est-ce que l'index Windows Search ?
Le service Windows Search (WSearch, processus SearchIndexer.exe) parcourt les emplacements configurés, applique les gestionnaires de propriétés et les filtres à chaque fichier, puis stocke le résultat pour que le menu Démarrer et l'Explorateur de fichiers répondent instantanément aux recherches. Le guide de performances de Windows Search de Microsoft indique qu'une machine typique compte moins de 30 000 éléments indexés et fixe un plafond pratique d'environ un million.
Un seul index sert toute la machine. Les éléments de tous les profils utilisateur situés dans un emplacement indexé aboutissent dans la même base, d'où l'importance de la propriété de propriétaire (System.FileOwner).
Ce qui est indexé dépend de la configuration :
| Paramètre | Effet sur les preuves |
|---|---|
| Mode Classique | Microsoft le décrit comme indexant Documents, Images, Musique et le Bureau. En pratique, la liste des Options d'indexation contient souvent le dossier Users et le menu Démarrer. |
| Mode Avancé (Enhanced) | Tout le PC, y compris les dossiers hors du profil. Plus de couverture, index plus gros. |
| Emplacements ajoutés | Tout dossier, lecteur ou partage ajouté par un administrateur ou un utilisateur. Les lecteurs amovibles apparaissent avec leur propre lettre. |
| « Propriétés uniquement » ou « propriétés et contenu », par type de fichier | Détermine si vous obtenez un extrait de contenu pour cette extension. |
Vérifiez toujours ce qui était indexé sur votre machine avant de raisonner sur une absence. Les tables gather (voir plus bas) listent les étendues parcourues, et l'outil affiche l'arborescence de dossiers qu'il en reconstruit.
Où se trouvent les bases
| Version de Windows | Fichiers dans C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ | Format |
|---|---|---|
| Windows Vista à Windows 10 | Windows.edb, MSS*.log, MSS.chk, *.jrs, tmp.edb | ESE (JET Blue) avec journaux de transactions |
| Windows 11 | Windows.db + Windows.db-wal, Windows-gather.db + -wal, Windows-usn.db et d'autres | SQLite en mode WAL |
L'article de dépannage de Microsoft cite Windows.edb pour Windows 10 et Windows.db pour Windows 11 dans ce même dossier. Les sources ne s'accordent pas sur la version exacte de Windows 11 qui a opéré la bascule ; ma règle est donc simple : regardez le dossier. La procédure d'acquisition complète, fichiers verrouillés et clichés instantanés compris, est dans où sont stockés Windows.edb et Windows.db et comment les collecter.
Comment les données sont organisées
Les deux formats conservent deux types d'enregistrements.
Le magasin de propriétés contient un enregistrement logique par élément indexé, identifié par un WorkId. Sous Windows 10, c'est SystemIndex_PropertyStore, une table ESE très large de plusieurs centaines de colonnes nommées comme 4447-System_ItemPathDisplay. Sous Windows 11, c'est SystemIndex_1_PropertyStore, une table SQLite étroite avec une ligne par triplet (WorkId, ColumnId, Value), et SystemIndex_1_PropertyStore_Metadata associe chaque ColumnId à un nom de propriété. La comparaison des formats détaille les deux structures.
Les tables gather (SystemIndex_Gthr et SystemIndex_GthrPth) sont la comptabilité du crawler : quels documents il connaît, sous quelle étendue (dossier), avec quelle date de dernière modification. Sous Windows 11, elles sont dans Windows-gather.db. Le DocumentID de la table gather correspond au WorkId du magasin de propriétés.
Cette séparation est précieuse. Un élément encore présent dans le magasin de propriétés mais absent de la table gather est un candidat « supprimé depuis son indexation ». Le Windows Search Index Parser signale exactement ce cas.
Ce que vous pouvez en tirer
| Élément de preuve | Propriété ou table | Pourquoi c'est utile |
|---|---|---|
| Chemin complet d'un fichier ou dossier | System.ItemPathDisplay | Existence d'un fichier à un emplacement, y compris longtemps après sa disparition |
| Taille, propriétaire, nom de l'ordinateur | System.Size, System.FileOwner, System.ComputerName | Attribution et identification |
| Création / modification / accès | System.DateCreated, System.DateModified, System.DateAccessed | Horodatages du système de fichiers vus au moment de l'indexation |
| Moment où l'indexeur l'a traité | System.Search.GatherTime | Un horodatage indépendant auquel les attaquants pensent rarement |
| Contenu textuel | System.Search.AutoSummary | Une partie d'un document, d'un script ou d'une note, même après suppression |
Historique de navigation (IE / ancien Edge ; System.Link.TargetUrl sous Windows 11) | Propriétés d'URL | Activité web quand les bases du navigateur ont disparu |
| Éléments d'historique d'activité | System.ItemType = ActivityHistoryItem | Usage d'applications et de fichiers rattaché au SID d'un utilisateur |
Les points sur les URL et l'ActivityHistory viennent des travaux de Stroz Friedberg publiés en 2023 par Phalgun Kulkarni et Julia Paluch, Windows Search Index: The Forensic Artifact You've Been Searching For. C'est la meilleure description publique du contenu de la structure Windows 11. Chaque propriété est expliquée dans les propriétés de l'index Windows Search expliquées.
L'angle des fichiers supprimés
Si cet artefact mérite sa place dans chaque triage Windows, c'est parce que l'index a du retard sur le disque. Quand un fichier est supprimé, l'indexeur est notifié et finit par retirer l'enregistrement, mais « finit par » peut durer longtemps sur une machine chargée ou éteinte. Sous Windows 11, la suppression arrive d'abord dans le journal WAL. Dès 2011, Chivers et Hargreaves ont montré (Forensic data recovery from the Windows Search Database, Digital Investigation) que les enregistrements de fichiers indisponibles persistent et que des enregistrements supprimés peuvent être carvés dans l'espace inutilisé de la base.
En pratique, trois situations se présentent, détaillées dans ce que l'index garde des fichiers supprimés :
- L'enregistrement est toujours actif dans le magasin de propriétés. N'importe quel parseur l'affiche.
- L'enregistrement a disparu de la base checkpointée mais figure encore dans le WAL (Windows 11), ou l'inverse.
- L'enregistrement a été supprimé de la base et ne survit que dans des pages libres. Il faut alors du carving.
Une méthode qui tient la route
- Collectez tout le dossier, pas seulement la base principale : fichiers WAL, base gather, journaux ESE. Utilisez la cible KAPE
WindowsIndexSearch, Velociraptor ou une image disque. - Vérifiez l'état. Pour ESE, un arrêt non propre (dirty shutdown) signifie que des modifications récentes sont encore dans les journaux. Voir réparer un Windows.edb en dirty shutdown avec esentutl. Pour SQLite, gardez
Windows.dbetWindows.db-walensemble. - Parsez et pivotez. Ouvrez le dossier dans le parseur dans le navigateur (voir le pas-à-pas) ou dans l'outil de votre choix. Exportez en CSV pour votre chronologie.
- Filtrez sur l'essentiel : chemins modifiables par l'utilisateur, exécutables, archives, autres lettres de lecteur, chemins réseau, extraits de contenu, éléments absents de la table gather.
- Corroborez. Un chemin dans l'index est une piste. Reliez-le à des fichiers LNK, des Jump Lists, au journal USN, à la Corbeille ou à Amcache avant d'écrire « l'utilisateur a ouvert ».
Un cas complet (fictif) est traité dans enquêter sur une intrusion avec l'index Windows Search.
Les limites à mentionner dans le rapport
- Périmètre. Seuls les emplacements indexés sont couverts. Dossiers exclus, lecteurs non indexés et types de fichiers réglés sur « propriétés uniquement » laissent des trous.
- La configuration peut changer. Le service peut être désactivé, l'index reconstruit ou supprimé. Voir l'anti-forensique contre l'index.
- Les horodatages sont des copies. Les dates MAC sont celles que le système de fichiers indiquait lors de l'indexation ; les changements ultérieurs n'apparaissent que si l'élément a été réindexé.
- Schéma non documenté. Microsoft documente les propriétés, pas la structure de la base. Tout ce qui concerne les tables provient de recherches publiques et de rétro-ingénierie.
- Maturité des outils. Les parseurs divergent sur les cas limites. Recoupez les constatations clés avec un second outil ; la comparaison des parseurs liste les options. Pour le Windows Search Index Parser en particulier : son lecteur ESE (Windows.edb) n'a été validé que sur des bases synthétiques à ce jour, son décodage Windows 11 suit des recherches publiques car Microsoft ne documente pas le schéma, et il ne carve pas encore les enregistrements supprimés dans les pages libres.
FAQ
L'index Windows Search est-il activé par défaut ?
Oui. Le service Windows Search (WSearch) démarre automatiquement sur les éditions clientes de Windows et indexe les emplacements par défaut, sauf si quelqu'un a désactivé le service ou exclu des dossiers.
L'index prouve-t-il qu'un utilisateur a ouvert un fichier ?
Non. Il prouve que l'indexeur a vu le fichier à un chemin donné, avec des métadonnées données. L'ouverture et l'exécution se démontrent avec d'autres artefacts : fichiers LNK, Jump Lists, Prefetch ou les éléments ActivityHistory que l'index lui-même peut contenir.
Peut-on se fier aux horodatages ?
Les dates de création, de modification et d'accès sont des copies des valeurs du système de fichiers au moment de l'indexation. Le gather time vient de l'horloge de l'indexeur. Tous sont des FILETIME en UTC.
Voir aussi la définition de FILETIME.
Pour aller plus loin
- Microsoft Learn : Troubleshoot Windows Search performance.
- Kulkarni et Paluch (Stroz Friedberg) : recherche sur l'index Windows Search et SIDR.
- Kaspersky Securelist : les artefacts forensiques de Windows 11.
- Chivers et Hargreaves (2011) : Forensic data recovery from the Windows Search Database.