Legacy Windows Driver Exploit Grants Attackers Kernel God Mode — Here’s How To Detect And Block It + Video

Introduction

A newly added entry to the LOLDrivers project, termdd.sys, has revealed a dangerous vulnerability that allows attackers to disable Code Integrity and load unsigned drivers on fully patched Windows systems. This “Living Off the Land Driver” (LOLDriver) abuse technique, discovered by Andrea Monzani, highlights how legacy driver components from as far back as Windows 7 can still introduce modern risk, particularly in environments where driver controls aren’t tightly enforced.

Learning Objectives

Understand how a vintage Windows driver (termdd.sys) can be exploited to disable Code Integrity and bypass Driver Signature Enforcement (DSE).
Learn to detect the presence of termdd.sys and other LOLDrivers on your systems using PowerShell and Sysmon.
Implement effective mitigation strategies, including Hypervisor-Protected Code Integrity (HVCI) and leveraging Microsoft’s recommended driver blocklist.

You Should Know

The termdd.sys Vulnerability: A Write-What-Where Primitive for Disabling Code Integrity

The vulnerability in `termdd.sys` lies in its unsafe handling of registry query operations, specifically the `RtlQueryRegistryValues` function. By crafting malicious registry entries, an attacker can trigger a write-what-where primitive that directly modifies the global variable `g_CiOptions` in `CI.DLL` — the kernel module responsible for enforcing code integrity.

This is not a traditional buffer overflow; it’s a more elegant bypass. The exploit abuses `REG_SZ` and `REG_MULTI_SZ` registry value types to perform arbitrary kernel memory writes without executing any shellcode. When `termdd.sys` processes a specially crafted registry key, it dereferences and writes to attacker-controlled memory addresses. By setting the `Buffer` parameter to NULL, the attacker can force `RtlQueryRegistryValues` to allocate and write string data, eventually overwriting `g_CiOptions` to a zero value — effectively disabling all signature checks.

Step-by-Step Guide: How the termdd.sys Exploit Works

Identify the target driver: The attacker first checks if `termdd.sys` is present on the system. This driver is a core Windows component responsible for Terminal Device Driver functionality and is present on all Windows versions from Windows 7 to Windows 11.
Create malicious registry entries: Using Windows API calls or command-line tools, the attacker creates a registry key under a specific path that `termdd.sys` reads. The key contains a `REG_MULTI_SZ` value with a carefully crafted string designed to overflow or write to arbitrary memory.

 Example registry modification (run as SYSTEM or with sufficient privileges)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\TermDD\Parameters" /v "MaliciousValue" /t REG_MULTI_SZ /d "AAAA...AAA" /f

Trigger the vulnerable code path: The attacker forces the system to invoke the vulnerable function in termdd.sys. This can be done by initiating a Terminal Services operation, connecting to a remote desktop session, or simply by loading the driver if it’s not already active.
Execute the write-what-where primitive: The exploit leverages RtlQueryRegistryValues’s handling of `REG_MULTI_SZ` data. When the `Buffer` parameter is NULL, the function allocates memory and writes the registry string data. By controlling the `Buffer` pointer value (through prior memory layout manipulation), the attacker can write arbitrary data (typically a zero) to an arbitrary kernel address — in this case, the address of g_CiOptions.
Disable Code Integrity: With `g_CiOptions` set to zero, Windows no longer enforces driver signature verification. Any unsigned driver — including rootkits, EDR killers, and kernel-mode malware — can now be loaded without restriction.

 After successful exploitation, load an unsigned driver
sc.exe create MaliciousDriver binPath= "C:\path\to\unsigned.sys" type= kernel
sc.exe start MaliciousDriver

2. Detecting termdd.sys and LOLDrivers on Your Network

Detecting the presence of vulnerable drivers like `termdd.sys` is a critical first step in preventing BYOVD (Bring Your Own Vulnerable Driver) attacks. The LOLDrivers project provides a comprehensive, community-curated database of known vulnerable and malicious drivers, complete with cryptographic hashes, signatures, and detection rules.

Step-by-Step Guide: How to Hunt for LOLDrivers Using PowerShell

