How Ransomware Operators Are Bypassing EDR With This Simple Trick!

Once a ransomware gang gains access to a system, there’s usually one major obstacle left:

The endpoint agent (aka EDR = Endpoint Detection & Response agent)

If the EDR detects ransomware, the attack is dead on arrival.

The file gets quarantined. Alerts go to the SOC. Game over.

That’s why attackers love to disable EDR before doing anything noisy.

But defenders know this. So they make sure EDR agents are tamper-proof.

But then I came across this smart workaround used by an attacker which I wanted to share today (credits: Stroz Friedberg)

🔧 Attack Flow: How It Worked

1. The attacker compromises an internet-facing server by exploiting a known CVE in a vulnerable application > Once inside, they identify the installed EDR - SentinelOne, in this case.
   

2. Attacker now downloads SentinelOne installer that is different from the installed version > Runs the installer file.
   

3. Here's the key part: When this upgrade happens, for a brief time (~50 seconds), the existing SentinelOne processes terminate. (Why? So that the MSI installer can spawn processes for the new agent version).
   

4. During this brief window, attacker kills the installation process (i.e. simply terminates msiexec.exe) interrupting the upgrade mid-way.
   

5. The Result: The old version is stopped. The new version is not installed. No SentinelOne agent is running. The system is now completely unprotected. Attacker now executes the ransomware!

   ---

💡 Key Insights: What This Attack Teaches Us

1. Security wants EDR running all the time—and that means even admins shouldn't be able to turn it off. EDRs are designed under the assumption that attackers will eventually gain high-level access to endpoints. So they’re built to resist even users with local administrator privileges. Here's how:
   

   • Kernel-level protection: The core components of most EDRs run as kernel-mode drivers. These operate below the user space where normal applications (and most admin tools) run. This makes it nearly impossible to kill or tamper with the EDR using standard tools like taskkill, Task Manager, or even PowerShell—because those tools can’t reach into the kernel directly.
     

   • Anti-tampering controls: EDRs often include policies that block process termination, protect configuration files, and prevent unauthorized uninstallation. Even if someone tries to shut down the agent or change its behavior, these protections intercept the action and block it—or at least alert the SOC.
     

2. And yet—it was disabled. The brilliance here is in the attacker's timing: they didn’t break the system; they waited for it to break itself, briefly. And then made sure it never came back.
   

3. The root cause: allowing local upgrades/downgrades. Check if your EDR supports upgrades/downgrades from local installation. If it does, that’s a potential path for tampering.
   

4. How to stop this attack? EDRs like SentinelOne have “Online authorization” feature that disables the ability to perform local upgrades/downgrades without central approval. Once enabled, even if an attacker runs a new installer, the upgrade won’t proceed without validation from the cloud.
   

5. We tend to focus detection and hardening around malware, exploits, or unauthorized tools. But increasingly, attackers are abusing legitimate binaries, signed installers, and trusted system behavior to carry out attacks.
   In this case, the SentinelOne installer wasn’t malicious—it was just used at the right moment in the wrong way. Security teams need to treat trusted processes as potential attack surfaces. That means logging, monitoring, and validating even the “safe” stuff.
   

6. Many enterprises overestimate what EDR alone can do and underestimate the value of basic endpoint hardening. For ex, if local admin rights had been restricted, the attacker wouldn’t have been able to kill the installer in the first place. Sometimes, the simplest controls are the most effective lines of defense.
   

7. Security isn’t just about detecting bad behavior—it’s about removing the opportunity for it. Too often, security programs focus on response: detect the ransomware, alert the SOC, investigate. But the more mature move is to eliminate paths attackers rely on, before they’re used. Restricting local admin rights, enforcing cloud validation for installers, and locking down upgrade mechanisms aren’t reactive—they’re preventative friction that forces attackers to work harder or give up entirely. That’s how you win: by removing opportunity, not just reacting to execution.