Enquêter sur un hôte Win7 avec le BCF : un court walkthrough

C'est un walkthrough composite tiré d'une poignée de cas similaires. L'hôte est fictif. Les artefacts et le workflow ne le sont pas. L'objectif est de montrer combien le RecentFileCache.bcf a réellement contribué à une investigation de forme réelle, et d'être honnête sur ce qu'il n'a pas apporté.

L'hôte

WS-FIN-014. Une station de travail Windows 7 SP1 dans le département finance d'un client manufacturier. Jointe au domaine. Dernier patch il y a quatorze mois. Propriété d'un contrôleur qui travaille depuis le bureau quatre jours par semaine. Le SOC l'a signalé sur une alerte HTTP POST to a low-reputation domain du NDR de périmètre. La destination s'est résolue à un hébergeur dans une juridiction avec laquelle le client ne fait pas affaires.

Périmètre du triage : confirmer ou écarter une compromission. Budget temps : une demi-journée.

Ce qu'on a tiré

Dans l'ordre d'acquisition, parce que l'ordre compte quand le cycle d'appraiser peut vider le BCF :

C:\Windows\AppCompat\Programs\RecentFileCache.bcf.
Le répertoire Prefetch.
Les hives du registre en direct via reg save : SOFTWARE, SYSTEM, SECURITY, NTUSER.DAT pour l'utilisateur connecté.
Microsoft-Windows-TaskScheduler%4Operational.evtx et les logs standard System/Security.
Un snapshot du journal USN du volume de boot.
La MFT.
Un dump ciblé de C:\Users\<controller>\AppData\ pour les LNK, jump list, et données recently-used.

Pas de dump RAM. L'endpoint avait été redémarré avant que nous obtenions l'accès réseau, ce qui est une histoire en soi.

Le contenu du BCF

Après parsing, le BCF contenait 14 chemins. La liste complète :

\??\C:\Windows\System32\rundll32.exe
\??\C:\Windows\System32\msiexec.exe
\??\C:\Windows\System32\wermgr.exe
\??\C:\Windows\System32\WerFault.exe
\??\C:\Windows\System32\dllhost.exe
\??\C:\Program Files\Microsoft Office\Office14\OUTLOOK.EXE
\??\C:\Program Files\Microsoft Office\Office14\EXCEL.EXE
\??\C:\Program Files\Microsoft Office\Office14\WINWORD.EXE
\??\C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe
\??\C:\Program Files\Internet Explorer\iexplore.exe
\??\C:\Users\jharper\AppData\Local\Temp\sb_v2.exe
\??\C:\Users\jharper\AppData\Roaming\printerhelper\phc.exe
\??\C:\Windows\Temp\update_check.exe
\??\C:\Windows\System32\cscript.exe

Les dix premiers étaient sans surprise : composants standard d'Office et de l'OS qu'un utilisateur finance touche quotidiennement. Les intéressants étaient les quatre derniers :

sb_v2.exe dans AppData\Local\Temp.
phc.exe dans AppData\Roaming\printerhelper\.
update_check.exe dans C:\Windows\Temp\.
cscript.exe, qui en soi va, mais sans histoire de macro Office à laquelle l'attacher.

Trois des quatre étaient dans des répertoires inscriptibles par l'utilisateur. Ça seul n'est pas accablant. Du logiciel légitime atterrit dans ces chemins tout le temps. Mais la combinaison de noms et d'emplacements suffisait à escalader chacun.

Corroboration round un : Prefetch

J'ai passé chacun des quatre par Prefetch d'abord.

sb_v2.exe : un fichier .pf, horodatage de dernière exécution il y a trois jours à 14:22 UTC. Compteur d'exécutions à un. Liste chargée incluant WININET.DLL, URLMON.DLL et BCRYPT.DLL. Pas de surprise pour quelque chose qui contacte le réseau.

phc.exe : un .pf, horodatage de dernière exécution il y a trois jours à 14:24 UTC. Compteur d'exécutions à sept. Le compteur élevé était intéressant ; il avait été exécuté plusieurs fois durant la semaine précédente. Liste chargée incluant WINHTTP.DLL et CRYPT32.DLL.

