Aller au contenu

06 · Activité utilisateur

Index Windows Search : analyse de Windows.edb et Windows.db

Exploiter l'index Windows Search : chemins, dates, extraits de contenu, e-mails Outlook et traces de fichiers supprimés. Windows.edb, Windows.db et outils.

Publié le 10 min de lecture

Ce guide vous apprend à collecter et analyser l'index Windows Search, puis à en tirer des preuves : qu'un fichier existait à un chemin donné, le texte qu'il contenait, les e-mails que possédait un utilisateur et les traces d'éléments supprimés depuis. Vous verrez aussi ses limites, pour ne pas confondre indexation en arrière-plan et activité utilisateur.

Ce qu'est l'indexeur

Le service Windows Search (WSearch, qui exécute SearchIndexer.exe) parcourt les emplacements configurés et stocke, pour chaque élément, un ensemble de propriétés : chemin, nom, taille, type, propriétaire, dates et, pour de nombreux formats, une partie du texte. L'Explorateur, le menu Démarrer et Outlook interrogent cet index pour afficher des résultats instantanés.

Pour l'enquêteur, c'est un catalogue des fichiers de l'utilisateur tenu par le système, indépendant du système de fichiers lui-même. Quand l'entrée de la MFT a été réutilisée et que le journal USN a tourné, l'index peut encore décrire un fichier, et parfois son contenu. La fiche de l'index Windows Search liste les champs clés ; ce guide explique comment les exploiter.

Formats et emplacements

Version de WindowsEmplacementFormat
Vista, 7, 8.x, 10C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edbBase ESE, avec MSS*.log, MSS.chk et MSS*.jrs à côté
11 (en général)Même dossier : Windows.db, Windows-gather.db, Windows-usn.dbSQLite, chacun avec ses fichiers -wal et -shm (WAL SQLite)
Server 2019+ et hôtes multisessionC:\Users\<user>\AppData\Roaming\Microsoft\Search\Data\Applications\<SID>\Index par utilisateur
Tous...\Applications\Windows\GatherLogs\SystemIndex\Journaux de parcours (*.Crwl, *.gthr)

Le passage à SQLite est lié à Windows 11, mais le build exact et la conversion éventuelle de l'index lors d'une mise à niveau varient : considérez les fichiers présents sur le disque comme la référence. Sous Windows Server, le service Search n'est pas activé par défaut, un dossier vide y est donc normal.

Deux emplacements du registre méritent d'être relevés avant l'analyse :

  • HKLM\SOFTWARE\Microsoft\Windows Search, où DataDirectory peut déplacer l'index ailleurs.
  • HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\ (DefaultRules et WorkingSetRules), qui définit ce qui a été indexé.

Par défaut (mode « Classique »), l'index couvre les dossiers du profil utilisateur, les bibliothèques et le menu Démarrer. Le mode « Avancé », réglé dans les Paramètres, couvre tout le PC. Le périmètre détermine ce que vous pouvez espérer trouver : un outil déposé dans C:\PerfLogs ne sera pas indexé en mode Classique.

Ce qu'il enregistre

PropriétéSignificationUsage
System_ItemPathDisplay, System_ItemNameChemin complet et nomProuve qu'un fichier existait à un emplacement
System_Size, System_ItemType, System_MIMETypeTaille et typeRepère archives, scripts, images
System_DateCreated, System_DateModified, System_DateAccessedDates du fichier copiées depuis le système de fichiers à l'indexationInstantané des dates propres au fichier
System_Search_GatherTimeDernier traitement de l'élément par l'indexeurBorne haute de l'existence du fichier avec ce contenu
System_FileOwnerCompte propriétaireAttribution à un compte, avec prudence
System_Search_AutoSummaryExtrait du texteContenu de documents, scripts, notes
System_ThumbnailCacheIdClé vers le thumbcacheNomme une miniature sinon anonyme
System_Message_*, System_Author, System_TitleMétadonnées d'e-mails et de documentsExpéditeur, destinataires, objets

Dans Windows.edb, les propriétés se trouvent dans la table principale (SystemIndex_PropertyStore sous Windows 10, SystemIndex_0A sur les versions plus anciennes), avec des noms de colonnes préfixés par un identifiant numérique, comme 4447-System_ItemPathDisplay. Dans la structure SQLite de Windows 11, SystemIndex_1_PropertyStore contient des lignes WorkId, ColumnId et Value, et une table de métadonnées associe chaque ColumnId à un nom de propriété. Les tables de collecte (SystemIndex_Gthr, SystemIndex_GthrPth) enregistrent les éléments parcourus et leurs dossiers parents ; en SQLite, elles se trouvent dans Windows-gather.db.

E-mails

Quand Outlook s'appuie sur Windows Search, les messages et pièces jointes de la boîte aux lettres sont indexés avec expéditeur, destinataires, objet, dates et extrait du corps. Leurs chemins utilisent un schéma mapi:// ou mapi16:// contenant le SID du profil. Cela peut faire ressortir des messages supprimés de la boîte, ou fournir du contenu quand l'OST ou le PST est chiffré, absent ou corrompu.

