WER LocalDumps: The Crash Dump Folder That Leaks Credentials

Windows Error Reporting (WER) is one of those subsystems everyone has and nobody thinks about. It quietly collects crash telemetry, occasionally pops a "Windows is checking for a solution" dialog, and otherwise stays invisible. That invisibility is exactly why it is a great place for an attacker to find secrets — and a great place for a defender to look before they do.

There are two independent WER exposures worth auditing on a single machine, and they point in opposite directions:

• Data leaving the machine — WER uploading additional in-memory data to Microsoft, or auto-sending all crash data without a prompt.
• Data staying on the machine — WER writing full user-mode crash dumps to a local folder, where anything that could read a process's memory now sits on disk.

Why a crash dump is a credential

A full user-mode dump is a byte-for-byte snapshot of a process's address space at the moment it crashed. If that process was holding a plaintext password, a session token, an API key, a decrypted secret, or a private key in memory — and most processes are, at least briefly — the dump contains it too. Unlike live memory, a dump is a file: it persists, it can be copied, and it inherits whatever ACLs the folder has.

WER's LocalDumps feature is off by default, but it gets turned on deliberately by developers who want crash artifacts, by application installers, and by well-meaning "collect diagnostics" scripts — and it rarely gets turned back off. Once it is on, every crash of a covered process drops a .dmp into a folder that is often world-readable. An attacker who lands on the box with normal user rights doesn't need to touch LSASS or trip Credential Guard; they can just harvest the dumps that Windows helpfully wrote for them.

The dangerous case is DumpType = 2 (full dump) combined with a permissive DumpFolder. A mini-dump is far less useful to an attacker; a full dump of the right process is game over.

The registry surfaces that matter

WER's posture lives entirely in the registry under HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting. The four values worth checking:

• DontSendAdditionalData — when 0, WER may upload the additional in-memory data slice to Microsoft. Secure default is 1.
• Consent\DefaultConsent — a value of 4 means "send all data automatically" with no prompt. That is the auto-exfil setting.
• LocalDumps\DumpType — 2 is a full dump (the credential-harvesting case); 1 is a mini-dump.
• LocalDumps\DumpFolder — where those dumps land, and therefore who can read them.

You can eyeball these by hand:

reg query "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting" /v DontSendAdditionalData
reg query "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent" /v DefaultConsent
reg query "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType

The catch is interpretation. A missing value is not the same as a dangerous value — DontSendAdditionalData defaults to the secure 1 when absent, and LocalDumps only counts as "on" if the subkey actually exists. Reading the raw registry is easy; not false-positiving on a clean machine is the part that takes care.

What WinSentinel checks

WinSentinel's Windows Error Reporting Exposure module reads this local state and turns it into concrete findings — with the secure-default handling baked in, so a machine that has simply never touched these keys reports clean instead of noisy. It surfaces:

• Whether WER may upload additional in-memory data (DontSendAdditionalData = 0).
• Whether the consent level auto-sends all crash data (DefaultConsent = 4).
• Whether local crash dumps are being written — and flags full dumps (DumpType = 2) as the higher-risk credential-exposure case.
• Whether WER has been disabled entirely (useful to know, since it also disables the diagnostics some other controls rely on).

It is a single-machine, local-only check — nothing leaves the box — so it lives in the free, open-source core alongside the rest of the audit modules. Run it with:

winsentinel --audit

and look for the Windows Error Reporting Exposure findings, or drill into one with:

winsentinel why "crash dump"

Fixing it

If you don't have a specific reason to collect local crash dumps on a production machine, don't. To stop full-dump writing, remove or neutralize the LocalDumps configuration and keep additional-data upload off:

# Stop uploading the additional in-memory data slice
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting' `
  -Name 'DontSendAdditionalData' -Value 1 -Type DWord

# If LocalDumps was enabled for diagnostics and is no longer needed, remove it
Remove-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps' -Recurse -ErrorAction SilentlyContinue

If you genuinely need local dumps for a specific application, scope them: set DumpType = 1 (mini-dump), point DumpFolder at a directory with tight ACLs, and cap DumpCount so old dumps don't accumulate. The goal is that a crash dump is never both full-fidelity and readable by every local user.

The takeaway

WER is a data-exposure surface that hides behind "it's just crash reporting." One direction leaks memory to Microsoft; the other leaves credential-grade memory snapshots sitting on local disk. Both are a couple of registry values, both are invisible in day-to-day use, and both are trivial to audit once you know where to look. That is precisely the kind of quiet, single-machine posture problem WinSentinel is built to catch — before someone else finds the dump folder first.