CQURE Hacks #76: Evading EDR Using Signed Driver

Setting up an EDR is a good first step, but simply having it installed doesn’t mean you’re protected. Many organizations rely on default settings, assuming the tools handle everything automatically. 

However, modern attackers know exactly how to work around those standard configurations. If your endpoints are invisible to your security team, or if your protection rules aren’t tuned to your specific environment, you’re leaving gaps that are easy to exploit. 

The Experiment: Turning the Shield Into a Sieve 

In this demo, we start with a properly secured system where Microsoft Defender is fully enabled. To prove it’s working, we run a malicious script, which Defender immediately flags and blocks. 

But what happens when we introduce a “trusted” element? We download a vulnerable driver that is properly signed by the Microsoft Windows Hardware Compatibility Publisher. Because it’s signed, the operating system trusts it. 

By using the Service Control Manager (sc.exe), we create a kernel-mode service to load this driver. Once the driver is in the kernel, we run a custom process-killer script. The result? Defender-related processes like MsMpEng.exe and NisSrv.exe are terminated. The security icon vanishes from the taskbar, and our malicious code now runs completely undetected. 

This highlights a critical reality: to stay ahead, you need to turn your security tools from a basic installation into a hardened shield that actually responds to threats.  

Why “Default” Settings are Your Biggest Security Debt 

Most security breaches aren’t the result of a lack of tools, but a lack of visibility and hardening. Attackers thrive in the gap between “installed” and “optimized.” When you rely on default configurations, you are essentially using a map that the attackers have already memorized. 

To move from a reactive state to a proactive defense, you must understand the “Language of the Kernel.” You need to know not just how to install Defender, but how to make it “blindness-proof” by automating hardening and mastering advanced threat hunting. 

Stop being a target of opportunity. Bridge the gap between basic administration and elite security architecture. 

Join our upcoming 3-day Masterclass: Configuring and Managing Microsoft Defender for Endpoint, starting April 8th. 

Led by CQURE’s Cybersecurity Expert Norbert Krzepicki, this is a “hands-on-keyboard” intensive designed for those who cannot afford to leave their environment to chance. You will move past the defaults, learn to automate EDR hardening with 3rd party tools, and master Kusto for advanced hunting to catch attackers before they can pull the plug on your defenses. 

Secure Your Spot here

TRANSCRIPT

Welcome to the new episode of Secure hacks, in today’s short episode we are going to create “malicious driver 1 binpath” and then we point to the file that will be loaded when the service starts. 

We’re going to take a look at how a driver, that is not on Microsoft’s driver blocklist can be abused to interfere with Microsoft Defender. 

 As you can see, Microsoft Defender is fully enabled and the protection options are turned ON. This is important as we want to clearly demonstrate the before-and-after effect. 

Now let’s download two things: a vulnerable driver that is not currently included in Microsoft’s driver blocklist and a script that searches for specific process names and terminates them. These will help us demonstrate how a legitimate, signed driver can be misused.  

I will unzip the downloaded archive and move the files into a convenient working directory so we can easily access them later. 

Before doing anything else, let’s confirm that Defender is actively protecting the system. I’ll run the Invoke-Shellcode command in PowerShell. And as expected — Defender immediately detects the script as malicious and blocks it. This confirms real-time protection is functioning correctly. 

Now let’s inspect the driver. I’ll open the file properties and navigate to Digital Signatures. Here we can see that the driver is properly signed — which makes it trusted by the operating system. That’s a key detail. 

Next, let’s load this driver. I’ll change the directory to where the driver file is located and use the service control manager to create a new Windows service entry. 

so SC.exe create MaliciousDriver1 binpath and then we point to the file that will be loaded when the service starts. 

type kernel tells Windows this is a kernel-mode driver, not a normal user-mode service. 

Now let’s start the service. Next we will compile our process killer tool using cargo build release. 

After compilation, let’s navigate to the newly created directory and launch our script, it will run for a few moments. 

Now let’s try running Invoke-Shellcode again. This time, it is no longer flagged as malicious and it’s not being blocked like before. 

Also, the Defender icon disappears from the taskbar. 

Finally, let’s check Task Manager. We’ll look for Defender-related processes such as: MsMpEng.exe, NisSrv.exe, MpCmdRun.exe 

And as you can see they’re no longer running. This demonstrates how a signed driver can be abused to disable security protections at the kernel level. 

It also highlights why maintaining and enforcing driver blocklists, and keeping systems updated, is critical.

Want to know more?