How to analyze Windows Prefetch files

You have a Prefetch folder pulled from a triage image. Now what? This walkthrough is the order an experienced DFIR analyst would actually go through, with the questions to ask at each step.

1. Triage the folder

Drop the entire Prefetch\ folder onto the parser on this site. The results table lists every .pf file with executable name, hash, version, run count, last-run timestamp, volume count, and number of referenced files.

First sweep — answer these questions without clicking any row:

• How many files total? Healthy Windows 10/11 workstations have hundreds. A handful or zero suggests prefetch was disabled, wiped, or this is a server.
• What's the version distribution? All v30/v31 is normal for a Win10/11 endpoint. Stray v17 entries on a modern host warrant investigation — they may be evidence of a prefetch file copied in from another system.
• Any unusual executables? Sort the table by executable name and skim for binaries that should not be on the machine: PowerShell-encoded loaders, packed .exe names, anything in user-writable paths, anything with high run counts you don't recognize.

2. Drill into suspicious entries

Click any row to expand the detail panel. For each candidate you flagged in step 1, ask:

• When did it run? The last-run-times list (up to 8 entries on Win8.1+) gives you a timeline. Correlate against your incident's window of compromise.
• Where did it run from? The volume info shows the device path and NTFS serial number. A serial that does not match the system's main volume suggests the binary was launched from removable media or a mounted image.
• What did it touch? The "files referenced" list is every DLL, configuration file, and resource the binary loaded on its first observed run. Unusual paths here — references to \Users\...\AppData\, to network shares, to renamed system DLLs — are leads.

3. Cross-reference with other artifacts

Prefetch alone tells you when something ran. It does not tell you what the binary was, who launched it, or whether it is malicious. Pull in:

• Amcache (Amcache.hve) — full inventory with SHA-1 hashes. If a prefetch entry exists but the Amcache record is missing, that's unusual. Use the Amcache parser for a matching client-side tool.
• ShimCache / AppCompatCache — corroborates the path. If Prefetch says the binary ran from C:\Temp\ and ShimCache says the same path was last modified five minutes earlier, the story strengthens.
• Security event log (4688 — process creation) — if process auditing was on, you get the parent process and command-line, which Prefetch alone does not provide.

4. Watch for tampering

A .pf file is just a file. Attackers can delete it, replace it with a fake, or stop it from being created. Three quick checks:

• Recompute the hash against the executable path you see inside the prefetch. A mismatch is strong evidence of a planted file.
• Run counts of 1 with a recent timestamp on a system that has been running for weeks is suspicious — the file may have been deleted and recreated.
• Timestamps in the future or precisely matching whole seconds across many files suggests batch manipulation.

5. Export and document

Hit "Download JSON" on the parser to capture the full structured output. That JSON is your audit artifact: timestamp-stable, easy to grep, easy to diff against another collection. Drop it next to your case notes.

For a deeper dive on what each prefetch field means, see Understanding Windows Prefetch and Prefetch v30 and v31 changes.