Prefetch — Application Execution Cache

Every time an application launches on a Windows system, the operating system silently writes a Prefetch file containing the executable name, the last eight execution timestamps, a total run count, and a list of every file and directory the application touched during its first ten seconds. Prefetch proves an application ran — not just that it existed. The timestamps and run count survive even if the application is deleted, unless someone specifically clears C:\Windows\Prefetch.

What Is Prefetch?

Prefetch is a Windows application execution caching subsystem introduced in Windows XP (October 2001). Its original purpose was performance optimization: by recording which files an application loads during startup, Windows can pre-fetch those files from disk into memory on subsequent launches, reducing load times. The subsystem is controlled by the Superfetch/SysMain service and writes its output to individual .pf files in a fixed system directory.

From a forensic perspective, Prefetch’s performance data is an execution artifact of extraordinary value. Each .pf file records: the executable name, the path-based hash used to distinguish different installations of the same binary, the last eight execution timestamps (Windows 8 and later; only the most recent on XP/Vista/7), the total run count since the file was created, and a complete list of files and directories referenced during the application’s first ten seconds of execution. This file/directory list often includes DLLs loaded, configuration files read, and data files accessed — providing not just proof of execution but context about what the application did when it ran.

Prefetch operates on all Windows desktop editions by default. On Windows Server, Prefetch is disabled by default but can be enabled via the registry key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher (set to 3 for both application launch and boot prefetching). SSD-equipped systems on Windows 10/11 may use Superfetch/SysMain instead of traditional Prefetch, but the .pf files are still generated.

Location & Format

File Path & Naming Convention

Prefetch files are stored at C:\Windows\Prefetch\ and follow the naming convention {EXENAME}-{HASH}.pf. The hash is calculated from the executable’s full file path, which means the same binary run from two different locations produces two distinct Prefetch files. For example, CMD.EXE-4A81B364.pf and CMD.EXE-D4E9B3A7.pf represent cmd.exe launched from C:\Windows\System32\ versus a copy in C:\Temp\. This path-based hashing is critical for detecting renamed binaries: if an attacker renames mimikatz.exe to svchost.exe and runs it from C:\Users\Public\, the hash will not match the legitimate SVCHOST.EXE Prefetch entry.

Format Versions

Internal Layout

Each .pf file contains a structured binary layout consisting of: a file header (signature 0x53434341 “SCCA”, version number, file size, executable name); a file metrics array listing every file referenced during the first 10 seconds of execution with NTFS file reference numbers; trace chains recording the disk sectors accessed; a filename strings section containing the full paths of all referenced files and directories; and a volumes information block containing the volume serial number, volume creation time, and volume device path. On Windows 10/11 (version 30), the entire file after the header is compressed using the MAM (Microsoft Algorithm for Microprocessors) format with Xpress Huffman encoding.

What It Reveals

Prefetch answers a specific class of investigative questions that other execution artifacts either cannot answer or answer less completely. The following questions are directly answerable from Prefetch data:

• Did a specific application execute on this system? — The existence of a .pf file for an executable is definitive proof of execution. Unlike Shimcache, which records image loads that may not have completed, Prefetch is only written for applications that actually launched.
• When did the application last run? — The most recent of the 8 stored timestamps (Win8+) provides the last execution time. On XP/Vista/7, only the single most recent timestamp is available.
• When were the previous 7 executions? — Windows 8+ stores the last 8 execution timestamps, allowing an investigator to build a usage pattern. An attacker tool that ran 8 times over 3 days reveals a sustained campaign, not a single incident.
• How many times total has the application run? — The run count field is cumulative since the Prefetch file was created. A run count of 47 for RCLONE.EXE indicates repeated use, not a single test.
• What files and DLLs did the application load? — The file metrics array lists every file referenced during the first 10 seconds. This reveals loaded DLLs, opened configuration files, and accessed data files — providing behavioral context beyond mere execution proof.
• What directories did the application access? — Directory paths in the filename strings section show where the application was reading from or writing to. An archiving tool that references \\fileserver\finance\ during its first 10 seconds reveals what data it was targeting.
• What volume was the application installed on? — The volume serial number and creation time in the volumes block can be used to correlate execution with a specific drive, including USB drives.
• Was the binary run from an unusual location? — The path-based hash changes when the same binary is run from different directories. Multiple Prefetch entries for the same executable name with different hashes indicate execution from multiple paths — a common indicator of lateral movement tools dropped into %TEMP% or staging directories.
• Was a binary renamed before execution? — If a Prefetch file named SVCHOST.EXE-{HASH}.pf exists with a hash that does not match the legitimate System32 path, and the file metrics show non-standard DLLs, the binary was likely a renamed attacker tool masquerading as a system process.
• Did the application access network shares? — UNC paths (e.g., \\server\share\file.docx) in the filename strings section prove the application accessed network resources during startup.

