Skip to content

RecentFileCache.bcf : l'artefact discret que la plupart des analystes oublient

Un artefact court, spécifique, qui n'existe que sur Windows 7 et Server 2008 R2, mais quand vous l'avez, c'est l'une des preuves les plus propres d'exécution récente en DFIR.

Publié le 7 min de lecture

RecentFileCache.bcf est l'artefact qu'on oublie jusqu'à ce que l'hôte qu'on regarde soit assez vieux pour en avoir un. Sa portée est petite. Sa durée de vie est courte. Et quand il est présent, il répond à la question "cet exécutable a-t-il tourné récemment ?" avec moins d'ambiguïté que presque tout le reste sur le système.

C'est le billet que je passerais à quelqu'un qui vient d'apprendre que l'hôte devant lui est Windows 7 et qu'il a un dossier Amcache plein de RecentFileCache.bcf et rien d'autre.

Ce que c'est, et ce que ce n'est pas

C:\Windows\AppCompat\Programs\RecentFileCache.bcf est un petit fichier binaire écrit par le service Application Experience sur Windows 7 SP1 et Windows Server 2008 R2. Il enregistre les exécutables qui ont tourné depuis la dernière passe d'évaluation d'Application Experience et n'ont pas encore été pliés dans les plus grands jeux de données de compatibilité. Pensez-y comme à un write-ahead log pour l'appraiser de compatibilité de programmes : éphémère, à portée étroite, mais spécifique.

Ce n'est pas l'AmCache. L'AmCache a remplacé RecentFileCache.bcf à partir de Windows 8 et tourne sur un cycle de vie différent. Sur un hôte Win7 vous verrez le fichier BCF. Sur un hôte Win10/11 vous verrez Amcache.hve à la place et (presque toujours) pas de fichier BCF du tout. Il n'y a pas de version de Windows où les deux sont l'artefact primaire en même temps.

Ce n'est pas non plus le Shimcache. Shimcache vit dans le hive SYSTEM et enregistre les fichiers que Windows a examinés (pas nécessairement exécutés). RecentFileCache ne contient que des binaires qui ont été exécutés depuis la dernière évaluation, une affirmation plus stricte.

Le seul fait utile à son sujet

Chaque entrée dans RecentFileCache.bcf prouve que l'exécutable a été démarré depuis la dernière passe d'évaluation. C'est tout. Pas de liste de chargement, pas d'horodatages par entrée, pas de hash. Juste une liste de chemins complets.

Ça a l'air peu spectaculaire jusqu'à ce qu'on réalise à quel point "a été démarré" est réellement fort comme affirmation forensique. Shimcache ne peut pas dire ça. L'AmCache ne peut pas dire ça sans corrélation. RecentFileCache le dit directement.

Le piège, et il y en a deux, est que vous ne savez pas quand chaque binaire a tourné, seulement qu'il a tourné depuis la dernière évaluation, et vous ne savez pas combien de fois. Pour ces deux choses, vous devez apparier le BCF avec Prefetch et le journal d'événements Security.

Le corollaire : un binaire qui apparaît dans RecentFileCache.bcf mais n'a pas d'entrée Prefetch a tourné récemment et soit vit sur un lecteur avec Prefetch désactivé, soit a tourné avec évasion Prefetch. Les deux cas méritent un regard plus rapproché.

Cycle de vie : court et implacable

C'est la partie qui surprend les gens. RecentFileCache est un fichier de travail. La tâche d'évaluation d'Application Experience (Microsoft\Windows\Application Experience\ProgramDataUpdater) tourne environ quotidiennement, traite le fichier, et le vide. Après traitement, le BCF est vide ou absent jusqu'à ce que quelque chose de nouveau tourne.

En pratique :

  • Un binaire qui a tourné dans les dernières ~24 heures est probablement dedans.
  • Un binaire qui a tourné il y a quatre jours est presque certainement parti.
  • Si la tâche d'appraiser est désactivée, le fichier s'accumule indéfiniment. J'ai vu des hôtes où il était périmé depuis 18 mois parce que quelqu'un avait désactivé la tâche avec un script "remover de télémétrie".
  • Le fichier est tronqué, pas supprimé, quand l'appraiser le vide. Les métadonnées du système de fichiers (heure de création) précèdent généralement les entrées.

Si vous êtes sur un hôte vivant que vous soupçonnez, attrapez le BCF immédiatement. D'ici demain il peut être vide. C'est un des rares artefacts où dix minutes de retard peuvent vous coûter la preuve.

Format de fichier, en bref

Le format est direct et n'a pas changé depuis Windows 7 SP1. En-tête, puis une séquence de chaînes de chemin UTF-16LE préfixées de leur longueur, paddées. Pas d'horodatages, pas de hashes. L'analyse originale de Willi Ballenthin de Mandiant tient, le fichier ne stocke pas plus que ce qu'il a l'air de stocker.

Cela signifie que le parsing est indulgent. La plupart des outils produiront la même sortie. La question intéressante n'est pas comment le parser, mais quoi faire de la liste une fois qu'on l'a.

Lire la liste des chemins

Une entrée typique ressemble à :

\??\C:\Users\bob\AppData\Local\Temp\setup.exe
\??\C:\Program Files\Internet Explorer\iexplore.exe
\??\C:\Windows\System32\rundll32.exe

