Prefetch: Execution Evidence and Its Limits

If you’ve been following this series, you’ve already done the hardest part. You’ve stopped treating Windows artefacts as indicators that “mean” something, and started treating them as evidence that supports a narrow claim under specific conditions.

Prefetch is a stress test for that mindset.

It looks like an execution log. It’s easy to parse. It often gives you names, timestamps, and supporting context in one place. In triage, it can feel like a shortcut to conclusions.

It is not.

Prefetch answers a specific operating system question. If you keep your interpretation constrained to that question, it’s one of the most useful execution artefacts on a Windows client. If you expand beyond that question without corroboration, it becomes a reliable way to overstate your case.

This post is about that boundary.

We’ll stay focused on Windows 10 and 11 client endpoints, because that’s where most analysts are doing enterprise work today. I’ll reference older behaviour where it still shapes misconceptions.

I’m also going to avoid turning this into a parsing guide. Tools matter, but the failure modes are usually analytical, not mechanical. The goal here is disciplined interpretation.

What Question Prefetch is Actually Trying to Answer

Prefetch exists for performance, not forensics.

Windows wants to launch common applications quickly. To do that, it needs a prediction about what files an executable will touch during startup. Prefetch is one input into that prediction. The operating system observes early file activity (up to the first 10 seconds of execution) for a launched executable, records a summary, and uses it to optimise subsequent launches.

That intent is important because it constrains what you can reasonably infer.

Prefetch isn’t designed to capture user intent, program purpose, or downstream behaviour. It’s designed to improve the next launch of the same thing. That pushes it towards recording what’s useful for caching and layout, not what’s meaningful to an investigator.

From a DFIR perspective, Prefetch is best treated as evidence for one narrow claim:

A specific executable started on this system in this environment, and Windows observed enough of its early execution to create or update a Prefetch record.

That’s already valuable. It’s also narrower than how Prefetch is often used.

The Temptation: Treating Prefetch as an “IOC Substitute”

In many investigations, you’re asked a version of the same question:

Did this program run?

Sometimes that question sits underneath a larger claim: data theft, staging, persistence, lateral movement, tool execution. In the pressure of triage, analysts reach for artefacts that look binary. Prefetch often gets promoted to an IOC substitute because it appears to offer a yes/no answer with a timestamp attached.

The reasoning error is subtle.

You start with a legitimate observation, such as “a Prefetch file exists for X.” Then you slide, often unconsciously, into a stronger claim: X executed successfully, or X was used by the user, or X is the malware that caused the impact.

Prefetch can’t carry that weight on its own. It doesn’t record enough about intent, success, or downstream behaviour. It records that Windows observed an execution context consistent with creating or updating a Prefetch entry.

If you keep that distinction clear, you can use Prefetch well. If you don’t, you’ll produce confident-sounding findings that don’t survive scrutiny.

How Prefetch Behaves on Modern Windows Clients

On Windows 10 and 11 client editions, Prefetch is commonly enabled. It is not universal.

It can be disabled by configuration. It can behave differently depending on storage type and enterprise baselines. Typically, that means Prefetch is usually enabled on workstations (with spinning disks, not with SSDs), and it’s disabled by default on Server OSs.

You should treat “Prefetch is enabled” as an assumption that you verify, not a default that you rely on.

Creation, Update, and the “First Run vs Last Run” Trap

The basic lifecycle is straightforward.

On first observed execution of an executable in a given context, Windows creates a .pf file in C:\Windows\Prefetch. Subsequent executions update the same .pf file. This is why analysts often treat the Prefetch file’s timestamps as execution timestamps.

That’s mostly reasonable, with caveats.

The .pf file’s creation time typically aligns to the first time Windows created the Prefetch record, which is usually the first observed run. The modified time typically aligns to the most recent run that caused an update.

Those statements are intentionally constrained. They leave room for common edge cases.

If a Prefetch file is deleted, the next run of that executable will recreate it, and the creation time will reflect that recreation, not the true first time the executable ever ran on the host. That matters when you’re making “first seen” claims.

