← Retour à tous les articles

La première moitié de toute conversation que j'ai sur Prefetch sur un hôte Win10 ou Win11 finit par tourner autour de SuperFetch, SysMain, ReadyBoost, et de la manière dont Microsoft appelait ses fonctionnalités de gestion mémoire à un trimestre donné. Une moitié de la salle pense que c'est la même chose. L'autre pense que Prefetch est déprécié. Les deux ont tort, mais dans des directions différentes, et les malentendus affectent à quel point on peut faire confiance au répertoire Prefetch sur un hôte moderne.

Ce billet est la version propre de cette conversation.

Ce qu'est vraiment chacun

Prefetch est le cache au niveau fichier pour le démarrage des applications. Observe les dix premières secondes d'un processus, écrit un fichier .pf, et utilise ce fichier au lancement suivant pour pré-fauter les pages dont le processus aura probablement besoin. Vit dans C:\Windows\Prefetch\. C'est l'artefact qui nous intéresse.

SuperFetch était une fonctionnalité de gestion mémoire introduite avec Windows Vista. Elle suit les motifs d'utilisation des applications dans le temps (pas seulement au démarrage, mais en usage normal) et précharge les pages en RAM pendant les périodes inactives, afin que les applications les plus utilisées démarrent plus vite. Elle écrit ses données de suivi dans des fichiers Ag*.db dans C:\Windows\Prefetch\. Ces fichiers .db ne sont pas des fichiers Prefetch. Ce sont des bases de données SuperFetch.

SysMain est le nom que SuperFetch a pris à partir de Windows 10 1709. Même fonctionnalité, même DLL de service (sysmain.dll), mêmes fichiers .db dans le répertoire Prefetch. Le service qui s'appelait « Superfetch » dans services.msc s'appelle désormais « SysMain » sur tout hôte Win10/11 actuel. Le renommage était cosmétique.

ReadyBoost est une fonctionnalité distincte qui utilise une clé USB comme cache write-through pour le working set. Pas pertinent pour l'analyse forensique Prefetch, mais vit dans le même voisinage conceptuel et se mélange donc aux autres.

