Limites du BCF : quand il ne vous dit rien, et que prendre à la place

Le RecentFileCache.bcf a une réputation discrète parmi les gens du DFIR qui savent qu'il existe. La réputation est en grande partie méritée. L'artefact est petit, spécifique, propre. Mais il est aussi plus étroit que les gens s'en souviennent entre les affaires. Après quelques mois sans toucher une boîte Win7, on tend à surévaluer ce que le BCF peut répondre.

C'est la liste honnête de ce que le BCF ne vous donne pas, et de ce qu'il faut tirer à côté.

Pas d'horodatages par entrée

Le fichier contient des chemins. C'est tout. Il n'y a pas de champ pour "premier vu", "dernière exécution" ou "nombre d'exécutions". Un binaire apparaît dans le BCF s'il a tourné depuis la dernière passe d'évaluation. C'est un unique bit d'information sur toute la fenêtre de vie de travail du fichier.

Ce qui se rapproche le plus d'un horodatage que le BCF offre est l'heure de dernière modification du fichier lui-même sur disque, qui vous dit quand l'appraiser y a écrit pour la dernière fois. Cet horodatage s'applique au fichier entier. Vous ne pouvez pas l'utiliser pour ordonner les entrées dans le fichier. Vous ne pouvez pas l'utiliser pour dire "ce binaire a tourné mardi".

Si vous avez besoin d'horodatages :

Prefetch. Jusqu'à huit dernières heures d'exécution par exécutable sur Win7 (l'ancien format .pf), avec métadonnées complètes de création et de modification.
Journal USN. Pour quand le binaire est apparu sur disque, a été modifié ou supprimé. Granularité au niveau de l'opération.
Master File Table. Horodatages des attributs Standard Information et File Name. Utile quand le binaire a été supprimé.
Security 4688 ou Sysmon 1. Événements de création de processus avec horodatages complets et lignes de commande, à condition que le logging soit activé. Sur une installation Win7 par défaut, il ne l'était pas.

Le BCF vous dit que quelque chose s'est passé. Les autres artefacts vous disent quand.

Pas de hashes

Il n'y a pas de hash dans le BCF. Ni SHA1, ni MD5, ni le hash tronqué de l'en-tête PE que l'AmCache enregistre. Si vous voulez pivoter vers du threat intel, vous avez besoin du binaire lui-même.

Trois manières d'obtenir le hash :

Tirer le binaire du disque et le hasher. Trivial si le fichier est encore là.
Reconstruire depuis un backup, un pagefile, ou un dump RAM. Moins fiable mais parfois la seule option.
Hasher le binaire référencé par le fichier Prefetch correspondant en lisant le .pf et en remontant. Le Prefetch ne stocke pas non plus le hash du binaire, mais il vous donne le chemin exact et vous pouvez le récupérer depuis le volume.

Si le binaire a été supprimé et qu'il n'y a pas de backup, le BCF vous laisse sans hash. Trou permanent.

Pas d'attribution utilisateur

Le BCF est par machine. Il n'y a pas de champ pour "a tourné en tant que bob" ou "a tourné en tant que SYSTEM". Un binaire qui a tourné en tant que service et un binaire qui a tourné en tant qu'utilisateur interactif sont identiques dans le fichier.

Sources d'attribution, en ordre approximatif de préférence :

Security 4688 avec SubjectUserSid. Le plus propre. Souvent absent sur Win7 sauf si la politique d'audit a été ajustée.
Sysmon 1 avec User. Le mieux, mais Sysmon sur Win7 est une bête rare sur le terrain.
Le NTUSER.DAT de l'utilisateur et MUICache sous les hives utilisateur. MUICache enregistre les exécutables avec lesquels l'utilisateur a interagi via Explorer. Pas autoritatif mais corroborant.
Fichiers LNK dans les dossiers Recent et Office Recent de l'utilisateur. Si un utilisateur a double-cliqué le binaire, un LNK existe probablement.
Jump lists. Pour les exécutables qui sont épinglables ou ont été récemment utilisés.

Pour qu'une entrée BCF devienne "l'utilisateur a exécuté ceci", vous avez besoin d'au moins une de ces sources corroborantes. Le BCF seul ne porte jamais cette affirmation.

Pas de tracking de scripts

C'est la limitation qui prend les gens au dépourvu le plus souvent. Le BCF trace les lancements d'exécutables. Un appel à powershell.exe qui a exécuté dix scripts différents produit une entrée BCF : \??\C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. Pareil pour cscript.exe, wscript.exe, mshta.exe, cmd.exe, regsvr32.exe, rundll32.exe.

Les interpréteurs sont dans le BCF. Les scripts qu'ils ont exécutés ne le sont pas.

Pour la visibilité au niveau script sur Win7 :

Logging style PowerShell 4688 via Microsoft-Windows-PowerShell/Operational (event ID 4103, 4104), mais seulement si Script Block Logging était activé. Presque personne ne l'avait activé par défaut sur Win7.
Log Windows PowerShell classique, Windows PowerShell.evtx. Moins informatif que le log Operational mais à vérifier.
Fichiers LNK pour les scripts explicitement double-cliqués.
Historique du navigateur pour les téléchargements de fichiers de script, apparié avec la corbeille pour ce qui a été supprimé.
Les fichiers de script réels sur disque, où les chemins user/AppData/Temp vivent typiquement.

Un BCF qui montre que cscript.exe a tourné est intéressant. Un BCF qui montre que cscript.exe a tourné et que vous ne trouvez pas le script sur disque est plus intéressant. Pivotez vers le journal USN pour la trace du script supprimé.

Pas de tracking de DLL ou de librairies

Contrairement à Prefetch, le BCF n'enregistre pas les DLL chargées dans un processus. Un binaire qui a chargé une DLL malveillante et un binaire qui a tourné propre sont identiques dans le fichier.

Si vous suspectez du DLL sideloading ou du process hollowing, le BCF vous dit que le processus hôte a tourné. Il ne vous dit pas ce qui a été chargé dedans. Tournez-vous vers :

La liste des fichiers référencés du Prefetch.
Sysmon Event ID 7 (ImageLoaded). Presque jamais présent sur Win7 en pratique.
Analyse mémoire depuis un dump RAM.
Les clés de registre KnownDlls et ImageFileExecutionOptions pour les vecteurs de sideloading.

Pas de contexte réseau ou de persistance

Le BCF n'enregistre pas le réseau. Il ne montre pas les lookups DNS, les connexions sortantes ou les ports en écoute. Il n'enregistre pas les mécanismes de persistance. Un binaire qui a installé un service, déposé une clé Run ou enregistré une tâche planifiée est juste une entrée dans le BCF ; l'activité d'installation n'affleure pas.

Pour ceux-là :

Registry pour les clés Run, Services et ASEPs.
Dossier Tasks du Task Scheduler et le log opérationnel EVTX.
SRUM, qui n'existe que sur Win8+, donc hors périmètre sur un hôte BCF. Mais bon à savoir pour quand l'hôte est autre chose.
Cache DNS en mémoire si vous avez un dump RAM.

Pas de couverture au-delà de la fenêtre d'évaluation

Le BCF contient les binaires qui ont tourné depuis la dernière passe d'évaluation. Cela représente environ les 24 dernières heures sur un hôte sain. Les exécutions plus anciennes sont parties.

L'artefact pour un historique d'exécution plus long sur Win7 est Shimcache, qui vit dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache et contient beaucoup plus d'entrées avec horodatages de dernière modification. Shimcache fait des affirmations plus faibles (le binaire a été examiné, pas nécessairement exécuté) mais couvre une fenêtre plus large. Utilisez-le pour la question "est-ce que cela a déjà tourné sur l'hôte ?" ; utilisez le BCF pour la question "est-ce que cela a tourné récemment ?".

Pas de couverture sur Windows moderne

Si l'hôte est Windows 8 ou plus récent, le BCF est parti. Allez à l'AmCache à la place. L'AmCache a ses propres limites (c'est plus de l'inventaire que de la preuve d'exécution) mais c'est la source primaire correcte sur ces builds.

