When Trust Breaks: The Microsoft‑Signed Rootkit That Bypasses Endpoint Security
Signed Is Not Safe: How Vulnerable Kernel Drivers Are Weaponised to Kill EDR Kernel drivers run in Ring 0, below your endpoint protection.
- Endpoint Security
Bottom line. Because EDR and antivirus run in user mode and kernel drivers run beneath them, a validly signed driver that exposes powerful operations without checking who is calling can be abused to kill protected security processes from Ring 0, and once code runs in the kernel, user-mode defenses go blind. Microsoft’s WHCP signature proves the publisher’s identity and that the file was not modified; it does not prove the code is secure. Defenders: enable Microsoft’s Vulnerable Driver Blocklist plus HVCI/Memory Integrity, restrict driver installation to admins, and alert on new kernel-driver loads and on EDR/AV process terminations.
Background
Kernel drivers sit at the top of Windows’ trust hierarchy. They execute in Ring 0, the most privileged level, which is why Microsoft gates them behind the Windows Hardware Compatibility Program (WHCP) driver-signing process. The catch is what that signature actually certifies: the identity of the publisher and that the driver package has not been tampered with. It does not certify that the driver’s code is safe, and a signed driver that exposes raw kernel primitives is a loaded gun that Windows will happily load because the signature checks out.
This is the basis of the Bring Your Own Vulnerable Driver (BYOVD) technique, one of the defining endpoint-security problems of the last few years. Real EDR-killers. The ABYSSWORKER driver used by Medusa ransomware, the Microsoft-signed PoisonX (g11.sys) driver used by GodDamn, and commodity tools like Terminator/Spyboy and AuKill/AvNeutralizer, all follow the same recipe: drop a validly signed but flawed driver, then abuse it to switch off protection. (The often-shared proof-of-concept for this class uses HackSysExtremeVulnerableDriver, or HEVD, a deliberately vulnerable driver built by researchers for training and CTFs. HEVD is a lab model, not an in-the-wild signed rootkit, but it demonstrates exactly the flaw class the real drivers have.)
What we observed
Why a trusted driver becomes a rootkit component:
- The trust inversion: antivirus and EDR operate primarily in user mode, while a kernel driver runs below them. Once attacker code executes inside the kernel it can terminate protected processes, manipulate memory, hide processes and disable protections, and traditional endpoint defenses lose visibility into all of it. That loss of visibility is what makes driver-based attacks so effective.
- The flaw class, unchecked IOCTL handlers: a driver exposes a device interface (via a symbolic link) that any user-mode app can open, then drives it with IOCTL codes that act like API calls into the kernel. A vulnerable driver runs a powerful operation from its DeviceIoControl dispatch routine without verifying the caller’s privileges, so anyone who can reach the device gets kernel-level power.
- The primitive that keeps working, process termination: many exposed operations (kernel memory read/write, process hiding) rely on hardcoded EPROCESS offsets that change between Windows builds and therefore break over time. Process termination does not, so it remains reliable, which is exactly why real-world EDR-killers converge on it. Feed the driver a target PID and it terminates that process from kernel mode.
- Killing the guard from below: because the termination originates in the kernel, it bypasses the user-mode hooks and the protected-process (PPL) shielding that guard security software. In demonstrations, the driver is used to terminate MsMpEng.exe. The core Windows Defender process, and endpoint protection silently disappears before the real attack even begins.
- Signed does not mean safe: the whole chain works precisely because the driver is validly signed. WHCP signing verifies the publisher and package integrity, not code quality, so a signed driver can ship dangerous primitives and still load automatically. Trust in a signature is not a substitute for trust in the code.
How BYOVD kills EDR
The signature is valid at every step, which is why Windows loads the driver and why detection has to focus on driver loads and EDR terminations, not signatures.
Attribution
This is a technique and an industry-wide problem, not a single actor. BYOVD is used by ransomware crews (Medusa with ABYSSWORKER, GodDamn with PoisonX), by commodity EDR-killer tooling sold to affiliates (Terminator/Spyboy), and by advanced groups (FIN7’s AuKill/AvNeutralizer), as well as by red teams for authorised testing. The concrete example most write-ups use, HackSysExtremeVulnerableDriver, is a purpose-built training driver, so it is the teaching model rather than a live threat; the live threat is the population of genuinely signed vulnerable drivers, which is why Microsoft maintains a blocklist for them.
Confidence: 90%.
A Microsoft signature tells you who wrote the driver and that no one changed it, not that it won’t hand attackers the keys to your kernel.
Tactics, techniques & procedures (MITRE ATT&CK)
Techniques below are drawn directly from the analysed samples/reporting – no technique is asserted without evidence:
| Tactic | Technique | ID | Evidence |
|---|---|---|---|
| Persistence | Create or Modify System Process: Windows Service | T1543.003 | The vulnerable driver is installed and registered as a kernel-mode service so Windows loads it into Ring 0. |
| Privilege Escalation | Exploitation for Privilege Escalation | T1068 | BYOVD abuses a signed-but-flawed driver to obtain kernel-level execution from a user-mode process. |
| Defense Evasion | Exploitation for Defense Evasion | T1211 | An unchecked IOCTL dispatch routine is exploited to run privileged kernel operations without a caller-privilege check. |
| Defense Evasion | Impair Defenses: Disable or Modify Tools | T1562.001 | The kernel primitive is used to terminate EDR/AV processes such as MsMpEng.exe (Windows Defender). |
| Defense Evasion | Rootkit | T1014 | With kernel access the driver can hide processes and manipulate system state, acting as a rootkit component. |
Detection
Copy-ready hunting query:
# Detect and harden against BYOVD / signed vulnerable drivers (defensive)
# 1) Audit loaded drivers and startup drivers
# driverquery /v /fo list > C:\driver_list.txt
# Get-WindowsDriver -Online -All | Select Driver, ProviderName, ClassName
# Sysinternals: autoruns64.exe /accepteula -a Driver (review unsigned / unknown-vendor / unexpected modules)
# 2) Confirm the protections are ON
# HVCI / Memory Integrity + Microsoft Vulnerable Driver Blocklist (Windows Security > Device security > Core isolation)
# reg query HKLM\SYSTEM\CurrentControlSet\Control\CI\Config /v VulnerableDriverBlocklistEnable
# 3) Monitor for kernel-driver loads and installs
# Sysmon Event ID 6 (driver loaded); Windows Event ID 7045 (new kernel-mode service)
# Alert on drivers loading from user-writable paths (Temp, Downloads, AppData)
index=edr (event_id=7045 service_type="kernel mode driver") OR sysmon_event=6
# 4) Alert on EDR/AV being terminated -- the payoff step
index=edr event="process_terminated" target_process IN ("MsMpEng.exe","MpDefenderCoreService.exe","*Sense*","*CrowdStrike*","*SentinelOne*") OR agent_heartbeat_lost=true
# 5) Restrict driver installation to admins / trusted update mechanisms via policy.Recommendations
- Turn on the built-in defenses: enable HVCI (Memory Integrity) and the Microsoft Vulnerable Driver Blocklist, and enforce Windows Defender Application Control (WDAC) so known-bad and unauthorised drivers cannot load.
- Block specific drivers by hash or signer: where you identify a dangerous signed driver, add an explicit WDAC deny rule so it is refused at load time, do not rely on its signature status.
- Monitor kernel activity: alert on new kernel-driver loads (Sysmon Event 6, Event ID 7045), driver installation attempts, drivers loading from user-writable paths, and any abnormal termination of EDR/AV processes, a silenced agent is an alarm, not a non-event.
- Restrict who can load drivers: only administrators and trusted update mechanisms should be able to install kernel drivers; treat driver installation as a privileged, monitored operation.
- Do not trust the signature, audit the driver: regularly review loaded modules with driverquery, Autoruns and Process Explorer, investigate unknown vendors and unexpected kernel modules, and assume vulnerable signed drivers already exist in your estate.
