Listen to this Post
Introduction:
Endpoint Detection and Response (EDR) platforms are the cornerstone of modern cybersecurity, providing critical visibility into endpoint activities. However, a sophisticated technique known as EDR-Freeze allows attackers to temporarily suspend EDR processes, effectively blinding security teams during critical stages of an attack. This article delves into the mechanics of this technique, providing both offensive understanding for red teams and defensive detection strategies for blue teams, leveraging tools like KQL for threat hunting.
Learning Objectives:
- Understand the process suspension technique used to neutralize EDR telemetry.
- Learn to hunt for indicators of EDR-Freeze activity in your environment.
- Develop detection rules to identify suspicious process suspension events.
You Should Know:
1. Identifying Common EDR Processes
A prerequisite for an EDR-Freeze attack is identifying the correct process to target. Attackers often scan for known EDR process names.
PowerShell command to list running processes
Get-Process | Where-Object {$<em>.ProcessName -like "sense" -or $</em>.ProcessName -like "crowd" -or $_.ProcessName -like "sophos"}
Linux command to list processes (for Linux EDRs)
ps aux | grep -i crowd
ps aux | grep -i sophos
Step-by-step guide: This command queries all running processes and filters for common EDR-related keywords like “sense” (Microsoft Defender for Endpoint), “crowd” (CrowdStrike), or “sophos.” An attacker uses this to find the Process ID (PID) of the EDR agent. Once the PID is identified, it can be targeted for suspension.
2. Suspending a Process using PowerShell
The core of the EDR-Freeze technique involves suspending the target process, halting its execution without terminating it.
PowerShell to suspend a process by PID Suspend-Process -Id 1234 Using NirSoft's NirCmd (external tool) nircmd.exe suspendprocess 1234 Alternative PowerShell method using .NET (Get-Process -Id 1234).Suspend()
Step-by-step guide: The `Suspend-Process` cmdlet (part of the `PSSuspend` utility or similar modules) takes the identified PID as an argument. This action freezes the EDR thread, preventing it from collecting and sending telemetry to the security console. This is often preferable to termination, as terminating a critical system process can cause a system crash or trigger immediate alerts.
3. Hunting with KQL: Suspended Process Creation
Blue teams can hunt for this activity by looking for events related to the creation of suspended processes. In Microsoft Sentinel, this query looks for specific Sysmon events.
SecurityEvent | where EventID == 4688 | where NewProcessName contains "werfaultsecure.exe" | where CommandLine has "1234" // The PID of the EDR process | project TimeGenerated, Computer, SubjectUserName, NewProcessName, CommandLine
Step-by-step guide: This KQL query searches for Event ID 4688 (a new process has been created). It looks for instances of `werfaultsecure.exe` (Windows Error Reporting) being spawned with a command line that includes a specific PID. This is a key indicator because `werfaultsecure.exe` is often involved when a process crashes or is manipulated, which could be a side effect of the suspension attempt.
- Detecting Process Suspension with Sysmon (Event ID 5)
Properly configured Sysmon logging is critical for detecting process tampering. Event ID 5 logs when a process terminates.// KQL Query for Sysmon Event ID 5 (Process Terminated) - Look for EDR process termination SecurityEvent | where EventID == 5 | where Image contains "MsSense.exe" | project TimeGenerated, Computer, Image
Step-by-step guide: While suspension is different from termination, some techniques or tooling might leave traces here. More importantly, monitoring for the unexpected termination of an EDR process is a high-fidelity alert. This query alerts on the termination of
MsSense.exe, the primary process for Microsoft Defender for Endpoint.
5. Windows API Call Monitoring for NtSuspendProcess
The suspension action ultimately calls a Windows API function, typically `NtSuspendProcess` or SuspendThread. Monitoring for these calls can be highly effective.
Example Sigma rule logic for detecting NtSuspendProcess calls (conceptual) title: Suspicious NtSuspendProcess Call description: Detects calls to NtSuspendProcess targeting known security processes logsource: product: windows service: sysmon detection: selection: EventID: 10 // Process Access TargetImage|endswith: - 'MsSense.exe' - 'CSFalconService.exe' CallTrace|contains: 'NtSuspendProcess' condition: selection
Step-by-step guide: This conceptual Sigma rule outlines the logic for detecting this technique. It triggers when a process access event (Sysmon Event ID 10) targets a known EDR executable and the call stack includes a reference to NtSuspendProcess. Implementing this requires deep visibility into API calls, often provided by EDRs themselves or advanced Sysmon configurations.
6. Investigating Parent-Process Relationships
Suspicious activity often reveals itself through anomalous parent-child process relationships. For example, if a typical user application spawns a process that then accesses the EDR agent, it’s a red flag.
// KQL query to analyze process creation chain
SecurityEvent
| where EventID == 4688
| where NewProcessName contains "werfaultsecure.exe"
| extend ParentProcessName = toupper(extract(@"(.+\[^\]+)", 1, ParentProcessName))
| where ParentProcessName in~ ("POWERSHELL.EXE", "CMD.EXE", "NIRCMD.EXE")
| project TimeGenerated, Computer, ParentProcessName, NewProcessName, CommandLine
Step-by-step guide: This query builds on the earlier hunt by analyzing the parent process of werfaultsecure.exe. If the parent is a command-line interpreter like PowerShell or CMD, or a utility like nircmd.exe, it significantly increases the suspicion level, suggesting a manual attack rather than a legitimate system error.
7. Mitigation: Hardening EDR Self-Defense
Prevention is the best defense. Organizations should leverage built-in EDR features that protect the agent itself from tampering.
Group Policy (GPO) setting to protect processes (example) Path: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options Setting: "System objects: Strengthen default permissions of internal system objects" State: Enabled PowerShell to set process priority (does not prevent suspension but adds a hurdle) wmic process where name="MsSense.exe" CALL setpriority "high priority"
Step-by-step guide: While not foolproof, enabling GPO settings that strengthen system object permissions can make it harder for lower-integrity processes to interact with the EDR agent. Setting the EDR process to a high priority is a symbolic gesture that does not prevent suspension but is part of a defense-in-depth strategy. The primary mitigation is ensuring your EDR’s self-protection features are enabled and configured to block malicious attempts.
What Undercode Say:
- The Telemetry Paradox: The core challenge lies in the “telemetry paradox.” If an attacker successfully freezes the EDR, the EDR may be unable to log the very event of its own suspension. This makes indirect detection, such as a sudden, unexplained gap in telemetry from a specific endpoint, a critical alert.
- Shifting the Battlefield: This technique forces defenders to look beyond the EDR console itself. Correlating data from the network (e.g., a drop in EDR heartbeat traffic) with events from the host OS (via Sysmon) and other security layers is essential for robust detection.
The EDR-Freeze technique demonstrates that absolute reliance on a single security product is a flawed strategy. Its effectiveness hinges on the attacker’s ability to operate before the EDR can log the initial suspension action. Therefore, a mature security posture must incorporate multi-layered detection. This includes configuring preemptive logging with tools like Sysmon to capture low-level system events independently of the EDR agent. The battle is no longer just about detecting malicious code; it’s about detecting the manipulation of the very systems designed to provide detection.
Prediction:
The evolution of EDR-Freeze will lead to a new arms race in kernel-level protection. We predict a rapid shift towards EDR vendors implementing stronger self-defending mechanisms that operate at the kernel level, making userland suspension increasingly difficult. This will, in turn, push red teams towards more sophisticated kernel-level exploits to disable EDRs, further blurring the lines between advanced malware and penetration testing tools. The future of endpoint security will be a deep, ongoing struggle for control over the operating system’s core, making technologies like Kernel Data Protection (KDP) and virtualization-based security (VBS) not just advantageous but essential for enterprise defense.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mehmetergene Redteam – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
