For the last several years, EDR-impairment tradecraft has revolved around two paths: kill the process (BYOVD, vulnerable-driver abuse) or blind the sensor (tamper with configuration, uninstall the agent). EDR-Freeze introduces a third path that avoids both drivers and uninstalls entirely — it simply suspends the security agent’s threads and leaves them suspended, using nothing but a signed Microsoft binary already present on every Windows host.

The technique was published as a proof of concept and has since attracted real attention because it works entirely in user mode, requires no kernel driver, generates no crash telemetry, and produces an outcome that looks — from the agent’s own perspective — like nothing happened at all. The EDR doesn’t die. It just stops running.

How the Race Condition Works

WerFaultSecure.exe is the signed Windows Error Reporting component responsible for generating memory dumps of protected processes, including PPL (Protected Process Light) processes such as many EDR and AV engines. When invoked to dump a target process, it calls MiniDumpWriteDump, which as a side effect suspends every thread in the target process for the duration of the dump — this is normal, expected behavior needed to get a consistent memory snapshot.

The attack chain abuses the timing of that suspension:

  1. The attacker invokes WerFaultSecure.exe against the PID of the target EDR/AV process, requesting a dump.
  2. MiniDumpWriteDump suspends all threads of the target process to begin the snapshot.
  3. At the exact moment the target is suspended, the attacker races in and suspends WerFaultSecure.exe itself — before it can complete the dump and resume the target’s threads.
  4. With WerFaultSecure.exe now frozen mid-operation, it never calls ResumeThread on the target. The EDR/AV process is left suspended indefinitely — no crash, no service stop event, no uninstall, no driver signature to flag.

The attacker releases both processes when finished, and monitoring resumes with a clean gap in telemetry rather than an alertable termination event. This is what makes EDR-Freeze harder to catch than BYOVD: there is no “process X terminated” or “driver Y loaded” event to hang a rule on. The signal is an absence — a heartbeat gap — combined with an unusual parent/child relationship and command line on a binary that is rarely invoked interactively against security PIDs.

Detection Data Sources

Three signals combine to make this technique detectable with reasonable confidence:

  • Process creation of WerFaultSecure.exe with command-line arguments referencing the PID of a known security process (Sysmon Event ID 1 / DeviceProcessEvents).
  • ProcessAccess/OpenProcess handles requested against the security agent’s PID from a non-standard parent (Sysmon Event ID 10).
  • Agent heartbeat loss — most EDR platforms emit a periodic self-telemetry or “last seen” signal; a gap correlated with the above events is the strongest indicator.

Sigma Rule: Suspicious WerFaultSecure Invocation Targeting Security Processes

title: Suspicious Process Suspension via WerFaultSecure (EDR-Freeze)
id: c4f1e9a2-7b3d-4e6f-9a1c-2d5b8e7f4a3c
status: experimental
description: >
  Detects invocation of WerFaultSecure.exe with command-line arguments consistent
  with dumping a security/AV/EDR process, which may indicate the EDR-Freeze
  process suspension technique (T1562.001).
references:
  - https://attack.mitre.org/techniques/T1562/001/
  - https://detection.fyi/sigmahq/sigma/windows/process_creation/proc_creation_win_hktl_edr_freeze/
author: SOC Analyst Hub
date: 2026-08-26
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith: '\WerFaultSecure.exe'
  selection_args:
    CommandLine|contains:
      - '/pid'
      - '/type full'
      - '/wer'
  selection_parent_anomaly:
    ParentImage|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\rundll32.exe'
  filter_legitimate_wer:
    ParentImage|endswith:
      - '\WerFault.exe'
      - '\svchost.exe'
  condition: selection_image and selection_args and selection_parent_anomaly and not filter_legitimate_wer
falsepositives:
  - Legitimate crash-dump collection tooling invoking WerFaultSecure manually
  - EDR self-diagnostic or support-triggered memory captures
level: high

Sigma Rule: Suspension Immediately Following WerFaultSecure ProcessAccess to a Security PID

title: Process Suspend Handle Requested After WerFaultSecure ProcessAccess
id: d5e2f0b3-8c4e-4f7a-ab2d-3e6c9f8a5b4d
status: experimental
description: Detects a suspend-capable handle request (PROCESS_SUSPEND_RESUME) shortly after WerFaultSecure.exe opens a handle to a security process, consistent with the EDR-Freeze race condition.
references:
  - https://www.picussecurity.com/resource/blog/edr-freeze-the-user-mode-attack-that-puts-security-into-a-coma
author: SOC Analyst Hub
date: 2026-08-26
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: process_access
  product: windows
detection:
  selection:
    SourceImage|endswith: '\WerFaultSecure.exe'
    GrantedAccess|contains:
      - '0x1FFFFF'
      - '0x1F0FFF'
  condition: selection
falsepositives:
  - Full-access dump requests for legitimate crash analysis of the same processes
level: medium

KQL (Microsoft Sentinel / MDE)

DeviceProcessEvents
| where FileName =~ "WerFaultSecure.exe"
| where ProcessCommandLine has_any ("/pid", "/type full", "/wer")
| where InitiatingProcessFileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "rundll32.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          ProcessCommandLine, AccountName
| sort by Timestamp desc

Correlate with agent heartbeat gaps by joining against your EDR’s own health/telemetry table (vendor-specific — e.g., DeviceEvents action types for CrowdStrike sensor health, or Defender’s DeviceInfo last-seen deltas):

let suspiciousWer = DeviceProcessEvents
| where FileName =~ "WerFaultSecure.exe"
| where ProcessCommandLine has "/pid"
| project Timestamp, DeviceName;
DeviceInfo
| where isnotempty(OSPlatform)
| summarize LastSeen = max(Timestamp) by DeviceName
| join kind=inner suspiciousWer on DeviceName
| where LastSeen between ((Timestamp - 1h) .. (Timestamp + 15m))
| project DeviceName, WerFaultTimestamp = Timestamp, AgentLastSeen = LastSeen

Threat Hunting Approach

  1. Baseline WerFaultSecure invocations. In most environments, this binary fires only via the WER service itself (svchost.exe parent) after a genuine crash. Any invocation with a shell or scripting parent is anomalous by default and worth a standing hunt query, not just a real-time rule.
  2. Map security process PIDs to WER activity. Cross-reference the PID argument passed to WerFaultSecure against your EDR/AV process list at the time of invocation — an exact PID match to a protected agent process is a high-confidence hit.
  3. Watch for heartbeat gaps without a corresponding uninstall, service-stop, or crash event. A silent multi-minute telemetry gap on an otherwise healthy endpoint, especially one immediately preceded by WerFaultSecure activity, is the clearest fingerprint EDR-Freeze leaves behind.

Mitigations

Because the technique lives entirely in user mode, kernel-level PPL protections and driver-blocklisting won’t stop it. Vendors are rolling out self-protection that specifically monitors for suspend attempts against their own process threads and for anomalous WerFaultSecure activity targeting their PIDs — confirm with your EDR vendor whether this hardening has shipped. In the interim, the detections above close the visibility gap: even if the suspension itself can’t be blocked, the invocation pattern and the resulting telemetry gap are both observable and alertable.