During a recent incident response engagement for a manufacturing firm in Pune, we identified a persistent threat actor who bypassed a top-tier EDR solution by deploying a signed, but vulnerable, version of the MSI Afterburner driver. The actor used this driver to gain Ring 0 privileges, allowing them to directly manipulate kernel memory and terminate the EDR’s protected processes. This technique, known as Bring Your Own Vulnerable Driver (BYOVD), effectively blinds the SOC by using the operating system's own trust mechanisms against it.
Understanding the BYOVD (Bring Your Own Vulnerable Driver) Threat
A BYOVD attack occurs when an adversary with administrative privileges—often secured through a lack of secure SSH access for teams—installs a legitimate, digitally signed driver that contains a known security flaw. Because the driver is signed by a trusted vendor like MSI, ASUS, or Realtek, the Windows Kernel Mode Code Signing (KMCS) policy allows it to load. Once loaded, the attacker exploits the driver's vulnerability—typically a lack of access control on IOCTL (Input/Output Control) codes—to read and write arbitrary kernel memory.
How Attackers Use Legitimate Drivers to Gain Kernel Access
We observed that the primary goal of loading these drivers is to bridge the gap between user-mode (Ring 3) and kernel-mode (Ring 0). In a standard environment, a user-mode process cannot access memory allocated to the kernel or other processes. However, a driver like RTCore64.sys (MSI Afterburner) provides IOCTLs that allow user-mode applications to read and write to MSRs (Model Specific Registers) or physical memory.
Attackers use tools like "Backstab" or "Terminator" to automate this process. These tools find the process ID (PID) of the EDR agent, use the vulnerable driver to map the kernel memory where the EDR's callback functions or process objects reside, and nullify them. This results in the EDR remaining "Running" in the service manager while being functionally dead in the kernel.
The Evolution of Driver-Based Exploitation
The landscape has shifted from custom-written rootkits to the exploitation of signed third-party drivers. Historically, attackers had to steal code-signing certificates to load malicious drivers. Today, they simply browse repositories of known vulnerable drivers (like the LOLDrivers project) to find a signed binary that Microsoft hasn't yet added to the revocation list.
We are seeing a rise in "EDR-Killers" that specifically target the communication channels between the EDR's filesystem minifilter and its user-mode service. By exploiting a driver like GUBELabs GIO.sys, an attacker can disable the callbacks that notify the EDR of new file creations or process starts, effectively making the malware invisible to the security stack.
Why BYOVD is a Critical Challenge for Modern Security
Most EDR and Antivirus solutions operate by hooking system calls or subscribing to kernel callbacks via PsSetCreateProcessNotifyRoutine. When a BYOVD attack occurs, the adversary is operating at the same privilege level as the security software. If the attacker can modify the kernel's internal data structures, they can remove the EDR's hooks before the EDR even processes the "Driver Load" event.
Bypassing Traditional EDR and Antivirus Solutions
Traditional detection often relies on the reputation of the binary being executed. Since the drivers used in BYOVD attacks are legitimate tools used by gamers, overclockers, or hardware monitors, their reputation score is high. We found that many EDRs default to an "Allow" stance for drivers signed by major hardware vendors to avoid breaking system stability.
In our testing, we successfully loaded Capcom.sys (a driver famous for having a deliberate "feature" that disables SMEP) on systems where the EDR was set to maximum sensitivity. The EDR flagged the tool used to exploit the driver, but the driver itself was allowed to reside in %SystemRoot%\System32\drivers without interference.
The Role of Digitally Signed Drivers in Evading Detection
Windows requires all drivers to be signed by a trusted CA and, in newer versions, verified by the Windows Hardware Quality Labs (WHQL). Attackers exploit this by using drivers that were signed years ago but never revoked. The WinRing0x64.sys driver, often bundled with older hardware diagnostic tools, is a frequent candidate. Even though it has known vulnerabilities (CVE-2020-14979), its signature remains valid, allowing it to bypass the standard KMCS checks on Windows 10 and 11.
Common Vulnerabilities Found in Third-Party Drivers
The vulnerabilities are rarely complex buffer overflows. Instead, they are usually architectural flaws where the driver exposes sensitive kernel functions to any user-mode process, often violating core OWASP Top 10 security principles. Common flaws include:
- Arbitrary Memory Read/Write: IOCTLs that wrap
MmMapIoSpaceormemcpywithout checking the caller's privilege level. - MSR Manipulation: Allowing user-mode to write to Model Specific Registers, which can be used to disable hardware-level protections.
- CR3/CR4 Access: Allowing the modification of control registers to disable Supervisor Mode Execution Prevention (SMEP).
Core Pillars of a Robust BYOVD Defense Strategy
Defeating BYOVD requires a shift from reactive detection to proactive enforcement. You cannot rely on the EDR to stop a driver that is already running in the kernel. The goal is to prevent the driver from ever transitioning from disk to memory.
Implementing the Microsoft Vulnerable Driver Blocklist
Microsoft maintains a recommended blocklist of drivers known to be exploited. However, this blocklist is not always enabled by default on older versions of Windows 10 or if certain virtualization features are disabled. We recommend verifying the status of this blocklist via the registry.
# Check if the Vulnerable Driver Blocklist is enabledreg query "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v "VulnerableDriverBlocklistEnable"
If it returns 0 or is missing, enable it
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v "VulnerableDriverBlocklistEnable" /t REG_DWORD /d 1 /f
On Windows 11, this is integrated into the "Smart App Control" or "Windows Security" UI under Device Security > Core Isolation. However, in enterprise environments, this should be enforced via Group Policy or Intune to ensure consistency across the fleet.
Enabling Hypervisor-Protected Code Integrity (HVCI)
HVCI, also known as Memory Integrity, uses hardware virtualization to isolate the Code Integrity (CI) decision-making process. This prevents attackers from modifying the kernel memory to bypass signature checks. Even if an attacker loads a vulnerable driver, HVCI ensures that only signed code can be executed in kernel-mode, significantly limiting the damage an exploited driver can do.
In the Indian context, we often see HVCI disabled in SME environments because of its performance impact on older CPUs (pre-8th Gen Intel). If your hardware supports it, this is the single most effective defense against kernel-level tampering.
Utilizing Windows Defender Application Control (WDAC) for Driver Enforcement
WDAC is the most powerful tool for stopping BYOVD. Unlike AppLocker, WDAC can enforce rules at the kernel level. We use WDAC to create a "Deny" policy for specific file hashes or publisher attributes associated with known vulnerable drivers.
Below is a snippet of a WDAC policy designed to block the MSI Afterburner driver often used in "Backstab" attacks.
# This is a conceptual representation of the WDAC Deny RuleUse New-CIPolicy and Merge-CIPolicy to generate the actual .bin file
<Deny ID="ID_DENY_RTCORE64" FriendlyName="Block MSI Afterburner Vulnerable Driver"> <FilePublisher ID="ID_PUB_MSI" FriendlyName="Micro-Star International Co., Ltd."> <FileAttrib ID="ID_FILE_RTCORE64" FileName="RTCore64.sys" MinimumFileVersion="0.0.0.0" /> </FilePublisher> </Deny>
Once the XML is generated, we convert it to a binary format and apply it via PowerShell:
# Convert XML to binary policyConvertFrom-CIPolicy -XmlFilePath "C:\Policies\Blocklist.xml" -BinaryFilePath "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b"
Force a refresh of the policy (requires reboot for kernel enforcement)
Update-DesktopPerUserPolicy
Advanced Detection and Monitoring Techniques
Detection is your fallback when prevention fails. Monitoring for driver loads is critical, as most legitimate software does not frequently load new drivers after the initial installation and reboot.
Monitoring for Suspicious Driver Load Events (Event ID 6)
Microsoft-Windows-Sysmon provides Event ID 6 (Driver Loaded). We configure Sysmon to log the hash of every driver loaded. This allows us to correlate loaded drivers against the LOLDrivers database or other threat intel feeds.
# Example Sysmon configuration snippet to capture driver loads
<Sysmon schemaversion="4.30"> <EventFiltering> <DriverLoad onmatch="exclude" /> <!-- Log everything by default --> <DriverLoad onmatch="include"> <Signature condition="contains">Micro-Star</Signature> <Signature condition="contains">Realtek</Signature> <Signature condition="contains">ASUSTeK</Signature> </DriverLoad> </EventFiltering> </Sysmon>
By focusing on drivers from hardware vendors that are not part of your standard hardware stack, you can quickly identify anomalies. For instance, seeing an MSI driver load on a Dell Latitude laptop is a high-fidelity indicator of a BYOVD attempt.
Behavioral Analysis: Identifying Kernel-Mode Manipulation
Since the goal of BYOVD is often to kill security processes, we monitor for the "Process Terminate" access right being requested on EDR processes. While the driver itself does the killing, the user-mode orchestrator must still interact with the driver.
We use the following PowerShell command to audit currently running drivers and their paths to identify any "out of place" binaries:
Get-CimInstance Win32_SystemDriver |
Where-Object { $_.State -eq 'Running' } | Select-Object Name, PathName, ServiceType | Export-Csv -Path "C:\Audit\RunningDrivers.csv"
Hunting for Known Vulnerable Driver Signatures in Your Environment
For large-scale hunting, we use Velociraptor. The following artifact collection allows us to scan the entire fleet for specific driver hashes known to be vulnerable.
# Velociraptor snippet to hunt for RTCore64.sys by hash
SELECT FullPath, Name, Size, mtime, hash(path=FullPath).SHA256 as SHA256 FROM glob(globs="C:\\Windows\\System32\\drivers\\*.sys") WHERE SHA256 = "01AAADC3043597FD58CD913966E74785F3E791115F63B3050F0392693D765444"
Hardening the OS Against Kernel-Level Attacks
Hardening involves reducing the surface area that an attacker can exploit. If a driver isn't there, it can't be used against you.
Enforcing Strict Driver Signature Requirements
Ensure that "Driver Signature Enforcement" is never disabled. Some legacy troubleshooting guides suggest running bcdedit /set testsigning on, which allows unsigned drivers to load. This should be alerted on immediately in your SIEM.
# Verify that Test Signing is disabledbcdedit /enum {current} | findstr /i "testsigning"
Ensure it is set to 'No' or is absent. To disable:
bcdedit /set testsigning off
The Importance of Virtualization-Based Security (VBS)
VBS is the foundation for HVCI. It uses the Windows Hypervisor to create a secure region of memory that is isolated from the normal operating system. In India, where many firms use "repacked" software for accounting or ERP, these installers often attempt to disable VBS/HVCI because it interferes with their licensing bypass mechanisms (which themselves often rely on vulnerable drivers like WinRing0).
Under the DPDP Act 2023, failing to implement these "reasonable security practices" can lead to significant regulatory scrutiny if a data breach occurs due to a kernel-level compromise.
Reducing the Attack Surface by Removing Unnecessary Drivers
We frequently find "ghost" drivers from old hardware or peripheral software (like RGB controllers or old printer drivers) that remain on the system. These are prime targets for BYOVD. Use pnputil to audit and remove non-essential drivers.
# List all third-party (OEM) driverspnputil /enum-drivers
Remove a specific vulnerable driver (example: oem12.inf)
pnputil /delete-driver oem12.inf /uninstall /force
Proactive Governance and Best Practices
Technical controls must be backed by governance. Driver management is often overlooked in standard patch management cycles.
Auditing Third-Party Software for Hidden Driver Dependencies
When onboarding new software, especially hardware utilities or "performance boosters," we audit the installation directory for .sys files. We then check these files against the LOLDrivers database. Many Indian manufacturing units use specialized CNC or PLC software that relies on extremely old, vulnerable drivers for direct hardware communication. These systems should be isolated in a separate VLAN with strict egress controls.
Establishing a Rapid Response Plan for Zero-Day Driver Vulnerabilities
When a new driver vulnerability is announced (like the recent CVE-2024-21338 in appid.sys), the response must be faster than the attacker's script.
- Identify: Use the
driverquerycommand to find if the driver exists in your environment. - Block: Immediately deploy a WDAC "Deny" rule for the driver's hash.
- Remediate: Use your RMM tool to delete the file and reboot the system.
# Quick audit for specific vulnerable driver names
driverquery /v /fo csv | findstr /i "Micro-Star Realtek Capcom AMD"
Educating IT Teams on the Risks of Outdated Hardware Utilities
Desktop support teams often install "All-in-One" driver packs or legacy utility suites to resolve hardware issues quickly. We have observed instances where these packs include drivers from 2015 that are trivial to exploit. IT policies should mandate the use of the Windows Update Catalog or official manufacturer support pages for driver sourcing, rather than third-party "driver updater" software.
Conclusion: Building a Multi-Layered Defense Against BYOVD
The threat of BYOVD is a reminder that "signed" does not mean "safe." As EDR solutions become more adept at catching user-mode techniques like process injection and living-off-the-land binaries, attackers will continue to descend into the kernel.
A multi-layered defense involves:
- Enabling hardware-backed protections (VBS/HVCI) to protect kernel integrity.
- Implementing WDAC policies to deny known-bad drivers.
- Monitoring driver load events (Sysmon ID 6) for anomalies.
- Regularly auditing the environment for legacy or unnecessary drivers.
By treating drivers as high-risk assets rather than trusted components, you can significantly increase the cost of an attack. The goal is to ensure that even if an attacker gains administrative access, the path to Ring 0 remains blocked.
To begin auditing your environment for common vulnerable drivers, run the following command to identify drivers that have been loaded from non-standard locations:
Get-CimInstance Win32_SystemDriver | Where-Object { $_.PathName -notlike "C:\Windows\System32\*" } | Select-Object Name, PathName