A new Living Off the Land (LOTL) threat has emerged that fundamentally challenges how we think about endpoint protection.

EDR-Freeze is a sophisticated and stealthy evasion technique that exploits legitimate Windows functionality to suspend security software, rendering it temporarily blind to malicious activity. Unlike Bring Your Own Vulnerable Driver (BYOVD) attacks, this technique operates entirely in user-mode using native Windows components.

This analysis provides a technical deep dive into how the attack works and explains the comprehensive detection strategy we’ve implemented in the ThreatDown agent to identify and prevent this threat before it can compromise system security.

Understanding the threat

To appreciate the sophistication of EDR-Freeze, we need to understand what makes it different from traditional approaches to disabling security software. Historically, attackers have used various stealthy methods to gain access to systems, including exploiting vulnerabilities and deploying malicious drivers. These approaches were noisy and increasingly easy for defenders to detect.

EDR-Freeze takes a fundamentally different approach. Rather than attacking security software directly, it manipulates the operating system to put security processes into a suspended state—much like freezing a video while it’s playing.

The security software isn’t damaged or terminated; it simply stops processing events, creating a window of opportunity for undetected malicious activity.

Technical background—the attack surface

The elegance of EDR-Freeze lies in its abuse of three core Windows components:

1. MiniDumpWriteDump, a DbgHelp library function designed to create process memory snapshots. 

2. WerFaultSecure.exe, a Windows Error Reporting service component with WinTCB protection level. 

3. Protected Process Light (PPL), a Windows security feature protecting critical processes. 

The heart of EDR-Freeze is a Windows debugging function called MiniDumpWriteDump:

BOOL MiniDumpWriteDump(
     HANDLE                               hProcess,
     DWORD                                ProcessId,
     HANDLE                               hFile,
     MINIDUMP_TYPE                        DumpType,
     PMINIDUMP_EXCEPTION_INFORMATION      ExceptionParam,
     PMINIDUMP_USER_STREAM_INFORMATION    UserStreamParam,
     PMINIDUMP_CALLBACK_INFORMATION       CallbackParam
);

This function, which developers use every day to troubleshoot application crashes, creates a snapshot of a program’s memory at a specific moment in time. To ensure the snapshot is consistent and accurate, Windows temporarily pauses all activity within the program—suspending every thread in the target process while the snapshot is created.

Under normal circumstances, the pause lasts only a fraction of a second, is imperceptible to users, and has no meaningful impact on system security. However, if MiniDumpWriteDump is prevented from completing its work, the suspended threads remain suspended indefinitely, and the target program is frozen in time—unable to process new information or respond to events.

Attackers looking to use MiniDumpWriteDump to pause security software encounter an obstacle: modern security software uses a Windows feature called Protected Process Light (PPL), which acts as a shield around critical system processes and prevents ordinary programs from interfering with them. Software running with normal user privileges cannot simply manipulate a protected security process.

This is where the second component enters the picture. Windows Error Reporting, the system that creates those familiar crash reports when applications fail, includes a specialized component called WerFaultSecure.exe. This component runs with extraordinarily high privileges—specifically, the Windows Trusted Computing Base level—which grants it authority to interact with even protected processes. After all, if a protected process crashes, the system needs a way to capture diagnostic information.

The attack leverages this by instructing WerFaultSecure.exe to create a memory dump of the target security software, causing the security software’s threads to suspend.

The typical command-line syntax is:

WerFaultSecure.exe -u -p <PID> -s <SessionID>

Where: 

• -u indicates unmanaged fault 

• -p specifies the target Process ID 

• -s specifies the session ID

The final piece of the attack is a race condition, a technique that exploits the precise timing of events. The implementation requires more sophistication than simply launching WerFaultSecure.exe with command-line parameters. The attack tool must create an inheritable file handle where the memory dump will be written, then spawn WerFaultSecure.exe as a PPL with the appropriate protection level to match the target EDR process. This spawning uses specific Windows APIs that configure process attributes, including PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, ensuring the dumper has sufficient privileges to interact with protected security software.