Le préfixe \??\ est la notation du gestionnaire d'objets NT pour un chemin DOS ; traitez-le comme C:\ et passez à autre chose. Trois choses que je cherche, dans l'ordre :

  1. Chemins dans des répertoires inscriptibles par l'utilisateur. \Users\*\AppData\Local\Temp\, \Users\Public\, \ProgramData\. C'est là que l'outillage d'attaquant a tendance à atterrir.
  2. Binaires système renommés. Un \Users\bob\AppData\Roaming\svchost.exe est suspect. Idem pour un \Windows\Temp\lsass.exe.
  3. Exécutions sur partage réseau. Tout ce qui commence par \\ ou \Device\HarddiskVolumeShadowCopy*\.

Vous verrez des entrées d'allure légitime provenant d'installateurs et de mises à jour. Les installateurs Microsoft adorent particulièrement %TEMP%. Triez par mtime et contexte parent, pas par chemin seul.

La corroboration, c'est tout

Un hit BCF sur un chemin suspect est un point de départ, pas une conclusion. La chaîne de corroboration standard :

  • Prefetch. Si le binaire a un fichier .pf, vous avez les horodatages d'exécution et une liste de chargement. Le parser Prefetch donne les deux.
  • MFT. La Master File Table vous donne l'heure de création du binaire sur ce volume, même si le fichier a été supprimé depuis.
  • Journal USN. Le journal USN montre quand le fichier a été créé, modifié ou supprimé, avec granularité au niveau de l'opération.
  • EVTX. Security 4688 ou Sysmon 1 vous donne la ligne de commande et le contexte utilisateur, à condition que le logging soit activé. Sur un hôte Win7 sans Sysmon, vous n'avez généralement pas la ligne de commande.
  • Registry. Clés de persistance, AppCompatFlags et MUICache sous NTUSER.DAT et SOFTWARE.

Si vous pouvez toucher au moins deux des ci-dessus pour un chemin donné, l'affirmation est rapportable.

Le cas "manquant" est intéressant aussi

Quand RecentFileCache.bcf est vide sur un hôte Win7 et que la tâche d'évaluation a clairement tourné, c'est un état normal, l'évaluation a nettoyé. Mais deux schémas valent la peine d'être vérifiés :

  • La tâche d'appraiser est désactivée ou n'a pas tourné depuis des jours. Vérifiez Microsoft-Windows-TaskScheduler%4Operational.evtx pour la dernière exécution réussie.
  • Le fichier a été supprimé par autre chose que l'appraiser. Vérifiez le journal USN pour les enregistrements FileDelete | Close sur RecentFileCache.bcf lui-même.

Le cas de suppression est plus rare que ce qu'on suppose. La plupart des attaquants ne ciblent pas spécifiquement ce fichier parce qu'ils n'en ont pas entendu parler. Cette obscurité fait partie de pourquoi il reste utile.

Là où il cesse d'être utile

Quelques limitations honnêtes :

  • Pas d'horodatages par entrée. Vous ne pouvez pas construire une timeline depuis le BCF seul.
  • Pas de hashes. Vous ne pouvez pas pivoter vers du threat intel depuis le contenu du fichier.
  • Pas d'attribution utilisateur. Comme l'AmCache, le BCF est par machine. La question "qui a exécuté ceci" a besoin de preuves séparées.
  • Pas de couverture sur Windows moderne. Si votre incident est sur Windows 8 ou plus récent, le BCF n'est pas là. Utilisez l'AmCache à la place.
  • Limité aux exécutables. Les scripts exécutés via cscript.exe ou powershell.exe montrent l'interpréteur, pas le script.

Un workflow court

Quand RecentFileCache.bcf est présent et compte :

  1. Acquérir le fichier immédiatement, avant la prochaine passe d'évaluation.
  2. Parser vers une liste plate de chemins.
  3. Filtrer pour les emplacements inscriptibles par l'utilisateur et les schémas de chemin connus d'attaquants.
  4. Pour chaque ligne intéressante, tirer l'entrée Prefetch correspondante (le cas échéant) et l'entrée MFT pour l'exécutable.
  5. Pivoter vers EVTX pour le contexte utilisateur et ligne de commande, si le logging le permet.

C'est tout le travail. Le BCF est un artefact étroit. Traitez-le comme une vérification rapide, pas comme une source de timeline complète.

Lire le fichier dans le navigateur

Le parser sur ce site lit RecentFileCache.bcf entièrement côté client. Déposez le fichier, obtenez la liste triée des chemins avec le préfixe NT normalisé. Pas d'upload. Utile quand vous faites de l'IR pour un client régulé dont les endpoints Win7 n'ont pas encore été remplacés ; ils existent, et ils sont étonnamment courants.

Pour aller plus loin

Si vous trouvez ce fichier sur un hôte construit en 2024, quelqu'un a fait un choix étrange. Enquêtez.

Articles liés

Le cycle de vie du BCF tient en une seule tâche planifiée. Comprenez quand ProgramDataUpdater s'exécute, quand il vide le fichier, et comment repérer un appraiser désactivé.
Pas d'horodatages, pas de hashes, pas d'attribution utilisateur, pas de tracking de script. Le RecentFileCache.bcf est plus étroit que sa réputation. Voici ce vers quoi se tourner.
Le BCF et l'AmCache résolvent des problèmes qui se chevauchent sur des versions différentes de Windows. Savoir lequel vous avez, et pourquoi, décide de ce que vous pouvez affirmer.