Investigating a Win7 host with the BCF: a short walkthrough

This is a composite walkthrough drawn from a handful of similar cases. The host is fictional. The artifacts and the workflow are not. The point is to show how much the RecentFileCache.bcf actually contributed to a real-shape investigation, and to be honest about where it did not.

The host

WS-FIN-014. A Windows 7 SP1 workstation in a manufacturing client's finance department. Domain-joined. Last patched fourteen months ago. Owned by a controller who works from the office four days a week. The SOC flagged it on a HTTP POST to a low-reputation domain alert from the perimeter NDR. The destination resolved to a hosting provider in a jurisdiction the client does not do business with.

Triage scope: confirm or rule out a compromise. Time budget: half a day.

What we pulled

In order of acquisition, because order matters when the appraiser cycle can clear the BCF:

C:\Windows\AppCompat\Programs\RecentFileCache.bcf.
The Prefetch directory.
Live registry hives via reg save: SOFTWARE, SYSTEM, SECURITY, NTUSER.DAT for the logged-in user.
Microsoft-Windows-TaskScheduler%4Operational.evtx and the standard System/Security logs.
A USN journal snapshot from the boot volume.
The MFT.
A targeted dump of C:\Users\<controller>\AppData\ for LNK, jump list, and recently-used data.

No RAM dump. The endpoint had been rebooted before we got network access, which is a story of its own.

The BCF contents

After parsing, the BCF held 14 paths. The full list:

\??\C:\Windows\System32\rundll32.exe
\??\C:\Windows\System32\msiexec.exe
\??\C:\Windows\System32\wermgr.exe
\??\C:\Windows\System32\WerFault.exe
\??\C:\Windows\System32\dllhost.exe
\??\C:\Program Files\Microsoft Office\Office14\OUTLOOK.EXE
\??\C:\Program Files\Microsoft Office\Office14\EXCEL.EXE
\??\C:\Program Files\Microsoft Office\Office14\WINWORD.EXE
\??\C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe
\??\C:\Program Files\Internet Explorer\iexplore.exe
\??\C:\Users\jharper\AppData\Local\Temp\sb_v2.exe
\??\C:\Users\jharper\AppData\Roaming\printerhelper\phc.exe
\??\C:\Windows\Temp\update_check.exe
\??\C:\Windows\System32\cscript.exe

The first ten were unremarkable: standard Office and OS components a finance user touches daily. The interesting ones were the last four:

sb_v2.exe in AppData\Local\Temp.
phc.exe in AppData\Roaming\printerhelper\.
update_check.exe in C:\Windows\Temp\.
cscript.exe, which itself is fine, but with no Office macro story to attach it to.

Three of the four were in user-writable directories. That alone is not damning. Legitimate software lands in these paths all the time. But the combination of names and locations was enough to escalate each one.

Corroboration round one: Prefetch

I walked each of the four through the Prefetch first.

sb_v2.exe: one .pf file, last-run timestamp three days ago at 14:22 UTC. Run count of one. Loaded list included WININET.DLL, URLMON.DLL, and BCRYPT.DLL. No surprise for something that contacts the network.

phc.exe: one .pf, last-run timestamp three days ago at 14:24 UTC. Run count of seven. The high run count was interesting; it had been executed multiple times across the prior week. Loaded list included WINHTTP.DLL and CRYPT32.DLL.

update_check.exe: one .pf, last-run timestamp three days ago at 14:23 UTC. Run count of one.

cscript.exe: one .pf, last-run timestamp three days ago at 14:22 UTC. Run count of 12 over the prior month.

So all four ran within a two-minute window three days ago, and cscript.exe and phc.exe had been running for longer than that. That was the first real shape: a cluster of executions three days back, on top of a longer-running thing that looked like established presence.

The BCF told me these binaries ran. Prefetch told me when and how often. Already, the BCF had done its job (proving execution) and was being eclipsed by Prefetch for timeline work.

Corroboration round two: MFT and USN

MFT entries for each binary:

sb_v2.exe: created three days ago at 14:21 UTC. One minute before its only execution.
phc.exe: created twenty-three days ago at 09:11 UTC. Multiple modifications since.
update_check.exe: created three days ago at 14:21 UTC.

