Artifact Analysis: Windows Error Reporting (WER)

Note

Executive Summary: Designed by Microsoft to collect diagnostic data when applications crash, hang, or encounter kernel errors, Windows Error Reporting (WER) is an unintentional forensic goldmine. For DFIR analysts, WER artifacts provide highly durable historical evidence of program execution, precise file paths, and application instability. It uniquely answers the critical question: “What crashed on this endpoint, and when?“

1. Technical Overview: The Reporting Mechanism

When an application encounters an unhandled exception, the Windows operating system invokes the WER service to manage the crash.

1. Interception: The OS suspends the crashing process and launches WerFault.exe.
2. Data Capture: WerFault.exe captures the state of the dying process, which may include generating a full or minidump of the process memory.
3. Report Generation: A text-based report file (.wer) is generated, summarizing the crash parameters.
4. Local Archiving: The report is saved to a local directory before the system attempts to transmit the telemetry to Microsoft.

Tip

Forensic Nuance: Even if telemetry transmission to Microsoft is disabled via Group Policy or endpoint configuration, the local generation and archiving of the .wer files generally still occur, preserving the artifact for investigators.

2. Artifact Location & Structure

WER artifacts are divided into two main categories depending on the context of the crashed process (user-space vs. system-wide).

A. Directory Locations

• User-Specific Crashes: C:\Users\<Username>\AppData\Local\Microsoft\Windows\WER\
• System-Wide Crashes (SYSTEM processes): C:\ProgramData\Microsoft\Windows\WER\

Within these paths, analysts must focus on three primary subdirectories:

1. ReportArchive: The historical repository of past crashes. This is the primary forensic target.
2. ReportQueue: Reports pending transmission to Microsoft.
3. Temp: Temporary files generated during the crash handling process.

B. The .wer File Structure

The .wer file itself is a plain text file formatted as an INI configuration file.

Critical forensic fields inside a .wer file include:

• EventType: The nature of the issue (e.g., APPCRASH, AppHangB1).
• AppPath: The absolute file path of the executable. (Irrefutable proof of execution and location).
• AppName: The name of the faulting executable.
• EventTime: The precise timestamp of the crash (stored in Windows FileTime format).
• TargetAppId: Often contains metadata or a hash representation of the application.

3. Forensic Value in Incident Response

WER is a highly resilient artifact. Because it documents failure rather than success, it often persists long after routine execution artifacts have rolled over.

Identifying “Unstable” Malware

Threat actors frequently deploy hastily compiled tools, poorly tested ransomware encryptors, or custom droppers. These binaries are notoriously unstable. Finding a directory in ReportArchive named AppCrash_malware.exe_[...] provides the exact path from which the payload was launched and the precise “Time of Death” of the execution attempt.

Historical Execution Evidence

WER retains reports for extended periods. Analysts can find evidence of a malicious tool (like a renamed psexec.exe or mimikatz.exe) that crashed months ago, long after the associated Prefetch (.pf) Files have been overwritten.

Advanced Threat Techniques (WerFault Abuse)

Sophisticated threat actors actively abuse the WER mechanism for credential theft and persistence.

• LSASS Memory Dumping: If an attacker intentionally crashes or injects into the Local Security Authority Subsystem Service (lsass.exe), WerFault.exe may automatically generate a memory dump (lsass.dmp) as part of the error reporting process. Attackers can harvest this legitimate dump file to extract credentials offline, bypassing EDR hooks that monitor direct LSASS access.
• Silent Process Exit Persistence: Attackers can modify the Image File Execution Options (IFEO) registry key to enable “Silent Process Exit” for a specific binary. When the targeted process terminates, WerFault.exe can be configured to silently launch a secondary malicious process (a “monitor” process), acting as a highly stealthy persistence and evasion mechanism.

4. Event Log Correlation

If threat actors systematically delete .wer files from the disk, the crash events are still recorded in the Windows Application Event Log.

• Event ID 1000 (Application Error): Details the “Faulting application name” and the “Faulting module name”.
• Event ID 1001 (Windows Error Reporting): Contains the bucket ID and the absolute path to the .wer report file. Even if the file is deleted, the path logged here confirms the original location of the crashed binary.

5. Recommended Tooling

Because .wer files are plain text, manual triage is highly effective. A simple grep or findstr across the ReportArchive directory searching for suspicious keywords (cmd.exe, powershell, known malicious names) yields immediate results.

WerForensicator

A specialized parsing tool designed to recursively read .wer files, decode the timestamps, and export the findings into structured formats for timeline analysis.

RECmd (Registry Explorer Command)

Utilized to analyze WER-related registry keys (HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting) to identify tampering or Silent Process Exit persistence.

---

References & Further Reading

• SANS Institute: Windows Forensic Analysis
• MITRE ATT&CK: OS Credential Dumping: LSASS Memory (T1003.001)
• Related Artifact: Understanding Prefetch Execution Evidence
• Related Artifact: Amcache and RecentFileCache