Once WerFaultSecure.exe begins execution with these carefully crafted parameters, the attack tool monitors the target security process with extreme frequency, checking its status dozens of times per second. The moment it detects that the security software has entered a suspended state, it immediately suspends the WerFaultSecure.exe process itself. This creates a deadlock: WerFaultSecure.exe cannot complete the memory dump operation because it has been frozen, and the security software cannot resume operation because WerFaultSecure.exe never finishes its work.

As a result, the security software remains trapped in suspended animation until someone manually terminates the WerFaultSecure.exe process.

Summarizing the timing-based race condition:

• T0: WerFaultSecure.exe launches and begins calling MiniDumpWriteDump on target EDR process.
• T1: Target process threads enter a suspended state. 

• T2: EDR-Freeze tool detects suspension (monitoring thread states). 

• T3: EDR-Freeze immediately suspends WerFaultSecure.exe process.
• Result: Target EDR remains frozen because WerFaultSecure.exe cannot complete the dump operation and resume threads. 

From an attacker’s perspective, this technique offers several advantages: it leaves no unusual drivers on the system, uses only components that belong there, and creates a clean window of time during which security monitoring is completely disabled.

The security software doesn’t crash or generate alerts—it simply stops observing. Once the attacker is done, they release the freeze, and security monitoring resumes as if nothing happened.

ThreatDown detection strategy

As a result of fundamental architectural decisions made during the platform’s design, the ThreatDown agent has never been susceptible to this attack. The ThreatDown kernel driver implements comprehensive resource protection at the system’s deepest level. This protection mechanism guards access to critical agent resources—including files, processes, and registry keys—from any unauthorized process attempting to interact with them.

The protection works by filtering access requests through the kernel driver, which evaluates whether the requesting process has legitimate authority to perform the requested operation. When WerFaultSecure.exe (or any other process) attempts to open a handle to ThreatDown’s processes, our kernel driver intercepts the request. Even though WerFaultSecure.exe operates with high privileges, the driver denies the handle acquisition if the requesting process isn’t explicitly authorized. Without a valid handle to our process, WerFaultSecure.exe cannot initiate the memory dump operation that would trigger the thread suspension—effectively preventing the attack before it can begin.

This protection extends beyond just blocking WerFaultSecure.exe. Any unauthorized process attempting to access ThreatDown’s resources encounters the same barrier, regardless of its privilege level or the specific technique employed. The kernel driver doesn’t need to recognize specific attack patterns or known malicious tools; it simply enforces a fundamental principle: only authorized entities can interact with agent resources.

Consequently, the ThreatDown agent doesn’t require detection rules specifically targeting EDR-Freeze behavior. The attack fails at its most fundamental step—unable to gain the process access necessary to execute the suspension technique.

This represents a crucial security principle: Prevention at the architectural level is more robust than detection of specific attack patterns. However, recognizing that the broader security landscape includes many different endpoint protection solutions—and understanding the value of sharing knowledge across the community—we present in the following sections a comprehensive analysis of how organizations can implement detection strategies for EDR-Freeze.

Detection Approaches 

Defending against EDR-Freeze requires understanding that we’re not looking for malicious software in the traditional sense. Instead, we’re looking for legitimate system components being used in illegitimate ways. This calls for a behavioral approach that examines the context and patterns of system activity rather than searching for bad files or signatures.

The first and most direct detection approach involves monitoring how WerFaultSecure.exe is used. Under normal circumstances, this component is invoked by the Windows Error Reporting service in response to application crashes. The parent process is almost always either the error reporting service itself or a system service host. The command-line parameters follow predictable patterns related to crash report generation. When we observe WerFaultSecure.exe being launched with parameters that specify a target process ID—particularly when that target is security software or other critical system processes like the Local Security Authority Subsystem Service—we should immediately flag this as suspicious.

Legitimate crash reporting doesn’t work this way. The error reporting system responds to crashes; it doesn’t proactively target specific processes. We examine the full context of these invocations: What process launched WerFaultSecure.exe? Was it a command prompt, PowerShell, or an unknown executable? These parent processes would never appear in legitimate crash-reporting scenarios. When we see WerFaultSecure.exe being launched from unexpected sources with parameters pointing at our own processes or other security software, we recognize this as a high-probability attack.

A pseudo-rule for clarity might look like this:

