Crash Dumps and Core Dumps Guide: Secrets in Memory Dumps, Collection Controls and Safe Handling

A crash dump is a copy of process or system memory, so it can hold every password, token, private key and customer record the process had in memory at the moment it failed. Dumps are created automatically, copied to support tickets, uploaded to crash reporting services and moved into debugging environments with far weaker controls than the production system they came from. This guide covers what Windows, Linux and managed runtimes put into dumps, the settings that control collection, how to handle dumps safely once they exist, and how to detect and measure exposure. It is for platform, endpoint, application and security engineering teams who run or support production systems.

Key takeaways

• Classify dumps at the level of the data in memory. A full dump of an authentication service is as sensitive as its key store, whatever the file extension says.
• Collection settings decide the exposure. Windows DumpType and CrashDumpEnabled, Linux core_pattern, coredump.conf and fs.suid_dumpable, and JVM heap dump flags set what is captured and where it lands.
• Leaving the secure boundary is the real risk. Microsoft's Storm-0558 investigation centred on key material that left an isolated signing environment for a debugging environment, which was then reached through a compromised engineering account.
• Secret scanning does not reliably see into dumps. Binary memory images defeat many pattern-based scanners, so rely on access control, retention and isolation first.
• Code can keep secrets out of dumps. Linux MADV_DONTDUMP excludes memory regions from core dumps, and short-lived secrets in memory reduce what any dump can reveal.

What ends up in a dump

Typical secrets found in application memory include database connection strings, cloud access keys and session tokens loaded from environment variables, OAuth refresh tokens, TLS private keys held by the process, signing keys, decrypted customer data and passwords being checked at login. The Environment Variables and .env Files guide explains why secrets loaded at start-up remain in memory for the life of the process.

Case study: key material and the debugging environment

In September 2023 Microsoft published the results of its investigation into how Storm-0558 obtained a consumer signing key. Its original account said a consumer signing system crash in April 2021 produced a crash dump containing the key, that the dump was moved from the isolated production network into a debugging environment on the corporate network, that credential scanning did not detect the key, and that the actor later compromised an engineer's account with access to that environment. On 12 March 2024 Microsoft updated the post: it had not found a crash dump containing the affected key material, though its leading hypothesis remained that operational errors let key material leave the secure token signing environment and that it was later accessed in a debugging environment through a compromised engineering account. Microsoft also said moving crash dump material out of the environment had not been prohibited in the past but is now prohibited by its debugging policy.

The lessons hold whatever the exact path: dumps and debugging data from high-value systems must not leave their security boundary, the debugging environment needs the same access controls as production, and scanning is a backstop. See the Microsoft Storm-0558 key breach analysis and the Storm-0558 and Cloud Key Theft Profile.

Collection controls on Windows

• System crash dumps: HKLM\System\CurrentControlSet\Control\CrashControl, value CrashDumpEnabled: 0x0 none, 0x1 complete, 0x2 kernel, 0x3 small, 0x7 automatic, and 0x1 with FilterPages 0x1 for an active memory dump. The dump goes to DumpFile (%SystemRoot%\Memory.dmp by default) and small dumps to MinidumpDir (%SystemRoot%\Minidump). Changes need a restart. On servers that process secrets, prefer kernel or automatic dumps and use complete dumps only for a time-limited investigation.
• Application dumps: Windows Error Reporting local dumps are configured under HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps, with per-application subkeys such as LocalDumps\MyApplication.exe. Microsoft documents that the feature is not enabled by default and needs administrator rights. DumpFolder defaults to %LOCALAPPDATA%\CrashDumps; dumps of services go to the service profile folders. DumpCount defaults to 10 and DumpType to 1 (mini dump).
• Policy: if you enable full application dumps for troubleshooting, scope them to one executable subkey, set DumpFolder to a protected location with restrictive ACLs, keep DumpCount low and remove the setting when the case closes.
• LSASS: a memory dump of the LSASS process is a classic credential theft technique (MITRE ATT&CK T1003.001, OS Credential Dumping: LSASS Memory). Treat any LSASS dump outside a sanctioned forensic process as an incident. See the Credential Dumping Guide.

