Prefetch File Forensic Parser Tool For Windows — Complete Documentation & Simulation

Overview & System Context

Prefetch File Forensic Parser Tool For Windows: Comprehensive Web-Sourced Technical Investigation Exhaustive Research Dossier · Pure Web-Scraped Content: ~7341 Words · Real Software Screenshots: 3 1. Executive Overview & Technical Background 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.

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. 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.

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. Figure 1: Windows Forensics: Analyzing Prefetch Files with Belkasoft X For deeper context on each field, see Understanding Windows Prefetch and Prefetch v30 and v31 changes .

In a controlled study by Horizon3 researchers, models that explicitly identified a trap in their reasoning still attacked it 73.4% of the time. Read the findings and see what they mean for canaries, decoys, and early detection. Incident responders frequently encounter the same scenario: an attacker ran Mimikatz, PsExec, and a custom C2 implant on a compromised machine, then deleted them before leaving. The disk shows no trace of the files. But C:\Windows\Prefetch contains .pf files for all three: including the exact paths where they ran and the timestamps of every execution.

Windows writes Prefetch files for performance optimization, not for forensics. But the side effect is a complete execution history that survives file deletion and often survives even anti-forensics attempts, since most malware authors do not specifically clean Prefetch artifacts. Figure 2: Windows Forensics: Analyzing Prefetch Files with Belkasoft X Each Prefetch file is named: EXECUTABLENAME-XXXXXXXX.pf where XXXXXXXX is an 8-character hash of the execution path. The same binary run from two different paths creates two separate Prefetch entries.

Note on path hashes: The 8-character hash is computed from the full path, so POWERSHELL.EXE-XXXXXXXX.pf from C:\Windows\System32 has a different hash than a renamed/moved PowerShell copy, giving forensic evidence of execution from unusual paths. Windows Prefetch files in C:\Windows\Prefetch record every program execution: the executable name, full path, up to 8 run timestamps, and the total run count. They survive file deletion and persist until the 128-entry limit is hit. Parse with Eric Zimmerman's PECmd to output CSV for timeline analysis. Key forensic value: proving that attacker tools like Mimikatz, PsExec, and custom C2 implants ran: including their exact execution paths, timestamps, and run frequency: even after the binaries were deleted from disk.

A Windows Prefetch (.pf) file contains: the executable name and full path at execution time, the total number of times the program ran, up to 8 timestamps of recent executions (Windows 8+), a list of DLLs and files accessed during the first 10 seconds of execution, and the volume serial number of the drive it ran from. This information persists even after the original binary is deleted, making Prefetch files critical execution evidence for incident response.

Figure 3: Digital Forensics, Part 06: Analyzing Windows Pre-fetch Files for ... Use Eric Zimmerman's PECmd tool (free, from ericzimmerman.github.io). Run PECmd.exe -d C:\Windows\Prefetch --csv output\ to parse all .pf files and export to CSV for timeline analysis. The CSV includes the executable name, all run timestamps, run count, and referenced file paths. Correlate Prefetch timestamps with Windows Event Logs (Event 4688 for process creation) and network logs to reconstruct the attack timeline.

Windows Prefetch files (.pf files in C:\Windows\Prefetch) are created by the SuperFetch service to speed up application loading. They record: the name of the executable, the last 8 execution timestamps, the total run count, and paths of all files and DLLs loaded during execution. Forensically, Prefetch files prove execution: even if malware was deleted from disk, its Prefetch file persists and shows when it ran. They also reveal file paths the malware accessed (showing staging directories, exfiltration targets, or persistence mechanisms). Prefetch is enabled by default on workstations and disabled by default on Windows Server.

Windows creates multiple execution artifacts: Prefetch files (last 8 run timestamps and loaded file paths), Shimcache (AppCompatCache in the registry — records applications executed, survives reboots), Amcache.hve (registry hive recording file path, size, hash, and first execution timestamp of all run executables), UserAssist registry keys (records GUI applications run by each user with execution count and timestamp), BAM/DAM (Background/Desktop Activity Moderator — records executables run by each user in the last ~7 days), and Event ID 4688 (process creation with command line if auditing is enabled). These artifacts are complementary: using multiple sources provides cross-validation during forensic investigation.

Yes. Attackers can delete Prefetch files with 'del C:\Windows\Prefetch\EVIL.EXE-XXXXXXXX.pf' or by clearing the entire Prefetch directory. However, deletion itself is an indicator: an otherwise clean system with a recently emptied Prefetch directory (particularly via automated scripts) is suspicious. Sysmon can log file deletion events (Event ID 23) if configured to monitor the Prefetch directory. Additionally, other execution artifacts (Shimcache, Amcache, BAM) are harder to clean comprehensively because they are stored in registry hives and require registry editing or hive deletion rather than simple file removal. A thorough attacker cleaning all artifacts is unusual: most malware either does not clean up or only cleans obvious items.

