AmCache is not alone; Using .WER files to hunt evil
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
Lately, I have been poking around with the concept of dump files. I was trying to see if we can find dumped process files which were left on disk and then leverage them in order to hunt for suspicious activity. This is not something new, and people have discussed it in the past. For example:
@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.
WER & DFIR
While I was going through dump files and trying to research further, I recalled that in some cases, when a program crashes on Windows, an error report file is being generated. That report file is part of the Windows Error Reporting feature which automatically submits user-mode process crashes to Microsoft.
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?
Well, from the tests we did, it turns out that starting Windows 10 — some report files now include the actual hash (SHA1) of the executed process. For example:
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:
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?
Now that the evidence also include a hash of the executed process, we can extend the ways its being used in DFIR.
Hadar Yudovich and I once heard Matias Bevilacqua from Mandiant, talking about how they use AmCache and ShimCache on a large scale in order to find suspicious executables. He also wrote about it here. We believe you can add this evidence to the stack and search for suspicious crashes in the same manner that is described in the blog (based on prevalent, for example).
Final Words
While doing this small research and talking about it with Hadar, we had some interesting thoughts:
- 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.
- Revisiting existing evidence which were already discussed and analyzed is super important, especially today when Microsoft changes things in their operating systems pretty often.
- 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 :)
