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.


Daily Term
Can you guess today’s cybersecurity word in 6 tries?
Play now

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.