Les systèmes anciens indexent l'historique d'Internet Explorer et de l'ancien Edge. Sous Windows 11, certains enregistrements d'URL et d'activité apparaissent aussi. Traitez-les comme un complément à la forensique des navigateurs, pas comme un substitut.

Collecte

La base est verrouillée par SearchIndexer.exe. Copiez-la via un cliché instantané, avec ses journaux :

set SRC=C:\ProgramData\Microsoft\Search\Data\Applications\Windows
mkdir E:\case\search
esentutl.exe /y "%SRC%\Windows.edb" /vss /d E:\case\search\Windows.edb
robocopy "%SRC%" E:\case\search MSS*.log MSS.chk /COPY:DAT
robocopy "%SRC%\GatherLogs" E:\case\search\GatherLogs /E /COPY:DAT

Sous Windows 11, copiez les bases SQLite avec leurs fichiers -wal et -shm depuis un cliché instantané ou une image, pour que le WAL reste cohérent avec sa base. La cible KAPE WindowsIndexSearch et la cible de triage Velociraptor du même nom collectent l'index système, les index par utilisateur et les journaux de collecte (acquisition et triage).

Windows.edb est souvent volumineux, plusieurs gigaoctets sur un poste très utilisé. Prévoyez-le dans vos collectes de triage plutôt que de l'écarter.

Rejouer les journaux ESE

Une copie à chaud est généralement en état « dirty ». Sur une copie de travail :

cd /d E:\case\search
esentutl.exe /mh Windows.edb | findstr /i "State"
esentutl.exe /r MSS /i

MSS est le nom de base des journaux de la base de recherche. Gardez aussi la copie non rejouée : certains outils récupèrent davantage d'enregistrements supprimés à partir des pages et journaux d'origine qu'à partir d'une base proprement récupérée.

Outils d'analyse

OutilFormatsAtout
SIDR (Stroz Friedberg, open source)ESE et SQLiteRapports fichiers, historique internet et activité en CSV ou JSON, par hôte
WinSearchDBAnalyzer (open source)ESEInterface graphique pour Windows.edb avec récupération des enregistrements supprimés
ESEDatabaseView (NirSoft)ESEParcours rapide des tables et export CSV
libesedb esedbexportESEExporte toutes les tables, tolère les bases endommagées
Navigateurs SQLiteSQLiteRequêtes manuelles sur les bases Windows 11, sur des copies
Windows Search ParserESE et SQLiteGratuit, fonctionne côté client dans le navigateur pour une base isolée
:: SIDR : lui indiquer le dossier contenant la ou les bases collectées
sidr.exe -f csv -o E:\out\search E:\case\search

:: libesedb : exporter toutes les tables ESE en fichiers texte
esedbexport -t E:\out\search\export E:\case\search\Windows.edb

Consultez sidr --help pour les options de votre build. Pour un travail manuel sous Windows 11, interrogez la table de propriétés et pivotez sur WorkId pour rassembler les propriétés de chaque élément.

Journaux de collecte (GatherLogs)

Le dossier GatherLogs\SystemIndex contient des journaux texte écrits pendant les parcours, en général des fichiers SystemIndex.<n>.Crwl et SystemIndex.<n>.gthr. Ils listent les URL des éléments traités ou en échec, avec codes d'état et horodatages. Ils tournent vite, mais lorsqu'ils sont présents ils peuvent montrer qu'un chemin existait au moment du parcours, y compris dans des emplacements que l'utilisateur a nettoyés depuis. Lisez-les avec un éditeur de texte ou un petit script : leur format n'est pas documenté et les outils les gèrent rarement.

Recouper avec l'historique de recherche de l'Explorateur

L'index stocke des éléments, pas des requêtes. Ce que l'utilisateur a tapé dans la zone de recherche de l'Explorateur se trouve dans WordWheelQuery, sous NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery, sous forme de chaînes UTF-16 classées par MRU. Les recherches lancées depuis la barre des tâches ou le menu Démarrer n'y sont pas stockées.

Associez les deux : un terme WordWheelQuery salaires, plus des entrées d'index pour \\fs01\hr$\salaires_2026.xlsx et une copie locale dans Downloads, construisent un récit solide de recherche, de découverte et de copie. Confirmez l'ouverture avec les fichiers LNK et les Jump Lists, comme décrit dans le guide ShellBags, LNK et Jump Lists.

Scénarios d'investigation

Fuite interne : que possédait l'utilisateur ?

Filtrez la table de propriétés sur le chemin du profil de l'utilisateur et sur les types de fichiers utiles (.xlsx, .pdf, .zip, .7z). L'index liste souvent des documents qui ne sont plus sur le disque, avec taille, dates et extrait AutoSummary. Comparez avec la liste actuelle de la MFT pour dresser la liste des « fichiers qui existaient et ont disparu ».

Rançongiciel et intrusion : outils et notes

