This please let us know.
Recently, I was confronted with a scenario where a very suspicious Windows pop-up message was shown to a specific user on a corporate network. It was a kind of Yes/No default Windows Dialog Box that, although I cannot reveal the message content, I can assure you that it was in the context of what the user was doing on his computer at that moment.
As we were dealing with a major incident on the same network, our first assumption was that someone had compromised that machine and was controlling it remotely through a reverse connection - the type of situation that urges for a rapid response.
However, after a few hours hunting for any piece of malware on that machine, including operating system events, network connections, user Internet history, e-mail attachments, external devices and so on, nothing interesting was found. In fact, the evidence came from a source Ive never imagined could help me on an incident response. It came from Windows Error Reporting (WER), as described in this diary.
The subtle clue
As no malware evidence was found, we decide to get back to the drawing board, and after looking carefully at the strange message, I noticed that, whatever application had been used by the attacker to present the message, it has hanging. The classic (Not Responding) width:332px" />
Figure 1 Not Responding application sample
By default, when an application hangs or crashes on a Windows system, the Windows Error Reporting (WER) mechanism  automatically gathers detailed debug information including the application name, loaded modules and, more important, a heap dump, which comprehends the data that was loaded in the application at the time that the memory was collected. All this data is reported to Microsoft that, in turn, may provide users with solutions for known problems.
As the application used to send the strange message has hanged, the chances are that we could find generated WER artifacts do analyze and track the supposed intrusion. Thus, our next step was looking for them.
Collecting WER information
To demonstrate how we found and analyzed WER files related to that hanged application without exposing real incident information, weve created a similar scenario and used it for this analysis.
Crashing an application
Using a Windows 10 default installation machine in our lab, the first thing was forcing an application to crash. For this purpose, we used the text editor application Notepad++ as the application to be crashed and Process Explorer tool  as the means to cause it.
For further analyses purposes, we typed a simple text on the editor, as seen in Figure 2 and, through the Process Explorer, started killing aleatory ntdll.dll width:566px" />
Figure 2 width:366px" />
Figure 3 Killing application threads
It didn width:401px" />
Figure 4 width:517px" />
Figure 5 Application event log evidence
Note that the event ID for crashed application has the value 1000 while for hangeing applications, the value is 1002.
The other evidence are the WER files themselves which, depending on the Windows version are generated in different paths and can be found through different control panel menu options. On Windows 7, for example, WER settings and reporting access can be found through Action Center and on Windows 8 through Problem Reports and Solutions.
On Windows 10, used in our demonstration scenario, the WER menu can be opened through the menu Control Panel - System and Security - Security and Maintenance - width:478px" />
Figure 6 Looking for the specific problem report
Figure 7 WER problem details
Another way to find WER files is going directly path they are created on the disk. On Windows 10, WER report files can be reached through the path: %SystemDrive%\ProgramData\Microsort\Windows\WER width:567px" />
Figure 8 width:567px" />
Figure 9 WER file list
Analyzing the evidence
Now, making a parallel to the real incident case, when we searched for event log evidence, we could find that an application hanged on that machine moments before the message screenshot time. Better than that, we also could find the WER files associated to that application hang!
You may be thinking right now how I could find WER files in the machine as they are deleted from disk after being sent to Microsoft. The point is: they weren
<li> <p dir="ltr">The WER report wasn width:523px" /></p>
Figure 10 Problem uploading WER during the MITM attack
Heading back to the real scenario, with WER files in our hands, we could discover the name of the possible application that generated that suspicious pop-up message and, by inspecting the heap dump file we could confirm it. It turns out that we found exactly the pop-up message content into the memory dump file using a simple strings command although there exist an orthodox way to inspect and debug those files using Windbg .
Employing the same strings width:567px" />
Figure 11 Evidence found
As we could see, in addition to helping Windows users to deal with application crashes and hangs, this case demonstrated that WER can be extremely useful for post-mortem analysis. Depending on the scenario, its like having an application memory dump to analyze as part of your DFIR activities without having collected it during the incident.
On the other hand, it raises some concerns regarding data leaking through the memory dump files. Considering that you have consented to send those information to Microsoft (remembering or not that you have done that ), there exists the possibility of those content to be accessed by third parts, like intruders that escalated the privileges on the targeted machine or simple by that new employee that is now using your machine and you thought that removing your user home directory could be enough.
Things may get worse if we consider that the crashed or hanged application is a password manager, for example. We did experiments on a group of them and privately reported those that allowed us to recover clear text passwords from WER memory dumps. The Enpass password manager has already published a security bulletin and a new version fixing the vulnerability  for which the CVE 2017-9733  has been associated.
For Windows application developers in general, to prevent sensitive information exfiltration from crash dumps, we recommend either completely disabling WER triggering by using AddERExcludedApplication or WerAddExcludedApplication functions  or by excluding the memory region that may contain sensitive information using the function WerRegisterExcludedMemoryBlock  (available only on Windows 10 and later).
A more comprehensive solution should be provided by Windows itself that could protect report files by encrypting them - at least the memory dumps. Interestingly, there is a patent from IBM exactly about protecting application core dump files . Today, the encryption is employed only while sending WER report files to Microsoft through SSL connections.
Regarding our case, in the end, fortunately realized that there was no violation or intrusion on that machine. It was, indeed, a misuse of a legitimate tool by an internal employee that made us learn a bit more the importance of WER files to digital forensics and users privacy.
© SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Article Link: https://isc.sans.edu/diary/rss/22536