QuestionCONSTRUCTED

Interview prep: does Shimcache prove execution?

The question that sorts people who have read about Windows forensics from people who have had a finding challenged. Three answers, and the difference between them.

mid levelwindows forensicsa spoken answer of about 3 minutes

The question

You find an executable listed in Shimcache on a Windows 10 workstation. Does that prove it ran?

Answer it out loud first, against a timer. Then open the three answers in order.

Goodcorrect, and where most candidates stop

No. Shimcache, the Application Compatibility Cache, records executables the operating system has looked at for compatibility purposes. A file can get an entry without being run, so an entry shows the file existed at that path on this machine. To show execution I would look for something else, such as Prefetch.

Betteradds the limits and the second source

No, and the detail matters. On Windows 10 an entry means the file was present and the system evaluated it. That can happen when it is executed, and it can also happen when a directory containing it is browsed. There is no field in the Windows 10 cache that says "this one ran".

Two more things I would say before anybody asks. The timestamp in the entry is the file's own last-modified time, copied from the file system. It is not an execution time and not even a time from this incident, so a date three years old is normal. And the cache is held in memory and written to the registry at shutdown, so on a machine that has not rebooted, what I parse from the SYSTEM hive is the state as of the last shutdown, not now.

For execution I would want Prefetch, which on a workstation gives me run times and a run count, and process creation logging if it was enabled: Security 4688 or Sysmon event 1.

Bestwhat somebody who has done it says

No. It proves presence, and I would write it that way: "the file existed at this path on this host at or before the last shutdown". That is still useful. It is frequently the only trace of a tool the operator deleted, it survives when Prefetch has aged out, and the order of entries gives a relative sequence, most recent first, even though the timestamps do not.

What I would not do is put "executed" in a report on the strength of it. The timestamp is the file's last-modified time and an operator can set that, so I would not lean on it for the timeline either.

To establish execution I would work down from the strongest source the host actually has. Process creation events, 4688 or Sysmon 1, are direct: they record the process starting, with the account and the parent. Prefetch is next on a workstation, with up to eight run times. It is off by default on servers, so there I would go to SRUM for application resource usage, BAM for the last run per user, and UserAssist if it was launched through Explorer. Amcache I would use for the SHA-1 and first-seen time, and I would be as careful with it as with Shimcache, because on current builds it also records files that never ran.

Then I would say what I could not establish. If the only evidence is Shimcache and Amcache, my finding is "present, execution not established", and I would recommend enabling process creation auditing so that next time the question has an answer. Being able to say exactly where my evidence stops is the part of this job that holds up when somebody pushes on it.

Why the gap between them matters

All three answers begin with the same word. Good knows the fact. Better knows the mechanism, which is what lets you answer the follow-up about the timestamp without having memorised it. Best does three things the others do not: it says what the artifact is still good for, it ranks the alternatives by what each one establishes rather than listing them, and it volunteers the limit of its own conclusion.

That last habit is what interviewers for incident response roles are listening for, because it is what makes a report survive being challenged. It is the same observed-against-assessed split the labs on this site use, said out loud.

If you want the artifact properly, the artifact reference covers what each execution source establishes and what it does not.

What they are listening for

Whether you separate what an artifact records from what people assume it records, and whether you reach for a second source without being asked.

Where it goes next

  • The Shimcache timestamp is three years before the intrusion. What is that timestamp, and is it a problem?
  • The host is a server with Prefetch disabled. What do you use to establish execution now?
  • The entry is there but the file is gone from disk. What can you still say?
  • Your report said the file executed and opposing counsel asks how you know. Walk me through your answer.

Confident and wrong

  • Yes, Shimcache is execution evidence. It is on every cheat sheet, and on modern Windows it is wrong.
  • Treating the Shimcache timestamp as the time the program ran.
  • Naming Amcache as the proof instead. On current builds it records presence too.
  • Listing five artifacts without saying what any one of them establishes.

sources

  1. Eric Zimmerman's AppCompatCacheParser, the standard parser, with notes on what the cache holds per Windows version · primary
  2. Eric Zimmerman's tools (PECmd for Prefetch, AmcacheParser)

Tags: interview · windows · shimcache · appcompatcache · execution-evidence · prefetch · amcache