Windows Prefetch

This document provides a structured forensic reference for Windows Prefetch files — one of the most valuable and reliable execution artifacts available to investigators on Windows systems. It is intended for forensic analysts, security researchers, and individuals conducting endpoint examinations including PC checks in environments such as FiveM, gaming anti-cheat investigations, or enterprise incident response.

Prefetch files are generated automatically by Windows to speed up application loading. As a side effect of this performance optimization, Windows maintains a detailed record of which programs have executed, when they ran, how many times they were launched, and what files they accessed during startup. For a forensic investigator, this creates an exceptionally rich evidentiary source that is often overlooked by attackers attempting to cover their tracks.

Unlike many forensic artifacts that require specific logging configurations to be enabled, Prefetch is active by default on all Windows workstation editions. It requires no administrator configuration, generates artifacts automatically, and persists even after the source executable has been deleted — making it one of the most consistently available sources of execution evidence across all Windows environments.

Windows Prefetch is a performance feature managed by the SysMain service (formerly SuperFetch in Windows 7 and earlier). When an application launches for the first time, the Windows kernel monitors its activity for the first 10 seconds of execution — specifically, which files and directories the application accesses during that window. This information is recorded in a Prefetch file (.pf) stored in C:\Windows\Prefetch\.

On subsequent launches, Windows uses this cached knowledge to pre-load the required files into memory before the application needs them, reducing perceived load time. The Prefetch file is updated on each execution, maintaining current execution counts and timestamps alongside the file reference data.

The Prefetch file format has changed significantly across Windows versions. Investigators must identify the correct format version before parsing, as tools calibrated for one version will misparse another. The format version is stored in the file header and can be used to confirm the Windows version that generated the artifact.

To confirm Prefetch is enabled on a target system, check the registry key below. A value of 3 enables both application Prefetch and boot Prefetch. A value of 0 disables it entirely.

Every Prefetch file follows a precise naming convention that encodes both the executable name and a hash derived from the file's full execution path. Understanding this convention is fundamental to reading Prefetch data correctly — the hash in particular is one of the most forensically significant elements in the filename.

# Prefetch filename format:
[EXECUTABLE_NAME]-[PATH_HASH].pf

# Real-world examples:
POWERSHELL.EXE-C4A49B7C.pf
CMD.EXE-4A81B364.pf
MIMIKATZ.EXE-7F3A2C11.pf
PYTHON.EXE-9B3E12A4.pf

# The hash is computed from the FULL PATH of the executable,
# NOT from the file's content — same exe from different locations
# produces different hashes and separate .pf files:

POWERSHELL.EXE-C4A49B7C.pf  ← from C:\Windows\System32\WindowsPowerShell\v1.0\
POWERSHELL.EXE-9D2F1A88.pf  ← from C:\Temp\ (same binary, different path)
POWERSHELL.EXE-3C7B4E22.pf  ← from C:\Users\User\AppData\Roaming\

# This means multiple .pf files for the same executable name
# indicate the program ran from multiple different locations — a major red flag.

A Prefetch file is a binary structure divided into a header section and a series of data sections. Understanding what each section contains helps investigators know exactly what can be recovered from a .pf file and what questions it can answer.

┌─────────────────────────────────────────────────────────┐
│  PREFETCH FILE STRUCTURE (Windows 10 / Format v30)      │
├─────────────────────────────────────────────────────────┤
│  HEADER (84 bytes)                                       │
│  ├── Signature:      "SCCA" (0x53 43 43 41)             │
│  ├── Format Version: 0x1E (30) for Win10                │
│  ├── File Size:      total size of uncompressed file     │
│  ├── Executable Name: UTF-16LE, max 29 chars + null     │
│  ├── Path Hash:       4-byte hash of execution path     │
│  └── [Section offsets and lengths for each data block]  │
├─────────────────────────────────────────────────────────┤
│  SECTION A — File Metrics Array                         │
│  ├── Start time offset of each file load                │
│  ├── Duration of file load                              │
│  └── Reference into filename strings section            │
├─────────────────────────────────────────────────────────┤
│  SECTION B — Trace Chains Array                         │
│  └── Block chain entries for prefetch data layout       │
├─────────────────────────────────────────────────────────┤
│  SECTION C — Filename Strings                           │
│  └── UTF-16LE full paths of every file/dir accessed     │
│      during the first 10 seconds of execution           │
├─────────────────────────────────────────────────────────┤
│  SECTION D — Volume Information                         │
│  ├── Volume device path (e.g. \Device\HarddiskVolume3)  │
│  ├── Volume creation timestamp                          │
│  ├── Volume serial number                               │
│  └── Directory strings accessed on this volume         │
├─────────────────────────────────────────────────────────┤
│  EXECUTION DATA (in header, after base fields)          │
│  ├── Last Run Time[0..7]: 8× FILETIME (Win8+)          │
│  └── Run Count: number of times executed               │
└─────────────────────────────────────────────────────────┘