How do I correlate Prefetch timestamps with other Windows forensic artifacts to build a reliable attack timeline? Prefetch timestamps are most valuable when combined with at least two other artifact sources because clock skew, volume shadow copy age differences, and NTFS timestamp manipulation can each introduce inaccuracies in a single-source timeline. Use PECmd to export Prefetch data to CSV, then import into a timeline tool such as Plaso (log2timeline) or a spreadsheet.

Layer in Event ID 4688 process creation timestamps from the Security event log (if process auditing was enabled), Shimcache entries from SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache (parsed with AppCompatCacheParser from Eric Zimmerman's tools), and Amcache.hve first-execution timestamps (parsed with AmcacheParser). Where Prefetch records that a binary ran multiple times, check whether the corresponding 4688 events exist -- if 4688 events are missing for runs that Prefetch recorded, audit logging may have been disabled or the log was cleared, which is itself an indicator. Finally, correlate execution timestamps with outbound network connections from Zeek or firewall logs: malware execution followed within 30-120 seconds by a new outbound connection to an uncategorized or newly registered domain is one of the highest-confidence lateral movement and C2 establishment patterns in incident response.

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team. Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam. Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

Actionable threat intelligence for working practitioners. Free. No spam. Trusted by 50,000+ SOC analysts, CISOs, and security engineers. The goal of this project was to practice Digital Forensics & Incident Response (DFIR) techniques by analyzing Windows Prefetch files . Prefetch files are artifacts created by Windows to optimize application startup, and they also provide valuable forensic evidence such as: This lab walks through creating a forensic analysis environment, simulating execution of suspicious programs, and using forensic tools to extract and interpret Prefetch artifacts.

I built a Windows 11 virtual machine in VMware Workstation to act as the analysis environment. The VM simulates a typical workstation where Prefetch artifacts will be generated. To simplify the lab environment, I bypassed the Microsoft Account requirement during setup and created a local user account . This reflects realistic scenarios where corporate or lab machines may not be tied to cloud accounts.

I downloaded forensic tools such as PECmd (for parsing Prefetch files) and Timeline Explorer (for analyzing CSV logs). These tools provide structured access to the metadata stored inside .pf files. Instead of generating my own Prefetch data, I imported a dataset of Prefetch files. This ensured I had a controlled set of artifacts containing both legitimate and suspicious program executions.

Working with a prebuilt dataset allowed me to focus directly on the forensic analysis process, without spending time setting up custom executions. I collected the .pf files from C:\Windows\Prefetch\ and ran PECmd to parse them into CSV format. This revealed program execution metadata including filename, run count, first/last run times, and associated file paths.

I then opened the parsed dataset in Timeline Explorer , which allows filtering, sorting, and searching across Prefetch entries. This made it easy to identify unusual executables in the dataset. Within the dataset, I quickly identified a suspicious entry: BURPSUITE-PRO-CRACKED.EXE . Prefetch confirms this executable ran on the system.

The Prefetch metadata showed that the executable was run multiple times , not just once. This indicates persistence or repeated use, which increases its forensic significance. Prefetch preserves first run and last run times.

This allowed me to build a timeline of when BURPSUITE-PRO-CRACKED.EXE was executed, and to correlate those times with other events.

Using Timeline Explorer’s filtering, I looked at other processes executed around the same time as the cracked Burp Suite. This showed additional system activity that may be related, such as supporting utilities or scripts run by the attacker. 2. System Architecture & Core Working Principles This lab reinforced how Windows Prefetch artifacts can be leveraged during investigations: By working through this exercise, I practiced artifact-based DFIR analysis , which is a foundational skill for SOC analysts and forensic investigators.

Windows Prefetch is a performance feature that helps applications and operating system components load more efficiently. It can create .pf files under: For investigators, Prefetch is valuable because a Prefetch file can indicate that Windows observed an executable run. The filename usually includes the executable name and a hash-like value derived from path information. Parsed Prefetch data may include execution timestamps, run count, referenced files, volume information, and other metadata depending on Windows version and parser support.

Prefetch is one of the most useful execution artifacts on Windows workstations. It is less consistently useful on servers, systems where Prefetch is disabled, or systems where settings and storage behavior reduce Prefetch creation. Windows created Prefetch for performance, not forensics. The operating system observes application startup behavior and records information that can help future launches load faster.

Related Windows performance features have changed naming and behavior over time. SuperFetch became SysMain in later Windows versions. Investigators should verify system configuration before relying heavily on Prefetch absence. The forensic benefit is incidental: when Windows creates or updates a Prefetch file, investigators may gain evidence that an executable ran and which files were referenced during startup.

Prefetch helps answer one of the most important DFIR questions: did this executable run on this host? Prefetch is often the bridge between "the file existed" and "Windows likely executed it." The executable name is visible. The hash-like value helps distinguish different execution paths for files with the same name. Prefetch may list files accessed during application startup. These references can support context but should not be treated as proof that the user opened each file intentionally.

Windows version and configuration affect what is present. Parser output should be interpreted with the target operating system in mind. Prefetch does not identify user intent. It also does not classify the file as malicious. Prefetch often provides quick value during triage because suspicious .pf filenames stand out.

No .pf file does not prove the program did not run. Always check system settings, collection scope, operating system type, and alternative execution artifacts. Run count is useful, but it should be treated with care. Windows version behavior, maintenance, and parser interpretation can affect what the investigator sees.

Referenced files may be loaded during program startup. They are context, not direct proof of user-opened documents. setup.exe , svchost.exe , and update.exe can exist in many paths. Use Prefetch hash, MFT data, Amcache, event logs, and EDR telemetry to identify the actual path. Use Prefetch as strong execution-related evidence when present, but do not let one artifact carry the entire conclusion.

Open a file with PrefetchFile.Open(path) (or PrefetchFile.Open(stream, name) ) to get an IPrefetch with the header, run times and run count, loaded files, and volume information. Windows 10/11 compressed (MAM) files are decompressed with a built-in managed XPRESS Huffman decoder, so every version can be parsed on any OS. Open throws PrefetchParseException when the data is not a prefetch file or can't be decompressed. Corruption after that does not throw: the damaged sections are left empty, and ParseErrors lists what went wrong.

PrefetchHash.Calculate(devicePath, version) computes the hash Windows uses in prefetch file names, so a loaded file path can be checked against Header.HashValue . Windows Prefetch parsing tools compared — PECmd, WinPrefetchView, and browser-based parsers PECmd, WinPrefetchView, libscca, and online parsers — what each one is good at, what it misses, and when to reach for which.

EnablePrefetcher=0, deleting .pf files, the rename-before-run trick. A practitioner's view of which attacks against Prefetch work and which leave a trail you can follow. The Windows Prefetch is the most reliable proof-of-execution artifact you'll see in DFIR — but only if you understand what it doesn't say. A practitioner's view on .pf files.

Prefetch is off by default on Windows Server, controlled by registry, and tied to the SysMain service. Here is what governs it and how to verify state on a live system. SCCA, MAM compression, sections A through D, and the version field. A practitioner's walkthrough of how .pf files have changed from XP to Win11, and which parsers keep up.

The Prefetch load list is the part most analysts skim. It's also where DLL hijacks, malware configs, and document opens hide in plain sight. A practical guide. Prefetch is the strongest single proof-of-execution artifact in Windows DFIR. Here's where the claim is solid, where it breaks, and how to corroborate it with EVTX 4688 and Sysmon.

A fictional but realistic ransomware case rebuilt from Prefetch. The eight timestamps, the encryptor's load list, lateral-movement tools. How the .pf files tell the story. SuperFetch became SysMain in Win10 1709. Prefetch is partly disabled on SSDs. Here's what the registry knobs actually do, and what to verify before trusting a .pf file.

Attackers delete, plant, and falsify .pf files to obscure execution evidence. Here is how to spot the common signs and what each one tells you. A practical step-by-step guide to reading .pf files for execution evidence — what to look for, what to ignore, and how to corroborate findings.

Three Windows artifacts record program execution. They overlap, but each one captures something the other two miss. Here is when to reach for which. 3. Software Implementation, Frameworks & Protocols The SCCA version field is the single most useful number in a prefetch file. Here is what each version means and what to watch for when parsing v30 (Win10) and v31 (Win11).

Modern .pf files start with a MAM signature and an Xpress Huffman compressed payload. Here is how the framing works, why it was introduced, and what a parser has to do to read it. The 8-character suffix in every .pf filename is a path-derived hash, and the algorithm has changed three times. Here is what it computes and why it matters for forensics.

What .pf files record, why they matter, and how this parser reads them entirely in your browser. Synthetic prefetch files from a fictional intrusion (host FIN-WKS-07) — no real data. Tip: click M64.EXE's last-run time to see what else ran within ±5 minutes. Windows, elevated prompt: right-click Command Prompt or PowerShell → Run as administrator . Nothing to install.

Prefetch files are not locked, so a plain elevated copy is complete — no shadow copy needed. Robocopy exit code 1 means "files copied". Then drop C:\triage\Prefetch on this page. Run as administrator on the host. KAPE and Velociraptor are free downloads from their publishers. Drop the whole C:\triage\kape folder (it contains C\Windows\Prefetch\ ). Add --vss to also pull Prefetch from shadow copies.

Already ran KapeTriage or !SANS_Triage ? They include Prefetch — drop that collection folder or ZIP. Velociraptor — offline collector with the Windows.Triage.Targets artifact (Velociraptor Triage project) and the Prefetch target (formerly Windows.KapeFiles.Targets on older releases): Server Artifacts › Build offline collector › Windows.Triage.Targets › Targets: Prefetch › Launch Run the collector as administrator on the host, then drop the resulting collection ZIP as-is. With a Velociraptor server, collect Windows.Triage.Targets → Prefetch from the client in the GUI and download the collection ZIP instead.

Windows.Forensics.Prefetch parses on the endpoint and returns rows, not .pf files. File › Add Evidence Item › Image File › [root]\Windows\Prefetch › right-click › Export Files… Image mounted read-only (Arsenal Image Mounter, ewfmount + ntfs-3g , …) — copy the folder: Replace 1 in HarddiskVolumeShadowCopy1 (and vss1 ) with a number from the vssadmin list; repeat per snapshot. .pf files overwritten since the snapshot survive there. Drop the Prefetch-vss* folders together with the live one: identical files are skipped, older versions are grouped under the same executable.

Nothing else is needed — each .pf is self-contained. Layout.ini , Ag*.db and ReadyBoot\ sit in the same folder and are skipped with a reason, so just drop the whole folder or ZIP. Windows 8+ keeps up to 1,024 .pf files (128 before) and 8 run times per file (1 before 8.1). Windows 10/11 files are MAM-compressed: drop them unmodified, they are decompressed in your browser.

EnablePrefetcher : 0 = disabled, 3 = applications and boot (workstation default). Prefetch also stops when the SysMain service is not running, and is off by default on Windows Server. Did it run, when, how often and from where — answered from the .pf files, without installing anything. All prefetch files of a program — different paths, hashes, shadow copies — collapse into one row with a combined run count.

Every launch slot Windows keeps (one before 8.1, eight since), in UTC, merged and de-duplicated across files. Folders and KAPE / Velociraptor ZIPs are searched for .pf files; anything skipped comes with the reason why. SCCA versions 17, 23, 26, 30 and 31. Windows 10/11 MAM-compressed files are decompressed in the browser. Device path, serial number and creation time of each volume, plus every DLL and file the program touched — all searchable.

A Rust parser compiled to WebAssembly runs in a Web Worker. No server, no upload; export everything as JSON. Each analysis is auto-saved in your browser (IndexedDB). Name it to keep it; resume, rename or delete saved sessions later. Drop a .pf file or the whole C:\Windows\Prefetch\ folder on this page. The parser runs entirely in your browser: A Rust prefetch decoder compiled to WebAssembly decompresses and parses each file inside a Web Worker.

Results render as a sortable, searchable table. Click any row to see all run times, volumes, and referenced files. Windows Prefetch ( .pf ) is a per-executable cache that Windows writes to C:\Windows\Prefetch\ every time a program is launched. Each file records what the program touched on its first run — the libraries it loaded, the volume it ran from, and how often it has been executed. For digital forensics, prefetch is one of the most reliable execution artifacts available: a program does not need to be installed or still present on disk to leave a .pf entry behind.

C:\Windows\Prefetch\ — typically several hundred .pf files on any active workstation. The folder is restricted but readable by administrators. Prefetch is enabled by default on workstation editions of Windows; on Windows Server it is often disabled. The hash at the end of each filename ( NAME-XXXXXXXX.pf ) is derived from the full executable path as a UTF-16 string. Two copies of the same binary launched from different directories produce two different .pf files. The algorithm changed between Windows XP/Vista and Windows 7+ ( SuperFetch hash).

From Windows 8 onward, the OS compresses prefetch files with the Xpress Huffman algorithm and prefixes them with the MAM\u00104 signature. This parser decompresses them transparently — you don't need to pre-process anything before dropping the folder. Yes — Windows only writes a .pf file after the executable actually runs. However, run counts and timestamps can be tampered with (e.g., by deleting prefetch files), and a missing entry does not prove a program never ran if .pf files were wiped post-execution. Combine with Amcache, ShimCache, and event-log data for corroboration.

No. The parser compiles a pure-Rust prefetch decoder ( frnsc-prefetch ) to WebAssembly and runs it inside a Web Worker in your browser. Bytes never leave your machine. There is no backend, no telemetry on file contents, and no upload. All SCCA versions from Windows XP through Windows 11: v17 (XP/Vista/7, uncompressed), v23 (Win8), v26 (Win8.1), v30 (Win10), and v31 (Win11). Both compressed and uncompressed prefetch files are detected automatically.

4. Practical Deployment, Analysis & Case Studies This is the fourth blog post in a series of five about recovering Business Applications & OS Artifacts for your digital forensics investigations. Prefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system.

Windows creates a prefetch file when an application is run from a particular location for the very first time. This is used to help speed up the loading of applications. For investigators, these files contain some valuable data on a user’s application history on a computer. Evidence of program execution can be a valuable resource for forensic investigators. They can prove that a suspect ran a program like CCleaner to cover up any potential wrongdoing.

If the program has since been deleted, a prefetch file may still exist on the system to provide evidence of execution. Another valuable use for prefetch files is in malware investigations which can assist examiners in determining when a malicious program was run. Combining this with some basic timeline analysis, investigators can identify any additional malicious files that were downloaded or created on the system and help determine the root cause of an incident.

Prefetch files are all named in a common format where the name of the application is listed, then an eight-character hash of the location where the application was run, followed by the .PF extension. For example, the prefetch file for the application Snipping Tool (SNIPPINGTOOL.EXE) would appear as SNIPPINGTOOL.EXE-9A9B0B31.pf, where 9A9B0B31 is a hash of the path from where the file was executed. These files are all stored in the ROOT/Windows/Prefetch folder.

Beyond the name and path mentioned previously, prefetch files contain details on the number of times the application has been run, volume details, as well as timestamp information detailing when the application was first and last run. For Windows 8+, prefetch files contain up to eight timestamps for when an application was last run, giving investigators several additional timestamps to help build a timeline of events on a system.

The location of the executable can be just as important as any timestamp data. Most seasoned malware investigators can recognize the added concern of a known file executing from a temp folder, versus a more legitimate location such as the Windows\system32 folder. Prefetch files also can exist after the original application (or its parent directory) has been deleted. Although the hashing algorithm for the parent directory was changed after Windows 8, making hash reversal difficult, it can still be a useful tool in identifying other applications that were run from the same deleted directories. In cases such as computer intrusion or malware, this can potentially identify other malicious applications.

Magnet Axiom parses out prefetch files from all versions of Windows into a separate artifact category for quick locating and review . The below screenshot (f rom a parsed Windows 11 image) shows a search result for a prefetch artifact (same SNIPPINGTOOL . EXE file referenced and shown above). However, Magnet A xiom has collected and organized the timestamps and additional details contained in the prefetch file, plus reported them to the investigator in an easy-to-read format : By adding these timestamps to our prefetch analysis, investigators can use the Axiom Timeline feature to map out the applications that a suspect has run on a system over a given time or identify any malicious executables that might have run during an incident.

Prefetch files are just one of many Windows OS artifacts that help investigators understand what a user was doing on a system at a particular time. All Windows OS artifacts should be examined together to uncover the bigger picture of an incident or investigation. Complete the company & contact information form below and sales will be in touch with you shortly.

Complete the company & contact information form below and sales will be in touch with you shortly. Windows Prefetch is the single most widely used program-execution artifact in DFIR, and for good reason. Every time an executable launches on a Windows workstation, the operating system records a small file under C:WindowsPrefetch that captures the program’s name, a hash of the full launch path, the number of times it has run, and a rolling history of the most recent execution timestamps. For a SOC analyst or forensic examiner answering the core question “what ran on this host, and when”, Prefetch is usually the first place to look.

The artifact exists for performance, not security. Windows uses it to pre-load the pages and dependencies a program needs so it starts faster on subsequent launches. That side-channel of execution metadata is what the defender harvests. Because Prefetch is generated automatically by the OS for nearly every interactive and many non-interactive process launches, it produces evidence even when an attacker deleted the original binary, cleared the event logs, or never triggered any other artifact.

This article treats Prefetch from the perspective of an incident responder. We cover where the files live, how Forenza decodes them natively, the normalized record and summary fields the parser produces, the per-version on-disk layout that drives the timestamp extraction, the forensic significance of run counts and last-run times, the adversary tradecraft a defender hunts for, Sigma and KQL scaffolding, the Forenza DQL rules that run against parsed records, correlation with neighbouring artifacts, the noise model, and the three Forenza collection paths.

A crucial modern caveat: from Windows 10 build 1607 onward, Prefetch files are MAM-compressed (Xpress-Huffman). Forenza’s native parser decodes the uncompressed SCCA generations (Windows XP, 7, 8, 8.1) directly and detects the compressed Windows 10/11 format explicitly so the dispatcher can route it through decompression rather than failing the job. We call this behaviour out where it matters.

The discussion assumes Prefetch is enabled. On SSD-equipped systems and on Windows Server, Prefetch may be disabled or limited by default, which is itself a fact the examiner must establish before reasoning about the absence of a .pf file. A Prefetch file is a per-application performance-cache file written by the Windows Cache Manager and the SuperFetch / SysMain service. Each file is named after the executable plus an eight-hex-digit hash of the path and command context, for example POWERSHELL.EXE-AE8EE1FF.pf . The hash means the same executable launched from two different paths produces two distinct .pf files, a property that lets a defender distinguish a legitimate svchost.exe in System32 from a masquerading copy elsewhere.

Internally, the file begins with a version code and an SCCA signature (or a MAMx04 signature on compressed Windows 10/11 files), followed by the executable name as UTF-16, the path hash, the file size, and a set of metrics including the total run count and a small array of recent run timestamps stored as Windows FILETIME values. Windows 8 and later retain the last eight execution timestamps per file; earlier versions retain only the single most recent.

Prefetch answers three questions with high reliability: did this program ever run on this host (the file exists), how many times has it run (the run-count field), and when did it last run (the most recent FILETIME). On Windows 8 and later it additionally answers when it ran on each of the last several occasions, enabling a coarse execution chronology from a single file. The file does not record the user who ran the program, the command-line arguments, or the parent process; those require correlation.

The directory holds at most 1024 .pf files on modern Windows (128 on Windows XP/7), after which the least-recently-used files are evicted. This cap means a busy host continually ages out old Prefetch files, so the absence of a .pf for a program that ran weeks ago is not necessarily anti-forensic; it may simply have been evicted. The examiner reasons about presence and recency, not about exhaustive history.

The Forenza catalog binds artifact ID execution.prefetch to a recursive walk of {windir}/Prefetch with the *.pf file mask, so a single artifact run yields one parsed result per .pf file found. The {windir} placeholder resolves to the Windows directory of the target (default “Windows”), which the path resolver determines from the accessor in image-mode and offline collection. When a process starts, the Windows Cache Manager monitors the first ten seconds of execution, recording which files and pages the process references. The SysMain service then writes (or updates) the .pf file for that executable, encoding the referenced-file list (used for pre-loading) along with the metadata block of interest to forensics: the run count, incremented on each launch, and the run-time array, into which the current launch time is inserted as a FILETIME.

The write is not instantaneous. Windows updates the .pf file a few seconds after the program launches, and the last-run timestamp it records reflects the launch time, not the write time. There is also a long-standing quirk that the recorded last-run time can lag the actual launch by up to roughly ten seconds because of when the metadata flush occurs. A defender doing fine-grained timeline work should treat the Prefetch last-run as accurate to within a few seconds rather than as a precise launch instant.

The path-hash component of the filename is computed from the full path of the executable and, in some Windows versions, additional context. The practical consequence for a defender is that running the same-named binary from a different directory yields a different .pf filename and a fresh run count. This is how Prefetch exposes masquerading: a legitimate Windows binary name running from a non-standard path produces a distinct, suspicious .pf file with its own low run count.

The Forenza PrefetchParser decodes the .pf bytes through the native prefetch package and emits a per-file summary plus a flattened list of run-time records. The summary carries the file-level metadata; the records flatten the last-run plus historical-run timestamps into ranked rows (rank 1 is the most recent). The normalized field names below are exactly what the parser writes.

When the parser encounters a Windows 10/11 MAM-compressed file, it does not crash the run. The native decoder returns a “compression not supported” soft error, the parser records it in the summary’s error field alongside source_path , and the dispatcher marks the artifact as parsed-with-diagnostics. The same soft-error handling applies to short buffers and bad signatures, so a single corrupt .pf in a directory of hundreds does not poison the whole scan.

The .pf binary layout differs per Windows generation, and the version code in the header (offset 0) selects which offset table the decoder uses. The table below documents the generations Forenza’s native decoder recognizes and where each finds its run count and run timestamps. The practical upshot for a defender: on a Windows 8 or 10/11 host, a single .pf file can yield up to eight execution timestamps, giving a coarse but genuine chronology of when a program ran. On Windows 7 you get only the most recent run from the file itself, and the run count must carry the rest of the story.

The JSON below is a representative Forenza-parsed result for a single Windows 8/10-class .pf file. It depicts POWERSHELL.EXE with a run count of 14 and four retained execution timestamps, the most recent of which is surfaced both in the summary last_run and as the rank-1 record. From this single file an examiner reads: PowerShell launched 14 times in total, most recently at 08:41 UTC on 30 May, with three earlier retained launches spanning the prior 13 hours. Pairing the path hash AE8EE1FF against the expected hash for C:WindowsSystem32WindowsPowerShellv1.0powershell.exe confirms (or refutes) that this is the legitimate system PowerShell rather than a copy run from elsewhere.

Prefetch is the canonical answer to “what executed on this host”. Its run-count and last-run fields establish both that a program ran and roughly when, and the path hash exposes execution from non-standard locations. Because Windows generates Prefetch automatically and stores it system-wide, it routinely survives the deletion of the original binary: a .pf file for a tool that no longer exists on disk is direct evidence that the tool ran and was subsequently removed, a textbook indicator-removal pattern.

The eight-timestamp history on Windows 8 and later turns a single file into a mini-timeline. An examiner can see whether a tool ran once or repeatedly, and whether its executions cluster around the suspected intrusion window. Run count plus timestamp spread distinguishes a one-time reconnaissance tool from an interactively-reused utility, which informs whether the host was a beachhead or a sustained operating position.

Prefetch is also a high-value source for living-off-the-land detection. The presence of .pf files for powershell.exe , cmd.exe , wmic.exe , rundll32.exe , regsvr32.exe , mshta.exe , certutil.exe , bitsadmin.exe and similar binaries, especially with elevated run counts or non-standard path hashes, maps directly onto the LOLBin tradecraft that dominates modern intrusions. The artifact does not tell you the arguments, but it tells you the tool was used and when, which is enough to pivot.

The following detection priorities are ordered for a defender working Prefetch records. Each is framed as something a SOC analyst looks for in parsed Prefetch and is mapped to the relevant MITRE ATT&CK technique. 5. Performance Evaluation & Extended Technical Observations Prefetch is a file artifact, so SIEM detection fires against parsed Prefetch records once collected and indexed. The Sigma rule below targets the high-fidelity case of a known LOLBin executing from an unexpected path hash, expressed against parsed Prefetch fields.

For Microsoft Sentinel or any KQL-capable backend, the equivalent query is below. It assumes parsed Prefetch records are available in a custom table (here ForenzaArtifact_CL ) and flags LOLBin executions with a recent last-run. Forenza ships its own SQL-derived DFIR Query Language (DQL), designed and developed in-house by the Forenza team, for incident-response queries against parsed artifact records and the unified timeline. Queries target the artifact_results table (per-case parsed records) or evidence_unified_timeline (cross-artifact correlation) and use JSONB field accessors ( normalized->>'field_name' ) against the canonical normalized column populated by the parser. DQL is submitted to POST /api/v1/query/run and executes server-side under tenant-scoped row-level security.

The first DQL example surfaces living-off-the-land binary executions recorded in Prefetch for a single case, ordered by most recent run. Note that Prefetch summary fields ( executable , run_count , last_run ) are carried in the same normalized object as the per-run records: The second DQL example hunts for first-time executions inside a time window across the whole tenant. A run count of 1 with a recent last-run is a fresh execution worth examining: The third DQL example detects same-named binaries that present multiple distinct path hashes across the estate, the Prefetch signature of name-based masquerading. A system binary name that appears under more than one prefetch_hash warrants a look at where each copy ran: The response carries columns , rows , row_count , execution_ms and a routing flag. Queries against artifact_results are always routed server-side; agent-bound DQL (live process or file hunting) is the alternate path that fans out to the agent fleet.

To register a recurring detection rather than a one-shot query, wrap the same DQL in a detection-rule definition and POST it to the detection service. The rule fires on every newly persisted Prefetch record matching the predicate and lands a row in findings at the configured severity: Forenza captures Windows Prefetch through three operator-facing collection paths: the web interface driving a deployed live agent, the standalone offline collector binary for hosts where an agent cannot be installed, and image-mode triage against a previously acquired disk image. All three paths feed the same PrefetchParser , persist identical rows into artifact_results , and surface Prefetch records to the same UI and DQL queries. The choice is operational, not analytical.

The web UI is the everyday collection path for incident response on agent-managed hosts. The operator never leaves the browser. When the suspect host has no Forenza agent (an isolated DMZ server, an OT operator console, a third-party-managed laptop, an air-gapped environment, or a host where deploying the agent would tip off an adversary), the standalone forenza-collector binary takes its place. The collector is a single-file, no-dependencies executable built per platform (Windows, Linux, macOS) and signed by the Forenza release pipeline.

When the source is a disk image already in evidence storage (E01, EX01, raw .dd / .img , VHDX, VMDK, AFF4-Logical, multi-segment EWF), Forenza skips both the agent and the offline collector and reads the bytes directly from the image. The operator creates the case with Disk Image as the workspace mode, attaches the relevant evidence_packages row instead of an agent-managed host, then proceeds identically through artifact selection, run and inspection.

Under the hood, Forenza’s accessor chain resolves the artifact path inside the image. Because Prefetch is a Windows filesystem artifact, the chain is file:// to open the container, then ewf:// or vhdx:// or vmdk:// to decode the disk format, then volume:// with a partition index to reach the Windows volume, then ntfs:// to mount the NTFS filesystem read-only, and the path resolver walks Windows/Prefetch for every *.pf file. (Linux images use the ext4:// , xfs:// or btrfs:// accessors and macOS images use apfs:// or hfs:// , but Prefetch is Windows-only, so those filesystems are relevant only when the same case mixes platforms.) The same PrefetchParser consumes the bytes and produces identical artifact_results rows, so the DQL detection rules above run unchanged against image-derived data.

Windows Prefetch is the workhorse of program-execution forensics. From a single small file an examiner learns that a program ran, how often, when most recently, and (on Windows 8 and later) on each of its last several launches, with the path hash exposing execution from non-standard locations. Because Windows generates it automatically and system-wide, Prefetch routinely outlives the binaries it describes, making it a reliable witness to run-then-delete tradecraft and living-off-the-land tooling alike.

The artifact’s limitations (no arguments, no user, eight-timestamp ceiling, LRU eviction, and Windows 10/11 compression) mean it is most powerful in correlation rather than in isolation. Joined to ShimCache, Amcache, UserAssist, 4688 and Sysmon 1, a Prefetch last-run becomes a fully contextualized execution event with a command line, a principal and a place. Collected through any of the three Forenza paths and queried through DQL, Prefetch anchors the “what ran here” question that nearly every Windows intrusion investigation must answer.

Amcache.hve is one of the richest program-execution and binary-inventory artifacts on a Windows host, and a staple of every intrusion timeline a… The Background Activity Moderator (BAM), together with its sibling the Desktop Activity Moderator (DAM), is a Windows service whose registry footprint is… The PowerShell ConsoleHost_history.txt file is one of the highest-signal execution artifacts on a modern Windows host, and it is created almost entirely… One short email when a new case writeup or detection deep dive ships. No marketing drip, no third-party tracking.

The Crow-Eye Prefetch Analyzer is a Python-based command-line tool designed for forensic analysis of Windows prefetch files (.pf) to extract execution metadata, such as executable names, run counts, last execution timestamps, and referenced resources. It supports both live and offline analysis, with output options in SQLite, JSON, or CSV formats. Features Parses Windows Prefetch Files: Extracts metadata from .pf files, including executable name, hash, run count, execution timestamps, volumes, directories, and resources. Live and Offline Analysis: Live: Analyzes C:\Windows\Prefetch. Offline: Analyzes a user-specified directory containing .pf files.

Output Formats: Saves parsed data to SQLite database, JSON, or CSV files with customizable output paths. Performance Optimization: Uses multiprocessing for faster parsing of multiple files. Progress Tracking: Displays a progress bar with the current file being processed. Error Handling: Logs parsing errors and high run counts to prefetch_analyzer.log. File Validation: Checks for minimum file size (84 bytes) before parsing. Static Logo: Displays an ASCII logo once at startup, with no screen clearing to keep output visible. Number-Based Navigation: Uses numbers (1-4) for menu selections. Run Count Behavior: Logs run counts exceeding 1,000,000 to prefetch_analyzer.log for analysis, as these may indicate parsing errors or Windows-specific quirks. The tool emphasizes the last execution timestamp for reliable analysis.

Operating System: Windows (due to prefetch file access and decompression requirements). Python: Version 3.8 or higher (tested with Python 3.12). Administrative Privileges: Required to access C:\Windows\Prefetch. Dependencies: sqlite3 (for SQLite output) tqdm (for progress bar) Download and install Python 3.8+ from python.org. Ensure pip is included in your Python installation.

Save the script as cli_prefetch_parser.py in your desired directory (e.g., E:\prefetch analysis). The script automatically checks for and installs sqlite3 and tqdm if missing. If automatic installation fails, install manually:pip install tqdm Open a PowerShell or Command Prompt as an administrator. Navigate to the script's directory (e.g., E:\prefetch analysis).

Execute the script:& C:/Users/YourUsername/AppData/Local/Microsoft/WindowsApps/python3.12.exe "E:/prefetch analysis/cli_prefetch_parser.py" The ASCII logo displays once at startup and remains visible. Choose an option by entering a number (1-4): The script displays a tqdm progress bar showing the current .pf file being processed. After completion, it shows the percentage of successfully parsed files. Errors and high run counts are logged to prefetch_analyzer.log in the script's directory.

Observation: The run count in prefetch files often shows unusually large numbers (>1,000,000), which may result from parsing errors, file corruption, or Windows prefetch behavior (e.g., counter overflows or system-specific quirks). Current Approach: The script logs high run counts to prefetch_analyzer.log for further analysis but does not cap them. Analysis focuses on the last execution timestamp (last_executed in output) to provide reliable execution timing data. Log File: Check prefetch_analyzer.log for entries like:2025-07-12 02:34:56,789 - WARNING - High run count (1200000000) in filename.pf, potential parsing error SQLite: Stores data in a database (prefetch_data3.db or custom path) with columns for filename, executable name, hash, run count, last executed timestamp, run times, volumes, directories, resources, and file timestamps. JSON: Saves data as a JSON array of objects (prefetch_data.json or custom path). CSV: Saves data as a table (prefetch_data.csv or custom path) with the same fields as SQLite. Log File: prefetch_analyzer.log contains errors and high run count warnings.

Run the script as administrator:& C:/Users/Ghass/AppData/Local/Microsoft/WindowsApps/python3.12.exe "E:/prefetch analysis/cli_prefetch_parser.py" Current output format: SQLITE (prefetch_data3.db) Enter a number (1-4) to select an option: Enter 1 for live analysis. View the progress bar and output:Processing 123 prefetch files... Parsing Files: 100%|IIIIIIIIII| 123/123 [00:05<00:00, 24.60file/s, file=Done] Percentage of Successfully Parsed Files: 98.37% Parsing errors logged to prefetch_analyzer.log Press Enter to continue...

Permission Denied: Ensure the script is run as an administrator. Missing Dependencies: If tqdm installation fails, run pip install tqdm manually. Invalid Directory: For offline analysis, verify the directory exists and contains .pf files. High Run Counts: Review prefetch_analyzer.log for files with run counts >1,000,000 and focus on the last_executed timestamp for reliable data. Errors: Check prefetch_analyzer.log for parsing or decompression errors.

The script requires Windows for prefetch decompression (Windows 10/11 files use XPRESS Huffman compression). Run counts may appear inflated due to prefetch file structure or system behavior; the last execution timestamp is typically more reliable for forensic analysis. For large directories, multiprocessing may increase memory usage. Adjust the number of processes in the Pool if needed (e.g., Pool(processes=4)).

Harvested Online Documentation & Reference Sources • https://www.prefetchparser.com/en/blog/how-to-analyze-prefetch-files • https://www.decryptiondigest.com/blog/how-to-analyze-windows-prefetch-files-for-forensics • https://github.com/RyanFeneley/DFIR-Lab-Docs • https://yasir-alharbi.github.io/windows-forensic-artifacts-handbook/chapters/05-chapter-5-windows-prefetch/ • https://github.com/EricZimmerman/Prefetch • https://www.prefetchparser.com/en/blog • https://www.prefetchparser.com/en • https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/ • https://forenza.io/execution-prefetch/ • https://github.com/Ghassan-elsman/Prefetch-Parser-CLI