Shimcache and Amcache Forensics: Execution Evidence Without Certainty

Shimcache and Amcache don’t prove execution by themselves

Prefetch is an artefact that’s easy to lean on too heavily. When it exists, it can answer the execution question with a level of confidence we don’t generally get elsewhere in Windows endpoint forensics: did this executable run on this system, and roughly when?

The problems start when we carry that confidence across other artefacts. Shimcache and Amcache are the common ones. They show the names we care about, they appear near the right part of the timeline, and our tools present them under execution-style headings.

Neither Shimcache nor Amcache proves execution by itself.

Both can show that Windows observed, inventoried, or evaluated an executable. Both are highly useful in DFIR. But on modern Windows systems, those records can be created by compatibility checks, installation, scanning, servicing, browsing, or other background activity. Execution is possible, not automatic.

Part of this comes from presentation. Tool output can make these artefacts look more authoritative than they are, especially when they appear under headings like “Program Execution” or next to timestamps that look like run times.

That doesn’t make Shimcache or Amcache useless. In practice, they’re often extremely valuable. They expand your visibility into program presence and compatibility interaction, and they can preserve traces long after more obvious artefacts have gone cold.

The trade-off is certainty. You don’t get to keep Prefetch-level confidence when you move into the application compatibility world. You need to understand and be clear about what the artefact actually shows, then look for evidence that specifically supports execution.

Do Shimcache and Amcache Prove Execution?

Execution Usually Breaks into Smaller Questions

Analysts often speak as though “execution” is a single property that an artefact either proves or doesn’t. In practice, execution questions split quickly once you move beyond Prefetch.

Did the file exist on disk at some point?
Was it evaluated by the operating system?
Was it launched as a process?
Was that launch user-initiated, service-initiated, or installer-initiated?
Did it run successfully or crash immediately?
Was it a one-time run, a repeatable action, or a transient artefact of servicing?

Shimcache and Amcache sit awkwardly across these questions. They’re built to support Windows compatibility behaviour, not forensic reconstruction. They weren’t designed to testify to user activity; they were designed to help Windows make decisions about software.

That matters because Windows isn’t trying to build a forensic timeline for us. It explains both why these artefacts exist, and why they refuse to behave as clean execution logs.

Once you move beyond Prefetch, split the execution claim before you write it. Was the file present? Did Windows evaluate it? Did a process start? Was that process started by a user, a service, an installer, or servicing activity? Shimcache and Amcache sit across those questions, which is why they’re useful and easy to overstate.

Keeping those clear makes Shimcache and Amcache reliable tools for answering certain questions, instead of misleading.

Why These Artefacts are Treated as “Execution Artefacts”

There’s a practical reason Shimcache and Amcache are routinely described as execution artefacts. In many investigations, they surface the names of suspicious binaries that also did execute. Analysts see an entry, later find supporting evidence, and the mental association sticks. Tools reinforce this by presenting outputs under headings like “Program Execution,” and by attaching timestamps that look like run times (even when they’re not).

There’s also a legacy reason. Older Windows behaviours contributed to early interpretations that were closer to “executed files list” than modern Windows allows you to claim. Those interpretations became folklore, and folklore became reporting boilerplate.

Modern Windows 10 and 11 enterprise endpoints don’t align with that boilerplate.

The core problem isn’t that the artefacts are wrong; it’s that the label is too broad. Shimcache and Amcache are better understood as execution-adjacent artefacts. They’re evidence that the OS saw a file and cared enough to record something about it. That “seeing” might be caused by execution, but it can also be caused by a range of normal, non-executing interactions.

Treat them as presence-and-context artefacts first. Treat execution as a hypothesis that must be tested, not a conclusion that falls out of the artefact name.

Windows Compatibility Intent, in Plain Investigative Terms

Windows compatibility features exist to preserve user experience across operating system change. Windows is expected to run old applications on new builds, and to handle edge cases where an application assumes an older environment. The system maintains databases and caches for backwards compatibility, so it can recognise executables, associate them with compatibility decisions, and speed up future evaluation.

That’s the operating system’s incentive. It’s not trying to record forensic evidence for us. It’s trying to prevent support calls for them.

That incentive produces a familiar pattern in forensic artefacts: the system records what it needs for its own decisions, at the times those decisions are triggered. Those triggers include execution, but they also include installation, scanning, browsing, and servicing.

Once you frame it that way, the ambiguity is less surprising. You stop asking:

Does this entry mean it ran?

and start asking

What kind of system behaviour could have caused the system to notice this file in this way?