If timestamps have been manipulated, the file system times can be misleading. That’s not theoretical. Time stomping is a known anti-forensic technique, and Prefetch isn’t immune. This is one reason to cross-check with other artefacts that store independent time references.

Even without tampering, Prefetch timestamps can be slightly offset from the true process start time. Windows records the data after a short observation window; that same window from earlier, up to the first 10 seconds of execution. In practical terms, that means the recorded run time can lag actual start by seconds. This isn’t usually significant operationally, but it matters when you’re trying to align an execution chain precisely to other events in a tight timeline.

What Gets Recorded and When

Prefetch is heavily shaped by when Windows chooses to observe.

The operating system is primarily interested in startup behaviour. It records what files were touched early in execution, because those are the ones that affect launch time. It doesn’t aim to capture everything the process does over minutes or hours.

This is the first major interpretive boundary.

If you treat the Prefetch file list as “all files the process accessed,” you’ll be wrong. It’s closer to “a subset of file activity associated with startup and early execution.”

That distinction matters in investigations where you’re trying to prove that a program staged data, accessed a specific document, or opened a particular archive. If those actions occurred well after startup, they might not appear in Prefetch at all. If they occurred early, they might appear, but you still need to think carefully about what “appears in Prefetch” means. A file can be accessed by a dependency, a plugin loader, or framework code, not by user-driven interaction.

Prefetch also records a run count and a limited set of prior run timestamps on modern systems. That information is useful for reasoning about frequency and recency, but it doesn’t give you a full execution history. It’s a bounded window.

Capacity, Ageing, and Why “Not Present” Isn’t a Conclusion

On modern Windows clients, Prefetch storage isn’t infinite. There’s a cap on the number of Prefetch entries retained. Historically, Windows 7 retained fewer entries (128) than Windows 8 and later (1,024), and that legacy behaviour still influences how some analysts think about overwrite risk.

The practical lesson is consistent across versions: absence of a Prefetch file is not proof of non-execution.

A Prefetch record might not exist because Prefetch is disabled.It might not exist because the file was deleted. It might not exist because it rolled out as the Prefetch store filled. It might not exist because the execution context didn’t trigger normal Prefetch behaviour.

Your job isn’t to pick the most convenient explanation. Your job is to assess which explanation is plausible in the environment you’re investigating, and to corroborate.

If you’re working an enterprise incident, you should also think in baselines. On a typical Windows 10 or 11 workstation used daily, the Prefetch folder will usually contain a broad set of common applications. If the folder is empty, unusually small, or shows discontinuities, that’s a signal. It might indicate a build standard, a policy choice, a storage issue, or tampering. The signal isn’t “malware did it.” The signal is “this environment isn’t behaving like a typical Prefetch-enabled endpoint, so Prefetch-based conclusions require more caution.”

SSD, HDD, and Enterprise Configuration Choices

Prefetch originated in a world where disk seek and read patterns mattered more. SSDs reduce some of the performance value, and Windows has evolved its behaviour over time.

In practice, analysts still encounter three common realities on Windows 10 and 11:

• Some SSD-based endpoints still have Prefetch enabled and populated normally
• Some environments partially tune it, often in combination with related features such as SysMain
• Some enterprise images disable it entirely, sometimes based on legacy performance guidance, sometimes simply because “we’ve always done it that way”

You can’t infer which reality you’re in without checking the host configuration and observing the artefact population.

This is a useful habit to cultivate: before you treat Prefetch as evidence, confirm that Prefetch is a feature the host actually uses.

The Core Interpretive Distinctions

If this article had a single purpose, it’d be to make you slow down and separate three pairs of claims that analysts routinely collapse.

Execution vs Attempted Execution

A Prefetch record is best interpreted as evidence that Windows observed an executable starting under conditions that caused Prefetch creation or update.

That’s closer to execution than to mere presence, but it’s not a guarantee of successful, complete, or meaningful execution.

Programs can start and fail. They can crash early. They can be launched in a way that creates minimal startup activity. They can be blocked by controls after partial initialisation. They can be run in an environment that doesn’t generate Prefetch for that execution path.

