How Hackers Are Using This Simple Trick to Silently Disable EDR!

This week, we're exploring the latest technique attackers are using to silently disable EDR software. Interestingly this involves no malware!

Attackers have a problem.

Once they break into a system, one thing stands in their way:

The EDR agent (EDR = Endpoint Detection & Response agent).

If the EDR spots malware, it kills it instantly.

The file gets quarantined. SOC gets alerted. Game over.

So, step one for attackers?

"Kill the EDR"

But there’s a catch:

EDRs now come with 'tamper protection'.

Regular users can’t just open it and hit “disable.” Access is denied.

But then, how do attackers disable an EDR?

Latest answer: Using an EDR!

Lets explore how.

---

🔍 The Attack Flow: A Step-by-Step Look:

Let’s break down how attackers are exploiting this latest technique:

1. Attacker signs up for free trials of EDR products (many offer them).
   

2. On a compromised system, attacker installs the trial EDR (requires local admin rights).
   

3. Attacker now identifies the file hash value of the real EDR running on the system > This can be gathered by running a command such as Get-FileHash "C:\Program Files\EDR.exe" on Windows > Attacker copies the hash.
   

4. Attacker now opens the trial EDR > Navigates to 'Blocked applications' feature (All EDRs allow you to submit the hash of a file that you want blocked) > Adds the hash value copied earlier.
   

5. Trial EDR now blocks the real EDR from running > Attacker then turns off key protections in the trial EDR > The endpoint is now fully vulnerable!

   ---

💡 Key Insights & Lessons:

1. Sometimes, it takes a diamond to cut a diamond. And an EDR to take down another EDR.
   

2. You’ve probably heard of Bring Your Own Driver (BYOD) vulnerabilities — where attackers load a legitimate, signed driver that contains a flaw, exploit that flaw to gain kernel access, and then do bad things from the inside. That’s already dangerous. But here, it goes one level deeper. Instead of any vulnerable driver, the attacker uses an EDR’s own driver.
   

3. Our mind generally frames cyberattacks as "malicious tools doing malicious things". But its also possible for "legit tools to do malicious things" and when that happens, its very hard to detect them. The most dangerous exploit is the one that's perfectly normal.
   

4. The interesting part: This attack does not generate any suspicious activity. Systems simply go offline. When an EDR agent stops reporting, that alone isn’t enough to trigger suspicion, as it can also happen due to system shutdowns, network connectivity issues etc.
   

5. How to defend?

   1. Block unauthorized EDR software installations
      In a managed corporate environment, there is almost never a legitimate reason for users to install an additional EDR agent. Enforce application control policies to block any installer packages associated with known EDR vendors, and maintain an allowlist of approved agents.

   2. Custom detections for EDR installation attempts
      Even if blocked, the installation attempt itself is a high-fidelity indicator of suspicious activity. Use EDR telemetry and endpoint logging to detect the “smoke” before the “fire” — spotting the rogue installation attempt before it’s used to disable the primary agent.

   3. Remove local admin rights
      Most EDR-killing techniques require local admin privileges to install kernel drivers. Eliminate this and eliminate the attack surface.

   4. EDR health state correlation
      Build detection logic that correlates EDR agent offline events with other system telemetry. A device that goes offline right after a suspicious installation event, driver load, or privilege escalation attempt should be treated as a high-severity incident, not a routine connectivity issue.