Skip to content

Application Experience et ProgramDataUpdater : comment .bcf est rempli

Parcours du service Windows 7 et de la tâche planifiée qui écrivent RecentFileCache.bcf, et ce que ce cycle de vie implique pour les fenêtres de triage.

Publié le 4 min de lecture

RecentFileCache.bcf n'apparaît pas par magie. Un service précis l'écrit à l'exécution et une tâche planifiée précise le vide à cadence. Connaître les deux est ce qui vous permet de raisonner sur la profondeur du retour en arrière de l'artefact, sa fréquence de modification, et la localisation de ses angles morts.

Le service Application Experience

Sous Windows 7, le service est enregistré comme AeLookupSvc (« Application Experience »). C'est la moitié runtime de l'infrastructure Application Compatibility, qui existe pour détecter des binaires connus comme problématiques sur les Windows plus récents et appliquer silencieusement des shims de compatibilité pour que les logiciels hérités continuent à fonctionner.

À un lancement typique d'exécutable, deux choses se produisent :

  1. Le chargeur d'image consulte sysmain.sdb pour des shims correspondant au binaire.
  2. Le service Application Experience consigne que le binaire a été vu, afin que la tâche de maintenance hors ligne puisse l'évaluer ultérieurement pour l'éligibilité à un shim.

RecentFileCache.bcf est le tampon de staging pour l'étape 2. Ce n'est pas un journal à long terme. Il existe pour alimenter la prochaine passe de maintenance, point final.

ProgramDataUpdater

La tâche planifiée qui consomme le tampon est :

\Microsoft\Windows\Application Experience\ProgramDataUpdater

Elle fait trois choses dans l'ordre :

  1. Lit C:\Windows\AppCompat\Programs\RecentFileCache.bcf.
  2. Parcourt chaque chemin, empreinte l'exécutable et met à jour l'ensemble d'enregistrements d'Amcache.hve.
  3. Réécrit RecentFileCache.bcf. Parfois plus court, parfois vide, parfois remplacé en totalité.

La tâche est enregistrée pour s'exécuter en idle système ou au logon, gouvernée par le cadre Automatic Maintenance. Sur un poste sain on la voit se déclencher à peu près quotidiennement. Sur une borne qui ne tourne qu'en heures ouvrées, la fenêtre entre écritures peut s'étendre sur plusieurs jours.

Ce que cela signifie pour le triage

La fraîcheur de l'artefact est fonction du dernier passage de ProgramDataUpdater, non d'un lancement particulier. Conséquences pratiques :

  • Le LastWriteTime du fichier est une borne supérieure du moment où ProgramDataUpdater s'est dernièrement terminé. Utile, mais pas par entrée. Ne le placez pas sur une chronologie d'exécution comme si c'en était une.
  • Si un système a été compromis, brièvement utilisé puis éteint avant la prochaine passe de ProgramDataUpdater, le binaire malveillant vit dans RecentFileCache.bcf et n'a pas encore été promu vers Amcache.hve. Cela fait du BCF le seul artefact à porter la piste.
  • Après une passe réussie, une entrée peut disparaître du BCF tout en persistant dans Amcache.hve. Lisez toujours les deux ensemble. Un chemin absent du BCF mais présent dans Amcache avec un LastWritten récent sur la clé est l'état normal post-promotion.

Ce qui ne tombe pas dans .bcf

La pipeline Application Experience n'attrape que les binaires qui passent par le chargeur d'image normal avec les hooks AppCompat actifs. Les éléments suivants la contournent en routine :

  • Injection DLL réflective et chargeurs PE en mémoire.
  • Pilotes et payloads kernel-mode (autre chemin de code).
  • Chaînes LOLBin où le lanceur est un binaire signé et la véritable charge utile est un script ou un scriptlet COM (mshta.exe, regsvr32.exe /i).
  • Outillage anti-forensique qui désactive purement et simplement AeLookupSvc.

Si vous avez des raisons de croire à l'utilisation d'un de ces moyens, l'absence dans RecentFileCache n'est pas un signal « ça n'a pas tourné ». C'est du silence, pas de la preuve.

L'empreinte d'un attaquant s'il supprime

Vaut le coup de connaître la piste d'audit pour les gestes évidents. Arrêter ou désactiver AeLookupSvc allume des événements 7036 et 7040 du Service Control Manager dans le log System. Désactiver ou supprimer la tâche ProgramDataUpdater allume 141/142 dans Microsoft-Windows-TaskScheduler%4Operational.evtx. Les deux sont détaillés dans Détecter la manipulation de RecentFileCache.

Un BCF qui n'a pas été touché depuis des mois sur une machine d'usage quotidien devrait lever un sourcil même si vous ne trouvez pas d'événements de contrôle de service ni de tâches. Parfois l'attaquant a désactivé la tâche en éditant le XML du Task Scheduler sur disque, et les événements se déclenchent sur le mauvais compte ou se perdent. Recoupez avec les logs System et Application dans EVTX et avec l'état du registre pour le service.

Cadence en chiffres

Valeurs approximatives observées sur des hôtes sains, utiles comme baseline :

  • Station, utilisateur quotidien : ProgramDataUpdater se déclenche toutes les 18 à 30 heures.
  • Serveur (faible idle) : toutes les 2 à 5 jours.
  • Borne allumée uniquement en heures ouvrées : quand Automatic Maintenance peut le caser, souvent tous les 3 à 7 jours.
  • Hôte sans jamais atteindre l'idle (charge lourde) : peut passer une semaine ou plus entre passages.

Un BCF périmé d'un mois sur un hôte que vous savez actif quotidiennement est significatif. Un BCF périmé d'une semaine sur un serveur est normal.

Pour aller plus loin

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é.
Le format BCF est un en-tête, une liste de chemins UTF-16LE préfixés de leur longueur, et c'est tout. Voici ce que signifie chaque octet et pourquoi rien n'a changé depuis 2009.
Un endpoint Win7 signalé par le SOC, 14 chemins dans le BCF, trois méritant un second regard. Une chaîne de corroboration réaliste et combien le BCF a réellement contribué.