
TL;DR: A recent proof-of-concept called EDR-Freeze demonstrates that Windows' own Error Reporting (WER) components can be used to suspend endpoint security processes by leveraging MiniDumpWriteDump and suspending the dumper itself. The technique doesn't rely on a driver or kernel exploit, but it does require high privileges and produces observable artifacts that defenders can detect if they instrument hosts appropriately.
Overview
EDR-Freeze is a PoC that orchestrates Windows' crash-dump machinery to put an endpoint agent into a suspended state. Instead of loading vulnerable drivers or achieving kernel execution, the PoC uses a legitimate, signed process (WerFaultSecure.exe) together with the MiniDumpWriteDump routine to cause a target process to be suspended - then suspends the dumper itself so the target never resumes. Researchers and vendors have validated the approach on modern Windows builds; as with any PoC, real-world impact depends on the attacker's privileges and the environment.

How it works
Target selection and privileges.
The attacker must be able to run code on the host with sufficient rights to invoke WER against another process and to suspend processes. Practically, this means having SeDebugPrivilege or an equivalent capability to open and manipulate other processes' threads. Without elevated rights, the attack fails.Invoker: WerFaultSecure + MiniDumpWriteDump.
WerFaultSecure.exe is part of Windows Error Reporting and is capable of creating dumps for high-integrity or protected processes (it runs as a Protected Process Light in several configurations). The dump routine commonly used is MiniDumpWriteDump (from dbghelp.dll), which suspends all threads of the target to capture a consistent memory image before resuming. The PoC triggers that routine while controlling the dumper process.Creating the race / holding the target suspended.
During dump creation, the target's threads are paused. The attack's key step is to suspend the dumper (WerFaultSecure) after it has suspended the target but before it resumes it. Once the dumper is suspended, it cannot resume the target and that target remains in a suspended state indefinitely. The PoC implements monitoring and timing logic to reliably enter that state.Outcomes and limitations.
The target process is not terminated; it is paused. No kernel payloads, no unsigned drivers.
Resuming the target returns normal operation - a reboot, a service restart, or explicit resumption will recover the agent.
The technique is situational: it requires privileges and precise orchestration; it is therefore more of an escalation/evasion primitive than a trivial mass-attack vector.
Observable artifacts & detection opportunities
Because the technique uses standard Windows components, defenders must rely on behavior and telemetry correlation rather than signature only. Key observable artifacts:
- WerFaultSecure command lines and invocation timing. Legitimate WER invocations are usually correlated with crashes. An invocation of WerFaultSecure.exe with explicit dump arguments (/pid, /encfile, etc.) against an agent PID, outside of a crash context, is suspicious. Vendors and researchers have highlighted this as a primary detection vector.
- Processes stuck in Suspended state. Task managers and APIs report suspended threads/processes. A security agent that remains suspended beyond the expected dump window is an indicator.
- Process access events. Calls that open process handles with PROCESS_SUSPEND_RESUME or SeDebugPrivilege usage by unusual binaries are notable. Sysmon's ProcessAccess (Event ID 10) and ProcessCreate (Event ID 1) can be used to spot suspicious chains: a dumper launching then being accessed by another process. (Vendor writeups have used these signals in detection recipes.)
- Telemetry gaps / heartbeat loss. If an agent's telemetry ceases simultaneously with the appearance of the dumper, that temporal correlation is high-fidelity evidence of interference.
Detections and Mitigations
Below are practical recommendations you can implement in a typical enterprise SOC or endpoint stack. Each item is intentionally specific and actionable.
Sysmon rule: alert on WerFaultSecure with dump arguments
Monitor Image = C:\Windows\System32\WerFaultSecure.exe AND CommandLine matching (?i)/pid\s+\d+|/encfile and ParentImage != svchost.exe|services.exe (adjust for local baselines). On match, trigger high-priority triage. This catches non-crash dump invocations.
Detect long-lived Suspended processes and auto-remediation
Create a scheduled script or a lightweight agent rule: every minute, enumerate protected agent PIDs; if GetProcessTimes + thread states indicate Suspended for > 30s without a corresponding crash event, automatically attempt a graceful service restart (or spawn a remediation job that logs, notifies, and restarts). This reduces the window of opportunity without requiring OS changes.
Restrict/monitor SeDebugPrivilege grants
Use GPO / LAPS / PAM controls to ensure SeDebugPrivilege is granted only to named admin accounts and service accounts. Log and alert on new processes acquiring SeDebug or on token duplication events.
Harden WER invocation paths via WDAC/AppLocker
Implement an allowlist policy that prevents non-system services or non-signed admin utilities from launching WerFaultSecure.exe with arguments. Where WDAC is too strict, an AppLocker rule for WerFaultSecure.exe invocation context can block unauthorized use.
Correlation rule: WerFaultSecure → agent suspended → telemetry gap
In SIEM: if WerFaultSecure ProcessCreate → immediately agent becomes Suspended → agent heartbeat missing within 5-15s, escalate to SOC. This sequence increases fidelity and reduces false positives.
Indicators of Compromise
| File Hashes |
|---|
| 2054a0866411f22a98c3fedc200d6947facdd6046a5e51ec9109380ef0cf2dd1 |
| d989ebd417e6fae60a544e43bfc0ee63f5d9352ce0059b95ed4e7e18efbc5d0b |
| 8819d5a64d7b95314630ed54156240c855e570b94bc01a88357e626615221858 |
| 1fa74c9be827171bfff81757130dbd1f1f79436199b4c4955410cf241e2b7a88 |
| 222649815d204ce19f652b3b57c81ddda3182f7a2851b9e4166d9160b2954d13 |
| 69e9b4ef471fb1ed719a44fe0a4e5aff5b341ee5a81d22cb3c57020d76a83f04 |
| e2b2dd0984e52112965392471f6a09020eb8380aa53d48d2fb4dd3aaa7edae9b |
Final notes
EDR-Freeze is a focused demonstration that repurposes a legitimate OS capability in a way defenders must treat as a behavior to detect and mitigate. It is not a stealthy kernel rootkit nor a trivial remote-execution worm; it's a privilege-dependent tactic that exposes gaps in visibility and control around trusted system components. Vendors and researchers published PoCs and technical notes within the last few days, and early signals indicate that behavioral detections are effective when tuned.










