Détecter les manipulations de Prefetch Windows
Si Prefetch est l'un des meilleurs artefacts d'exécution produits par Windows, c'est aussi l'un de ceux que les attaquants tentent le plus souvent d'effacer. Un intrus sophistiqué laisse rarement les compteurs d'exécutions et les horodatages intacts. Voici à quoi ressemble, à l'analyse, chaque forme courante de manipulation.
Suppression de masse
L'approche grossière : del /q C:\Windows\Prefetch\*.pf. L'empreinte
est évidente — un poste de travail actif passe de plusieurs centaines
de fichiers prefetch à quelques-uns, tous créés très récemment au fur
et à mesure que le système tourne après la suppression.
Signal : nombre de fichiers très en deçà du référentiel attendu
pour la version de l'OS et l'âge de la machine. Un poste de travail
vieux de six mois avec douze fichiers .pf est suspect.
Contre-analyse : les fichiers prefetch laissent des entrées dans le
journal NTFS lors de leur suppression. Récupérez le $LogFile et le
$UsnJrnl, et vous pourrez sans doute restaurer à la fois les noms de
fichiers et les horodatages des entrées supprimées. Le fait même de la
suppression constitue une preuve.
Suppression ciblée
Plus prudent : ne supprimer que le fichier .pf du binaire malveillant.
Tout le reste paraît normal.
Signal : un processus dont vous pouvez prouver l'exécution (via Security 4688, Sysmon, ou Amcache) n'a pas d'entrée prefetch correspondante sur un hôte où prefetch est activé. Une suppression ciblée peut aussi être déduite quand l'horodatage de modification du dossier est suspicieusement récent par rapport à son contenu.
Contre-analyse : croisez Amcache et ShimCache pour récupérer le
chemin manquant. Carvez l'espace non alloué du volume système à la
recherche de fichiers .pf ; le prefetch compressé Xpress laisse un
en-tête distinctif MAM\x04 facile à scanner.
Fichiers prefetch déposés
Plus subtil : déposer un fichier prefetch provenant d'une autre machine sur la cible pour fabriquer un faux alibi (ou, lors d'exercices red team, pour tester la détection du SOC).
Signal : le hash prefetch présent dans le nom de fichier ne correspond pas à ce que l'algorithme de hash produit pour le chemin d'exécutable incorporé dans le payload prefetch. Recalculez le hash sur le chemin parsé et comparez-le au suffixe du nom de fichier — une non-correspondance est concluante.
Autres indices : des horodatages d'enregistrement de fichier NTFS qui ne concordent pas avec le contenu prefetch parsé ; des valeurs FILETIME identiques sur des fichiers prefetch « différents » (un attaquant a copié-collé le même gabarit).
Compteurs d'exécutions et horodatages falsifiés
L'attaque la plus chirurgicale : éditer un vrai fichier prefetch en place pour réduire le compteur d'exécutions ou modifier les horodatages. C'est rare, parce qu'il faut comprendre le format, mais cela arrive.
Signal : les checksums SCCA (quand ils sont présents) échouent. Des horodatages qui ne correspondent pas à l'heure de modification NTFS du fichier. Des compteurs d'exécutions qui diminuent entre deux collectes — Windows ne fait qu'incrémenter, donc une décroissance signifie qu'un autre acteur a écrit le fichier.
Prefetch désactivé
La version pré-attaque : configurer Windows pour que prefetch ne crée jamais de fichiers, dès le départ. Voyez Prefetch sur Windows Server et configurations désactivées pour ce qu'il faut chercher dans le registre.
Signal : PrefetchParameters\EnablePrefetcher = 0 dans le registre
sur un poste de travail, alors que la valeur par défaut est 3.
Combiné à un dossier Prefetch\ vide, c'est un indicateur fort que le
système a été préconfiguré pour supprimer cet artefact.
En synthèse
Lorsque les preuves prefetch comptent dans un dossier, la question est rarement « ce fichier s'est-il exécuté ». C'est « puis-je faire confiance à ce que dit cette entrée prefetch ? » Traitez la réponse comme n'importe quelle autre pièce à conviction : corroborez-la. Une entrée prefetch seule est une piste ; une entrée prefetch qui concorde avec Amcache, ShimCache, le journal Sécurité et Sysmon est un témoignage.