La forme d'une réponse complète

Un hit BCF n'est jamais toute l'histoire. La forme d'une affirmation complète pour "le binaire X a tourné sur l'hôte Y à l'heure T en tant qu'utilisateur Z et a fait ce qui suit" requiert :

BCF ou Prefetch pour l'exécution elle-même.
Prefetch ou EVTX pour l'horodatage.
EVTX, MUICache ou LNK pour l'utilisateur.
Les referenced-files de Prefetch, Sysmon ImageLoaded ou la mémoire pour ce qu'il a chargé.
Journal USN et MFT pour le cycle de vie du fichier sur disque.
Registre, tâches planifiées et services pour la persistance.
Logs réseau, historique du navigateur ou mémoire pour l'activité sortante.

Le BCF apporte le bit le plus propre de "a-t-il tourné". Tout le reste a besoin d'une autre source. Traitez le fichier comme une vérification rapide, pas comme la pièce maîtresse de l'investigation.

Pour aller plus loin

Harlan Carvey, Windows Forensic Analysis Toolkit. Les chapitres sur les artefacts d'exécution de programme restent pertinents pour les affaires Win7.
Eric Zimmerman, documentation des outils. Pour les artefacts corroborants (Prefetch, Shimcache, AmCache, MFT) que vous apparierez avec le BCF.

Si le BCF est le seul artefact que vous avez, l'affaire va être pauvre en preuves. Si le BCF est l'un des sept artefacts que vous avez, il peut porter un vrai poids. La différence est le reste de la chaîne.