The USN journal added detail. sb_v2.exe had a FileCreate | DataExtend | Close sequence from iexplore.exe as the originating process context (USN does not give you a PID directly, but the timestamps lined up with an iexplore.exe execution in the BCF and Prefetch). The user had visited a site, the browser had written the file, and the file had executed within sixty seconds.

update_check.exe had a similar creation pattern, originating around the same time, with iexplore.exe again in the implied context.

phc.exe was different. The USN showed a FileCreate twenty-three days ago, originating from msiexec.exe. That made it look like an installer dropped it. The MFT confirmed the parent directory printerhelper was created at the same moment.

The shape after MFT and USN: two binaries dropped by a browser session three days ago, plus a binary installed three weeks ago by what looked like an MSI.

Corroboration round three: registry and persistence

The printerhelper directory's parent context pointed me at the registry. Under HKCU\Software\Microsoft\Windows\CurrentVersion\Run was an entry named PrinterHelperCore with the value "C:\Users\jharper\AppData\Roaming\printerhelper\phc.exe" /q. Last-write timestamp on the key matched the MSI install date.

Persistence. The thing the BCF could never tell me on its own.

The Run key also explained the high run count in Prefetch: every logon executed phc.exe. Seven runs in three weeks tracked with the user's logon pattern.

No persistence for sb_v2.exe or update_check.exe. Both looked like one-shot payloads.

Corroboration round four: EVTX

The Security log was thin. Audit policy was at Win7 defaults; no 4688s for command lines. The TaskScheduler operational log was clean for ProgramDataUpdater, with regular 200/201 pairs roughly every 26 hours. The appraiser had been running on schedule. That mattered because it explained why the BCF only had 14 entries: anything from before the last appraisal pass (roughly 18 hours before acquisition) had been processed out.

The System log had a service-install event two weeks ago that did not match the persistence I already had, but on follow-up it was a printer driver update. Coincidence.

The most useful EVTX entry came from Microsoft-Windows-Windows Defender/Operational. Defender had quarantined a file three days ago at 14:23 UTC, two seconds after update_check.exe ran. The quarantine name matched a generic downloader signature. That gave me my first malware-family hit and confirmed that the cluster three days back was real.

What the user did

LNK files and browser history filled in the human element. The user had received an email three days ago at 14:18, opened a link three minutes later, and reached a fake software-update page. The browser history showed the navigation chain. The Internet Explorer download manager log had the file drops.

The MSI installation three weeks ago was harder to attribute. The user did not remember installing printer software. The MSI itself was no longer on disk, but the USN journal had its short-lived existence in Downloads. The browser history three weeks ago showed a navigation to a fake driver-update domain. Same pattern as the recent activity, different campaign-looking infrastructure.

What the BCF actually contributed

Honestly: it pointed me at the four interesting binaries quickly. That is what it is for.

It did not give me:

The timestamps. Prefetch did.
The persistence. Registry did.
The drop chain. USN and the browser history did.
The user attribution. LNK, browser history, and MUICache did.
The malware family hit. Defender's log did.
The campaign linkage. Network and browser history did.

The BCF gave me a 14-line shortlist to triage. Without it I would have started from Prefetch and arrived at the same four binaries, just slower. With it, the first pass took about ten minutes. The whole corroboration chain took most of the day.

If the host had been Win10, I would have used the AmCache for the same purpose. The shape of the investigation would have been the same; the entry artifact would have been different.

What got into the report

The report claimed:

The host was compromised at least three weeks ago via a fake printer-driver installer.
The compromise established persistence via an HKCU Run key.
Three days ago, the same user fell for a similar fake-update lure, which dropped two additional binaries. One was quarantined by Defender. The other (sb_v2.exe) executed and made network contact.
The network contact was the alert the SOC flagged.
The persistence binary (phc.exe) was still running on the host until isolation.

The BCF supported point three (the cluster of recent executions) directly. It supported point one indirectly (its inclusion of phc.exe was the bridge to the persistence finding). The other points came from corroborating artifacts.

What I would have missed without the BCF

Probably nothing. Prefetch covered the same ground for these particular binaries. The BCF's role here was a fast-triage filter, not a unique evidence source.

That is the honest answer about most BCF cases. It is a clean, fast, narrow artifact. It rarely tells you something that nothing else can. Its value is the speed at which it points you at the right files.