Cherchez les noms d'outils, les extensions de scripts (.ps1, .bat, .vbs) et les noms de notes de rançon. Un C:\Users\admin\Desktop\run.ps1 indexé, dont l'AutoSummary contient le corps du script, peut permettre de récupérer un script d'attaquant supprimé. Le gather time indique que le fichier existait au moins à cet instant.

Fichiers supprimés et reconstructions

Les enregistrements d'éléments supprimés peuvent survivre dans les pages libres ESE et les fichiers MSS*.log, ou dans le -wal et la freelist SQLite ; WinSearchDBAnalyzer et les outils de carving les récupèrent (file carving). Les états antérieurs de l'index complet se trouvent dans les clichés instantanés de volume : comparer deux copies montre ce qui est apparu et a disparu entre elles. Une base récemment recréée, ou un service WSearch désactivé, sur un système qui indexe normalement, est un indicateur d'anti-forensique.

Nommer les miniatures

Une entrée du thumbcache a un identifiant mais pas de nom de fichier. Faites correspondre System_ThumbnailCacheId dans l'index à l'entrée du cache pour nommer l'image, ce qui est souvent décisif dans les affaires liées à des images.

Des e-mails sans la boîte aux lettres

Quand l'utilisateur a supprimé une conversation ou que l'OST est inaccessible, les éléments mapi16:// indexés peuvent encore fournir expéditeur, objet, date et extrait du corps. Présentez-les comme des enregistrements d'index, pas comme des messages récupérés.

Lire l'AutoSummary avec prudence

System_Search_AutoSummary est produit par le filtre (IFilter) associé à chaque type de fichier, sa qualité dépend donc du format : texte brut, scripts et documents Office donnent en général des extraits lisibles, les PDF dépendent du filtre installé, et les fichiers chiffrés ou binaires ne donnent rien. L'extrait reflète le contenu du fichier lors du dernier parcours, pas au moment de la suppression. Citez-le tel quel dans votre rapport, avec le gather time à côté, et précisez qu'il s'agit d'une copie partielle produite par l'indexeur. Quand le même chemin apparaît dans plusieurs clichés instantanés de l'index, comparer les extraits peut montrer comment un document a évolué.

Horodatages

Toutes les dates de l'index sont des valeurs FILETIME en UTC. Gardez leur sens en tête :

  • les System_Date* sont des copies des dates propres au fichier au moment du parcours ;
  • System_Search_GatherTime indique quand l'indexeur a traité l'élément ;
  • aucune ne correspond à une action de l'utilisateur.

Alignez les gather times sur le journal USN pour dater plus précisément la création et la suppression des fichiers (forensique NTFS).

Pièges

  • Indexation n'est pas accès. Le service fonctionne seul. N'écrivez jamais « l'utilisateur a consulté » sur la base d'un enregistrement d'index.
  • Le périmètre compte. Un fichier absent peut simplement se trouver hors des emplacements indexés, ou être exclu par son type.
  • Décalage. Le gather time peut suivre les modifications de fichiers avec des minutes de retard ou plus, et un indexeur chargé ou bridé peut sauter des éléments.
  • Bases « dirty ». Rejouer les journaux modifie la base ; gardez l'original pour récupérer les enregistrements supprimés.
  • Ouvrir les originaux SQLite. Cela peut déclencher un checkpoint du WAL et faire perdre des enregistrements. Travaillez sur des copies.
  • Contenu limité. L'AutoSummary est un extrait, pas le document, et tous les formats ne sont pas indexés en texte intégral.
  • Hypothèses de format. Un Windows 11 mis à niveau depuis Windows 10, ou un DataDirectory déplacé, peut ne pas correspondre à ce que vous attendez.

Checklist de la méthode

  1. Relever le build de Windows, l'état du service WSearch, DataDirectory et les règles de périmètre d'indexation.
  2. Collecter Windows.edb avec les journaux MSS*, ou Windows*.db avec -wal et -shm, ainsi que les index par utilisateur et GatherLogs, depuis un cliché instantané ou une image.
  3. Conserver une copie intacte ; rejouer les journaux ESE sur une seconde copie avec esentutl /r MSS /i si nécessaire.
  4. Analyser avec SIDR, et parcourir avec WinSearchDBAnalyzer ou ESEDatabaseView pour les enregistrements supprimés ou les tables brutes.
  5. Filtrer sur les mots-clés de l'affaire : noms de fichiers, chemins, extensions, expéditeurs, noms d'outils.
  6. Comparer les chemins indexés avec la MFT actuelle et les clichés instantanés pour lister les fichiers supprimés ou déplacés.
  7. Recouper avec WordWheelQuery, les fichiers LNK, les Jump Lists, le thumbcache et le journal USN ; noter le sens de chaque horodatage à côté de lui sur une chronologie en UTC.

Domaine 06

Activité utilisateur

Les fiches artefacts derrière ce guide : emplacement selon la version de Windows, ce que prouve chacun et les outils pour l'analyser.

Articles liés