Exploring Windows Error Reporting
Monday, February 24, 2014
The Application Experience and Compatibility feature ensures compatibility of existing software between different versions of the Windows operating system. The implementation of this feature results in some interesting program execution artifacts that are relevant to Digital Forensic and Incident Response (DFIR). I already highlighted a few of these in my posts Revealing the RecentFileCache.bcf File and Revealing Program Compatibility Assistant HKCU AppCompatFlags Registry Keys. There are more artifacts associated with this feature and the Windows Error Reporting (WER) are one of them. Over the past few months WER has been discussed frequently due to the potential data it exposes when data is sent to Microsoft. However, WER can be a useful program execution artifact for incident response since malicious code - such as malware and exploited applications - can crash on systems. This short post provides discusses WER and illustrates how it is helpful to track malware on a system.
Windows Error Reporting is basically a feature to help solve problems associated with programs crashing on the Windows operating system. The Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7 goes into more detail by stating:
"WER is a sophisticated mechanism that automates the submission of both user-mode process crashes as well as kernel-mode system crashes."
The service analyzes the crashed application's state and builds context information surrounding the crashed program. The book continues by saying:
On default configured systems, an error report (a minidump and XML file with various details, such as the DLL version numbers loaded in the process) is sent to Microsoft's online crash analysis server. Eventually, as the service is notified of a solution for a problem, it will display a tooltip to the user informing her of steps that should be taken to solve the problem.
There are two registry keys responsible for WER's configuration. These keys are listed below; the first key affects system-wide behavior while the second is user specific.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting
HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting
The best resource I found explaining how WER works is a paper written by 0xdabbad00. Their paper is titled Notes on Windows Error Reporting and the actual PDF can be found here. The paper "attempts to better explain what is and is not possible and to generalize the attack classes for all error reporting" and touches on the following key points:
- What traffic is sent unencrypted and what is sent encrypted
- What data is in the unencrypted traffic
I won't try to rehash what is written in the paper since it really goes into great detail. Anyone who wants to know more about WER should read this.
One item I really liked about the Notes on Windows Error Reporting paper is its Appendix. The focus of the paper is on explaining the WER feature but the Appendix provides some useful DFIR tidbits about the WER artifacts present on the system. These artifacts are important because they show a program was running on the system and it eventually crashed. In the past, WER artifacts have given me more context about the other program execution artifacts located on a system. The WER artifacts outlined in the Appendix include: event logs, WER folder, AppCompat.txt file, and WERInternalMetadata.xml file.
WER records an entry in the event log when a crashed application is analyzed and then another event log entry is recorded if information is sent to Microsoft. The Appendix shows what this event log looks like including the information it contains. The event log also shows that the WER folder is located at C:\Users\username\AppData\Local\Microsoft\Windows\WER.
The paper also explains what the AppCompat.txt and WERInternalMetadata.xml files are while the Appendix shows the information stored in these files. Either one of the files provide a wealth of information about the program that crashed such as the parent process, parent process command line, and process path.
I wanted to provide additional information about one WER artifact mentioned in the paper. Specifically, the actual Windows Error Report themselves. A Windows Error Report records a ton of information about a program that was running at some point in the past. To illustrate I'll walk through a WER for a piece of malware that crashed on a system. The screenshot below shows the beginning of a report and some of the information shown is when the program crashed and program was 32-bit (notice the WOW64).
The next portion of the report starts to provide information about the crashed program.
A little bit further down in the report you can see part of the user interface message as shown below.
The report even recorded the program's loaded modules at the time of the crash. This section contains the file path to the crashed application and in this instance the program is highly suspicious (executable launching from a temp folder).
The end of the report contains the last piece of useful information about the crash.
A search on the AppName in the Malware Analysis Search provides some leads about what malware was present on the system. It leads to VirusTotal reports and sandbox reports showing malware crashing such as this one.
WER provides more artifacts that show program execution. Overall this artifact is not as beneficial as the other program execution artifacts but once in a while malicious code will crash or cause an application to crash. When this occurs WER provides more context about what occurred on the system and the relevance of the executable listed means the following:
1. The program executed on the system.
2. The program crashed on the system.
3. The data in the WER artifacts is information about the program at the time it was running and crashed on the system.
What is Windows Error Reporting
Windows Error Reporting is basically a feature to help solve problems associated with programs crashing on the Windows operating system. The Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7 goes into more detail by stating:
"WER is a sophisticated mechanism that automates the submission of both user-mode process crashes as well as kernel-mode system crashes."
The service analyzes the crashed application's state and builds context information surrounding the crashed program. The book continues by saying:
On default configured systems, an error report (a minidump and XML file with various details, such as the DLL version numbers loaded in the process) is sent to Microsoft's online crash analysis server. Eventually, as the service is notified of a solution for a problem, it will display a tooltip to the user informing her of steps that should be taken to solve the problem.
How Does Windows Error Reporting Work?
There are two registry keys responsible for WER's configuration. These keys are listed below; the first key affects system-wide behavior while the second is user specific.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting
HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting
The best resource I found explaining how WER works is a paper written by 0xdabbad00. Their paper is titled Notes on Windows Error Reporting and the actual PDF can be found here. The paper "attempts to better explain what is and is not possible and to generalize the attack classes for all error reporting" and touches on the following key points:
- What traffic is sent unencrypted and what is sent encrypted
- What data is in the unencrypted traffic
I won't try to rehash what is written in the paper since it really goes into great detail. Anyone who wants to know more about WER should read this.
What Artifacts Are Left By Windows Error Reporting?
One item I really liked about the Notes on Windows Error Reporting paper is its Appendix. The focus of the paper is on explaining the WER feature but the Appendix provides some useful DFIR tidbits about the WER artifacts present on the system. These artifacts are important because they show a program was running on the system and it eventually crashed. In the past, WER artifacts have given me more context about the other program execution artifacts located on a system. The WER artifacts outlined in the Appendix include: event logs, WER folder, AppCompat.txt file, and WERInternalMetadata.xml file.
WER records an entry in the event log when a crashed application is analyzed and then another event log entry is recorded if information is sent to Microsoft. The Appendix shows what this event log looks like including the information it contains. The event log also shows that the WER folder is located at C:\Users\username\AppData\Local\Microsoft\Windows\WER.
The paper also explains what the AppCompat.txt and WERInternalMetadata.xml files are while the Appendix shows the information stored in these files. Either one of the files provide a wealth of information about the program that crashed such as the parent process, parent process command line, and process path.
Additional about Windows Error Reports
I wanted to provide additional information about one WER artifact mentioned in the paper. Specifically, the actual Windows Error Report themselves. A Windows Error Report records a ton of information about a program that was running at some point in the past. To illustrate I'll walk through a WER for a piece of malware that crashed on a system. The screenshot below shows the beginning of a report and some of the information shown is when the program crashed and program was 32-bit (notice the WOW64).
The next portion of the report starts to provide information about the crashed program.
A little bit further down in the report you can see part of the user interface message as shown below.
The report even recorded the program's loaded modules at the time of the crash. This section contains the file path to the crashed application and in this instance the program is highly suspicious (executable launching from a temp folder).
The end of the report contains the last piece of useful information about the crash.
A search on the AppName in the Malware Analysis Search provides some leads about what malware was present on the system. It leads to VirusTotal reports and sandbox reports showing malware crashing such as this one.
WER's Relevance
WER provides more artifacts that show program execution. Overall this artifact is not as beneficial as the other program execution artifacts but once in a while malicious code will crash or cause an application to crash. When this occurs WER provides more context about what occurred on the system and the relevance of the executable listed means the following:
1. The program executed on the system.
2. The program crashed on the system.
3. The data in the WER artifacts is information about the program at the time it was running and crashed on the system.
Labels:
program execution
Posts
Great job, Corey! Great bit of valuable information. In a timeline, I'd look for the creation of the WER report files at anytime "near" something being executed (such as during user login or application launch).
WER is not only located in %UserProfile% sub folder, but 'ProgramData(All Users in XP) sub folder. It can also trace to event log.
ref. http://forensic-proof.com/archives/4358