AmCache is not alone; Using .WER files to hunt evil

martin korman
Jun 26 · 3 min read

TL;DR — Starting Windows 10, most of *.WER files include the process’ hash, which can be used for hunting in the same way that AmCache is being used.

How it all started

@Lee Holmes wrote on his blog about how one can extract activity history from PowerShell process dumps (here).

@James Habben also wrote about a case he had that involved a dump file. In that case he found a crash dump that lead him to the initial infection vector, which was a flash exploit.


The use of WER files for DFIR purposes is not new either. Kim Jinkook (@pr0neer) wrote about it back in 2012, and so did @Corey Harrell back in 2014, in his great blog — Journey Into Incident Response (here).

The blog posts are great and they detail how the evidence is being created, what is included in the evidence and how it can be used during investigations. Additionally, both of them mention that this evidence can be used as a process execution evidence and as part of a forensics timeline.

So, what’s new?

chrome.exe SHA1 hash, found in a crash report

As you can see in the image, the hash resides in the value of the “TargetAppId” field, with 4 zeros preceding (exactly like how SHA1 is stored in AmCache).

Unfortunately, not all reports contain the SHA1 of the file, and we haven’t found (yet) what will determine if the report will includes the hash or not. From our small testing environment, it seems like the reports that do not contain the hash are Microsoft Store applications:

Example entries in which the “TargetAppId” field does not contain the hash

We did not find anything else besides this valuable piece of information, but our dataset is quite small, so there might be some other useful things!

How can we use it?

Final Words

  1. The DFIR community is insane, and the amount of shared knowledge is huge. If you know where and how to search what you look for, someone probably wrote something about it in the past. There’s no need to reinvent the wheel every single time.
  2. Revisiting existing evidence which were already discussed and analyzed is super important, especially today when Microsoft changes things in their operating systems pretty often.
  3. We, as a community, must have a dataset of forensic evidence and automated tests that will automatically discover broken evidence and assist in finding their replacement / alternatives.

Would love to hear any feedback, and thanks for reading :)

DFIR Dudes

Yet another DFIR blog, authored by Martin Korman & Hadar Yudovich

martin korman

Written by

Malware Analyst and Forensic Investigator. Tweets represent my own opinion.

DFIR Dudes

Yet another DFIR blog, authored by Martin Korman & Hadar Yudovich