update_check.exe : un .pf, horodatage de dernière exécution il y a trois jours à 14:23 UTC. Compteur d'exécutions à un.

cscript.exe : un .pf, horodatage de dernière exécution il y a trois jours à 14:22 UTC. Compteur d'exécutions à 12 sur le mois précédent.

Donc tous les quatre ont tourné dans une fenêtre de deux minutes il y a trois jours, et cscript.exe et phc.exe tournaient depuis plus longtemps. C'était la première vraie forme : un cluster d'exécutions il y a trois jours, par-dessus une chose plus ancienne qui ressemblait à une présence établie.

Le BCF m'a dit que ces binaires avaient tourné. Prefetch m'a dit quand et combien de fois. Déjà, le BCF avait fait son travail (prouver l'exécution) et était éclipsé par Prefetch pour le travail de timeline.

Corroboration round deux : MFT et USN

Entrées MFT pour chaque binaire :

sb_v2.exe : créé il y a trois jours à 14:21 UTC. Une minute avant sa seule exécution.
phc.exe : créé il y a vingt-trois jours à 09:11 UTC. Plusieurs modifications depuis.
update_check.exe : créé il y a trois jours à 14:21 UTC.

Le journal USN a ajouté du détail. sb_v2.exe avait une séquence FileCreate | DataExtend | Close depuis iexplore.exe comme contexte de processus originant (USN ne vous donne pas un PID directement, mais les horodatages s'alignaient avec une exécution de iexplore.exe dans le BCF et le Prefetch). L'utilisateur avait visité un site, le navigateur avait écrit le fichier, et le fichier s'était exécuté dans les soixante secondes.

update_check.exe avait un schéma de création similaire, originant autour du même moment, avec iexplore.exe encore dans le contexte implicite.

phc.exe était différent. L'USN montrait un FileCreate il y a vingt-trois jours, originant de msiexec.exe. Cela faisait penser qu'un installateur l'avait déposé. La MFT confirmait que le répertoire parent printerhelper avait été créé au même instant.

La forme après MFT et USN : deux binaires déposés par une session navigateur il y a trois jours, plus un binaire installé il y a trois semaines par ce qui ressemblait à un MSI.

Corroboration round trois : registre et persistance

Le contexte parent du répertoire printerhelper m'a pointé vers le registre. Sous HKCU\Software\Microsoft\Windows\CurrentVersion\Run se trouvait une entrée nommée PrinterHelperCore avec la valeur "C:\Users\jharper\AppData\Roaming\printerhelper\phc.exe" /q. L'horodatage de dernière écriture sur la clé correspondait à la date d'installation du MSI.

Persistance. La chose que le BCF ne pourrait jamais me dire seul.

La clé Run expliquait aussi le compteur élevé dans Prefetch : chaque ouverture de session exécutait phc.exe. Sept exécutions en trois semaines correspondaient au schéma de logon de l'utilisateur.

Pas de persistance pour sb_v2.exe ou update_check.exe. Les deux ressemblaient à des payloads one-shot.

Corroboration round quatre : EVTX

Le log Security était maigre. La politique d'audit était aux défauts Win7 ; pas de 4688s pour les lignes de commande. Le log opérationnel du TaskScheduler était propre pour ProgramDataUpdater, avec des paires 200/201 régulières environ toutes les 26 heures. L'appraiser avait tourné selon le planning. Cela importait parce que cela expliquait pourquoi le BCF n'avait que 14 entrées : tout ce qui datait d'avant la dernière passe d'évaluation (environ 18 heures avant l'acquisition) avait été traité.

Le log System avait un événement d'installation de service il y a deux semaines qui ne correspondait pas à la persistance que j'avais déjà, mais en suivi c'était une mise à jour de pilote d'imprimante. Coïncidence.

L'entrée EVTX la plus utile venait de Microsoft-Windows-Windows Defender/Operational. Defender avait mis en quarantaine un fichier il y a trois jours à 14:23 UTC, deux secondes après que update_check.exe ait tourné. Le nom de quarantaine correspondait à une signature générique de downloader. Cela m'a donné mon premier hit de famille de malware et confirmé que le cluster d'il y a trois jours était réel.

Ce que l'utilisateur a fait

Les fichiers LNK et l'historique du navigateur ont rempli l'élément humain. L'utilisateur avait reçu un email il y a trois jours à 14:18, ouvert un lien trois minutes plus tard, et atteint une fausse page de mise à jour logicielle. L'historique du navigateur montrait la chaîne de navigation. Le log du gestionnaire de téléchargement d'Internet Explorer avait les dépôts de fichiers.

L'installation MSI d'il y a trois semaines était plus difficile à attribuer. L'utilisateur ne se souvenait pas d'avoir installé un logiciel d'imprimante. Le MSI lui-même n'était plus sur le disque, mais le journal USN avait son existence éphémère dans Downloads. L'historique du navigateur il y a trois semaines montrait une navigation vers un faux domaine de mise à jour de pilote. Même schéma que l'activité récente, infrastructure d'allure différente de campagne.

Ce que le BCF a réellement contribué

Honnêtement : il m'a pointé rapidement vers les quatre binaires intéressants. C'est à ça qu'il sert.

Il ne m'a pas donné :

Les horodatages. Prefetch l'a fait.
La persistance. Le registre l'a fait.
La chaîne de dépôt. USN et l'historique du navigateur l'ont fait.
L'attribution utilisateur. LNK, l'historique du navigateur et MUICache l'ont fait.
Le hit de famille de malware. Le log de Defender l'a fait.
Le lien de campagne. Les logs réseau et l'historique du navigateur l'ont fait.

Le BCF m'a donné une shortlist de 14 lignes à trier. Sans lui j'aurais commencé par Prefetch et serais arrivé aux quatre mêmes binaires, juste plus lentement. Avec lui, la première passe a pris environ dix minutes. Toute la chaîne de corroboration a pris la majeure partie de la journée.

Si l'hôte avait été Win10, j'aurais utilisé l'AmCache pour le même usage. La forme de l'investigation aurait été la même ; l'artefact d'entrée aurait été différent.

Ce qui est entré dans le rapport

Le rapport affirmait :

L'hôte a été compromis il y a au moins trois semaines via un faux installateur de pilote d'imprimante.
La compromission a établi la persistance via une clé HKCU Run.
Il y a trois jours, le même utilisateur est tombé sur un leurre de fausse mise à jour similaire, qui a déposé deux binaires supplémentaires. Un a été mis en quarantaine par Defender. L'autre (sb_v2.exe) s'est exécuté et a établi un contact réseau.
Le contact réseau était l'alerte que le SOC a signalée.
Le binaire de persistance (phc.exe) tournait encore sur l'hôte jusqu'à l'isolation.

Le BCF a soutenu le point trois (le cluster des exécutions récentes) directement. Il a soutenu le point un indirectement (son inclusion de phc.exe était le pont vers la trouvaille de persistance). Les autres points sont venus d'artefacts corroborants.

Ce que j'aurais manqué sans le BCF

Probablement rien. Prefetch couvrait le même terrain pour ces binaires particuliers. Le rôle du BCF ici était un filtre de triage rapide, pas une source unique de preuves.

C'est la réponse honnête sur la plupart des cas BCF. C'est un artefact propre, rapide, étroit. Il vous dit rarement quelque chose que rien d'autre ne peut. Sa valeur est la vitesse à laquelle il vous pointe vers les bons fichiers.

Pour aller plus loin

SANS, poster Windows Forensic Analysis. La disposition de la chaîne d'artefacts est datée pour Win10 mais les cases Win7 s'appliquent encore.
David Cowen, études de cas Forensic Lunch. Beaucoup de formes IR réalistes sur d'anciennes builds Windows.

Si vous avez un endpoint Win7 signalé demain, attrapez le BCF en premier. Inquiétez-vous du reste en second.