Forensic Use Cases

1. Malware Execution Proof

A Prefetch file for an unknown executable in C:\Users\Public\Downloads\ provides definitive proof that the malware ran, even if the binary has since been quarantined or deleted by endpoint detection. The file metrics array reveals which DLLs the malware loaded, which may identify the malware family (e.g., loading wininet.dll and crypt32.dll suggests HTTP-based C2 with encrypted communications). The 8 timestamps show whether this was a single detonation or a persistent implant that executed repeatedly.

2. Anti-Forensics Tool Detection

The irony of anti-forensics tools is that they leave their own forensic footprint. CCLEANER.EXE, CCLEANER64.EXE, ERASER.EXE, SDELETE.EXE, and BLEACHBIT.EXE all generate Prefetch entries when they execute. An investigator who finds CCLEANER64.EXE-{HASH}.pf with a last-run timestamp of 2026-03-15 02:14:00 and a run count of 1 has evidence that the subject ran CCleaner exactly once — almost certainly to destroy evidence. The timestamp of the CCleaner Prefetch entry brackets the anti-forensics activity.

3. Lateral Movement Tool Detection

Remote administration and lateral movement tools leave distinctive Prefetch signatures. PSEXEC.EXE, PSEXESVC.EXE (the service component deployed to remote hosts), WMIC.EXE, MSTSC.EXE (Remote Desktop), and NET.EXE (used for share mapping and user enumeration) all generate Prefetch entries. On a compromised host, finding PSEXESVC.EXE-{HASH}.pf proves that PsExec was used to execute commands on that machine remotely — the service binary is only present on the target, not the source.

4. Data Exfiltration Tool Detection

Prefetch entries for RCLONE.EXE, WINSCP.EXE, FILEZILLA.EXE, MEGACMD.EXE, 7Z.EXE, and RAR.EXE indicate potential data staging and exfiltration. The file metrics are especially valuable here: if 7Z.EXE’s Prefetch file references \\fileserver\hr-data\ in its filename strings, the archiving tool was accessing HR data during its first 10 seconds of execution. Combined with the run count, this reveals the scale of the exfiltration operation.

5. Renamed Binary Detection

Attackers frequently rename tools to blend in. mimikatz.exe becomes svchost.exe; PsExec.exe becomes winupdate.exe. Because the Prefetch hash is derived from the full file path, a renamed binary run from a non-standard location produces a Prefetch entry with a hash that does not match any legitimate system binary. SVCHOST.EXE-A41295B3.pf alongside the legitimate SVCHOST.EXE-B901B5A2.pf immediately flags the anomaly. The file metrics inside the suspicious entry will show DLLs inconsistent with the real svchost.exe.

Acquisition Methods

Live System — Direct Copy

:: Copy all Prefetch files to evidence directory
robocopy C:\Windows\Prefetch C:\Evidence\Prefetch *.pf /COPY:DAT /R:0 /W:0

:: Alternative: xcopy (preserves timestamps)
xcopy C:\Windows\Prefetch\*.pf C:\Evidence\Prefetch\ /Y /H

Live System — KAPE Collection

:: Using KAPE (Kroll Artifact Parser and Extractor)
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target Prefetch