Download the latest LOLDrivers database: The LOLDrivers repository provides a CSV file containing all known vulnerable drivers with their MD5, SHA1, and SHA256 hashes.

 Download the LOLDrivers CSV
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/magicsword-io/LOLDrivers/main/drivers.csv" -OutFile "$env:TEMP\loldrivers.csv"

Enumerate all loaded drivers on your system: Use PowerShell to list every kernel driver currently loaded, along with their file paths and digital signatures.

 Get all loaded kernel drivers with their details
Get-WmiObject Win32_SystemDriver | Where-Object { $_.State -eq "Running" } | Select-Object Name, DisplayName, PathName, Started, StartMode, State | Format-Table -AutoSize

Alternative using driverquery.exe (more detailed)
driverquery.exe /v /fo csv | ConvertFrom-Csv | Select-Object 'Module Name', 'Display Name', 'Path', 'Driver Type', 'Start Mode'

Calculate cryptographic hashes for each driver file: For each driver binary on disk, compute its SHA256 hash and compare it against the LOLDrivers database.

 Function to compute SHA256 hash of a file
function Get-FileHashSHA256 {
param([bash]$filePath)
Get-FileHash -Path $filePath -Algorithm SHA256 | Select-Object -ExpandProperty Hash
}

Example: hash termdd.sys
Get-FileHashSHA256 "C:\Windows\System32\drivers\termdd.sys"

Cross-reference with the LOLDrivers database: Load the CSV and check if any loaded driver’s hash matches a known malicious entry.

 Load LOLDrivers CSV
$loldrivers = Import-Csv "$env:TEMP\loldrivers.csv"

Check a specific driver hash
$driverHash = Get-FileHashSHA256 "C:\Windows\System32\drivers\termdd.sys"
$match = $loldrivers | Where-Object { $_.sha256 -eq $driverHash }
if ($match) {
Write-Host "WARNING: Vulnerable driver detected! Name: $($match.filename)" -ForegroundColor Red
}

Set up Sysmon event monitoring for LOLDrivers: Configure Sysmon to log driver load events and alert on known vulnerable drivers.

<!-- Sysmon configuration snippet to monitor driver loads -->
<Sysmon>
<EventFiltering>
<DriverLoad onmatch="include">
<Image condition="end with">.sys</Image>
</DriverLoad>
</EventFiltering>
</Sysmon>

Deploy the configuration and monitor Event ID 6 (Driver Loaded) for any matches against the LOLDrivers hash database.

3. Mitigation Strategies: Hardening Windows Against BYOVD Attacks

The most effective defense against termdd.sys and similar driver exploits is to prevent the vulnerable driver from loading in the first place or to render the exploit useless through modern security features like HVCI.

Step-by-Step Guide: How to Mitigate termdd.sys Exploitation

Enable Hypervisor-Protected Code Integrity (HVCI): HVCI, also known as Memory Integrity, uses virtualization-based security to isolate the kernel from normal OS operations. When enabled, even if an attacker gains kernel write primitives, they cannot modify critical code integrity variables like g_CiOptions.

 Check if HVCI is enabled
Get-ComputerInfo -Property "DeviceGuard"

Enable HVCI via Group Policy or registry
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f

Deploy Microsoft’s recommended driver blocklist: Microsoft maintains a blocklist of known vulnerable drivers. Enable this feature via Group Policy or Intune.

 Enable the Microsoft Driver Blocklist
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v "VulnerableDriverBlocklistEnable" /t REG_DWORD /d 1 /f

Block termdd.sys explicitly via WDAC policy: Use Windows Defender Application Control (WDAC) to explicitly deny `termdd.sys` from loading, even if it is signed by Microsoft.

 Create a WDAC policy that blocks termdd.sys
$rules = @"
<FileRules>
<Deny ID="DENY_TERMDD" FriendlyName="Termdd.sys" FileName="termdd.sys" />
</FileRules>
"@
 Deploy the policy via Group Policy

Monitor for attempts to load unsigned drivers: Even with mitigations in place, monitor for failed driver load attempts, which may indicate an active bypass attempt.

 Query the System event log for driver load failures
Get-WinEvent -FilterHashtable @{LogName='System'; ID=7000} | Where-Object { $_.Message -match "unsigned" }

Regularly update your LOLDrivers detection rules: The LOLDrivers project is continuously updated. Integrate automated updates into your SIEM or log management pipeline.

 Linux-based cron job to daily update LOLDrivers data