Prefetch is evidence of observed start-up behaviour, not proof that the program achieved its objective.

When you write findings, be explicit about this. “Evidence that X executed” is defensible. “Evidence that X ran successfully and performed Y” needs corroboration.

Program Presence vs Program Use

Prefetch is often used to argue that a user “used” a program.

That can be true. It can also be wrong in predictable ways.

A scheduled task might launch an executable. A management agent might run it. An updater might invoke it. A service wrapper might start it. A user might double-click it. All of these can produce Prefetch.

Prefetch tells you that the program started. It doesn’t tell you who initiated it, whether the user interacted with it, or whether it was meaningful activity versus background noise.

If the question you’re answering is about user action, Prefetch is usually insufficient by itself. You’ll need corroboration from artefacts that better represent user context, like interactive session information, logon events, Jump Lists, or shell artefacts. You don’t need all of these every time. You do need at least one independent source that ties execution to a user context if that’s the claim you’re making.

Artefact Existence vs Activity Significance

This is the most common failure in reporting.

An analyst finds a Prefetch record for a tool associated with attacks. They treat the existence of the record as evidence of maliciousness. That’s an indicator mindset sneaking back in.

Tools aren’t intent. Tools aren’t impact. Tools aren’t context.

In an enterprise, you’ll find Prefetch for administrative utilities, remote support tools, built-in Windows binaries used for legitimate purposes, and third-party programs that are also used by attackers. Prefetch for psexec.exe might mean lateral movement. It might mean a sysadmin doing maintenance. Prefetch for rundll32.exe is almost guaranteed on a healthy system and means nothing on its own.

The question isn’t is this program associated with attacks? The question is what does this execution mean in this environment, in this timeframe, in relation to other evidence?

Prefetch helps you answer the execution part. It doesn’t answer the meaning part.

Reasoning with Prefetch in Real Investigative Patterns

Let’s make this concrete with the kinds of situations where Prefetch is routinely misused.

Triage: “We Found Prefetch for X, Therefore X is the Root Cause”

In triage, you often build a candidate narrative quickly. Prefetch can feed that narrative, but it shouldn’t anchor it.

If you find Prefetch for a suspicious executable that matches an alert, that’s useful corroboration. It supports that the executable started on the host. It also gives you a first run and last run window, a run count, and a set of startup file references that may lead you to additional dropped components.

The mistake is treating Prefetch as a root cause artefact. Prefetch records execution, not impact.

A ransomware incident is a good example. The ransomware payload might execute once. Prefetch will likely show it ran. That doesn’t tell you how it got there, whether it executed under a user context or a service context, whether it succeeded fully, or what else executed earlier to prepare the environment. It also won’t capture everything it did, because much of ransomware activity occurs after startup.

Use Prefetch to support “the payload started around this time.” Use other artefacts to support delivery, privilege changes, lateral movement, persistence, and impact.

Post-Incident Review: “No Prefetch, so it Didn’t Happen”

This is the inverse and it appears in both internal reviews and legal disputes.

If an analyst can’t find a Prefetch record for an alleged tool or program, the temptation is to declare the absence exculpatory. Sometimes it is. Often it’s not.

Start by assessing whether Prefetch is reliably present on that host at all. If the Prefetch folder is populated normally and the system configuration indicates Prefetch is enabled, the absence of a specific .pf file is more meaningful.

Even then, it’s still not proof of non-execution. It could have rolled out. It could have been deleted. It could have been executed in a way that didn’t generate a record. It could have been executed and then the system was reimaged or restored. It could have executed on another host entirely.

The disciplined approach is to frame absence as absence. Then, seek corroboration. If other execution artefacts agree that there is no evidence of execution, you can begin to support a stronger claim. If other artefacts contradict it, Prefetch becomes one negative data point among several.

Frequency Claims: “Run Count Proves Repeated Use”

Prefetch run count is attractive because it looks quantitative.

Use it carefully.

Run count indicates how many times the Prefetch file has been updated due to execution in its current lifecycle. If the Prefetch file was deleted and recreated, the run count resets. If the executable was relocated or copied to a different path, it’ll generate a separate Prefetch record with a separate run count. If multiple hosts are involved, local run count tells you nothing about usage elsewhere.

