Limits of the BCF: when it tells you nothing, and what to use instead

The RecentFileCache.bcf has a quiet reputation among DFIR people who know it exists. The reputation is mostly deserved. The artifact is small, specific, and clean. But it is also narrower than people remember between cases. After a few months of not touching a Win7 box you tend to over-credit what the BCF can answer.

This is the honest list of what the BCF does not give you, and what to pull alongside it.

No timestamps per entry

The file holds paths. That is it. There is no field for "first seen," "last run," or "execution count." A binary appears in the BCF if it ran since the last appraisal pass. That is a single bit of information across the whole window of the file's working life.

The closest thing to a timestamp the BCF offers is the file's own last-modified time on disk, which tells you when the appraiser last wrote to it. That timestamp applies to the whole file. You cannot use it to order entries within the file. You cannot use it to say "this binary ran on Tuesday."

If you need timestamps:

Prefetch. Up to eight last-run times per executable on Win7 (the older .pf format), with full creation and modification metadata.
USN journal. For when the binary appeared on disk, was modified, or was deleted. Operation-level granularity.
Master File Table. Standard Information and File Name attribute timestamps. Useful when the binary has been deleted.
Security 4688 or Sysmon 1. Process creation events with full timestamps and command lines, if the logging was on. On a default Win7 install, it was not.

The BCF tells you something happened. The other artifacts tell you when.

No hashes

There is no hash in the BCF. Not SHA1, not MD5, not the truncated PE-header hash that the AmCache records. If you want to pivot to threat intel, you need the binary itself.

Three ways to get the hash:

Pull the binary off disk and hash it. Trivial if the file is still there.
Reconstruct from a backup, a pagefile, or a RAM dump. Less reliable but sometimes the only option.
Hash the matching Prefetch file's referenced binary by reading the .pf and walking back. The Prefetch does not store the binary's hash either, but it gives you the exact path and you can fetch it from the volume.

If the binary has been deleted and there is no backup, the BCF leaves you without a hash. Permanent gap.

No user attribution

The BCF is per-machine. There is no field for "ran as bob" or "ran as SYSTEM." A binary that ran as a service and a binary that ran as an interactive user look identical in the file.

Attribution sources, in rough preference order:

Security 4688 with SubjectUserSid. Cleanest. Often not present on Win7 unless audit policy was tuned.
Sysmon 1 with User. Best, but Sysmon on Win7 is a rare beast in the wild.
The user's NTUSER.DAT and MUICache under the user hives. MUICache records executables that the user has interacted with via Explorer. Not authoritative but corroborating.
LNK files in the user's Recent and Office Recent folders. If a user double-clicked the binary, an LNK probably exists.
Jump lists. For executables that are pinnable or have been recently used.

For a BCF entry to become "user ran this," you need at least one of those corroborating sources. The BCF alone never carries that claim.

No script tracking

This is the limitation that most often catches people out. The BCF tracks executable launches. A powershell.exe invocation that ran ten different scripts produces one BCF entry: \??\C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. Same for cscript.exe, wscript.exe, mshta.exe, cmd.exe, regsvr32.exe, rundll32.exe.

The interpreters are in the BCF. The scripts they ran are not.

For script-level visibility on Win7:

PowerShell 4688-style logging via Microsoft-Windows-PowerShell/Operational (event ID 4103, 4104), but only if Script Block Logging was enabled. Almost nobody had this on by default on Win7.
Windows PowerShell classic log, Windows PowerShell.evtx. Less informative than the Operational log but worth checking.
LNK files for explicit double-clicked scripts.
Browser history for downloads of script files, paired with recycle bin for what was deleted.
The actual script files on disk, where the user/AppData/Temp paths typically live.

A BCF that shows cscript.exe ran is interesting. A BCF that shows cscript.exe ran and you cannot find the script on disk is more interesting. Pivot to the USN journal for the deleted-script trail.

No DLL or library tracking

Unlike Prefetch, the BCF does not record the DLLs loaded into a process. A binary that loaded a malicious DLL and a binary that ran clean look identical in the file.

If you suspect DLL sideloading or process hollowing, the BCF tells you the host process ran. It does not tell you what was loaded into it. Reach for:

Prefetch's referenced-files list.
Sysmon Event ID 7 (ImageLoaded). Almost never present on Win7 in practice.
Memory analysis from a RAM dump.
The KnownDlls and ImageFileExecutionOptions registry keys for sideloading vectors.

No network or persistence context

The BCF does not record the network. It does not show DNS lookups, outbound connections, or listening ports. It does not record persistence mechanisms. A binary that installed a service, dropped a Run key, or registered a scheduled task is just an entry in the BCF; the installation activity does not surface.

For those:

Registry for Run keys, Services, and ASEPs.
Task Scheduler Tasks folder and the EVTX operational log.
SRUM, which only exists on Win8+, so it is not in scope on a BCF host. But worth knowing for when the host is something else.
DNS cache in memory if you have a RAM dump.

No coverage past the appraisal window

The BCF holds binaries that ran since the last appraisal pass. That is roughly the last 24 hours on a healthy host. Older executions are gone.

The artifact for longer execution history on Win7 is Shimcache, which lives in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache and holds many more entries with last-modified timestamps. Shimcache makes weaker claims (the binary was examined, not necessarily executed) but covers a wider window. Use it for the "did this ever run on the host?" question; use the BCF for the "did this run recently?" question.

No coverage on modern Windows

If the host is Windows 8 or later, the BCF is gone. Go to the AmCache instead. The AmCache has its own limits (it is more inventory than execution evidence) but it is the right primary source on those builds.

The shape of a complete answer

A BCF hit is never the whole story. The shape of a complete claim for "binary X ran on host Y at time T as user Z and did the following" requires:

BCF or Prefetch for the execution itself.
Prefetch or EVTX for the timestamp.
EVTX, MUICache, or LNK for the user.
Prefetch's referenced-files, Sysmon ImageLoaded, or memory for what it loaded.
USN journal and MFT for the file's lifecycle on disk.
Registry, scheduled tasks, and services for persistence.
Network logs, browser history, or memory for outbound activity.

The BCF contributes the cleanest "did it run" bit. Everything else needs another source. Treat the file as a quick check, not as the centerpiece of the investigation.