That question keeps your interpretation tied to what Windows actually did.

Shimcache: The Cache That Remembers What Windows Noticed

Shimcache is commonly referred to as the Application Compatibility Cache (AppCompatCache). Conceptually, it’s Windows keeping a memory of certain executable paths it’s encountered, along with limited metadata that helps it understand compatibility handling.

From an investigative point of view, Shimcache is most valuable as an indicator that an executable existed at a specific path on the system at some point. It can also help you find evidence of binaries that are no longer present, and it can provide a rough sense of relative recency among entries.

The risk is that its contents are easy to misread as a direct execution log.

What Shimcache Records, and What That Implies

Shimcache entries typically include the path to an executable and a timestamp associated with the file. That timestamp is commonly the file’s last modification time, not an execution time. That matters because last modification time is often stable across copying and staging behaviour, and it can pre-date the incident window by months or years.

When you see a Shimcache entry, you can usually say something defensible about presence. You can’t usually say something defensible about run time.

Even when tools expose an “executed” indicator or flag, that indicator should be treated as a clue about how Windows encountered the file, not as courtroom-grade proof that a process started. The semantics of that indicator vary across versions and implementation details, and the only safe way to treat it is as a factor to weigh alongside other evidence.

How Entries Can Be Created Without Execution

The most fundamental problem with Shimcache interpretation is assuming that the only way Windows “encounters” an executable is by running it. On modern Windows systems, that’s not necessarily true.

Windows can populate Shimcache when an executable is browsed in certain contexts (i.e. it’s visible in File Explorer or an Open/Save dialog). The system might query metadata about a file while presenting it in File Explorer, while generating icons, or while evaluating compatibility characteristics. In those cases, the file becomes “known” to the compatibility subsystem without being launched.

That means a staged toolset on disk, a folder of extracted binaries, or a downloaded archive that includes executables can lead to Shimcache entries even if nothing was run.

Treat Shimcache as evidence of exposure rather than proof of execution. Exposure can be malicious, administrative, or investigative. A responder browsing a folder after the fact can create exposure on the live system under review. Collection method matters.

Persistence, Ageing, and Why Absence Doesn’t Help You Much

Shimcache isn’t a complete historical record. It has finite capacity, and it behaves like a rolling cache, first-in-first-out. New observations can push older entries out. Heavily used systems, systems with lots of software churn, and systems with active patching can cycle entries quickly.

It’s also shaped by system uptime and shutdown behaviour. If a system hasn’t shut down cleanly in a long time, the on-disk representation usually won’t reflect the most recent in-memory state. If a system crashed or powered off unexpectedly, recent observations might never have been committed in the way you expect.

This leads to a common reporting error: arguing from silence. Analysts sometimes state, implicitly or explicitly, that a program didn’t execute because it doesn’t appear in Shimcache. On modern systems that’s rarely defensible. The absence might mean it never existed. It might also mean it existed but was evicted, never committed, or observed in a way that didn’t trigger recording.

If you want to make negative statements, you need to make them with scope. You can say that you didn’t observe evidence of a file in this specific artefact, under the constraints of its retention behaviour. You can’t usually say the file never ran.

A Practical Way to Use Shimcache Without Lying to Yourself

Shimcache works best as a lead generator and a corroboration target.

As a lead generator, it answers: what executables were present on this system in a way that Windows deemed relevant? That can surface renamed tools, portable executables, or short-lived binaries that were later deleted.

As a corroboration target, it answers: does Windows compatibility state show that this file path was observed at all? If you already have evidence of execution elsewhere, Shimcache presence can support the idea that the executable existed locally and wasn’t purely referenced.

What it doesn’t do, on its own, is prove that a user ran a program at a particular time. If you find yourself writing that sentence, stop and look for the corroboration you’d expect if it were true.

Amcache: An Inventory That Looks like a Timeline

Amcache is stored as a dedicated hive file that Windows maintains to support application compatibility and program inventory. Investigators tend to value it because it often contains richer metadata than Shimcache, including file identity information and application-level context.

The risk is different from Shimcache. Shimcache is commonly misread as “ran.” Amcache is commonly misread as “ran at this time” because it often exposes timestamps that look precise.

For Amcache, treat those times as “first seen by this mechanism,” not “first executed by a user,” unless you can show why the mechanism implies execution.

What Amcache is Actually Good At

From an investigative standpoint, Amcache is usually strongest in three areas.

First, file and program presence. It can record that a file existed at a path, even if it’s since been removed. That’s useful when you suspect staging or cleanup.

