Enquête avec l'index Windows Search : un cas concret

En bref. Scénario fictif, construit sur l'exemple synthétique fourni avec l'outil. Sur le poste FIN-WKS-07, l'index de recherche de Windows 11 donne à lui seul les grandes lignes d'une intrusion menée par le compte svc_backup : une archive d'outils téléchargée, un binaire déposé dans C:\ProgramData\Intel, un fichier d'identifiants écrit puis supprimé (son texte survit dans System.Search.AutoSummary), un tableur de paie copié d'un partage réseau vers un lecteur amovible, rclone.exe déposé dans Users\Public et une visite sur un site de stockage cloud. Les étapes les plus récentes ne figurent que dans Windows.db-wal. Chaque constatation est une piste à confirmer avec d'autres artefacts, et la suite indique lesquels.

Tout est inventé. L'entreprise, les machines, les comptes, les noms de fichiers, les horodatages et les identifiants proviennent des bases de démonstration générées pour le bouton « Essayer un exemple » du site. Aucun incident ni aucune donnée réels ne sont décrits. Vous pouvez charger les mêmes données avec Essayer un exemple (Windows 11) dans le Windows Search Index Parser et suivre pas à pas.

La situation

Le référent informatique de l'équipe finance signale que svc_backup, un compte de service qui ne devrait jamais ouvrir de session interactive, apparaît dans la liste des utilisateurs récemment connectés sur FIN-WKS-07. La machine est isolée le 14 septembre 2026 dans l'après-midi. Vous recevez une collecte KAPE incluant la cible WindowsIndexSearch. Les journaux d'événements sont traités par un collègue. Vous commencez par l'index de recherche, parce qu'il est rapide et qu'il fait partie des rares artefacts capables de contenir le contenu des fichiers.

Étape 1 : charger et vérifier la complétude

En déposant le ZIP de collecte, on voit Windows.db, Windows.db-wal et Windows-gather.db associés depuis le même dossier. Aucun avertissement de WAL ou de base gather manquants. Bien : nous avons l'état actuel et le contrôle croisé gather. Les compteurs montrent un petit index : c'est une démo. Un vrai poste de travail afficherait des dizaines de milliers d'éléments, ce qui explique justement l'importance du filtrage.

Tous les horodatages sont en UTC (les FILETIME stockés sont en UTC ; je garde l'affichage en UTC pour le rapport).

Étape 2 : les éléments signalés d'abord

Signalés uniquement, triés par date de création (extrait ; le signalement « Indexé récemment », présent sur la plupart de ces lignes, est omis pour la lisibilité) :

S'y ajoute un enregistrement présent uniquement dans la table gather : m64.exe sous C:\Users\svc_backup\AppData\Local\Temp\7zS4A2.tmp, sans plus aucune propriété dans le magasin.

Étape 3 : lecture de chaque élément

Le profil

C:\Users\svc_backup créé à 09:58:41. Un dossier de profil pour un compte de service sur un poste de travail signifie qu'une ouverture de session interactive ou RDP l'a créé. À corroborer : événements d'ouverture de session (4624, types 10 ou 2) dans les journaux d'événements autour de 09:58.

L'archive d'outils et l'extraction temporaire

tools.zip, 4 812 331 octets, propriétaire FIN-WKS-07\svc_backup, créé à 10:05:31, indexé à 10:05:58. À 10:06:38, le raccourci du menu Démarrer 7-Zip File Manager.lnk présente une nouvelle date d'accès. À 10:06:55, la table gather connaît un m64.exe dans un dossier 7zS…tmp sous le Temp du compte. Ses propriétés ont disparu du magasin : c'est le motif table gather uniquement d'un fichier temporaire nettoyé. Lecture : l'archive a été ouverte avec 7-Zip et m64.exe extrait, d'abord vers un emplacement temporaire. À corroborer : les Jump Lists de 7-Zip et le journal USN pour le dossier temporaire.

Le binaire déposé

C:\ProgramData\Intel\m64.exe, 1 359 872 octets, créé à 10:07:14. ProgramData\Intel est un chemin de préparation classique « qui a l'air légitime » ; un dossier au nom d'un fabricant de matériel contenant un exécutable isolé mérite l'attention. L'élément est modifié dans le WAL : la base checkpointée a une date d'accès de 10:07:14, le WAL une nouvelle date d'accès de 10:51:02 et un nouveau gather time de 10:51:30. Il a été touché à nouveau 45 minutes plus tard. L'index ne prouve pas l'exécution. À corroborer : Prefetch, Amcache, ShimCache.

Le fichier d'identifiants supprimé

C:\ProgramData\Intel\creds.txt, 214 octets, créé à 10:09:48, modifié à 10:14:02, indexé à 10:14:30. Il est absent de la table gather, et l'enregistrement gather du dossier Intel indique une dernière modification à 10:55:04. Sur le disque, le fichier a disparu. Son extrait de contenu est toujours dans le magasin de propriétés :

FIN-SQL01 sa / Winter2026! | FILESRV01 CORP\svc_backup / Bkp#2026-fin | mega: fin-backup

Trois jeux d'identifiants : le compte sa du serveur SQL, le mot de passe de domaine du compte de service lui-même, et ce qui ressemble à un nom de compte de stockage cloud. Dans un vrai rapport, je le citerais dans une annexe à diffusion restreinte et je déclencherais la réinitialisation des identifiants. C'est la valeur décrite dans les traces de fichiers supprimés dans l'index Windows Search : le contenu d'un fichier qui n'existe plus, sans aucun carving. À corroborer : la Corbeille (supprimé via l'Explorateur ?), le journal USN (enregistrement de suppression de creds.txt vers 10:55) et les journaux d'authentification de FIN-SQL01 et FILESRV01.