Timestamps are stored in Windows FILETIME format — a 64-bit integer counting 100-nanosecond intervals since January 1, 1601 UTC. They are stored in UTC and must be converted to local time for reporting, keeping the investigator's timezone in mind. All parsing tools handle this conversion automatically.

# PECmd output for MIMIKATZ.EXE-7F3A2C11.pf (Windows 10 system)

Executable Name: MIMIKATZ.EXE
Hash:            7F3A2C11
Source Created:  2025-03-14 09:12:44
Run Count:       7

Last Run:        2025-03-18 22:47:03  ← most recent
Last Run -1:     2025-03-18 19:31:11
Last Run -2:     2025-03-17 14:05:58
Last Run -3:     2025-03-16 23:12:44
Last Run -4:     2025-03-15 08:47:30
Last Run -5:     2025-03-14 22:19:07
Last Run -6:     2025-03-14 09:12:51
Last Run -7:     2025-03-14 09:12:44  ← oldest recoverable

Volume Path:     \Device\HarddiskVolume3
Volume Created:  2024-11-02 14:23:01
Volume Serial:   A4B2-9C3E

The most fundamental forensic application of Prefetch is proving that a specific program executed on a specific system. This is particularly valuable when other execution evidence (event logs, AV logs, browser history) has been cleared or was never enabled.

A Prefetch file is created or updated only when the corresponding program runs. There is no mechanism by which a .pf file can appear without actual execution — it cannot be created by simply copying an executable to the system, opening it in a file browser, or scanning it with antivirus. The presence of a Prefetch file is therefore one of the most definitive execution indicators available.

One of the most powerful forensic properties of Prefetch is its persistence after the source executable is deleted. When an attacker removes their tools — whether by deleting files directly, emptying the Recycle Bin, or running cleanup utilities — the corresponding Prefetch files typically remain untouched in C:\Windows\Prefetch\. This is because most cleanup routines do not specifically target the Prefetch directory.

The execution path embedded in each Prefetch file is one of its most forensically revealing elements. Legitimate system programs consistently run from consistent, known paths. Any deviation from expected paths is immediately suspicious and warrants investigation.

# LEGITIMATE paths for common system binaries:
C:\Windows\System32\cmd.exe
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\System32\net.exe

# SUSPICIOUS paths — same binary names, wrong locations:
C:\Temp\powershell.exe              ← attacker-dropped copy
C:\Users\User\AppData\Roaming\cmd.exe ← masquerading
C:\Users\User\Downloads\update.exe  ← user-downloaded payload
C:\ProgramData\Microsoft\svchost.exe ← svchost outside System32
C:\Windows\Temp\wscript.exe         ← copy to evade path monitoring

# TOOL NAMES that should NEVER appear in Prefetch on a clean system:
MIMIKATZ.EXE      ← credential dumping
PROCDUMP.EXE      ← process memory dumping (legitimate but abused)
PSEXEC.EXE        ← remote execution (legitimate but frequently abused)
WCEWORLD.EXE      ← Windows Credential Editor
WINCRED.EXE       ← credential tool
COBALTRIKE*.EXE   ← C2 framework
METERPRETER.EXE   ← Metasploit payload
NMAP.EXE          ← network scanning
NC.EXE            ← netcat
LAZAGNE.EXE       ← credential harvesting

Section C of each Prefetch file contains the full paths of every file and directory the executable accessed during the first 10 seconds of its run. This is often the most information-dense section for forensic investigation — it reveals not just that a program ran, but what it did when it ran.

# File references from MIMIKATZ.EXE-7F3A2C11.pf (Section C)
# These are files/directories accessed in first 10 seconds of execution:

