Acquiring RecentFileCache.bcf from live and offline systems

You cannot analyse RecentFileCache.bcf until you have a copy. The file has a short shelf life (the next ProgramDataUpdater run rewrites it), so grab it early. This post covers the three settings you will actually meet and the traps that bite each.

Live system: the file is held open

On a running Windows 7 box, RecentFileCache.bcf is held open by the Application Experience service. A naive copy fails:

PS C:\> copy C:\Windows\AppCompat\Programs\RecentFileCache.bcf C:\tmp\
Access to the path 'C:\Windows\AppCompat\Programs\RecentFileCache.bcf' is denied.

Three approaches that work:

1. Raw file read with FTK Imager (GUI or CLI). Bypasses the Win32 lock by talking to the volume at the device level. The copy captures whatever bytes are on disk at the moment of read.

2. Volume Shadow Copy. vssadmin list shadows to find a recent snapshot, then read the file out of the snapshot path:

   $sc = (vssadmin list shadows | Select-String 'Shadow Copy Volume:').Line.Split(' ')[-1]
   Copy-Item "$sc\Windows\AppCompat\Programs\RecentFileCache.bcf" C:\triage\
   

3. KAPE with the RecentFileCache target. Preferred for triage at scale. The target file lives at Targets/Windows/RecentFileCache.tkape in the Kroll KAPE distribution. Running KAPE with --target RecentFileCache pulls the file plus its NTFS metadata using raw reads.

All three preserve the file's LastWriteTime, which (per the lifecycle post) is the closest thing you get to a "last updated" timestamp for the artifact as a whole.

A note that has saved me once or twice: if you are first-responder on a host you suspect, do not wait. By tomorrow the appraiser will have run and your evidence will be a much shorter list. This is one of the few artifacts where ten minutes of delay can cost you the lead.

Offline: disk images

For an E01, VHD, or dd image the file lives at the same path inside the Windows partition:

<partition root>/Windows/AppCompat/Programs/RecentFileCache.bcf

Common workflows:

• libewf + a mounted partition — read the path directly:

  ewfmount image.E01 /mnt/ewf
  mmls /mnt/ewf/ewf1            # find the NTFS partition offset
  mount -o ro,offset=$((2048*512)) /mnt/ewf/ewf1 /mnt/win
  cp /mnt/win/Windows/AppCompat/Programs/RecentFileCache.bcf ./
  

• Sleuth Kit without mounting, useful when the image is large or when you want $LogFile-recoverable copies:

  fls -r -p -o 2048 image.dd | grep -i RecentFileCache.bcf
  # use the inode that fls reports:
  icat -o 2048 image.dd <inode> > RecentFileCache.bcf
  

• FTK Imager / X-Ways / EnCase. Point and click. All three handle locked files inside an image without trouble.

Volume Shadow Copies are your friend

Windows 7 systems typically carry weeks of VSS history under default settings. Each shadow copy contains its own RecentFileCache.bcf, and because the file is rewritten (not appended), older shadows often hold entries that have since been purged from the live file.

Workflow:

1. Enumerate snapshots: vssadmin list shadows (live) or pull \System Volume Information\ out of an image.
2. For each snapshot, pull the BCF from <shadow root>\Windows\AppCompat\Programs\.
3. Diff the parsed entries across snapshots. Entries that exist in old snapshots but not in the live file are particularly interesting. They were either promoted to Amcache.hve or aged out.

The parser on this site has no built-in diff, but the JSON it emits is small and stable. jq handles the rest:

jq -r '.entries[].path' rfc_2026-05-20.json | sort > old.txt
jq -r '.entries[].path' rfc_2026-05-26.json | sort > new.txt
comm -23 old.txt new.txt  # paths that vanished
comm -13 old.txt new.txt  # paths that appeared

The vanished list is where the interesting things live. A path present three days ago and gone today either ran and got promoted, or somebody cleaned up. The corroboration chain through MFT and USN journal tells you which.

Gotchas worth keeping in mind

• The file may not exist. On a freshly imaged machine or one where AeLookupSvc is disabled, the BCF can be absent. Absence is data. See Detecting RecentFileCache tampering.
• Acquisition timestamps are not entry timestamps. Pulling the file at 14:00 does not mean the last entry landed at 14:00. The file's own LastWriteTime is the relevant clock, and it tracks the appraiser run, not any single execution.
• Server 2008 R2 behaves like Win7. Same file, same service, same scheduled task Microsoft\Windows\Application Experience\ProgramDataUpdater. Do not skip a 2008 R2 server because "it is a server, not a workstation."
• Win8 and later do not have it. If your image is Windows 8 or newer, stop looking. You want Amcache.hve.
• Path semantics. Entries are recorded with the \??\ NT-prefix. Decent parsers strip it. If you are scripting against raw bytes, do the strip yourself.

Next

You have a file. The next post covers what to actually look for once it is parsed.

Further reading

• Triage: spotting suspicious entries in RecentFileCache
• Validating RecentFileCache findings
• USN journal and MFT for confirming the file's lifecycle on disk