Listen to this Post
Introduction:
A newly revealed open-source project exploits a legitimate but vulnerable driver, wsftprm.sys, which is not on Microsoft’s blocklist, to terminate critical Antivirus (AV) and Endpoint Detection and Response (EDR) processes. This Bring Your Own Vulnerable Driver (BYOVD) attack works even on fully patched Windows 11 systems with Hypervisor-Protected Code Integrity (HVCI) and Secure Boot enabled, bypassing some of Microsoft’s strongest kernel protections. The technique highlights a critical gap in defensive strategies that rely solely on blocklists and hardware-enforced security.
Learning Objectives:
- Understand the mechanism of the BYOVD attack using the `wsftprm.sys` driver.
- Learn how HVCI works and why this specific driver bypasses it.
- Identify defensive strategies to detect and mitigate BYOVD threats.
You Should Know:
1. Anatomy of the Weaponized Driver: wsftprm.sys
The core of this attack is a driver signed with a valid digital signature from a company called “WinISO,” known as wsftprm.sys. This driver is classified as “weaponizable”—it contains a legitimate, intended function that malicious actors can repurpose for harm. In this case, the driver exposes a Device I/O Control (IOCTL) routine that can terminate any process.
Step-by-step guide explaining what this does and how to use it.
The driver’s vulnerability is triggered via an IOCTL code. Analysis of the driver shows it imports kernel functions `ZwOpenProcess` and ZwTerminateProcess. A user-mode application communicates with the loaded driver by sending a specific IOCTL to its device object. The driver creates a symbolic link for user-mode access, which was found to be `\DosDevices\Warsaw_PM` (accessible as \\.\Warsaw_PM).
To weaponize this, an attacker’s tool must:
- Load the Driver: Write the `wsftprm.sys` file to disk (e.g.,
C:\Windows\System32\Drivers\) and load it via the Service Control Manager.sc create wsftprm binPath= C:\Windows\System32\Drivers\wsftprm.sys type= kernel start= demand sc start wsftprm
- Open a Handle: Use `CreateFile` to obtain a handle to the driver device.
HANDLE hDevice = CreateFileW(L"\\.\Warsaw_PM", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
- Send the Malicious IOCTL: Send IOCTL code `0x22201C` with a 1036-byte buffer where the first 4 bytes (a
DWORD) specify the Process ID (PID) to terminate.DeviceIoControl(hDevice, 0x22201C, &killBuffer, 1036, NULL, 0, &bytesReturned, NULL);
2. Bypassing HVCI and Secure Boot
Hypervisor-Protected Code Integrity (HVCI), also known as Memory Integrity, is a cornerstone of modern Windows security. It uses hardware virtualization to isolate code integrity checks, ensuring that kernel memory pages are executable only after validation and are never writable. This effectively prevents running unsigned shellcode in the kernel.
Step-by-step guide explaining what this does and how to use it.
This attack bypasses HVCI not by exploiting a flaw in the feature itself, but by abusing its inherent design. HVCI validates driver signatures and integrity before loading. The `wsftprm.sys` driver passes this validation because it is:
Properly Signed: It holds a valid digital signature from a legitimate vendor.
Not Blocklisted: Microsoft’s HVCI-compatible driver blocklist, updated via Windows Update, does not currently include this specific vulnerable driver.
Since the driver loads legally, its built-in—but weaponizable—function to terminate processes operates with full kernel privileges, untouched by HVCI. The defense is bypassed because the attack uses the driver’s sanctioned functionality maliciously, not injected malicious code.
3. The Attack Chain in Action
The proof-of-concept tool, BYOVD_EDRKiller, automates this weaponization into a persistent attack loop.
Step-by-step guide explaining what this does and how to use it.
1. Deployment: The tool drops the `wsftprm.sys` driver to the system drivers’ directory and loads it.
2. Target Enumeration: It continuously scans for processes related to specific EDR products (e.g., Microsoft Defender, Elastic EDR, Sysmon).
3. Process Termination: For each detected EDR PID, it sends the lethal IOCTL `0x22201C` via the driver.
4. Persistence Loop: This scan-and-kill loop continues until the operator stops it, crippling security visibility.
5. Cleanup: Ideally, the tool unloads the driver and deletes it. If cleanup fails, administrators must manually intervene:
sc stop wsftprm sc delete wsftprm del C:\Windows\System32\Drivers\wsftprm.sys
4. Real-World Impact and Ransomware Connection
BYOVD is not a theoretical threat but a primary tool for advanced adversaries. Research shows its widespread adoption by ransomware groups to disable security software before deploying encryptors.
Step-by-step guide explaining what this does and how to use it.
Threat actors follow a predictable pattern:
- Initial Access: Gain a foothold on a system, often through phishing or exploiting vulnerabilities.
- Privilege Escalation: Use initial access to gain administrative rights.
- Driver Deployment: Drop a known vulnerable driver (like `gdrv.sys` from Gigabyte, `dbutil_2_3.sys` from Dell, or `zamguard64.sys` from Zemana) that is not blocked on the target system.
- EDR Neutralization: Use the driver’s capabilities—whether arbitrary kernel writes or direct process termination—to disable EDR/AV processes and their kernel callbacks.
- Deploy Payload: With defenses blinded, deploy ransomware (e.g., BlackByte, Akira) or other malware unimpeded.
5. Defensive Strategies and Detection
Defending against BYOVD requires a layered approach beyond relying on Microsoft’s blocklist.
Step-by-step guide explaining what this does and how to use it.
1. Enable Advanced Protections: Ensure HVCI is enabled. Check its status via the Windows Security app under “Core isolation” or using the command line:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\CI\State" /v HVCIEnabled
2. Implement Application Control: Use Windows Defender Application Control (WDAC) to define explicit allow lists of permitted drivers and software, blocking all others, including newly dropped vulnerable drivers.
3. Monitor for Driver Loads: Deploy EDR/SIEM solutions to alert on the loading of non-standard kernel drivers, especially those with known vulnerabilities. Look for events related to `sc.exe` creating new kernel services.
4. Leverage Vendor Protections: Modern EDR solutions like CrowdStrike Falcon have specific protections that detect and block suspicious IOCTL requests to known vulnerable drivers, as seen in real intrusions.
5. Hunt for Anomalies: Proactively search for devices communicating with driver device names associated with known vulnerable drivers (e.g., \\.\Warsaw_PM) or for processes making unusual `DeviceIoControl` calls.
What Undercode Say:
- The Blocklist is a Reactive, Not Proactive, Defense: This case proves that security relying on a known-vulnerable driver blocklist is fundamentally fragile. Attackers continuously discover and weaponize new legitimate drivers faster than they can be cataloged and blocked.
- The Weaponizable Driver Problem is Intractable: Unlike drivers with arbitrary write vulnerabilities that can be patched, drivers with weaponizable features present a permanent risk. As long as security, hardware utility, or gaming anti-cheat software require deep kernel access, such drivers will exist and be abused.
Prediction:
The success of this non-blocklisted driver will accelerate a shift in the threat landscape. We predict a surge in threat actors, from ransomware affiliates to infostealer operators, hunting for and weaponizing obscure but signed drivers from niche hardware vendors or legacy software. This will make attacks more heterogeneous and harder to block with signatures alone. Consequently, defender focus will forcibly shift from blocklisting to stricter default-deny policies (like WDAC), behavioral detection of driver abuse, and increased scrutiny of all kernel-level code, regardless of its signature. The cat-and-mouse game is moving deeper into the software supply chain of legitimate but rarely-audited kernel drivers.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Saad Ahla – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
