Anti-forensique de l'index Windows Search et ses limites

En bref. Quiconque a des droits d'administrateur peut facilement neutraliser l'index Windows Search : désactiver le service WSearch, reconstruire l'index, le compacter ou supprimer C:\ProgramData\Microsoft\Search\Data. On peut aussi l'éviter tout simplement en travaillant hors des emplacements indexés. Rien de tout cela n'est propre. Les changements de service laissent des traces dans le journal d'événements Système et dans le registre. Un index reconstruit a des gather times révélateurs et un fichier de base récent. Des fichiers de base supprimés laissent des traces dans l'USN et la MFT. Avant de conclure quoi que ce soit d'un enregistrement manquant, vérifiez le périmètre d'indexation et l'âge de l'index lui-même. Une absence dans l'index est, à elle seule, une preuve faible.

C'est aussi un article sur les limites. La plupart des trous dans l'index ne sont pas des attaques : ils viennent de la configuration, de la maintenance et du comportement propre de l'indexeur. Tout le travail consiste à distinguer les deux.

Ce qu'un attaquant (ou un administrateur) peut faire

Action	Comment	Effet sur l'index
Rester hors périmètre	Travailler dans `C:\ProgramData`, `C:\Windows\Temp`, un nouveau dossier racine ou un lecteur non indexé	Rien n'est indexé. Pas une altération, juste un évitement.
Exclure un emplacement	Options d'indexation → Modifier, ou Paramètres → « Ajouter un dossier exclu »	Les éléments concernés sont retirés de l'index au fil du temps
Suspendre ou désactiver le service	`sc config wsearch start= disabled` + `net stop wsearch`, ou Services	Index figé à ce moment-là
Reconstruire	Options d'indexation → Avancé → Reconstruire	L'ancienne base est remplacée par une nouvelle construite de zéro
Compacter	`esentutl /d` sur `Windows.edb` (service arrêté)	Espace libre récupéré : les restes carvables d'enregistrements supprimés disparaissent
Supprimer les données	Arrêter le service, supprimer `C:\ProgramData\Microsoft\Search\Data\…`	Index perdu ; Windows en recrée un vide au démarrage du service
Modifier les réglages par type de fichier	Options d'indexation → Avancé → Types de fichiers : « Indexer les propriétés uniquement »	Plus d'extraits de contenu pour cette extension

Chacune de ces actions figure dans le guide de dépannage de Microsoft comme une étape légitime de réglage ou de réparation, y compris les commandes de compactage esentutl /d et la suppression du contenu de C:\ProgramData\Microsoft\Search\Data. C'est important pour votre rapport : la même action peut relever de la maintenance ou de la dissimulation, et l'intention doit venir du contexte.

Ce que laisse chaque action

Service désactivé ou arrêté

Registre : HKLM\SYSTEM\CurrentControlSet\Services\WSearch\Start. Une valeur de 4 signifie désactivé. Le guide de Microsoft attend Automatique (début différé) sur un poste client normal. Lisez-la avec un parseur de registre.
Journal d'événements Système : le Gestionnaire de contrôle des services enregistre les changements d'état et de type de démarrage des services. Cherchez le service Windows Search dans les journaux d'événements autour de la fenêtre de l'incident.
Traces d'exécution de sc.exe, net.exe ou services.msc : Prefetch, Amcache.
L'index lui-même : le gather time le plus récent de la base marque le moment où l'indexation s'est effectivement arrêtée. S'il précède l'incident de plusieurs heures ou jours sur une machine utilisée, demandez-vous pourquoi.

Index reconstruit

Base récente : la date de création de Windows.edb / Windows.db dans la MFT est récente, bien postérieure à l'installation du système et aux profils utilisateur.
Gather times resserrés : presque tous les éléments ont un gather time dans une courte fenêtre après la reconstruction, y compris les vieux fichiers. Sur un index qui a vieilli normalement, les gather times s'étalent sur des mois.
Historique manquant : les éléments de fichiers supprimés avant la reconstruction ont disparu, de même que l'historique web et les éléments d'activité antérieurs.
Les clichés instantanés (VSS) peuvent encore contenir la base précédente. Vérifiez-les avant d'abandonner.