Les trois artefacts voisins de Prefetch sur un hôte Win10/11 sont donc :

  • C:\Windows\Prefetch\<EXE>-<HASH>.pf : traces Prefetch par application, l'artefact qui occupe tout ce site.
  • C:\Windows\Prefetch\AgAppLaunch.db et compagnie : bases de données SysMain, un artefact distinct (SRUM et les bases SysMain sont des choses différentes, toutes deux utiles, aucune n'est Prefetch).
  • C:\Windows\Prefetch\NTOSBOOT-XXXXXXXX.pf : le Prefetch de boot, régénéré à chaque démarrage.

Quand quelqu'un dit « le répertoire Prefetch », il veut généralement parler du premier. Quand il dit « Prefetch » sans contexte, probablement aussi du premier, mais ça vaut la peine d'être précis quand on rédige un rapport.

La question de la désactivation sur SSD

Voici la partie qui revient sans cesse.

Sur Vista et Windows 7, Prefetch et SuperFetch étaient activés pour tout le monde, sur tout type de disque. Sur Windows 8, Microsoft a ajouté la logique pour détecter les SSD et réduire ou désactiver certaines opérations dessus, partant du principe que les SSD ne profitent pas autant du préchargement séquentiel que les HDD.

Sur Windows 10, cette logique est devenue plus agressive. Sur Windows 11, plus encore.

Ce que « désactivé sur SSD » signifie en pratique, autant que j'aie pu le déterminer depuis la télémétrie et la documentation variable de Microsoft :

  • Le Prefetch de boot (NTOSBOOT-XXXXXXXX.pf) est toujours écrit.
  • Le Prefetch d'application (les .pf par .exe) est partiellement écrit. Certaines applications produisent des .pf, d'autres non. La décision semble être prise par SysMain à partir d'heuristiques selon que l'application bénéficierait du préfetch.
  • Le préchargement proactif de SuperFetch/SysMain est largement désactivé sur SSD parce que Microsoft considère que la baisse de latence ne vaut pas le coût d'E/S.

La conséquence forensique : sur un hôte Win10 ou Win11 avec SSD, l'absence d'un .pf pour un exécutable donné n'est pas une preuve que l'exécutable n'a pas tourné. C'est une preuve que soit l'exécutable n'a pas tourné, soit SysMain a décidé de ne pas écrire de données Prefetch pour lui.

Empiriquement, j'ai vu une couverture Prefetch de 60 à 90 % sur des hôtes Win11 sur SSD, contre près de 100 % sur des hôtes Win10 sur HDD. Le pourcentage exact dépend de la charge de l'hôte, des exécutables que les heuristiques Microsoft ont décidé de sauter, et si le système est sous pression mémoire.

Si vous devez savoir avec certitude qu'un binaire a tourné, ne vous fiez pas à l'absence d'un .pf sur un hôte SSD moderne. Couplez à l'EVTX, à AmCache, et à la télémétrie réelle d'exécution de processus de l'hôte.

Les boutons du registre

Le chemin de registre qui contrôle tout cela est :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

Les valeurs qui comptent :

  • EnablePrefetcher (REG_DWORD). Contrôle le Prefetch d'application.
    • 0 = désactivé
    • 1 = Prefetch d'application uniquement
    • 2 = Prefetch de boot uniquement
    • 3 = les deux (défaut sur la plupart des SKU client)
  • EnableSuperfetch (REG_DWORD). Mêmes valeurs possibles, contrôle SuperFetch/SysMain.
  • EnableBootTrace (REG_DWORD). Contrôle la trace de boot. Généralement 0 sur les SKU client où le reste est activé.

Sur une installation par défaut Windows 10/11 Pro, vous verrez EnablePrefetcher = 3 et EnableSuperfetch = 3. Sur une installation Windows Server par défaut, les deux sont typiquement 0. Sur des hôtes où une stratégie de groupe a modifié des choses, on peut voir n'importe quelle valeur.

La logique de détection SSD ne modifie pas ces valeurs. Même avec EnablePrefetcher = 3, l'OS peut sauter l'écriture de certains .pf sur un hôte SSD. On ne peut pas conclure « Prefetch sera complet » à partir d'un 3 dans le registre sur Win10+.

Le résumé honnête : le registre vous dit si Prefetch est administrativement activé. Il ne vous dit pas si Prefetch a effectivement été écrit pour une exécution donnée. Sur Win7 et antérieur, les deux étaient la même affirmation. Sur Win10+, non.

Ce qui a changé à Win10 1709

La release 1709 (« Fall Creators Update ») est celle où :

  • SuperFetch a été renommée SysMain.
  • L'anneau de huit horodatages d'exécution du Prefetch d'application a commencé à être agressivement élagué pendant les fenêtres de maintenance inactives. Un .pf qui devrait montrer huit horaires peut n'en montrer que trois sur un hôte en place depuis un moment.
  • Le saut SSD-aware sur les écritures de .pf est devenu plus agressif que dans les builds Win10 antérieurs.

Si vous lisez une littérature DFIR ancienne sur Prefetch (tout ce qui est antérieur à 2018), supposez que l'auteur travaillait dans un monde pré-1709 et que certaines de ses hypothèses sur la couverture Prefetch ne tiennent plus.

La plus conséquente est l'élagage des horodatages. L'enseignement classique est « Prefetch garde les huit dernières exécutions ». L'enseignement corrigé est « Prefetch garde jusqu'à huit, avec Win10 1709+ qui élague opportunément les anciennes entrées ». Un .pf qui montre trois horodatages ne signifie pas que le binaire a tourné trois fois. Cela signifie que le compteur d'exécutions dit une chose (la borne inférieure du total de runs) et que le tableau d'horodatages en montre trois qui ont survécu à l'élagage.

Windows Server

À redire clairement : Prefetch est désactivé par défaut sur Windows Server. De 2008 R2 à 2022, la valeur par défaut d'EnablePrefetcher sur une installation serveur fraîche est 0. SysMain est également éteint.

Beaucoup de parcs activent Prefetch sur les serveurs via GPO. Beaucoup non. Si vous travaillez une mission serveur et que le répertoire Prefetch est vide, la première chose à vérifier est si Prefetch a jamais été activé sur cet hôte. Récupérez la hive SYSTEM, lisez la valeur, vérifiez le LastWrite. Si la valeur a été écrite pour la dernière fois à l'installation de l'OS et vaut 0, l'absence de .pf ne dit rien sur ce qui a tourné.

Si la valeur est passée à 3 il y a six mois et que le répertoire ne contient que des .pf des six derniers mois, c'est cohérent. Si la valeur a changé il y a deux jours et que le répertoire contient des fichiers d'avant le changement, vous avez une discordance à expliquer (généralement, la politique a été appliquée récemment mais le répertoire contient des fichiers de l'époque d'installation de l'OS ou d'un état de politique antérieur).

Que vérifier avant de se fier à un .pf

Avant de citer Prefetch dans un rapport sur un hôte Win10/11, je vérifie :

  1. Prefetch est-il activé ? Récupérez EnablePrefetcher et EnableSuperfetch dans la hive SYSTEM. Notez le LastWrite de PrefetchParameters.
  2. Était-il activé au moment des événements qui m'intéressent ? Si la valeur a changé pendant la fenêtre suspecte, le changement fait partie de la chronologie.
  3. L'hôte est-il SSD ou HDD ? Vérifiez le type de disque depuis les infos système. Sur SSD, baissez votre confiance en « absence de .pf = absence d'exécution ».
  4. L'hôte est-il un serveur ? Si oui, intégrez l'état par défaut désactivé et l'historique de politique.
  5. Y a-t-il des fichiers Ag*.db dans le répertoire Prefetch ? Si oui, SysMain a tourné, et sa base de données peut contenir des données d'exécution supplémentaires séparées des .pf.
  6. PECmd parse-t-il les .pf proprement ? Les fichiers incohérents ou qui échouent à la validation du parser méritent un second regard pour détecter une manipulation.

Si les six sont OK, la preuve Prefetch est solide. Sinon, la preuve Prefetch reste utile mais avec des réserves qui devraient apparaître dans le rapport.

Une note sur les bases SysMain

Les fichiers Ag*.db du répertoire Prefetch sont un artefact distinct qui mérite sa propre discussion un jour. Brièvement : AgAppLaunch.db suit les compteurs et heures de lancement d'applications sur des fenêtres plus larges que Prefetch. Il peut corroborer Prefetch et couvre parfois des exécutions que Prefetch a ratées.

Des outils pour les parser existent, mais sont moins matures que les parsers Prefetch. Eric Zimmerman a écrit dessus. Le format n'est pas documenté par Microsoft et est rétro-ingénierisé, traitez donc toute sortie de parser avec le scepticisme approprié.

Ce que je dis aux clients

Sur Win7 et antérieur, Prefetch est exhaustif. Sur Win10 sur HDD, exhaustif. Sur Win10 sur SSD, partiel. Sur Win11 sur SSD, plus partiel encore. Sur Windows Server, conditionnel à la politique.

La bonne réponse à « y a-t-il un fichier Prefetch pour le binaire X » n'est jamais la seule question. La bonne réponse à « devrais-je m'attendre à en trouver un compte tenu de la configuration de cet hôte » est la question à poser avant la première.

Pour aller plus loin