Valider les findings RecentFileCache

Un chemin à l’apparence suspecte dans RecentFileCache.bcf est une piste, pas un verdict. L’artefact vous dit qu’AppCompat a vu un fichier — rien de plus. Ce post est la checklist que vous exécutez avant d’écrire « l’attaquant a exécuté C:\Users\Public\update.exe » dans votre rapport.

La chaîne de validation

Un finding « exécuté » à forte confiance pour un seul chemin est généralement une chaîne de trois ou quatre artefacts qui s’accordent :

RecentFileCache (chemin vu)
       ↓
Prefetch (timestamp d’exécution + compteur)        ← meilleur corroborateur unique
       ↓
Amcache.hve (SHA-1, éditeur, état d’installation)  ← métadonnées plus riches de la même époque
       ↓
MFT / $LogFile (création, suppression, MFT record) ← quand/comment le fichier a bougé
       ↓
Binaire sur disque → hash → VT / threat intel      ← identité

Arrêtez-vous à n’importe quel barreau s’il contredit ceux du dessus. Un chemin dans .bcf sans Prefetch et sans entrée Amcache signifie l’un des suivants : (a) le fichier a été vu mais jamais exécuté, (b) le fichier a tourné mais Prefetch est désactivé / l’entrée a été évincée, (c) ProgramDataUpdater n’a jamais tourné avant l’extinction. Les trois sont courants.

Spécificités par pivot

Prefetch

Le fichier pertinent est C:\Windows\Prefetch\<NOM_MAJUSCULE>-<HACH_8_HEX>.pf. Deux chemins produisant le même basename donnent des fichiers prefetch distincts car le hachage incorpore le chemin de l’exécutable. Utilisez le frère prefetch-parser côté client, ou PECmd.exe sur Windows.

Lecture de confiance :

Prefetch existe, compteur de lancements ≥ 1, dernier run dans les heures de la fenêtre d’incident → confirmation forte d’exécution.
Prefetch existe, compteur de lancements = 1, dernier run = date de création du fichier → exécuté une fois peu après dépôt, cohérent avec « a lancé le dropper ».
Pas de Prefetch malgré plusieurs artefacts corroborants → vérifier si Prefetch était désactivé (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher) — étape anti-forensique connue.

Amcache.hve

Même répertoire que .bcf. Parser avec amcache-parser. Champs clés à lire :

SHA-1 — pivoter vers VT ou votre store interne. Un hash ici signifie qu’AppCompat a haché le fichier au moment de la promotion.
Publisher + PublisherName — vide signifie que le binaire n’était pas signé. La majorité du malware atterrit ici.
LastWritten de la clé — quand la clé de registre a été modifiée pour la dernière fois. Le timestamp le plus proche d’exécution que le registre vous donne.
AppPath — le chemin enregistré par Amcache. Comparer au chemin dans .bcf ; les mismatches surviennent quand le fichier a été déplacé.

MFT et $LogFile

Utilisez MFTECmd.exe ou mft-parser pour faire ressortir le MFT record du binaire. Vous voulez :

$STANDARD_INFORMATION Created, Modified, Accessed, MFT-changed — l’image complète des timestamps, y compris des signes de timestomping (e.g. $SI Modified ≠ $FILE_NAME Modified).
Entrées $LogFile qui enregistrent la création, le renommage ou la suppression du fichier — utile quand le fichier n’est plus sur disque.

Hash sur disque → threat intel

Si le chemin résout encore, certutil -hashfile <path> SHA256 (Win7+) ou Get-FileHash (PowerShell) vous donne un SHA-256 en secondes. Pivotez vers VirusTotal, MalwareBazaar, la base IOC de votre EDR, MISP interne, etc.

Faux positifs qui piègent

Tous les chemins bizarres ne sont pas malveillants. Les motifs ci-dessous brûlent des analystes chaque trimestre :

Dépaquetages MSI par session. De nombreux installateurs extraient vers C:\Users\<user>\AppData\Local\Temp\{GUID}\setup.exe et lancent depuis là. A l’apparence textbook-suspecte ; habituellement légitime. Validez via la nature signée de l’installateur parent et l’âge du dossier temp.
Chemins de quarantaine des protections endpoint. Certains produits AV déplacent les fichiers détectés vers C:\ProgramData\<Vendor>\Quarantine\.... Le chemin a l’air alarmant mais le fichier est déjà neutralisé.
Artefacts de build / CI sur postes de dev. Les machines de développeur ont D:\build\bin\Debug\app.exe, C:\Users\dev\source\repos\foo\bin\foo.exe, etc. qui pattern-matchent « lecteur bizarre + basename d’apparence aléatoire » mais sont parfaitement normaux en contexte.
Auto-updaters style Squirrel. Des apps comme Discord, Atom, VS Code déposent des binaires versionnés sous %LOCALAPPDATA%\<App>\app-<version>\<App>.exe et se ré-exécutent. Ressemble à « un binaire unique qui se relocalise sans cesse » — c’est juste de l’auto-update.
Le cache « Click-to-Run » d’Office. C:\Program Files\Common Files\microsoft shared\ClickToRun\... produit beaucoup de variantes de chemin ; apprenez la forme pour arrêter d’y pivoter.
Cache de paquets Windows Update. C:\Windows\SoftwareDistribution\Download\<GUID>\... est normal.

Modèle mental pratique : les chemins temp/AppData avec un installateur parent signé qui les lance une fois puis plus jamais sont du bruit. Les mêmes chemins invoqués à répétition par un binaire non signé ne le sont pas.

La phrase de rapport

Une fois que votre chaîne tient debout, la phrase défendable dans un rapport ressemble à :

« RecentFileCache.bcf, Prefetch et Amcache.hve montrent de manière cohérente que C:\Users\Public\update.exe était présent sur le système ; Prefetch enregistre deux exécutions le 2026-05-23 entre 14:11 et 14:17 UTC ; Amcache enregistre le SHA-1 d2b7…f0c1, qui correspond à un échantillon VirusTotal vu pour la première fois le 2026-05-20 avec des détections de N éditeurs. »

Si l’un de ces trois artefacts manque, dégradez le langage (« un fichier à ce chemin a été observé par le scanner AppCompat ») en conséquence.

Suite

Le post final couvre ce qu’un attaquant ferait pour faire taire toute cette chaîne — et les signaux qui le trahissent quand il essaie.

Valider les findings RecentFileCache : pivots et faux positifs