Run count is still useful. It can support “this program ran many times on this host under this Prefetch record.” It’s not a complete “usage metric,” and it’s not a substitute for timeline reconstruction.

File List Interpretation: “Prefetch Proves the Program Accessed This Document”

This is one of the most common overstatements I see in reports.

A Prefetch file includes referenced files and directories associated with early execution. Analysts sometimes treat that list as a definitive statement of what the program opened.

Even if the document path appears in a Prefetch file, you have to ask what that implies.

Did the executable open it directly? Did a library enumerate the folder? Did a plugin scan recent locations? Was it a file that existed and was checked, not read? Was it accessed because the program loaded thumbnails or metadata? Was it accessed by a dependency at startup?

Prefetch can support leads. It can point you at likely related files. It can support a hypothesis that a program interacted with a location. It’s rarely sufficient to prove that a user opened, viewed, or exfiltrated a specific document.

If the investigative question is “did this file get opened,” you should treat Prefetch as supportive context and look for stronger artefacts, like application-level recent file lists, Jump Lists, application logs, or file system evidence that aligns with actual open/read behaviour.

Environmental Context That Changes Prefetch Interpretation

Rather than isolate limitations into a standalone section, I want you to get into the habit of asking the same environmental questions every time you use Prefetch.

Is Prefetch Enabled and Functioning on This Endpoint?

This should be your first check.

Don’t assume. Verify.

Look for the existence and population of the Prefetch directory. Evaluate whether it contains recent entries for common executables you expect to see in a live user workstation environment. Consider enterprise policy and build standards.

If the artefact is absent by design, Prefetch can’t support your execution claims. That’s not a failure. It’s simply a boundary you acknowledge.

What Storage and Performance Features are in Play?

SSD vs HDD still matters operationally, but the bigger point isn’t the hardware. It’s configuration.

Some environments tune Prefetch and related features. Some don’t. Some turn them off. Some use virtual desktops or non-persistent images where Prefetch behaves differently across sessions.

The common reasoning error is assuming that your personal lab experience is universal. It’s not.

Is the Endpoint a VM, VDI, or Non-Standard Build?

Virtual desktops and VDI environments often have different performance configurations and different persistence characteristics.

If the host is non-persistent, Prefetch might reflect only the current session. If the base image is pre-populated, Prefetch may contain entries that reflect image preparation rather than user activity. If the environment uses layered profiles or redirected directories, the relationship between Prefetch and “user actions” becomes more complex.

In these environments, Prefetch might still be useful, but you need to constrain your claims to what’s supportable in that build model.

Are You Dealing with Copied or Transplanted Artefacts?

Prefetch analysis is sometimes performed on artefacts extracted from a host, from backups, or from partial collections.

If Prefetch files have been copied, timestamps might reflect copy times rather than creation/modification on the original host, depending on the collection method and filesystem semantics. If you’re working with artefacts from a mounted image, you need to be clear about which timestamps you’re relying on and why they’re trustworthy in that acquisition pathway.

This isn’t unique to Prefetch. Prefetch is simply a place where analysts often forget that file system times aren’t magic. They’re metadata that can be changed by normal operations and by the collection process.

Prefetch vs Amcache vs Shimcache

Prefetch sits alongside other execution artefacts that analysts often conflate. You don’t need to master all of them to use Prefetch responsibly, but you should understand the high-level contrast, because it reinforces interpretive boundaries.

Prefetch vs Amcache

A useful mental model is that Prefetch is about observed execution behaviour for performance optimisation, while Amcache is about application and executable inventory over time.

Amcache can retain information about executables even when Prefetch is missing or has been cleared. It might provide file metadata and, depending on version and context, time references that help you reason about when an executable first appeared or was first executed. It’s often more resilient to simple Prefetch deletion.

The analytic habit here is corroboration by artefact intent. If two artefacts with different operating system purposes converge on the same conclusion, your execution claim becomes stronger.

Prefetch vs Shimcache

