Listen to this Post
Introduction:
A new offensive security tool dubbed EDRFreeze has emerged, demonstrating a novel technique to bypass Endpoint Detection and Response (EDR) solutions. By weaponizing a legitimate Windows function intended for error reporting, attackers can suspend EDR processes, effectively rendering them inert and blind to subsequent malicious activity. This method highlights the ongoing cat-and-mouse game between defenders and attackers exploiting trusted system mechanisms.
Learning Objectives:
- Understand the core mechanics of how EDRFreeze abuses the Windows Error Reporting (WER) `WerFault.exe` process.
- Learn key detection strategies to identify potential process suspension attacks within your environment.
- Explore mitigation techniques to harden systems against this specific bypass method.
You Should Know:
1. The Core Vulnerability: MiniDumpWriteDump Function
The technique hinges on the `MiniDumpWriteDump` function, a part of the Windows Debugging API (DbgHelp.dll). While designed for creating crash dumps for debugging, it suspends all threads in the target process during the dump creation. EDRFreeze abuses this by triggering a mini-dump on EDR processes.
// C++ Snippet illustrating the function call
include <windows.h>
include <DbgHelp.h>
int main() {
// Get PID of target EDR process (e.g., via <code>tasklist</code>)
DWORD pid = 1234;
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
// Create a dump file
HANDLE hFile = CreateFile(L"edr.dmp", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
// This call suspends the target process threads
MiniDumpWriteDump(hProcess, pid, hFile, MiniDumpWithFullMemory, NULL, NULL, NULL);
CloseHandle(hFile);
CloseHandle(hProcess);
return 0;
}
Step-by-step guide: An attacker would first enumerate running processes to identify the EDR’s core agent (e.g., CrowdStrike, SentinelAgent, MsMpEng). Using the Process ID (PID), the code above loads the target process and calls MiniDumpWriteDump. The EDR process threads are suspended for the duration of the dump creation, creating a window of opportunity.
2. Identifying Suspicious WerFault Activity
A key detection opportunity lies in monitoring the `WerFault.exe` process. It is unusual for WerFault to be launched targeting a stable, core security process. The following PowerShell command can help identify WerFault processes with command-line arguments pointing to security software.
Get-CimInstance Win32_Process -Filter "Name='WerFault.exe'" | Select-Object ProcessId, CommandLine
Step-by-step guide: This PowerShell command queries all running `WerFault.exe` processes and displays their command-line arguments. Security teams should look for instances where the `-p` parameter (specifying the PID) points to a known EDR or antivirus process. This is a high-fidelity indicator of compromise for this specific attack.
3. Hunting for Suspended EDR Threads
Once the dump is complete, the EDR process may remain in a suspended state. The following PowerShell script checks for processes with a high number of suspended threads, which is atypical for active security agents.
Get-Process | Where-Object {$<em>.Threads.ThreadState -contains "Wait" -and ($</em>.Threads | Where-Object {$<em>.WaitReason -eq "Suspended"}).Count -gt 5} | Format-Table ProcessName, Id, @{Name="SuspendedThreads"; Expression={($</em>.Threads | Where-Object {$_.WaitReason -eq "Suspended"}).Count}}
Step-by-step guide: This script iterates through all running processes. It counts threads where the `WaitReason` is “Suspended”. A healthy process will have mostly “Waiting” or “Ready” threads. Finding a critical security process with a large number of suspended threads is a major red flag.
4. Windows Sysmon Detection for Image Load
EDRFreeze must load `DbgHelp.dll` to call the critical function. Configuring Sysmon to log DLL loads by `WerFault.exe` can provide crucial telemetry. The following is a sample Sysmon configuration rule.
<Sysmon schemaversion="4.90"> <EventFiltering> <RuleGroup name="" groupRelation="or"> <ImageLoad onmatch="include"> <Image condition="end with">WerFault.exe</Image> <ImageLoaded condition="contains">DbgHelp.dll</ImageLoaded> </ImageLoad> </RuleGroup> </EventFiltering> </Sysmon>
Step-by-step guide: Deploy this Sysmon configuration to log events when `WerFault.exe` loads DbgHelp.dll. While legitimate crash reporting will also trigger this, correlating these events with the target PID being a security tool creates a strong detection signature.
5. Mitigation via Windows Defender ASR Rules
Application Control and Attack Surface Reduction (ASR) rules can block this activity. The “Block credential stealing from the Windows local security authority subsystem (lsass.exe)” rule can be adapted, as it already governs `WerFault.exe` behavior related to sensitive processes.
Check ASR Rule Status in PowerShell Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
Step-by-step guide: While not a direct configuration, ensuring ASR rules are enabled and in “Block” mode adds a layer of defense. The underlying principle of blocking `WerFault.exe` from interacting with protected processes is key. Audit your ASR rules using the PowerShell command above.
6. Process Mitigation Policy: Disable Dumping
A more targeted mitigation is to use the Windows `SetProcessMitigationPolicy` API to prevent a process from being dumped. This can be applied to critical EDR components, though it may interfere with legitimate debugging.
PowerShell to set mitigation policy for a running process (example) $ProcessMitigation = New-Object -ComObject Microsoft.Security.ApplicationId.Policies.Management This is a conceptual example; exact cmdlets may vary. The policy would be set during EDR installation.
Step-by-step guide: This is an advanced mitigation that EDR vendors themselves would implement. It uses a process mitigation policy flag (DisableSystemCalloutScan or similar) to mark the process as undumpable. This would cause the `MiniDumpWriteDump` call to fail when targeting the hardened process.
7. Implementing Kernel-Level Protections
The ultimate defense involves kernel-mode components. EDRs with kernel drivers can register callbacks for process and thread creation. A kernel driver could detect and block a `WerFault.exe` instance attempting to suspend a protected process.
// Conceptual Kernel Callback Function (PsSetCreateThreadNotifyRoutine)
NTSTATUS ThreadNotifyCallback(HANDLE ProcessId, HANDLE ThreadId, BOOLEAN Create) {
if (!Create) { // Thread is being terminated or suspended?
PEPROCESS Process;
PsLookupProcessByProcessId(ProcessId, &Process);
// Check if the target process is a protected EDR component
if (IsProtectedProcess(Process)) {
// Check if the caller is WerFault.exe
if (IsCallerWerFault()) {
DbgPrint("Blocked thread operation on protected process by WerFault!\n");
return STATUS_ACCESS_DENIED; // Block the operation
}
}
}
return STATUS_SUCCESS;
}
Step-by-step guide: This C code is a simplified example of a kernel callback routine. EDR vendors can implement such callbacks to get notified of thread state changes system-wide. If a thread in a protected EDR process is about to be suspended by an untrusted caller like WerFault.exe, the operation can be blocked at the kernel level.
What Undercode Say:
- Abuse of Legitimate Mechanisms is the New Normal. This attack is part of a clear trend where adversaries move away from malware and instead leverage signed, trusted OS tools and functions. Detection logic must now account for malicious use of benign system components.
- Detection Engineering Requires Deep System Understanding. Defending against such techniques isn’t about new signatures but about understanding expected vs. anomalous behavior of core Windows subsystems like WER. The highest-value detections will be behavioral, focusing on the context of an action rather than the action itself.
The EDRFreeze technique is significant not for its complexity, but for its elegance in turning a defensive feature into an offensive weapon. It forces a re-evaluation of what “normal” WER activity looks like on an endpoint. While the immediate impact can be mitigated by EDR vendors updating their agents with anti-tampering measures, the broader lesson is permanent: every system feature accessible to userspace is a potential attack vector. The defense requires continuous monitoring of process interactions, thread states, and DLL lifecycles, moving security monitoring to a more granular, system-level perspective.
Prediction:
The success of EDRFreeze will catalyze a wave of similar research into other Windows system functions that involve temporary process suspension or introspection. We predict a short-term surge in bypasses targeting other diagnostic and reporting features, such as Windows Performance Recorder or Event Tracing for Windows (ETW). In response, EDR vendors will accelerate the integration of their agents deeper into the kernel, leveraging Hypervisor-Protected Code Integrity (HVCI) and secure core principles to create protected processes that are more resilient to user-space manipulation. This will inevitably lead to an escalation where attackers focus more on kernel-level exploits or firmware attacks, making the defense-in-depth strategy of application control, least privilege, and robust monitoring more critical than ever.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Zack Allen – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
