Validating RecentFileCache findings

A suspicious path in RecentFileCache.bcf is a lead, not a verdict. The artifact tells you AppCompat saw a file. Nothing more. This post is the checklist I run before I write "the attacker executed C:\Users\Public\update.exe" in a report.

The validation chain

A high-confidence "executed" finding for a single path is usually three or four artifacts agreeing:

RecentFileCache (path seen)
       v
Prefetch (execution timestamp + count)            <- strongest single corroborator
       v
Amcache.hve (SHA-1, publisher, install state)     <- richer metadata for the same era
       v
MFT / $LogFile (creation, deletion, MFT record)   <- when/how the file moved
       v
On-disk binary -> hash -> VT / threat intel       <- identity

Stop at any rung if it conflicts with the rungs above. A path in the BCF with no Prefetch and no Amcache.hve entry means one of: (a) the file was seen but never executed, (b) the file ran but Prefetch is disabled or rolled out, or (c) ProgramDataUpdater never fired before shutdown. All three are common. None of them is "the attacker is lying to you."

Per-pivot specifics

Prefetch

The relevant file is C:\Windows\Prefetch\<UPPERCASE_NAME>-<8-HEX-HASH>.pf. Two binaries with the same basename produce distinct prefetch files because the hash incorporates the executable's path. Use the Prefetch parser client-side, or PECmd.exe on Windows.

Confidence reading:

Prefetch exists, run count >= 1, last run within hours of incident window is strong execution confirmation.
Prefetch exists, run count = 1, last run equals file creation time is consistent with "ran the dropper once."
No Prefetch despite multiple corroborating artifacts suggests Prefetch was disabled at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher. That registry tweak is a known anti-forensics step and worth flagging on its own.

Amcache.hve

Same directory as the BCF. Parse with the Amcache parser. Fields to read:

SHA-1. Pivot to VirusTotal or your internal store. A hash here means AppCompat hashed the file at promotion time.
Publisher / PublisherName. Empty means unsigned. Most malware lands here.
Key LastWritten. When the registry key was last touched. Closest-to-execution timestamp the registry gives you.
AppPath. The path Amcache recorded. Compare against the BCF path. Mismatches happen when the file moved between the appraiser run and your acquisition.

MFT and $LogFile

Use the MFT parser (or MFTECmd.exe) to surface the binary's MFT record. You want:

$STANDARD_INFORMATION Created, Modified, Accessed, MFT-changed. Full timestamp picture, including signs of timestomping ($SI Modified disagreeing with $FILE_NAME Modified is the classic tell).
$LogFile entries that record the file's creation, rename, or deletion. Useful when the file is no longer on disk.
The USN journal for operation-level granularity on creation and delete events.

On-disk hash to threat intel

If the path still resolves, certutil -hashfile <path> SHA256 (Win7+) or Get-FileHash (PowerShell) gives you a SHA-256 in seconds. Pivot to VirusTotal, MalwareBazaar, your EDR's IOC database, or an internal MISP.

Surrounding context

When the chain above looks shaky, fill it in from elsewhere:

EVTX / Sysmon for process-create events with command line, parent, and user. On a Win7 host without Sysmon you usually have nothing here.
LNK files and jump lists for user-driven launches.
Registry MUICache and UserAssist under NTUSER.DAT for execution under a specific user context.
Recycle bin when the binary was deleted by a user rather than by malware cleanup.

False positives that catch people

Not every weird path is malicious. These patterns burn analysts every quarter.

MSI per-session unpacks. Many installers extract to C:\Users\<user>\AppData\Local\Temp\{GUID}\setup.exe and run from there. Looks textbook-suspicious; usually legitimate. Validate with the parent installer's signed nature and the temp folder's age.
Endpoint protection quarantine paths. Some AV products move detected files to C:\ProgramData\<Vendor>\Quarantine\.... The path looks alarming but the file is already neutralized.
Build and CI artifacts on dev workstations. Developer machines have D:\build\bin\Debug\app.exe and C:\Users\dev\source\repos\foo\bin\foo.exe. Pattern-matches "weird drive + odd basename" but is normal in context.
Squirrel-style auto-updaters. Discord, Atom, VS Code drop versioned binaries under %LOCALAPPDATA%\<App>\app-<version>\<App>.exe and re-execute themselves. Looks like "single binary repeatedly relocating." It is auto-update.
Office Click-to-Run cache. C:\Program Files\Common Files\microsoft shared\ClickToRun\... produces many path variants. Learn the shape so you stop pivoting on them.
Windows Update package cache. C:\Windows\SoftwareDistribution\Download\<GUID>\... is normal.

A useful mental model: temp and AppData paths with a signed parent installer running them once and then never again are noise. The same paths invoked repeatedly by an unsigned binary are not.

The report sentence

When the chain holds together, the defensible sentence in a report reads like this:

"RecentFileCache.bcf, Prefetch, and Amcache.hve consistently show C:\Users\Public\update.exe was present on the system. Prefetch records two executions on 2026-05-23 between 14:11 and 14:17 UTC. Amcache records the SHA-1 d2b7...f0c1, which matches a VirusTotal sample first seen on 2026-05-20 with N vendor detections."

If any of those three artifacts is missing, downgrade the language. "A file at this path was observed by the AppCompat scanner" is honest. "The attacker executed this file" without Prefetch corroboration is not.

Validating RecentFileCache findings: pivots and false positives