Second, enrichment. Amcache often carries details that let you identify what a binary likely is, even if its name is misleading. This can include version metadata and hashes in some cases, which can help you distinguish a legitimate signed component from a renamed tool or a repacked binary.

Third, installation and packaging context. Amcache frequently reflects that software was installed, updated, or registered in a way that the operating system considered meaningful. That context is often more valuable than the superficial “execution” label, because it can differentiate between a portable dropper, an MSI-installed tool, and a component introduced by servicing or enterprise software distribution.

These strengths are why Amcache appears in so many workflows. It gives you visibility and context. What it doesn’t automatically give you is a clean execution timeline.

How Amcache Helps Even When You Can’t Claim Execution

There are investigations where you never get clean execution artefacts. Prefetch might be disabled, pruned, or unavailable due to scope. Event logs might be rolled or not collected. Telemetry might be partial. The system might have been rebuilt.

In those situations, Amcache can still be valuable because it answers a different question: what did Windows consider present and relevant?

That’s often enough to support hypotheses about tool deployment, malware staging, or administrative activity, especially when combined with file system evidence like the Master File Table ($MFT), Update Sequence Number (USN) journal, and volume shadow copy analysis. It can also support discussions about intent without overreaching. Presence of a toolkit doesn’t prove use, but it might prove that the environment was prepared for use.

Amcache gives you visibility and context. If execution evidence is missing, use it to support claims about presence, staging, inventory, or preparation. Don’t let precise-looking metadata do work it hasn’t earned.

Execution Versus Compatibility Evaluation: The Critical Fault Line

The most productive way to manage uncertainty with Shimcache and Amcache is to keep returning to the fault line:

Did Windows record this because something executed, or because Windows evaluated the file for compatibility or inventory purposes?

When you conflate these, cracks appear:

• Causality inversion: You see an artefact entry and assume it was caused by execution, when it might have been caused by scanning or browsing. You then build a timeline that treats the timestamp as a run time, and everything downstream becomes distorted.
• Over-attribution: You see a system-wide artefact and speak as though it reflects a user decision. In reality, the OS and enterprise tooling do a lot of work in the background. The artefact reflects that work, not necessarily a person.

To avoid these cracks, start by identifying the minimum claim the artefact supports.

For Shimcache, that claim is typically “Windows observed an executable at this path, and it captured file metadata at that time.” Execution might be consistent with that claim, but it’s not required.

For Amcache, the claim is typically “Windows recorded this file or application in its compatibility and inventory state, with associated metadata, at approximately this time.” Execution might be consistent with that, but it’s not required.

Once you have the minimum claim, ask what additional evidence would be expected if execution had occurred.

You might expect Prefetch, depending on configuration and application behaviour. You might expect process creation telemetry in the Security log or Sysmon, depending on auditing and retention. You might expect user artefacts like Jump Lists, Recent Files, or UserAssist, depending on the application type and user activity. You might expect Endpoint Detection and Response (EDR) telemetry, script block logging, network connections, or file system side effects like created outputs, configuration files, or persistence changes.

If those expected corroborators are absent, that doesn’t automatically mean execution didn’t occur. It does mean you should adjust the confidence and language of the execution claim.

Why Corroboration Isn’t Generic, and How to Choose It

A common response to ambiguity is to say “corroborate with other artefacts” as a blanket statement. That advice is correct but incomplete. Corroboration only helps your report when it answers the same question as your claim.

If the question is “did this binary ever exist here?”, corroboration might come from $MFT, USN journal entries, volume shadow copies, backup artefacts, or content hashes in other inventories.

If the question is “did this binary execute as a process?”, corroboration should prioritise artefacts that imply process start or runtime, like Prefetch, process creation event logs, EDR process telemetry, or application-specific execution traces.

If the question is “was this a user action?”, corroboration should prioritise user-context artefacts that reflect interaction, like Jump Lists and Recent Files, browser downloads, email attachment traces, and shell navigation artefacts.

If the question is “was this administrative or servicing behaviour?”, corroboration might come from installer logs, servicing stack traces, scheduled task history, software deployment tooling logs, or the timing of patch windows.

This approach forces you to be explicit about the claim you want to make. It also avoids a common trap where analysts pile unrelated artefacts into a narrative without checking whether they actually support the conclusion.

Scenarios Where Shimcache and Amcache Mislead You

Scenario 1: The Staged Toolkit That Looks like Execution

You find a cluster of entries in Shimcache and Amcache for tools commonly used in lateral movement and credential access. The timestamps cluster around a narrow window. The instinct is to report “the attacker executed these tools at this time.”