\DEVICE\HARDDISKVOLUME3\WINDOWS\SYSTEM32\LSASS.EXE         ← LSASS access
\DEVICE\HARDDISKVOLUME3\WINDOWS\SYSTEM32\NTDLL.DLL
\DEVICE\HARDDISKVOLUME3\WINDOWS\SYSTEM32\KERNEL32.DLL
\DEVICE\HARDDISKVOLUME3\WINDOWS\SYSTEM32\WDIGEST.DLL       ← credential provider
\DEVICE\HARDDISKVOLUME3\WINDOWS\SYSTEM32\KERBEROS.DLL      ← kerberos module
\DEVICE\HARDDISKVOLUME3\WINDOWS\SYSTEM32\MSV1_0.DLL        ← NTLM auth module
\DEVICE\HARDDISKVOLUME3\USERS\ATTACKER\DESKTOP\CREDS.TXT   ← output file

# Volume information (Section D):
Volume Path:    \Device\HarddiskVolume3
Serial Number:  A4B2-9C3E
Created:        2024-11-02 14:23:01

Prefetch artifacts are primarily located in a single directory but must be collected carefully to preserve all associated metadata. Always work from a forensic copy — never parse Prefetch files directly on a live system without first imaging them, as some tools may modify file access timestamps.

Prefetch files are binary structures that require dedicated parsing tools. The following workflows cover the most common analysis scenarios from a basic triage through to a full batch investigation with timeline export.

# PECmd by Eric Zimmerman — most comprehensive Prefetch parser
# https://ericzimmerman.github.io

# Parse a single .pf file (detailed output)
PECmd.exe -f "C:\Windows\Prefetch\MIMIKATZ.EXE-7F3A2C11.pf"

# Parse entire Prefetch directory — output to CSV for timeline analysis
PECmd.exe -d "C:\Windows\Prefetch" --csv "C:\Output" --csvf prefetch_results.csv

# Parse offline (from forensic copy) with quiet output
PECmd.exe -d "E:\ForensicCopy\Windows\Prefetch" --csv "C:\Output" -q

# Include Section C file references in output (verbose — large files)
PECmd.exe -d "C:\Windows\Prefetch" --csv "C:\Output" --json "C:\Output"

# Sort output by last run time (newest first) — useful for triage
PECmd.exe -d "C:\Windows\Prefetch" --csv "C:\Output" --csvf triage.csv
# Then in Timeline Explorer: sort by LastRun descending

# Key fields in CSV output:
#  SourceFilename  ExecutableName  Hash  Size  RunCount
#  LastRun  LastRun-1 ... LastRun-7  SourceCreated  SourceModified
#  Volume0Name  Volume0Serial  Volume0Created

# Quick manual header check — confirm signature and format version
import struct

with open('MIMIKATZ.EXE-7F3A2C11.pf', 'rb') as f:
    data = f.read()

# Check for MAM compression (Windows 10/11)
if data[:3] == b'MAM':
    print("File is MAM-compressed — decompress first")
else:
    sig     = data[0:4]         # should be b'SCCA'
    version = struct.unpack('<I', data[4:8])[0]   # format version
    filesize= struct.unpack('<I', data[8:12])[0]  # uncompressed size
    exe_name= data[0x10:0x4A].decode('utf-16-le').rstrip('\x00')
    path_hash = hex(struct.unpack('<I', data[0x4C:0x50])[0])

    print(f"Signature:  {sig}")       # b'SCCA'
    print(f"Version:    {version}")    # 17/23/26/30/31
    print(f"Exe Name:   {exe_name}")
    print(f"Path Hash:  {path_hash}")

The following indicators, derived from Prefetch analysis, represent reliable signals of malicious activity. Each can be identified through standard Prefetch parsing without additional tooling.

Sophisticated attackers are aware of Prefetch and may take steps to defeat it. Understanding these counter-techniques helps investigators recognize when Prefetch has been tampered with and how to compensate using other artifact sources.

Windows Prefetch is one of the most reliably available and consistently informative execution artifacts in Windows forensics. Generated automatically without any administrator configuration, it records execution evidence that persists after log clearing, executable deletion, and many common anti-forensics operations. For investigators working in environments where event logging was never configured, or where an attacker has cleared logs, Prefetch may be the primary — or only — source of execution timeline data.

The combination of execution timestamps (up to 8 per program), run counts, execution paths, and Section C file references gives Prefetch a depth that few single artifacts can match. A single .pf file can confirm not just that a tool ran, but when it ran, how many times, from what location, what credential stores it accessed, and whether it wrote output to disk — all from a file the attacker likely did not think to remove.

Effective Prefetch investigation requires attention to version differences across Windows editions, awareness of the anti-forensic techniques attackers use against it, and systematic correlation with complementary artifacts — ShimCache, AmCache, LNK files, MFT records, and Windows event logs — to build the most complete possible picture of execution activity on a system.