Le fichier de paie, deux fois

\\FILESRV01\Finance\Payroll\Payroll_2026.xlsx : un chemin réseau appartenant à CORP\payroll-admins, 188 406 octets, modifié pour la dernière fois le 12 septembre à 16:02, consulté le 14 septembre à 10:32:15, indexé à 10:33:01. Extrait : les en-têtes de colonnes d'un tableau de paie. Le partage était indexé sur ce poste, donc l'index enregistre la date d'accès telle qu'il l'a vue.

Puis E:\exfil\finance_2026\Payroll_2026.xlsx : autre lecteur, même taille, même date de modification (12 septembre 16:02, préservée par la copie), créé à 10:40:12, propriétaire FIN-WKS-07\svc_backup. Uniquement dans le WAL : cet enregistrement n'existe que dans les dernières transactions, pas dans la base checkpointée. Sans Windows.db-wal, vous ne le verriez pas. Voir l'analyse forensique de Windows.db : SQLite et le WAL. Lecture : copie du fichier de paie vers un lecteur amovible vers 10:40. À corroborer : historique des périphériques USB dans le registre et les journaux d'événements, fichiers LNK pointant vers E:\.

rclone et le site cloud

C:\Users\Public\rclone.exe, 58 720 256 octets, créé à 10:45:03, consulté à 10:47:12, uniquement dans le WAL. Rclone est un outil de synchronisation légitime, très utilisé abusivement pour l'exfiltration. Un élément d'historique web indexé à 10:46:52 pointe vers https://mega.nz/start, consulté à 10:46:30, avec un SID utilisateur se terminant par -1013 dans son URL iehistory://. À corroborer : associer le SID à un compte via les ruches SAM / ProfileList, vérifier les artefacts de navigateur, chercher rclone.conf et les journaux réseau ou proxy.

Étape 4 : la chronologie

Chaque ligne est une observation d'indexation, pas en soi une exécution ou une action de l'utilisateur. La colonne de confiance correspond à ce que je défendrais devant un relecteur avant corroboration.

Ce que l'index ne pouvait pas nous dire

• Si m64.exe ou rclone.exe ont été exécutés. Il faut des artefacts d'exécution.
• Ce que rclone a envoyé. Journaux réseau, proxy et cloud, ou rclone.conf.
• Tout ce qui se trouve hors des emplacements indexés. Un outil lancé depuis un dossier non indexé serait invisible ici.
• Tout ce qui s'est passé après 10:51. Le dernier gather time de l'index marque la limite de sa visibilité.

À retenir

• Collectez le WAL et la base gather : trois des constatations clés en dépendent.
• Triez d'abord les éléments signalés par date ; ouvrez les détails ensuite.
• Traitez les extraits de contenu comme la preuve du contenu au moment de l'indexation, et protégez-les comme les données qu'ils contiennent.
• Rédigez chaque constatation sous la forme « l'index enregistre… » et indiquez à côté l'artefact de corroboration.

Articles liés

• Comment ouvrir Windows.edb et Windows.db pas à pas
• Les propriétés de l'index Windows Search expliquées
• L'anti-forensique contre l'index Windows Search