RecentFileCache.bcf: the quiet artifact most analysts forget about

RecentFileCache.bcf is the artifact you forget about until the host you are looking at is old enough to have one. Its scope is small. Its lifetime is short. And when it is present, it answers the "did this executable run recently?" question with less ambiguity than almost anything else on the system.

This is the post I would hand to somebody who has just learned that the host in front of them is Windows 7 and they have an Amcache folder full of RecentFileCache.bcf and nothing else.

What it is, and what it isn't

C:\Windows\AppCompat\Programs\RecentFileCache.bcf is a small binary file written by the Application Experience service on Windows 7 SP1 and Windows Server 2008 R2. It records executables that ran since the last Application Experience appraisal pass and have not yet been folded into the larger compatibility datasets. Think of it as a write-ahead log for the program-compatibility appraiser: short-lived, narrowly scoped, but specific.

It is not the AmCache. The AmCache replaced RecentFileCache.bcf starting in Windows 8 and runs on a different lifecycle. On a Win7 host you will see the BCF file. On a Win10/11 host you will see Amcache.hve instead and (almost always) no BCF file at all. There is no version of Windows where both are the primary artifact at the same time.

It is not the Shimcache either. Shimcache lives in the SYSTEM hive and records files Windows examined (not necessarily ran). RecentFileCache only contains binaries that were executed since the last appraisal — a stricter claim.

The single useful fact about it

Every entry in RecentFileCache.bcf proves the executable was started since the last appraisal pass. That is it. No load list, no timestamps per entry, no hash. Just a list of full paths.

That sounds underwhelming until you realize how strong "was started" actually is as a forensic claim. Shimcache cannot say this. The AmCache cannot say this without correlation. RecentFileCache says it directly.

The catch — and there are two of them — is that you do not know when each binary ran, only that it ran since the last appraisal, and you do not know how many times. For both of those, you need to pair the BCF with Prefetch and the Security event log.

The corollary: a binary that appears in RecentFileCache.bcf but has no Prefetch entry ran recently and either lives on a drive with Prefetch disabled, or ran with Prefetch evasion. Either case is worth a closer look.

Lifecycle: short and unforgiving

This is the part that surprises people. RecentFileCache is a working file. The Application Experience appraisal task (Microsoft\Windows\Application Experience\ProgramDataUpdater) runs roughly daily, processes the file, and clears it. After processing, the BCF is empty or absent until something new runs.

In practical terms:

A binary that ran in the last ~24 hours is likely to be in there.
A binary that ran four days ago is almost certainly gone.
If the appraiser task is disabled, the file accumulates indefinitely. I have seen hosts where it was 18 months out of date because somebody disabled the task with a "telemetry remover" script.
The file gets truncated, not deleted, when the appraiser empties it. The file system metadata (created time) usually predates the entries.

If you are on a live host that you suspect, grab the BCF immediately. By tomorrow it may be empty. This is one of the few artifacts where ten minutes of delay can cost you the evidence.

File format, briefly

The format is straightforward and has not changed since Windows 7 SP1. Header, then a sequence of length-prefixed UTF-16LE path strings, padded. No timestamps, no hashes. The original analysis by Mandiant's Willi Ballenthin holds up — the file does not store more than it looks like it does.

That means parsing is forgiving. Most tools will produce the same output. The interesting question is not how to parse it, but what to do with the list once you have it.

Reading the path list

A typical entry looks like:

\??\C:\Users\bob\AppData\Local\Temp\setup.exe
\??\C:\Program Files\Internet Explorer\iexplore.exe
\??\C:\Windows\System32\rundll32.exe

The \??\ prefix is the NT object manager's notation for a DOS path; treat it as C:\ and move on. Three things I look for, in order:

Paths in user-writable directories. \Users\*\AppData\Local\Temp\, \Users\Public\, \ProgramData\. These are where adversary tooling tends to land.
Renamed system binaries. A \Users\bob\AppData\Roaming\svchost.exe is suspicious. So is a \Windows\Temp\lsass.exe.
Network-share executions. Anything starting with \\ or \Device\HarddiskVolumeShadowCopy*\.

You will see legitimate-looking entries from installers and updaters. Microsoft installers in particular love %TEMP%. Triage by mtime and parent context, not by path alone.

Corroboration is everything

A BCF hit on a suspicious path is a starting point, not a conclusion. The standard corroboration chain:

Prefetch. If the binary has a .pf file, you have execution timestamps and a load list. The Prefetch parser gives both.
MFT. The Master File Table gives you the binary's creation time on this volume, even if the file has since been deleted.
USN journal. The USN journal shows when the file was created, modified, or deleted, with operation-level granularity.
EVTX. Security 4688 or Sysmon 1 gives you the command line and the user context, assuming the logging was on. On a Win7 host without Sysmon, you usually do not have the command line.
Registry. Persistence keys, AppCompatFlags, and MUICache under NTUSER.DAT and SOFTWARE.

If you can hit at least two of the above for a given path, the claim is reportable.

The "missing" case is interesting too

When RecentFileCache.bcf is empty on a Win7 host and the appraisal task has clearly been running, that is a normal state — the appraisal cleaned up. But two patterns are worth checking:

The appraiser task is disabled or has not run in days. Check Microsoft-Windows-TaskScheduler%4Operational.evtx for the last successful run.
The file was deleted by something other than the appraiser. Check the USN journal for FileDelete | Close records on RecentFileCache.bcf itself.

The deletion case is rarer than people assume. Most attackers do not target this file specifically because they have not heard of it. That obscurity is part of why it remains useful.

Where it stops being useful

A few honest limitations:

No timestamps per entry. You cannot build a timeline from the BCF alone.
No hashes. You cannot pivot to threat intel from the file's content.
No user attribution. Like the AmCache, the BCF is per-machine. The "who ran this" question needs separate evidence.
No coverage on modern Windows. If your incident is on Windows 8 or later, the BCF is not there. Use the AmCache instead.
Limited to executables. Scripts run through cscript.exe or powershell.exe show the interpreter, not the script.

A short workflow

When RecentFileCache.bcf is present and matters:

Acquire the file immediately, before the next appraisal pass.
Parse to a flat list of paths.
Filter for user-writable locations and known-adversary path patterns.
For each interesting row, pull the matching Prefetch entry (if any) and the MFT entry for the executable.
Pivot to EVTX for the user and command-line context, if logging permits.

That is the entire job. The BCF is a narrow artifact. Treat it as a quick check, not as a comprehensive timeline source.

Reading the file in the browser

The parser on this site reads RecentFileCache.bcf entirely client-side. Drop the file in, get the sorted path list with the NT-prefix normalized away. No upload. Useful when you are doing IR for a regulated client whose Win7 endpoints have not been replaced yet — they exist, and they are surprisingly common.