Collection controls on Linux and containers

• Where dumps go: /proc/sys/kernel/core_pattern names the core file, or with a leading | pipes it to a handler such as systemd-coredump or Apport. Piped dumps run as root and are not subject to RLIMIT_CORE, so ulimit -c 0 alone does not stop them.
• systemd-coredump: /etc/systemd/coredump.conf (or a drop-in in coredump.conf.d/) sets Storage= (external by default, storing cores in /var/lib/systemd/coredump/; journal; or none), ProcessSizeMax=, ExternalSizeMax=, MaxUse= and KeepFree=. To keep only a log entry, set Storage=none and ProcessSizeMax=0; the documentation notes that with Storage=none alone a core is still written during processing. Check the effective configuration with systemd-analyze cat-config systemd/coredump.conf.
• Privileged processes: fs.suid_dumpable 0 (default) produces no dump for processes that changed credentials or run set-user-ID programs; 1 is a debug mode that the kernel documentation calls insecure because unprivileged users can read privileged process memory; 2 writes such dumps readable only by root and requires an absolute core_pattern or a pipe. Keep it at 0 in production.
• Handler vulnerabilities: in May 2025 Qualys disclosed CVE-2025-5054 in Apport and CVE-2025-4598 in systemd-coredump, race conditions that let a local attacker read the core dump of a crashed set-user-ID program; its proof of concept recovered password hashes from /etc/shadow through unix_chkpwd. Qualys gave setting fs.suid_dumpable to 0 as a temporary mitigation where patching was not immediately possible.
• Containers: core_pattern is a host kernel setting, so a container's crash is handled by the host's handler and dumps can land on the node, outside the container's own storage and access controls. Decide dump policy at node level and treat node dump directories as sensitive. See the Kubernetes NHI Security Guide.
• In code: applications that hold keys can mark those pages with madvise(MADV_DONTDUMP) so they are omitted from core dumps.

Managed runtimes and crash reporting services

• JVM: -XX:+HeapDumpOnOutOfMemoryError is commonly left on in production because Oracle documents it as having no overhead. Pair it with -XX:HeapDumpPath pointing to a protected directory rather than the working directory default (java_pid<pid>.hprof), and treat the files as sensitive data.
• Fatal error logs: hs_err_pid logs and similar crash logs include the command line and system properties. Do not pass secrets on the command line.
• Crash reporting SaaS: services such as Sentry scrub event fields whose names or values look like passwords, secrets, tokens and private keys by default, and let you add sensitive fields. Field scrubbing applies to structured event data; confirm separately how the service handles binary minidumps and attachments, and whether you need to upload them at all.
• Operating system error reporting: decide whether endpoint and server crash reports may be sent to the OS vendor, and set the relevant policy centrally.

Safe handling of dumps once they exist

Personal data in dumps is still personal data. Under GDPR Art. 32 controllers must apply appropriate security to processing, and a dump of customer data sent to the wrong party can be a personal data breach, which under Art. 33 must be notified to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless it is unlikely to result in a risk to individuals. See the Data Retention and Secure Deletion Guide for deletion controls.

Where identity fits

The highest-value contents of most dumps are non-human credentials: service account passwords, API keys, cloud access keys, workload tokens and signing keys. Three identity practices shrink the blast radius. Short-lived, automatically rotated credentials mean a dump from last month holds expired secrets. Fetching secrets from a vault at use time and discarding them reduces how long they sit in memory. Hardware-backed keys in an HSM or TPM never appear in process memory at all. The Secrets Access Logging and Detection guide covers spotting secret use after a possible exposure.

Choosing a collection policy

Small organisations can usually turn full dumps off everywhere and enable them case by case. Large organisations with vendor support contracts need a documented route for sending dumps to vendors that includes minimisation and deletion.