Shimcache is commonly introduced as “evidence of execution,” and it can be, but it’s frequently misunderstood.

The key isn’t to treat Shimcache timestamps as execution times in the same way you might treat Prefetch modified times. Shimcache is tied to compatibility mechanisms and can reflect the system’s awareness of an executable in ways that don’t map cleanly to “user ran it at this time.”

That difference is precisely why it’s valuable. If Prefetch supports a recent execution and Shimcache supports the presence of the executable in the system’s execution awareness, you have two different lenses on the same reality. If Prefetch is missing and Shimcache still shows the executable, that tells you something about possible configuration, ageing, or tampering. It doesn’t conclusively solve the question. It informs your next step.

The broader point is that no single artefact should become your execution oracle. Prefetch is strong evidence in many cases. It’s still only one artefact.

Writing Defensible Prefetch Findings

The most practical way to improve Prefetch interpretation is to adjust how you phrase findings.

Avoid conclusions that collapse execution into intent, success, or maliciousness. Instead, make the narrow claim Prefetch supports, then describe what you did to strengthen or constrain it.

A defensible Prefetch-based statement looks like this:

This endpoint contains a Prefetch record for <executable>, indicating the program started on the system and was observed by Windows Prefetch. The Prefetch timestamps suggest execution occurred within <time window>. The run count and recent execution entries suggest the program executed <frequency impression>. Additional artefacts were reviewed to assess user context and impact.

That style keeps your conclusion tied to what Prefetch can support, while signalling that you understand its limits.

By contrast, an overconfident statement looks like this:

<executable> ran at <time> and accessed <file>, proving the user executed malware and stole data.

That statement might be emotionally satisfying in a pressured investigation. It’s not technically defensible without substantial corroboration.

The difference ism’t about being cautious for its own sake. It’s about aligning claims to evidence, and making your reasoning legible.

Keep Prefetch in its Lane

Prefetch is one of the most useful execution artefacts you’ll encounter on Windows 10 and 11 endpoints. It often gives you a clean anchor: a program started, in a specific context, around a specific time, and Windows recorded early execution behaviour consistent with its performance goals.

That’s a narrow answer to a narrow question.

The analytical failure happens when you treat that answer as a proxy for broader truths.

Prefetch doesn’t tell you why the program ran, who initiated it, or whether it succeeded. It doesn’t tell you that it was malicious. It doesn’t tell you what it did after startup. It doesn’t tell you that the absence of a record proves non-execution.

If you keep those boundaries in view, Prefetch becomes a strong piece of evidence that you can use confidently and defensibly. If you lose them, Prefetch becomes a shortcut to over-interpretation.

In this series, we’ve moved from artefacts that reflect navigation and interaction into artefacts that reflect execution. Prefetch is a natural pivot point because it feels definitive.

It is not definitive.

It’s disciplined. Use it that way.

Prefetch is often the first artefact that lets you say, with some confidence, that an executable started on a Windows endpoint. The limits are where the work begins. As soon as you move from “it executed” to “it means something,” you’re back in ambiguity, environment-dependence, and corroboration.

The next post in the series, Shimcache and Amcache, sits in that uncomfortable middle ground. We’ll look at artefacts that are routinely described as “execution evidence,” but where the evidentiary floor is lower, the interpretation is easier to get wrong, and the discipline is less optional. If Prefetch is the pivot into execution, Shimcache and Amcache are where you learn how quickly certainty collapses when the operating system’s intent isn’t aligned with what investigators wish the artefact meant.

References

1. Forensic Value of Prefetch - SANS Internet Storm Center
2. Windows Prefetch: when attackers try to hide their tracks - Khalil Z. | Medium
3. Forensic Value of Prefetch - SANS Internet Storm Center
5. Prefetch: The Little Snitch That Tells on You - TrustedSec
6. Prefetch and Superfetch
7. Prefetch history missing – General (Technical, Procedural, Software, Hardware etc.) – Forensic Focus Forums
8. Amcache, Shimcache, and Prefetch: Evidence of Program Execution - Saheed Oyedele Zpaje