Triage des entrées suspectes RecentFileCache

Une fois que vous avez parsé un RecentFileCache.bcf, vous avez une liste de chemins et rien d’autre. Pas d’horodatages, pas de hachages, pas de signataires. La question de triage est : lesquels de ces chemins méritent un second regard ? Ce post parcourt les heuristiques qui ont fait leurs preuves sur des cas réels.

Les quatre voisinages de chemin à fort signal

La plupart des attaquants opportunistes et ciblés laissent des exécutables dans un petit ensemble de répertoires inscriptibles. Filtrez votre .bcf sur ceux-ci d’abord :

Motif (insensible à la casse)	Pourquoi c’est intéressant
`\AppData\Local\Temp\`	Destination par défaut des dézip / téléchargements Office — aussi un site de dépôt favori des loaders et second-stages
`\Windows\Temp\`	Inscriptible en SYSTEM ; courant pour le malware ayant escaladé
`\Users\Public\`	Inscriptible par tous, souvent utilisé pour partager des outils de staging entre comptes
`\ProgramData\`	Sous-arborescence inscriptible par tous que certains installateurs (et malware) abusent
`\PerfLogs\`	Vide par défaut, étrangement souvent utilisé par les red teams
`\$Recycle.Bin\`	Presque jamais légitime d’exécuter quelque chose depuis ici
`\Recovery\`, `\System Volume Information\`	Doivent être réservés au système ; des entrées ici méritent investigation

Dans la vue tableau du parser, trier par Drive puis Path fait apparaître visuellement les voisinages suspects.

Bizarreries de basename

Le nom de fichier (dernier segment) de chaque chemin porte son propre signal :

Noms à une ou deux lettres — a.exe, b.exe, xx.exe. Presque toujours du malware, des artefacts de build, ou le helloworld.exe d’un développeur. Pivoter vers le répertoire d’origine.
Chaînes à l’apparence aléatoire — j2k9f.exe, cfa31b.exe. Une forte entropie dans le basename indique fréquemment une sortie de dropper ou des stages dépaqués.
Doubles extensions — invoice.pdf.exe, image.jpg.scr. Motif classique de payload de phishing. Vaut une investigation à lui seul.
Noms ressemblant à des GUID — {f3b3c8d4-...}.exe. Soit une copie par-session d’un installateur légitime, soit du malware qui l’imite.
Nom légitime au mauvais endroit — svchost.exe sous C:\Users\Public\ (vs C:\Windows\System32\) est un déplacement classique de binaire signé.
Espaces de fin / astuces unicode — notepad .exe, noms avec caractères right-to-left override (U+202E). Le parser les préserve tels quels ; une vue hex du chemin ou un simple length(path) les expose.

Analyse de la lettre de lecteur

Le parser expose une colonne drive. La plupart des entrées en cache sont C:. Tout le reste mérite attention :

D:, E:, F: et au-delà — clés USB, partages montés, ISO montés. Vecteurs courants de staging de malware. Croiser avec les shellbags / clés de registre USBSTOR pour identifier le périphérique.
Chemins UNC (\\server\share\...) — exécution depuis des partages réseau. À corréler avec les logs de session SMB.
Pas de lecteur du tout — les chemins qui commencent par un seul nom (pas de C:, pas de \\) sont inhabituels pour .bcf et signifient généralement qu’un chemin relatif a été enregistré — ce qui est intéressant en soi car le service normalise presque toujours en absolu.

Pivot nom de fichier → processus

L’apparition d’un basename donné dans .bcf n’est pas une preuve qu’il a tourné — seulement qu’AppCompat l’a vu. Une fois que vous avez une courte liste de candidats, pivotez :

Prefetch (C:\Windows\Prefetch\<NOM>-<HACH>.pf). Si un .pf correspondant existe, vous avez un événement d’exécution avec horodatages et un compteur de lancements.
Amcache.hve — même époque que .bcf mais avec hachage, éditeur, date d’installation. Le frère amcache-parser fait ça côté client.
Le fichier sur disque. Si le chemin résout encore, hachez-le et pivotez vers VirusTotal / votre store d’IOC interne. Si le chemin ne résout pas, le binaire a été supprimé — et cette suppression est elle-même un événement à chercher dans le MFT / $LogFile.

Ce qui n’y est pas

Tout aussi important : ce que vous ne devez pas espérer dans .bcf.

Scripts. .ps1, .vbs, .js, .bat, .hta ne sont pas suivis par le scanner Application Experience. Un .bcf propre ne signifie pas une machine propre.
DLLs chargées par des hôtes signés. RecentFileCache s’intéresse aux images de type EXE qui croisent le chemin de code AppCompat du loader. Les DLLs chargées par rundll32.exe, regsvr32.exe ou mshta.exe n’apparaîtront normalement pas.
Tout ce qui contourne le loader. Injection réflective, process hollowing, PE en mémoire — invisibles par construction pour RecentFileCache.

Un filtre pragmatique

Une première passe pragmatique, exprimée en jq sur la sortie JSON du parser :

jq '.entries[] | select(
  (.path | ascii_downcase | test(
    "\\\\(appdata\\\\local\\\\temp|windows\\\\temp|users\\\\public|programdata|perflogs|\\$recycle\\.bin)\\\\"
  )) or
  ((.filename // "") | test("^[a-z0-9]{1,3}\\.exe$"; "i")) or
  ((.filename // "") | test("\\.(pdf|doc|docx|xls|xlsx|jpg|png)\\.exe$"; "i"))
) | "\(.drive // "?")\t\(.filename // "?")\t\(.path)"' rfc.json

Vous obtiendrez une liste triage tab-separated prête à coller dans un notebook ou à alimenter une boucle hash-and-VT. Le post suivant couvre quoi faire avec les candidats.

Triage : repérer les entrées suspectes dans RecentFileCache