Détecter la manipulation de Windows Prefetch

Prefetch est l'un des artefacts d'exécution les plus propres que Windows produit, et c'est précisément pourquoi des attaquants compétents s'en prennent à lui. Bonne nouvelle : les attaquants sont plus souvent négligents que prudents avec prefetch, et chaque forme courante de manipulation laisse une trace ailleurs sur l'hôte. Voici à quoi chacune ressemble quand on s'assoit avec les données.

Suppression massive

L'option grossière est del /q C:\Windows\Prefetch\*.pf ou un équivalent PowerShell. Rapide, bruyante, efficace tant que personne ne compare le résultat à une baseline.

Signal : un nombre de fichiers bien inférieur à ce que la version de l'OS et l'uptime devraient produire. Une station Windows 11 en ligne depuis six mois avec douze fichiers .pf n'est pas une installation propre. Même une image Win10 fraîche atteint la centaine en une semaine.

Contre-analyse : les suppressions de fichiers sont des événements USN. Récupérez le journal USN et grepez sur .pf pour reconstituer les noms et les horodatages de suppression. Le $LogFile NTFS (encore résident, fenêtre beaucoup plus courte) contient souvent la même preuve avec le détail des attributs. L'entrée MFT du répertoire lui-même conserve une heure de dernière modification qui fixe quand la purge a eu lieu. Croisez avec l'EVTX Security ou Sysmon autour de cette fenêtre et vous identifierez généralement le processus responsable.

Suppression ciblée

La version soignée : supprimer le seul .pf correspondant au binaire malveillant, laisser tout le reste intact. Beaucoup plus difficile à repérer rien qu'au nombre de fichiers.

Signal : une exécution que vous pouvez prouver ailleurs — Security 4688, Sysmon EID 1, AmCache, Shimcache, entrées LNK ou jump list — sans .pf correspondant. Sur un hôte où EnablePrefetcher = 3 et où le service SysMain a tourné, ce trou n'est pas une coïncidence.

Contre-analyse : faites du carving sur l'espace non alloué du volume système. Le prefetch compressé en Xpress Huffman commence par MAM\x04 — une signature de quatre octets rare dans les données normales. bulk_extractor ou une règle rapide pour scalpel ressortiront les .pf supprimés tant que leurs clusters n'ont pas été réutilisés. Vérifiez aussi les Volume Shadow Copies ; les répertoires Prefetch survivent souvent dans des snapshots plus anciens.

Fichiers prefetch plantés

Déposer un .pf provenant d'une autre machine sur la cible. Utilisé pour fabriquer un alibi, dans des exercices red team pour tester la détection du SOC, occasionnellement par des malwares qui veulent paraître installés depuis longtemps.

Signal : le hash de 8 caractères dans le nom de fichier ne correspond pas à ce que la Hash Function 5 de Win7+ produit pour le chemin de l'exécutable embarqué dans le payload. Recalculez et comparez. Une discordance est concluante.

Autres indices : des horodatages du file record NTFS qui contredisent les valeurs FILETIME à l'intérieur du fichier (un .pf ne peut pas avoir tourné avant son existence) ; des horodatages d'exécution identiques sur des entrées « différentes », ce qui veut généralement dire que l'attaquant a copié-collé le même modèle en oubliant de varier les plages d'octets ; des numéros de série de volume dans la section d'information de volume qui ne correspondent pas aux volumes de cet hôte.

Compteurs et horodatages falsifiés

La variante chirurgicale : éditer un vrai .pf sur place pour abaisser le compteur d'exécutions ou réécrire les huit emplacements FILETIME de dernière exécution. Rare car il faut comprendre le layout SCCA, mais ça arrive.

Signal : là où des sommes de contrôle SCCA sont présentes, elles échouent. Le Last-Modified du fichier dans la MFT ne s'aligne pas avec le FILETIME le plus récent à l'intérieur. Des compteurs d'exécution qui chutent entre deux collectes sont impossibles en comportement Windows normal — SysMain ne fait qu'incrémenter — donc une diminution signifie que quelque chose a réécrit le fichier.

Prefetch désactivé avant l'attaque

L'anti-forensique la moins chère est de ne pas produire l'artefact en premier lieu. Réglez EnablePrefetcher = 0 et EnableSuperfetch = 0, arrêtez SysMain, et l'hôte n'écrira pas de fichiers .pf du tout. Voir le post sur le serveur désactivé pour le layout de registre en détail.

Signal : HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher = 0 sur une station dont la valeur par défaut est 3, combiné à un C:\Windows\Prefetch\ vide. Recoupez via le parser de hive registre avec une Volume Shadow Copy plus ancienne : si la valeur est passée de 3 à 0 en plein uptime, le LastWrite de la hive SYSTEM vous dit quand, et l'EVTX pour cette fenêtre vous dit en général qui.

Assembler le tout

La question, dans un dossier contesté, n'est que rarement « ce binaire a-t-il tourné ». Elle est « puis-je défendre l'affirmation que ce .pf dit ce qu'il dit ? ». Traitez chaque entrée comme n'importe quelle autre pièce à conviction : corroborez-la. Un seul hit prefetch est une piste. Un hit prefetch qui s'aligne avec les hashes AmCache, les chemins Shimcache, les événements d'écriture USN et un Security 4688 ou Sysmon 1, c'est un témoignage.

Pour aller plus loin

• Joachim Metz, documentation libscca — pour la disposition exacte des champs nécessaires à la détection d'éditions in-place.
• Eric Zimmerman, PECmd — expose les champs SCCA à recouper avec le hash du nom de fichier.