EDR-Freeze: suspending endpoint security processes through WerFaultSecure

The gap EDR-Freeze fills in a red team exercise

Endpoint agents are built to watch. The README describes the tool in one blunt sentence: it puts a process of EDR or AntiMalware into a coma state. That phrasing is not a bug, it is the design. A red team operator who has a foothold on a Windows host often finds that the security agent notices the very step the operator wants to run, and reacts before the operator is finished.

Rather than trying to hide the action, EDR-Freeze removes the observer for a measured window. The target process stops executing for a number of milliseconds the caller chooses, then continues exactly where it left off. Nothing is killed, uninstalled or corrupted, so the host looks the same after the run as it did before it.

The audience is narrow and stated in the repository itself: the author files the project under tools for security researchers. It assumes you already know how to find the PID of the agent you want to quiet, and how to reach a command line on the host. It is not a detection evasion suite, a scanner, or a privilege escalation path. It is a pause button, and its value depends entirely on what you plan to do during the pause.

Exploiting WerFaultSecure instead of bringing your own vulnerable driver

The mechanism is the interesting part. The README states that EDR-Freeze exploits a software vulnerability in WerFaultSecure, the Windows error reporting component, to suspend the processes of EDRs and antimalware. The effect is the same as suspending a thread in the target process, but it arrives through a path the product does not expect.

What this avoids is the pattern the author names in the description, BYOVD, Bring Your Own Vulnerable Driver. The usual way to tamper with a protected security process is to load a signed but exploitable driver and use it to issue kernel operations. That route needs a driver file, a matching certificate, and often a reboot, and it leaves traces on disk that defenders look for. EDR-Freeze works in user mode, so no additional driver has to be installed.

The README also claims the tool can run on the latest version of Windows, and it is specific about the tested configuration. The experiment was conducted with Windows 11 24H2 at the time of project creation, and the author flags that qualifier in italics. Read it as a tested version rather than a permanent guarantee, because Windows error handling is exactly the kind of surface that changes between feature updates.

Two arguments, one executable: target PID and sleep time

The command line surface is deliberately tiny. The README documents the syntax as EDR-Freeze.exe with a target PID and a sleep time, and gives one example that freezes process 1234 for ten thousand milliseconds.

**EDR-Freeze.exe [TargetPID] [SleepTime]**
*Example: __EDR-Freeze.exe 1234 10000__*

The first line is the documented signature, the second the example from the README. The sleep value is in milliseconds, so one thousand is one second and three thousand is the upper end of the range the author later recommends.

Two practical notes follow from that design. The PID is resolved by the caller, not by the tool, so a mistyped or stale PID either targets the wrong process or fails outright. And because the argument is a single PID rather than a name or a pattern, covering a machine with several agents means running the tool once per agent, each with its own short window. The README does not document what happens when the PID does not exist, so treat that as undefined behaviour rather than something to rely on in a script.

Building from the Visual Studio solution in the repository

There is no install script, no package manager entry and no binary release artifact listed in the README, so the project has to be built. The repository layout points at the usual Microsoft toolchain: EDR-Freeze.sln and EDR-Freeze.vcxproj sit at the top level next to EDR-Freeze.cpp, with PPLHelp.cpp, PPLHelp.h, ProcessMisc.cpp and ProcessMisc.h as the remaining translation units and headers.

That file set explains a good deal about the design without any extra documentation. PPLHelp is the protected process light area of Windows, where code running inside a PPL process cannot be touched by ordinary tooling. ProcessMisc is the general process utility layer, which is where PID lookup, open and suspend style calls would sit. The naming is the evidence, and the README says nothing further about the internals, so treat any more specific claim as guesswork.

Open the solution in a recent Visual Studio with the C++ desktop workload, build the Release configuration, and you get EDR-Freeze.exe. The README does not document a command line build, a toolset version, or the runtime prerequisites, so expect to settle those yourself on the first attempt. There is also no stated dependency to install, which is consistent with a tool that claims to work in user mode without extra components.

The author's own advice: freeze briefly, act immediately

The README gives a short operational recipe, and it is worth reading literally. Instead of freezing an agent for a long time, incorporate the tool into a script that halts all antimalware and EDR processes for a short period of one to three seconds and then executes the pending tasks immediately after the suspension succeeds. The longer you hold the agent, the more likely something else notices the gap.

There is a second reason for the short window. The author warns that the GUI may become unresponsive in some cases, so the sleep time should be as short as possible, with the script finishing before the agent resumes. In other words, the tool is not meant to be run and left alone.

The alternative the author offers is more direct still: insert the code you want to execute directly into the source code of EDR-Freeze, as shown in the README image. Building your payload into the binary removes the external process launch from the sequence and lets you control the timing precisely, at the cost of recompiling for every target machine.

Where the approach stops working

Several limits are visible in the documentation itself.

The freeze is temporary and non destructive, so this is not a way to disable protection permanently. The target resumes when the timer ends, and any long running operation will overlap with a live agent.

The mechanism depends on a flaw in WerFaultSecure. A patched Windows build could close it, and the README only confirms behaviour on Windows 11 24H2. If the flaw is fixed, the tool does not degrade gracefully, it stops suspending anything.

The interface is single PID and single window. There is no selection by process name, no handle to a service, no filtering by vendor, so an operator facing a standard Windows host with several agents runs the tool repeatedly and must keep track of the clock.

Licensing is the last gap. The repository does not state a licence, and the README does not mention one either, so redistribution and internal use have no documented permission attached to them.

How EDR-Freeze differs from the BYOVD and PPL routes

The alternative that the README itself points at is a different project by the same author, CreateProcessAsPPL, described in the repository links as a tool to run a process with PPL without a driver. The two solve opposite halves of the same problem. CreateProcessAsPPL starts your own process inside the protected process light boundary, which is about gaining a privileged, tamper resistant position for the code you launch. EDR-Freeze takes the position of the defender's agent and suspends it, which is about removing an observer for a moment. Neither replaces the other, and using them together is a common arrangement in this line of work.

Compared with the BYOVD approach the README names, the difference is in the cost and the footprint. A BYOVD route needs a signed but vulnerable driver on disk, which is a heavier artifact to manage and easier for a defender to spot. EDR-Freeze stays in user mode and leaves no driver behind. The trade is that user mode means a smaller reach: it works against processes it can act on as a user, and it gives no lasting control once the sleep timer expires.

Editorial conclusion

Treat EDR-Freeze as a research and red team instrument for the narrow case where you hold authorization on the endpoint and need a one to three second gap inside an agent's view. It is the wrong choice for long lived stealth, for machines you do not own, or for any use that needs durable privilege escalation, since the frozen process wakes up exactly when the sleep timer expires. Verify three things before relying on it: that the target PID you pass still points at the agent you mean, that the built executable runs on the Windows build in front of you, and that your own authorization covers suspending security software on that host.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. TwoSevenOneT/EDR-Freeze on GitHub