In reality, the tools were extracted to disk as part of an initial staging step. A responder later browsed the folder during triage. A compatibility scan ran overnight and catalogued the new files. The timestamps now describe observation, not use.

The correct approach is to separate presence from execution. Report presence confidently. Treat execution as unconfirmed until supported by artefacts that imply process start or tool output.

Scenario 2: Installer Behaviour That Looks like Malicious Activity

A system receives a legitimate software deployment via enterprise tooling. The deployment copies multiple executables to Program Files and registers components. Amcache records rich metadata for these files. Shimcache might record paths due to compatibility evaluation.

If you’re hunting for “new executables around the incident time,” you might misclassify the deployment as attacker activity because it aligns temporally with other suspicious signals.

Incorporate environmental context early. On enterprise endpoints, software deployment and patching are routine and often noisy. Compatibility artefacts will reflect that noise. You need to understand what “normal change windows” look like for the environment you’re investigating.

Scenario 3: The Precise Timestamp That Isn’t a Run Time

An Amcache entry has a precise time, down to sub-second precision, and it aligns with an email delivery time. It’s very tempting to assert that the user ran the attachment at that time.

The more defensible move is to ask what else should exist if that happened.

Is there evidence of the attachment being saved?

Is there evidence of execution via Prefetch or process telemetry?

Is there evidence of user interaction via Jump Lists or Recent Files?

Is there evidence of downstream impact?

If those are missing, the safe interpretation is that Windows recorded the file around that time, possibly because it was written to disk or scanned, not necessarily because it was executed.

Scenario 4: Investigative Handling Contaminates Interpretation

A responder mounts a live system, browses suspicious directories, and copies suspected malware to a staging location for analysis. Shimcache and Amcache now reflect responder interactions, not attacker interactions.

This is a normal operational hazard. The analytical habit is to account for it. Track who touched the system, when, and how. Prefer acquisition methods that minimise interaction. When you can’t, annotate the timeline with investigative actions so you don’t misattribute them later.

Common Reasoning Errors

The best way to reduce mistakes is to name them as habits to replace, rather than as warnings to fear.

The points are simple. The difficulty is applying them consistently when the case pressure is high and the CEO needs answers.

Managing Uncertainty is a Skill

DFIR reporting almost always involves uncertainty. The issue isn’t whether uncertainty exists, but whether the report makes the level of confidence clear.

If Shimcache only supports presence, say presence. If Amcache shows that Windows inventoried a file, say that. If you want to claim process execution, bring in evidence that actually speaks to process start or runtime behaviour. That might be Prefetch, process creation logging, EDR telemetry, UserAssist, application logs, or downstream side effects. The corroboration should match the claim.

Every artefact carries both signal and ambiguity. Prefetch happens to carry relatively more signal for a particular question. Shimcache and Amcache carry broader visibility and richer context, but they carry ambiguity about what triggered recording.

Good analysis means recognising that trade-off and making the confidence level clear in the report.

Managing uncertainty means doing three things well:

1. Choosing claims that match the evidence. If you can prove presence, prove presence. If you can prove execution, prove execution. If you can’t, describe what you can show and what remains unconfirmed.
2. Selecting corroboration based on the question, not based on habit. “More artefacts” isn’t a method. A coherent hypothesis and targeted validation is.
3. Using careful language in reporting. Words like “indicates,” “suggests,” “is consistent with,” and “is compatible with” aren’t hedges when used properly. They’re accurate descriptions of evidentiary strength.

This makes your reporting more defensible. It also makes your investigation more effective, because you stop wasting time chasing certainty where the artefact can’t deliver it.

Bringing It Back to Prefetch

Prefetch and compatibility artefacts answer different questions.

Prefetch is most comfortable answering “did this executable run, and when did Windows observe that execution?”

Shimcache is most comfortable answering “did Windows observe this executable’s presence at this path, in a way that became relevant to compatibility state?”

Amcache is most comfortable answering “what executables and applications did Windows inventory for compatibility and program context, and what metadata can help identify them?”

If you treat Shimcache and Amcache as inferior versions of Prefetch, you’ll be disappointed and you’ll make mistakes. If you treat them as different tools that expand visibility in exchange for certainty, they become valuable and honest components of your reasoning.

What Your Report Should Say

Shimcache and Amcache often surface the right names, preserve traces after cleanup, and look like execution evidence. Treat them as evidence of program presence, compatibility interaction, and operating system observation. They support an execution hypothesis when your other artefacts show process start, user interaction, or runtime side effects.

The better report says exactly what the artefact supports, then stops before a lead becomes proof.