IF process_name == "WerFaultSecure.exe" AND
    command_line CONTAINS "-p" AND
    target_pid IN [edr_processes, antivirus_processes, security_tools] THEN
    ALERT HIGH_SEVERITY

Understanding process lineage provides another valuable detection signal. Every process on a Windows system has a parent process that launched it, and these parent-child relationships follow predictable patterns in legitimate operation. WerFaultSecure.exe should only be launched by specific system components.

When we observe WerFaultSecure.exe being created as a child of cmd.exe, PowerShell, or especially an unknown executable, this represents a significant deviation from normal behavior. We track these relationships and assign risk scores based on how unusual the pattern is compared to typical system behavior. A WerFaultSecure.exe process spawned from a command-line tool scores much higher than one launched by the error reporting service.

Implications for organizations 

For organizations evaluating their security posture, EDR-Freeze highlights an important reality: security software itself is a target, and attackers are developing increasingly sophisticated techniques to blind or disable it. The days of simply deploying endpoint protection and assuming it will always be operational are over. Modern threats require security solutions that can defend themselves while defending the broader system.

The techniques we’ve implemented in ThreatDown—monitoring for attacks against the security software itself and implementing self-protection mechanisms—represent an essential evolution in endpoint protection. However, no single security product can provide complete protection in isolation. The complexity of modern attacks demands comprehensive telemetry collection across multiple layers: process creation with full context, access rights requests, file system activity (including transient files), privilege modifications, and continuous health monitoring of security agents themselves.

Security teams should monitor for the behavioral indicators described here: unusual WerFaultSecure.exe activity, unexpected process suspensions, access attempts requesting suspension rights against security software, and gaps in security telemetry that might indicate successful attacks. The correlation of multiple weak signals often provides stronger detection than any single indicator.

Beyond detection, organizations should consider whether their incident response procedures account for scenarios where security software itself has been compromised or disabled. Do your playbooks include steps to verify that security agents are functioning correctly?

The Managed Detection and Response advantage 

The operational challenges described above—from correlating weak signals across multiple telemetry sources to maintaining incident response procedures that account for attacks on security infrastructure—represent a significant burden for many organizations. Building and maintaining the expertise required to effectively detect sophisticated threats like EDR-Freeze demands substantial investment in specialized personnel, continuous training, and operational infrastructure.

This is where ThreatDown’s Managed Detection and Response (MDR) service transforms the security equation. Rather than requiring organizations to develop and maintain this expertise internally, our MDR service provides access to a team of highly skilled security analysts who continuously monitor for advanced threats. These analysts bring deep technical knowledge of attack techniques, immediate recognition of suspicious patterns, and the experience to distinguish genuine threats from benign anomalies.

The advantages of a managed approach extend beyond simply having experts available. When our analysts detect suspicious WerFaultSecure.exe activity or observe behavioral patterns associated with EDR-Freeze, they can immediately investigate, correlate events across your environment, and determine whether remediation is required—all while your business continues operating normally. The response happens in minutes rather than hours or days, without requiring your internal teams to drop everything and become instant experts in this specific attack technique.

Perhaps most importantly, MDR provides continuous coverage that internal teams often struggle to maintain. Sophisticated attacks don’t respect business hours or holiday schedules. Our analysts monitor around the clock, ensuring that an attack attempt on a Sunday night receives the same expert attention as one during peak business hours.

This continuous vigilance dramatically shrinks the window of opportunity for attackers, even for techniques designed to operate stealthily. The managed approach also addresses the challenge of keeping pace with evolving threats. As attackers modify their techniques or develop new variants of attacks like EDR-Freeze, our analysts update detection strategies across all monitored environments simultaneously.

Organizations benefit from collective defense: insights gained from attempted attacks against any customer enhance protection for all customers. This shared intelligence creates a force multiplier that individual organizations would struggle to replicate independently. For organizations without dedicated security operations centers—or those whose internal teams are already stretched managing day-to-day security tasks—MDR removes the burden of becoming experts in every new attack technique that emerges. Your teams can focus on strategic initiatives and business enablement, confident that sophisticated threat detection and response are being handled by specialists whose sole focus is identifying and mitigating advanced threats.