Windows Error Reporting Abuse: Auditing WerFault and Silent Process Exit
How attackers misuse Windows Error Reporting for credential dumps and persistence, and how defenders can audit the settings that make it possible.
Windows Error Reporting (WER) is usually treated as plumbing: an application crashes, WerFault.exe collects diagnostic data, and Windows records or uploads a report. That benign workflow also gives an attacker something valuable: a trusted system component that can capture process memory and launch configured commands around a crash. The risk is not WER itself; it is the registry-controlled behavior that can quietly turn crash handling into credential collection or durable execution.
Two WER surfaces defenders should understand
LocalDumps tells WER to create user-mode dump files after a process crashes. Administrators legitimately use it for troubleshooting, but a full dump may contain access tokens, passwords, connection strings, private keys, or application secrets. A broad machine-level configuration that dumps every crashing process into a writable directory creates a predictable collection point for sensitive memory.
Silent Process Exit is more dangerous when unexplained. It combines Image File Execution Options (IFEO) monitoring with SilentProcessExit settings. Windows can then create dumps or run a MonitorProcess command whenever a selected executable exits. Debuggers use this feature, but attackers can register a security-sensitive process and obtain execution without installing a conventional service or scheduled task.
Audit the configuration, not merely WerFault.exe
Seeing WerFault.exe is not enough to declare an incident; it is a Microsoft-signed binary and appears during normal failures. Start with the configuration that causes it to act:
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<image.exe>
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\<image.exe>
For LocalDumps, inventory DumpFolder, DumpType, and DumpCount, including per-application subkeys. A DumpType of 2 requests full dumps and deserves stronger scrutiny. Confirm that the destination has restrictive ACLs, is not a user profile or shared folder, and is governed by retention and deletion procedures.
For Silent Process Exit, correlate matching executable names across both registry branches. The IFEO entry commonly enables GlobalFlag monitoring, while the SilentProcessExit key defines actions such as ReportingMode, DumpType, LocalDumpFolder, and MonitorProcess. A monitor command pointing to PowerShell, a script host, a user-writable path, or an unsigned binary should be treated as high-priority.
What good detection looks like
- Alert on creation or modification of IFEO and SilentProcessExit keys, especially outside approved debugging windows.
- Record the actor, command line, parent process, and deployment mechanism behind each registry change.
- Watch for new
.dmpfiles containing names of browsers, identity agents, password managers, database clients, or other secret-bearing processes. - Correlate
WerFault.exewith unusual child processes, outbound connections, or immediate archive and deletion activity. - Baseline authorized developer and support endpoints separately; server and executive workstation exceptions should be rare and documented.
A trusted binary is not a trusted outcome. The effective control is the binary plus its configuration, target process, destination, and change history.
Hardening without breaking diagnostics
Do not disable WER fleet-wide as a reflex. That removes useful crash evidence while leaving other dump techniques available. Instead, remove stale LocalDumps and Silent Process Exit entries, scope legitimate settings to named applications, prefer smaller dump types where sufficient, protect dump folders with administrator-only ACLs, and enforce short retention. Never collect dumps from authentication or credential-handling processes unless an incident procedure explicitly requires it.
On one machine, WinSentinel Free provides the full set of 64 security modules with no feature limits, making local configuration review and remediation practical. Organizations need a different layer: WinSentinel Pro adds central node and agent management, compliance rollups, drift alerts, and fleet orchestration so a newly introduced WER exception does not remain hidden on machine 47 of 100.
Incident response priorities
When you find an unauthorized entry, preserve the registry values and relevant event telemetry before removal. Hash and quarantine any referenced monitor binary, secure existing dump files, identify who could read the dump directory, and hunt for the same executable name, command, and path across the fleet. Rotate exposed credentials if sensitive process memory may have been captured. Finally, determine whether the configuration arrived through local access, software deployment, Group Policy, or another management channel; otherwise, deleting the key only treats the symptom.