Pause, Play, Breach: Inside the EDR-Freeze Technique

One morning burglars enter your house, but instead of disabling the alarm, they simply pause it. The lights stop flashing, the sirens go silent, yet the system isn’t broken, just frozen. That’s exactly the trick behind a new attack technique called EDR-Freeze, which targets Windows security tools.

What is EDR-Freeze?

EDR-Freeze is a method discovered by researchers that abuses a built-in Windows debugging feature. Instead of deploying malware to kill antivirus or EDR (Endpoint Detection & Response) agents which usually raises red flags attackers can simply suspend their processes.

• This is done by using Windows’ “process suspension” APIs, normally meant for troubleshooting.
• Once frozen, the EDR or antivirus engine can’t scan, log, or block malicious activity.
• It’s stealthy because the software is not “killed” it just appears idle, giving attackers a quiet window to act.

Why This Matters

·       Low-skill friendly: The technique doesn’t require malware coding. Even attackers with minimal skills can replicate it with freely available tools.

·       Silent bypass: Most security monitoring relies on detecting crashes or shutdowns. Suspended processes don’t always trigger alerts.

·       Not a vulnerability but a feature abuse: Microsoft hasn’t patched this because it’s technically “intended behavior.” That makes it a living-off-the-land attack vector.

How the Technique Works:

Windows APIs leveraged:

·       Attackers abuse functions like NtSuspend Process and NtResumeProcess (part of the Native API) to freeze or unfreeze a process at will.

·       These calls can be accessed via PowerShell, C#, or even Python scripts using standard libraries.

Tools that can be abused:

·       Task Manager (right-click→ Suspend Process)

·       Sysinternals Process Explorer

·       PowerShell modules (Stop-Process -Suspend)

·       Custom malware loaders embedding API calls

Why it’s stealthy:

·       Terminating an AV/EDR process often generates an alert.

·       Suspending it keeps the process “alive” in memory but unresponsive, making it appear normal in high-level monitoring.

Detection challenges:

·       Suspended processes often still show up as “running” in dashboards.

·       Unless an EDR explicitly tracks thread states, analysts may not notice.

Abuse scenarios:

·       Freezing EDR before executing credential dumping tools like Mimikatz.

·       Temporarily suspending antivirus to drop ransomware payloads.

·       Using EDR-Freeze inside red team engagements to simulate advanced evasion.

Lessons Learned

Attackers don’t need exploits when features suffice.

·       EDR-Freeze is not a bug but an abuse of legitimate system functionality. This shows the growing trend of “feature-as-an-attack.”

Stealth is evolving.

·       Classic defenses (e.g., monitoring for terminated services) are less reliable because attackers can now pause rather than kill.

Vendor resilience gaps.

·       Many security products aren’t designed to detect or self-heal from suspension. This exposes a blind spot in agent architecture.

Incident response complexity.

·       Suspended EDRs may cause responders to misinterpret system health, assuming a false sense of protection.

Living-off-the-land keeps expanding.

·       Today it’s process suspension, tomorrow it could be another overlooked Windows feature. Defenders must anticipate misuse of “everyday” tools.

What Security Teams Should Do

Log API calls: Track usage of NtSuspendProcess and NtResumeProcess via Sysmon or ETW (Event Tracing for Windows).

Hunt for anomalies: Look for non-admin processes suspending high-value targets like MsMpEng.exe (Windows Defender) or EDR vendor binaries.

Baseline normal usage: Developers or admins may legitimately suspend processes during debugging anything outside this baseline is suspect.

Restrict debugging privileges: Ensure only approved admin groups can use suspension APIs or debugging tools.

EDR vendor configurations: Push vendors to implement watchdog processes — secondary services that detect and auto-resume suspension.

Application whitelisting: Limit execution of PowerShell or scripts that can call native APIs.

Incident Response Playbook Additions

· Validate EDR responsiveness: During IR, test if security tools are actually scanning/logging or just idling.

· Add suspension checks: Incorporate “process state verification” into IR triage steps.

· Use deception: Deploy decoy processes or honey tokens that alert when suspension APIs are used.‍

· Educate analysts: Make them aware that “green check marks” in dashboards don’t always equal active defense.

Red team drills: Include EDR-Freeze scenarios in table top and purple team exercises.