How to implement

1. Find where dumps already exist. Search servers and endpoints for *.dmp, *.hprof, core* files, /var/lib/systemd/coredump/, /var/crash/, %LOCALAPPDATA%\CrashDumps, %SystemRoot%\Minidump and Memory.dmp, plus support ticket attachments and shared drives. Record size, age and source system.
2. Read the current settings. Collect CrashDumpEnabled, LocalDumps keys, core_pattern, coredump.conf, fs.suid_dumpable and JVM flags through configuration management.
3. Set baselines by system class using the table above, and deploy through Group Policy, Intune, configuration management or sysctl drop-ins.
4. Pilot on one service. Confirm that support teams can still diagnose crashes with the reduced dump type before widening. Roll back by restoring the previous registry or configuration values from configuration management.
5. Lock down storage and transfer. Restrict dump folder ACLs, define the approved transfer channel and set automatic deletion.
6. Change code where it matters. Exclude key pages from dumps, avoid secrets on command lines, and shorten secret lifetimes in memory.
7. Rotate anything exposed. For old dumps from sensitive systems found in step 1, delete them and rotate the credentials those systems held.

Detection and measurement

• Dump creation events: alert on new dump files on tier 0 and secret-handling systems, and on any dump of lsass.exe.
• File movement: data loss prevention or file access monitoring on dump extensions leaving servers, uploaded to cloud storage or attached to tickets.
• Configuration drift: alert when CrashDumpEnabled changes to 0x1, when full LocalDumps are set globally, or when fs.suid_dumpable is not 0.
• Debugging environment access: log and review who opens dump files from sensitive systems.

Metrics:

• Number of dump files older than the retention limit (target zero).
• Percentage of tier 0 and secret-handling systems on the approved dump baseline.
• Number of dumps sent to third parties per quarter, and percentage with recorded deletion.
• Median age of secrets held by services that produce dumps.
• Configuration drift alerts closed within the agreed time.

Common failure patterns

• Full dumps enabled globally during an outage and never turned off, filling disks with copies of production memory.
• Dumps attached to support tickets or chat and retained for years in systems with broad access.
• Treating the debugging environment as lower risk than production, the pattern at the centre of the Microsoft Storm-0558 key breach.
• Relying on secret scanning to catch keys in binary dumps instead of preventing the dump from leaving.
• Heap dump flags with the default path writing .hprof files into application directories that are backed up, synced or served.
• Setting fs.suid_dumpable to 1 for debugging and leaving privileged process memory readable by unprivileged users.

Framework mapping

Practitioner checklist

NHI Mgmt Group recommends the following checks.

• Inventory existing dump files and delete those past retention, rotating secrets from sensitive systems.
• Set CrashDumpEnabled and WER LocalDumps baselines per system class.
• Set coredump.conf storage and size limits and keep fs.suid_dumpable at 0.
• Point JVM heap dumps to a protected directory, or disable them on secret-handling services.
• Classify dumps at the level of the source system and restrict folder access.
• Define one approved transfer route for dumps to vendors, with deletion confirmation.
• Keep dumps from key and identity systems inside their security boundary.
• Exclude key material from dumps in code and keep secrets off command lines.
• Alert on LSASS dumps and on dump configuration drift.

Standards and references

• Microsoft: Collecting User-Mode Dumps
• Microsoft: Overview of memory dump file options for Windows
• Linux man-pages: core(5)
• Linux man-pages: proc_sys_fs(5)
• systemd: coredump.conf
• Oracle: Java SE Troubleshooting, Command-Line Options
• Microsoft MSRC: Results of Major Technical Investigations for Storm-0558 Key Acquisition
• Qualys: Information disclosure vulnerabilities in Apport and systemd-coredump

Related NHI Mgmt Group resources: Memory Forensics Guide · Credential Dumping Guide · Environment Variables and .env Files · Data Classification Guide · Storm-0558 and Cloud Key Theft Profile