Detecting Windows Prefetch tampering

If prefetch is one of the best execution artifacts Windows produces, it is also one of the artifacts attackers most often try to scrub. A sophisticated intruder will rarely leave run counts and timestamps untouched. Here is how each common form of tampering looks under analysis.

Wholesale deletion

The crude approach: del /q C:\Windows\Prefetch\*.pf. The footprint is obvious — a busy workstation drops from hundreds of prefetch files to a few, all created very recently as the system runs after the deletion.

Signal: file count far below baseline for the OS version and the machine's age. A six-month-old workstation with twelve .pf files is suspicious.

Counter-analysis: prefetch files leave NTFS journal entries when deleted. Pull the $LogFile and $UsnJrnl and you may recover both filenames and timestamps of the deleted entries. The fact of the deletion is itself evidence.

Targeted deletion

More careful: delete only the .pf file for the malicious binary. Everything else looks normal.

Signal: a process you can prove ran (via Security 4688, Sysmon, or Amcache) has no corresponding prefetch entry on a host where prefetch is enabled. Targeted deletion can also be inferred when the directory's modification timestamp is suspiciously recent relative to its contents.

Counter-analysis: cross-reference Amcache and ShimCache to recover the missing path. Carve unallocated space on the system volume for .pf files; Xpress-compressed prefetch leaves a distinctive MAM\x04 header that's easy to scan for.

Planted prefetch files

Subtler: drop a prefetch file from another machine onto the target to create a false alibi (or, in red-team exercises, to test SOC detection).

Signal: the prefetch hash in the filename does not match what the hash algorithm produces for the executable path embedded in the prefetch payload. Recompute the hash on the parsed path and compare to the filename suffix — a mismatch is conclusive.

Other signs: NTFS file-record timestamps that disagree with the parsed prefetch contents; identical FILETIME values across "different" prefetch files (an attacker copy-pasted the same template).

Falsified run counts and timestamps

The most surgical attack: edit a real prefetch file in place to lower the run count or change the timestamps. This is rare because it requires understanding the format, but it does happen.

Signal: SCCA checksums (where present) fail. Timestamps that don't match the file's NTFS modification time. Run counts that drop between collections — Windows only ever increments, so a decrease means something else wrote the file.

Prefetch disabled

The pre-attack version: configure Windows so prefetch never creates files in the first place. See Prefetch on Windows Server and disabled configurations for what to look for in the registry.

Signal: PrefetchParameters\EnablePrefetcher = 0 in the registry on a workstation, where the default is 3. Combined with an empty Prefetch\ folder this is a strong indicator the system was pre-configured to suppress this artifact.

Putting it together

When prefetch evidence matters for a case, the question is rarely "did this file run". It's "can I trust what this prefetch entry says?" Treat the answer like any other piece of evidence: corroborate it. A single prefetch entry is a lead; a prefetch entry that agrees with Amcache, ShimCache, the Security log, and Sysmon is testimony.