Base compactée

esentutl /d réécrit la base dans un nouveau fichier compact. Les enregistrements actifs survivent ; les entrées « defunct » et les restes en pages libres, non. Vous ne verrez aucune différence dans un parseur classique, seulement dans ce qu'un outil de carving peut récupérer. Cherchez esentutl.exe dans les artefacts d'exécution, et un Windows.edb dont les horodatages MFT ont changé pendant que le service était arrêté.

Dossier de données supprimé

Journal USN : enregistrements de suppression pour Windows.edb, Windows.db, Windows-gather.db, MSS*.log dans …\Search\Data\Applications\Windows. Analysez le $J avec un parseur de journal USN.
MFT : les nouveaux fichiers de base ont une date de création correspondant au démarrage suivant du service.
Restes récupérables : les clusters des anciens fichiers peuvent encore être non alloués. Carver une base ESE ou SQLite entière dans l'espace non alloué est aléatoire, mais les signatures d'en-tête (0x89ABCDEF à l'offset 4 pour ESE, SQLite format 3 pour SQLite) donnent quelque chose à chercher.

Exclusions et changements par type de fichier

Ils se trouvent dans la configuration de Windows Search dans la ruche SOFTWARE, et les étendues gather de la base reflètent ce qui a réellement été parcouru. Une exclusion ajoutée le jour de l'incident, sur un dossier qui s'avère ensuite être une zone de préparation, est une constatation en soi.

Ce qui n'est pas de l'anti-forensique (mais y ressemble)

Contenu chiffré ou indisponible. Chivers et Hargreaves notaient en 2011 que le périmètre d'indexation et les attributs de chiffrement influent sur ce qui est indexé.
Le retrait de l'indexeur. L'indexeur se met en pause sur batterie, en cas d'activité de l'utilisateur ou de ressources faibles, selon le guide de Microsoft. Un trou de quelques heures dans les gather times sur un portable est normal.
Mises à niveau récentes. Une mise à jour de fonctionnalités ou le passage de Windows.edb à Windows.db peut produire un index neuf. Vérifiez l'historique d'installation du système avant de parler de reconstruction.
Mode Avancé ou Classique. Un fichier hors des emplacements du mode Classique n'aurait de toute façon jamais été indexé.
Timestomping. Modifier les horodatages d'un fichier change ce que l'index enregistre pour DateCreated / DateModified à la prochaine indexation. Cela ne change pas le gather time, qui vient de l'horloge de l'indexeur. Un exécutable « de 2019 » avec un gather time de 2026 est une piste, pas une contradiction.

Check-list avant de raisonner sur une absence

WSearch tournait-il pendant la période concernée ? (Registre, journaux d'événements, gather time le plus récent.)
L'emplacement était-il indexé ? (Étendues gather, configuration des Options d'indexation, mode Classique ou Avancé.)
Le contenu de ce type de fichier était-il indexé ? (Réglages Types de fichiers.)
Quel âge a l'index ? (Date de création MFT de la base, étalement des gather times.)
Avez-vous collecté le WAL et la base gather (Windows 11) ou rejoué les journaux ESE (Windows 10) ? Voir l'acquisition.
Existe-t-il des clichés instantanés avec un index plus ancien ?

Ce n'est que si les six questions ont une réponse que « absent de l'index » peut peser, et même alors cela doit appuyer d'autres éléments plutôt que tenir seul.

Ce que l'outil apporte, et ce qu'il n'apporte pas

Dans le Windows Search Index Parser, trier sur la colonne Indexé donne les gather times les plus récents et les plus anciens, le signalement « Indexé récemment » met en évidence la dernière journée d'indexation, et les avertissements ainsi que la liste « Fichiers non analysés » indiquent quels fichiers compagnons (WAL, base gather, journaux) étaient présents. Cela couvre une partie des questions 1 et 4, et la question 5, rapidement. Il ne lit ni le registre, ni la MFT, ni le journal USN, et il ne carve ni les enregistrements supprimés ni des bases entières dans l'espace libre. Utilisez pour cela les outils de la même famille cités plus haut.