:: Using Velociraptor (remote collection via VQL)
:: Artifact: Windows.KapeFiles.Targets with target "Prefetch"
:: Or directly:
:: SELECT * FROM glob(globs="C:/Windows/Prefetch/*.pf")

Forensic Image — Direct Extraction

# Mount the forensic image (read-only)
mount -o ro,noexec,nodev /dev/sdb1 /mnt/evidence

# Copy all Prefetch files
cp /mnt/evidence/Windows/Prefetch/*.pf /analysis/prefetch/

# Verify file count
ls -la /analysis/prefetch/ | wc -l

Parsing Tools & Analysis

Parsing with PECmd (Eric Zimmerman)

:: Parse all Prefetch files in a directory to CSV
PECmd.exe -d C:\Evidence\Prefetch --csv C:\Analysis\Prefetch_Output

:: Parse a single Prefetch file with full detail
PECmd.exe -f C:\Evidence\Prefetch\RCLONE.EXE-7B3A2C1D.pf

:: Output files:
::   [timestamp]_PECmd_Output.csv           (one row per .pf file)
::   [timestamp]_PECmd_Output_Timeline.csv  (all 8 timestamps per entry)

Sample Output

Executable Name     Run Count  Last Run (UTC)           Previous Runs (UTC)                                              Hash       Source Path
RCLONE.EXE          47         2026-03-15 02:14:33      2026-03-14 22:01:11, 2026-03-14 18:30:45, 2026-03-13 23:15:02,   7B3A2C1D   C:\Users\jdoe\AppData\Local\Temp\rclone.exe
                                                         2026-03-13 19:44:18, 2026-03-12 21:08:33, 2026-03-12 17:22:01,
                                                         2026-03-11 23:55:47
PSEXESVC.EXE        3          2026-03-14 04:22:17      2026-03-13 04:18:45, 2026-03-12 04:15:02                          A1B2C3D4   C:\Windows\PSEXESVC.EXE
CCLEANER64.EXE      1          2026-03-15 02:18:44      (none)                                                            E5F6A7B8   C:\Program Files\CCleaner\CCleaner64.exe
7Z.EXE              12         2026-03-14 21:45:08      2026-03-14 21:30:22, 2026-03-14 20:15:33, 2026-03-14 19:00:11,   C9D0E1F2   C:\Users\jdoe\Downloads\7z.exe
                                                         2026-03-13 22:45:18, 2026-03-13 21:30:44, 2026-03-13 20:15:02,
                                                         2026-03-12 23:00:55

Retention & Persistence

Prefetch retention is not time-based. Entries persist indefinitely until the maximum count (1024 on Win10+; 128 on XP/7) forces eviction of the oldest entry. On a low-activity system (e.g., a single-purpose workstation), Prefetch files may persist for months or years. On a high-activity system (e.g., a developer workstation running builds, test suites, and package managers), the 1024-entry limit may cause eviction within days. The effective retention window is entirely determined by the rate at which new, unique applications are executed.

Anti-Forensics Resilience

Prefetch is a well-known artifact, and unlike SRUM.db, it is targeted by some anti-forensics tools. However, the act of running a cleanup tool creates its own Prefetch entry — making anti-forensics partially self-defeating.

MITRE ATT&CK Detection Mapping

Prefetch data provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Studies

References

1. Eric Zimmerman, “PECmd — Prefetch Explorer Command Line” — https://ericzimmerman.github.io/
2. Joachim Metz, “libscca — Library and tools to access Windows Prefetch files” — https://github.com/libyal/libscca
3. NirSoft, “WinPrefetchView” — https://www.nirsoft.net/utils/win_prefetch_view.html
4. SANS Institute, “Windows Forensic Analysis — Prefetch” — https://www.sans.org/blog/
5. 13Cubed, “Prefetch Deep Dive for DFIR” — https://www.13cubed.com/blog
6. ForensicArtifacts.com, “Windows Prefetch Artifact Definition” — https://github.com/ForensicArtifacts/artifacts
7. Microsoft, “Superfetch and Prefetch” — https://learn.microsoft.com
8. Hexacorn, “Prefetch File Format” — https://www.hexacorn.com