BYOVD Tactics: Qilin & Warlock Silencing 300+ EDRs
Just reviewed the latest findings from Cisco Talos and Trend Micro regarding the Qilin and Warlock operations. It is concerning to see the Bring Your Own Vulnerable Driver (BYOVD) technique being leveraged so effectively to disable over 300 EDR tools.
The mechanics are becoming more polished. Instead of just loading a known vulnerable driver, we are seeing chains where Qilin deploys a malicious msimg32.dll (likely via sideloading) to facilitate the kernel-level abuse. Once the vulnerable driver is loaded, they exploit a known bug to kill the security agents' processes.
Detection remains a cat-and-mouse game. Since the drivers are usually legitimately signed, standard certificate checks fail. We need to focus on the behavior: drivers loading from non-standard paths or the sudden termination of av.exe/csagent.exe following a driver load.
Here is a basic KQL query to hunt for drivers loaded from temporary directories or suspicious paths, followed by process termination events:
DeviceProcessEvents
| where ActionType == "ProcessTerminated"
| where FileName in~("csagent.exe", "MsMpEng.exe", "savservice.exe")
| join kind=inner (
DeviceImageLoadEvents
| where IsSigned == true
| where FolderPath contains "\AppData\" or FolderPath contains "\Temp\"
) on DeviceId, Timestamp
| project Timestamp, DeviceName, FileName, FolderPath, Signer
Are any of you enforcing Vulnerable Driver Blocklists (VDI) via Group Policy or Intune strictly yet, or is the risk of breaking legitimate hardware too high for your environments?
We started enforcing HVCI (Hypervisor-Protected Code Integrity) across the fleet last quarter. It’s painful for legacy hardware, but it completely stops this class of BYOVD attacks because the vulnerable drivers can’t pass the integrity checks. If you can manage the rollout, it’s the single most effective control against kernel abuse.
From an MSP perspective, rolling out strict driver policies is a nightmare because every client has different specialized software (printing, medical imaging, etc.) that requires ancient, signed drivers. We usually stick to application control (AppLocker) to prevent the initial dropper from executing in the first place.
Great points. While hardening drivers is ideal, we've found success hunting the DLL sideloading behavior itself using Defender for Endpoint. You can query for unsigned images loading from suspicious paths. This catches the msimg32.dll abuse before the driver even loads. Here's a quick KQL query to get started:
DeviceProcessEvents
| where FolderPath endswith @"\msimg32.dll"
| where IsSigned == 0
It’s a good stopgap for those legacy systems that can't run full HVCI yet.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access