What is the first thing to check when reviewing a Prefetch folder?

File count and version distribution. A modern Windows 10/11 workstation usually has hundreds of .pf files, mostly v30 or v31. A handful of files, or stray v17 entries on a modern host, deserve investigation.

How many recent execution times does a .pf file record?

Up to eight, on Windows 8.1 and later (v26+). Earlier versions only kept the single most recent run. Use that window to correlate executions against your incident timeline.

What does the volume info inside a .pf tell me?

The NTFS device path and serial number of the volume the binary ran from. A serial that does not match the system's primary volume hints at removable media or a mounted image.

How can I corroborate a suspicious prefetch entry?

Pull Amcache for the SHA-1 and inventory metadata, ShimCache for path corroboration, and Security event 4688 (or Sysmon) for parent process and command line.

How to analyze Windows Prefetch files

You have a C:\Windows\Prefetch\ directory pulled off a triage image and a question to answer about program execution. The order below is what I actually run, in roughly the order I run it. Skip steps at your own risk; the part where analysts get burned is almost always step 3.

1. Triage the folder

Parse the whole directory in one shot. PECmd over a folder, pyscca in a loop, or the parser on this site — pick one that handles MAM-compressed Win10/11 files correctly. Older Python tools silently skip MAM and give you a partial picture.

Before clicking on anything, answer three questions from the summary table:

How many files? A Windows 10/11 workstation with normal use sits in the hundreds. Twelve files on a six-month-old endpoint means either a server SKU, a wipe, or EnablePrefetcher = 0. Zero files plus an existing directory usually means SysMain was stopped.
What versions? Mostly v30 on Win10, mostly v31 on Win11. A stray v17 entry on a modern host is anomalous — v17 only ships on XP/Vista/7, so finding one on a Win11 image means the file was carried in from somewhere else.
Any obviously unusual names? Sort by executable name and skim. PowerShell variants with random suffixes, binaries with single-character names, anything that looks packed, anything living in \AppData\Local\Temp\ or \Users\Public\.

2. Drill into the rows you flagged

For each candidate, three questions:

When did it run? On v26+ you get up to eight FILETIME values, in UTC, plus the "last run". Map those onto the incident window. If your window is "between Tuesday 18:00 and Wednesday 03:00" and three of the eight last-run slots fall inside, that is your execution count for the period of interest.
Where did it run from? The volume information section carries the NTFS device path and serial. A serial that does not match the system's primary volume points at removable media or a mounted image. Cross-check the serial against MFT volume records and LNK drive serials, which often hold the same number.
What did it touch? The file-metric list is every path the binary read in its first ten seconds of monitored execution — typically a few hundred entries on a real application. References to user profile directories, network shares, or renamed system DLLs are leads. DLL search-order hijacking shows up here as a trusted binary loading something out of \AppData\Local\Temp\ instead of \System32\.

3. Cross-reference, always

Prefetch alone tells you a process started. It does not tell you who started it, with what arguments, or whether the binary on disk now is the binary that ran. This step is what turns a Prefetch hit into a defensible execution claim.

AmCache for SHA-1, file size, publisher, signing status. A Prefetch entry with no AmCache record is unusual on Win10+. An AmCache entry with no Prefetch is common (binary present, never ran).
Shimcache / AppCompatCache corroborates the path. Both Prefetch and Shimcache placing the binary in C:\Users\Public\evil.exe is harder to argue against than either alone.
Security 4688 or Sysmon EID 1 — if process auditing was on, this is where you get the parent process and the command line. Prefetch does not record arguments. Ever.
USN journal tells you when the binary first hit the disk; pair that with the earliest Prefetch FILETIME to bound the dwell time.
RecentFileCache on older systems for the same coverage AmCache provides on modern ones.

4. Look for tampering

A .pf is just a file. It can be deleted, planted, or rewritten. Three cheap checks:

Recompute the path hash and compare to the filename suffix. The Win7+ algorithm is short and the parser exposes the path it parsed; a mismatch means the file did not originate here.
A run count of 1 with a "last run" timestamp matching the suspected compromise window on a host that has been online for weeks is worth a second look. The legitimate .pf may have been deleted and a fresh one written when the binary ran again post-cleanup.
Eight last-run FILETIMEs clustered to the same second, or precisely whole seconds, smells like batch manipulation. Real executions distribute across sub-second offsets.

The dedicated tampering write-up has more detail; this is the quick pass.

5. Export and write it up

Export structured output (JSON or CSV) and store it next to the case notes. You want a timestamp-stable artifact that is easy to grep, easy to diff against a later collection from the same host, and easy to drop into a timeline tool. PECmd's CSV plugs straight into KAPE's timeline output; the JSON from the parser on this site is suitable for jq and a notebook.

For deeper context on each field, see Understanding Windows Prefetch and Prefetch v30 and v31 changes.