In this section
Prefetch Forensic Analysis: PECmd, Execution Timestamps, DLL Load Patterns
Prefetch is the strongest single filesystem artifact for proving program execution on a Windows workstation.
Scenario
Your KAPE triage produced a Prefetch directory with 847 .pf files. The Security event log retained only 36 hours of data, but the EDR alert timeline suggests the compromise started five days ago. Prefetch reaches back further than any event log on this system. You need to find the attacker's tools, determine when they first executed, and classify what each binary does before the Amcache hash results come back.
Every time an executable runs on a Windows workstation, the Prefetch subsystem creates or updates a .pf file in C:\Windows\Prefetch\. The OS uses these files to speed up application loading by pre-caching code pages. Forensically, each .pf file records the executable name, a hash of its launch path, the last 8 execution timestamps (Windows 8+), the total run count, and every file and DLL the program loaded during approximately the first 10 seconds of its most recent execution. The filename format is {EXECUTABLE}-{HASH}.pf, where the hash is computed from the executable's path. The same binary run from two different directories produces two separate .pf files with different hashes.
Estimated time: 40 minutes.
Evidence location and availability
Before starting Prefetch analysis, confirm the artifact exists on the target system. Check the EnablePrefetcher registry value in the collected SYSTEM hive.
Windows Server. Prefetch is disabled by default on Server 2012 and later. If the target is a server, plan execution analysis around event logs, SRUM, and Amcache instead.
Disabled by policy. Some hardening guides recommend disabling Prefetch. Note that Prefetch is not disabled on SSDs. Microsoft kept it enabled on Windows 8+ regardless of disk type.
Attacker cleanup. A sparse Prefetch folder (under 100 entries on a workstation running for months) indicates cleanup. Deleted .pf files still have MFT entries that MFTECmd can recover.
Capacity eviction. A full folder (1,024 entries) means older entries have been pushed out. If the compromise predates the oldest entry, the attacker's initial tools may have been evicted by normal system activity. Check MFT for deleted .pf entries.
Parsing with PECmd
# Parse entire Prefetch directory to CSV
PECmd.exe -d "E:\Evidence\C\Windows\Prefetch" --csv "E:\Processed" --csvf "prefetch.csv"
# Parse a single file with full verbose output
PECmd.exe -f "E:\Evidence\C\Windows\Prefetch\SVCHOST.EXE-E1C4A2B8.pf"If KAPE ran with !EZParser, the CSV already exists in your processed output. Open it in Timeline Explorer.
Reading PECmd output
Annotated entry from a compromised workstation. A binary named svchost.exe ran once from C:\Users\Public\ at 03:14 UTC.
Path mismatch. SVCHOST.EXE from C:\Users\Public\ is not the Windows Service Host. The legitimate copy runs from System32 with path hash 3530F672. This entry has hash E1C4A2B8 because it ran from a different directory. Two Prefetch files with the same executable name and different hashes always warrants investigation.
Run count of 1. System processes run hundreds or thousands of times. A single-use executable during the attacker's activity window is a tool that was deployed, used once, and abandoned.
DLL profile. The legitimate svchost.exe loads service management DLLs: RPCRT4.DLL, OLE32.DLL, COMBASE.DLL. This binary loaded SAMLIB.DLL, VAULTCLI.DLL, WDIGEST.DLL, DPAPI.DLL. That DLL combination is Mimikatz. The filename is a lie. The DLL dependencies are not.
Triage method: finding suspects in 847 entries
Do not scroll through Prefetch results looking for suspicious names. That only catches the attacker who did not rename their tools. Apply three filters in sequence.
Filter 1: Activity window. Sort by LastRun. Filter to the 24 hours around your alert timestamp. On this workstation, 847 entries drop to 31.
Filter 2: Run count. Within that window, filter to RunCount = 1. Every system service and installed application drops out. Remaining: 4 entries.
Filter 3: Path hash duplicates. Back to the full 847. Group by ExecutableName. Look for the same name with different path hashes. One copy with a high run count (legitimate, running from System32). One copy with a low run count from a non-standard path (attacker staging directory).
The following example demonstrates the filtered result from this workstation.
SVCHOST.EXE-E1C4A2B8.pf 03:14 UTC RunCount 1 C:\Users\Public\
UPDATE.EXE-7A3B2C1D.pf 03:17 UTC RunCount 1
PROCDUMP64.EXE-1B4C3E5F.pf 03:24 UTC RunCount 1
7ZA.EXE-92F4D1B3.pf 03:38 UTC RunCount 1
RCLONE.EXE-8D2F6A4C.pf 03:41 UTC RunCount 1Five tools, all single-use, all within a 27-minute window (03:14 to 03:41). The sequence reads as a complete attack chain: credential access (renamed Mimikatz), unknown second tool (needs Amcache hash in WF2.3), process dumping (likely targeting LSASS), archiving (staging data for exfil), exfiltration (rclone). You have gone from 847 entries to a five-tool shortlist.
Anti-Pattern
Starting Prefetch analysis by searching for known-bad names like "mimikatz" or "cobalt." That catches only the attacker who did not rename their tools. The three-filter triage (activity window, run count, path hash duplicates) finds renamed tools, staged copies, and temporal clustering that name-based searches miss entirely.
DLL load patterns: classifying unknown binaries
The loaded files list is a behavioral fingerprint. The attacker controls the filename. They do not control which DLLs the binary needs to function.
The following DLL profiles identify common tool categories. When you encounter an unknown binary on the shortlist, check its loaded files list before waiting for the Amcache hash.
CREDENTIAL ACCESS
SAMLIB.DLL, VAULTCLI.DLL, WDIGEST.DLL, DPAPI.DLL, CRYPTDLL.DLL
Tools: Mimikatz, Rubeus, SharpDPAPI
NETWORK OPERATIONS
WINHTTP.DLL, WININET.DLL, DNSAPI.DLL, WS2_32.DLL
Tools: C2 implants, download cradles, exfiltration utilities
PROCESS MANIPULATION
DBGHELP.DLL, DBGCORE.DLL
Tools: procdump, MiniDumpWriteDump, comsvcs.dll abuse
SERVICE MANAGEMENT (legitimate svchost.exe)
RPCRT4.DLL, OLE32.DLL, COMBASE.DLL, SECHOST.DLL
Compare against attacker-renamed binaries using the same nameIf UPDATE.EXE on the shortlist loaded WINHTTP.DLL, DNSAPI.DLL, and BCRYPT.DLL, you are looking at a network-focused tool, likely a C2 implant or download cradle. If it loaded SAMLIB.DLL and VAULTCLI.DLL, you have a second credential access tool. The DLL profile narrows classification before you ever get the Amcache hash.
Timestamp patterns
The 8-timestamp array (LastRun plus PreviousRun0 through PreviousRun6) reveals what kind of operation you are investigating.
Single session. Three timestamps within an hour: 03:14, 03:47, 04:22. The attacker ran the tool three times in one session, probably iterating through targets. The gap before the first timestamp and after the last is your session boundary.
Persistent access. Three timestamps days apart: March 8, March 12, March 15. All overnight hours. The attacker returned on separate occasions with persistent access. This is not a single incident.
Automated execution. Eight timestamps at exactly 04:00 UTC on consecutive days. RunCount is 14, more than the 8 visible entries. This is a scheduled task or persistence mechanism. Check Task Scheduler artifacts and registry Run keys.
The run count resolves ambiguity. If RunCount matches the number of visible timestamps, you have the complete execution history. If RunCount is 47 and you see 8 timestamps, the earlier 39 executions are invisible.
Estimating first execution from the MFT
Prefetch records the last 8 runs and a total run count. It does not record when the executable first ran.
The .pf file's $FILE_NAME Created timestamp in the MFT approximates when Windows first created the Prefetch entry, which corresponds to the first execution (with up to 10 seconds of skew from the prefetcher's monitoring window).
For single-use tools (RunCount 1), this matches LastRun. For persistent tools (RunCount 47, only 8 timestamps visible), the MFT creation date tells you when the activity started. If the oldest visible Prefetch timestamp is March 1 but the MFT shows the .pf file was created February 14, the attacker has been on the system for a month.
# Search MFTECmd output for a specific Prefetch file
Import-Csv "E:\Processed\mft.csv" |
Where-Object { $_.FileName -eq "SVCHOST.EXE-E1C4A2B8.pf" } |
Select-Object FileName, FileNameCreated0x30, LastModified0x10, ParentPathThe following example demonstrates the expected output.
FileName FileNameCreated0x30 LastModified0x10 ParentPath
-------- ------------------- ---------------- ----------
SVCHOST.EXE-E1C4A2B8.pf 2026-03-15 03:14:16 2026-03-15 03:14:16 .\Windows\PrefetchFileNameCreated0x30 is the $FILE_NAME attribute creation timestamp. LastModified0x10 is the $STANDARD_INFORMATION modification timestamp, which updates on every execution. When these two values match, the tool ran exactly once. When they diverge significantly, the tool has been running repeatedly over time.
Before moving on, verify your understanding: parse the Prefetch CSV from your KAPE collection using all three filters. For each suspect, examine the FilesLoaded column and classify the tool category from the DLL profile. Cross-reference each suspect's .pf file against MFTECmd output to establish the first-execution timestamp. If your Prefetch folder has fewer than 100 entries, explain what that means and identify where to find the deleted .pf file records.
Next: WF2.3 covers the artifact Prefetch cannot provide. When the attacker deletes a binary after execution, Amcache holds the SHA1 hash that identifies what the tool actually was.