0 2    wget -O /var/lib/loldrivers/drivers.csv https://raw.githubusercontent.com/magicsword-io/LOLDrivers/main/drivers.csv && /usr/local/bin/siem_ingest.sh

The Bigger Picture: BYOVD as a Persistent Threat

The `termdd.sys` vulnerability is not an isolated incident. It represents a broader class of attacks known as “Bring Your Own Vulnerable Driver” (BYOVD), where attackers leverage signed but flawed kernel drivers to bypass security controls. In 2025, Check Point Research uncovered a sophisticated campaign leveraging over 2,500 unique variants of a vulnerable legacy driver to disable EDR and AV solutions across thousands of endpoints.

These attacks are becoming increasingly common because they exploit a fundamental asymmetry: security products run in user mode or with limited kernel privileges, while a compromised kernel driver operates with unrestricted access to system memory and hardware. Once a BYOVD attack succeeds, the attacker can disable EDR processes, hide malicious processes, and establish persistent rootkits — all while remaining undetected by traditional antivirus.

How Red Teams Can Ethically Test Defenses Against termdd.sys

Security professionals can use controlled, ethical testing to validate their defenses against BYOVD attacks. The following steps should only be performed in isolated, authorized lab environments.

Step-by-Step Guide: Ethical Testing of termdd.sys Defenses

Set up a Windows 10 or 11 virtual machine with HVCI and driver blocklists disabled for testing purposes. Ensure the VM is isolated from any production network.
Obtain a copy of the termdd.sys driver from a clean Windows installation. Note that the vulnerable version is present in all Windows builds up to and including Windows 11 22H2.
Develop or acquire a proof-of-concept exploit that triggers the `RtlQueryRegistryValues` write primitive. A basic PoC in C would involve:

// Simplified PoC structure (for educational purposes only)
HANDLE hDriver = CreateFileW(L"\\.\Global\TermDD", ...);
// Set up registry key with malicious REG_MULTI_SZ data
// Call DeviceIoControl with IOCTL that triggers the vulnerable path
// Verify that g_CiOptions is modified by attempting to load an unsigned driver

Test your detection stack: After successful exploitation, verify that your Sysmon configuration logs the driver load event, that your SIEM generates an alert, and that your EDR detects the unsigned driver load attempt.
Validate mitigations: Enable HVCI or deploy the Microsoft driver blocklist and re-run the exploit to confirm it is blocked. Document the results.

What Undercode Says

Legacy drivers are a goldmine for attackers: The termdd.sys vulnerability, dating back to Windows 7, demonstrates that age does not reduce risk. Every signed Microsoft driver in your system is a potential attack vector if it contains exploitable bugs.
HVCI is not optional anymore: Hypervisor-Protected Code Integrity (HVCI) is the only reliable defense against kernel memory write primitives. Organizations still running Windows without HVCI enabled are effectively inviting BYOVD attacks.

The termdd.sys disclosure serves as a wake-up call for enterprise security teams. The LOLDrivers project now lists over 100 vulnerable drivers, and threat actors are actively weaponizing them. While Microsoft has made progress with HVCI and driver blocklists, the reality is that many production systems still run with these features disabled for compatibility reasons. The attack surface is enormous, and the tools for exploitation are publicly available.

Defenders must shift from reactive patching to proactive hardening. This means enabling HVCI, deploying WDAC policies, integrating LOLDrivers data into detection pipelines, and continuously auditing loaded drivers. The era of trusting signed Microsoft drivers implicitly is over — every kernel module must be treated as potentially hostile.

Prediction

The termdd.sys vulnerability will be weaponized by multiple APT groups within six months, leading to a wave of BYOVD-based attacks targeting critical infrastructure sectors. Microsoft will eventually issue an out-of-band security update that either removes the vulnerable code from termdd.sys or adds the driver to the default blocklist. However, thousands of unpatched systems will remain vulnerable for years, and third-party security vendors will rush to add termdd.sys-specific detection rules to their products. The LOLDrivers project will become an essential component of every enterprise’s threat intelligence pipeline, and regulatory frameworks like NIS2 and CMMC will begin mandating driver blocklist enforcement as a compliance requirement.

▶️ Related Video (72% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: New Loldrivers – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post