Listen to this Post
Introduction:
The Bring Your Own Vulnerable Driver (BYOVD) attack technique has become a cornerstone of modern post-exploitation frameworks, allowing adversaries to abuse legitimately signed but flawed kernel drivers to gain unrestricted access to the Windows kernel. This article provides a technical analysis of gdrv3.sys, a Gigabyte driver with 13 exposed IOCTL handlers—including arbitrary physical memory read/write, MSR manipulation, raw I/O port access, and kernel memcpy—that lack any meaningful authentication, demonstrating how a handful of hardware access primitives can completely dismantle an operating system’s security model.
Learning Objectives:
- Understand the BYOVD technique and how vulnerable kernel drivers like `gdrv3.sys` enable privilege escalation and EDR evasion
- Learn to enumerate, interact with, and analyze IOCTL interfaces using both Windows user-mode code and Linux-based cross-compilation approaches
- Master detection and prevention strategies for BYOVD attacks, including WDAC policies, HVCI, and the Microsoft Vulnerable Driver Blocklist
You Should Know:
- How to Enumerate and Interact with Vulnerable Driver IOCTLs
When a vulnerable driver like `gdrv3.sys` is loaded, its IOCTL dispatch routines can be reached from any user-mode process with sufficient access rights. Understanding how to identify and communicate with these IOCTLs is the first step in both exploitation and security auditing.
To interact with a driver’s IOCTL interface on Windows, an attacker or researcher must first obtain a handle to the device object, then call `DeviceIoControl` with the appropriate IOCTL code and input/output buffers. The following command lists all loaded drivers and their base addresses to confirm whether a particular driver is present:
Windows - list loaded drivers and filter for gdrv3 driverquery /v | findstr /i "gdrv" sc query type= driver | findstr /i "gdrv"
From a Linux-based analysis environment, cross-compiling a Windows executable that communicates with the driver requires the Mingw-w64 toolchain. The following command builds a simple IOCTL sender targeting gdrv3.sys:
Linux cross-compilation for Windows x64 sudo apt-get install gcc-mingw-w64-x86-64 x86_64-w64-mingw32-gcc -o ioctl_sender.exe ioctl_sender.c -lntdll -static
The `gdrv3.sys` driver’s IOCTL codes are uncovered through reverse engineering tools like Ghidra, IDA Pro, or WinDbg. Once identified—values such as `0xC3502800` for physical memory read, `0xC3502804` for physical memory write—a simple user-mode program can invoke them. Below is a minimal C snippet that uses `CreateFileA` to obtain a device handle and `DeviceIoControl` to read arbitrary physical memory:
// Windows user-mode IOCTL sender for physical memory read
HANDLE hDevice = CreateFileA("\\.\GIO", GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
if (hDevice == INVALID_HANDLE_VALUE) return 1;
DWORD ioctl_code = 0xC3502804; // Example physical write IOCTL
BYTE input_buffer[bash];
(UINT64)input_buffer = physical_address; // target physical address
(DWORD)(input_buffer + 8) = length; // size to write
DeviceIoControl(hDevice, ioctl_code, input_buffer, 16, write_buffer, length, &bytes_ret, NULL);
- Building a BYOVD Detection Lab with Windows Defender Application Control (WDAC)
The Microsoft Vulnerable Driver Blocklist is a Windows security feature designed to prevent known vulnerable drivers from loading. Administrators can manually enable this blocklist and extend it with custom policies to block additional drivers such as gdrv3.sys. The following steps deploy a WDAC policy that denies all third‑party kernel drivers except an explicit allowlist.
Step 1 – Create a base WDAC policy. On a clean reference machine, run PowerShell as Administrator and generate a policy that puts the system in audit mode:
Generate initial WDAC policy in audit mode New-CIPolicy -Level Publisher -FilePath "C:\WDAC_Policies\AuditPolicy.xml" -UserPEs Set-RuleOption -FilePath "C:\WDAC_Policies\AuditPolicy.xml" -Option 3 Enable audit mode ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC_Policies\AuditPolicy.xml" -BinaryFilePath "C:\WDAC_Policies\SiPolicy.p7b"
Step 2 – Review the audit events. After running the system with the audit policy for several days, use the following command to analyze which drivers would have been blocked:
Query CodeIntegrity operational log for driver load events
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" |
Where-Object { $_.Id -eq 3076 } |
Select-Object TimeCreated, Message
Step 3 – Add gdrv3.sys to the blocklist. Obtain the driver’s hash (SHA256 or SHA1) and create a deny rule. The following PowerShell commands compute the file hash and generate a deny rule in the WDAC policy XML:
Compute SHA256 hash of the gdrv3.sys file $filePath = "C:\Windows\System32\drivers\gdrv3.sys" $hash = (Get-FileHash -Path $filePath -Algorithm SHA256).Hash Import the existing policy XML and add a deny rule $policy = Get-CIPolicy -FilePath "C:\WDAC_Policies\AuditPolicy.xml" $denyRule = New-CIDenyRule -DriverHash $hash -Description "Block gdrv3.sys" Add-CIRule -Policy $policy -Rule $denyRule ConvertFrom-CIPolicy -XmlFilePath "C:\WDAC_Policies\AuditPolicy.xml" -BinaryFilePath "C:\WDAC_Policies\SiPolicy.p7b"
Step 4 – Deploy the WDAC policy. Copy the binary policy file `SiPolicy.p7b` to `C:\Windows\System32\CodeIntegrity\` and reboot the system. After deployment, verify the policy is active with the following command:
Verify WDAC policy status Get-CIPolicy
- Automating BYOVD Attack Detection Using Sysmon and EDR Telemetry
Detecting BYOVD attacks in real time requires monitoring driver load events and analyzing IOCTL traffic. Sysmon (System Monitor) provides detailed logging of driver load attempts, while EDR solutions can extend detection to IOCTL‑level analysis. The following Sysmon configuration captures all driver load events along with image signatures and hashes:
<Sysmon> <EventFiltering> <DriverLoad onmatch="include"> <Image condition="end with">.sys</Image> </DriverLoad> </EventFiltering> </Sysmon>
After installing Sysmon, security teams can query the Windows Event Log for new driver loads and cross‑reference them against known vulnerable driver signatures:
Query Sysmon Event ID 6 (Driver Load)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=6} |
Where-Object { $<em>.Message -match "gdrv3" -or $</em>.Message -match "ThrottleStop" } |
Format-List TimeCreated, Message
For advanced detection, anomaly-based rules can look for sequences where a user‑mode process (e.g., a suspicious executable) loads a driver and then immediately sends a high‑risk IOCTL (0xC3502580, which triggers wrmsr). The following KQL (Kusto Query Language) snippet can be adapted for Microsoft Sentinel or Defender for Endpoint:
DeviceEvents | where ActionType == "DriverLoad" | join kind=inner ( DeviceEvents | where ActionType == "DeviceIoControl" | where AdditionalFields has "0xC3502580" ) on DeviceId, Timestamp | where TimeDiff < 5min | project Timestamp, DeviceName, DriverName, InitiatingProcessCommandLine
- Reverse Engineering Vulnerable Drivers with Ghidra and WinDbg
Understanding the internals of a vulnerable driver is critical for both defenders and researchers. The following step‑by‑step guide analyzes `gdrv3.sys` using Ghidra and WinDbg on a Windows test system with kernel debugging enabled.
Step 1 – Extract the driver from a running system. Open an elevated command prompt and locate the driver file:
sc query type= driver | findstr "gdrv" fltmc instances | findstr "gdrv"
If the driver is actively loaded, its file is typically located in C:\Windows\System32\drivers\. Copy the `gdrv3.sys` file to an analysis workstation.
Step 2 – Load the driver into Ghidra. Create a new project, import gdrv3.sys, and run the auto‑analysis. Focus on the `DriverEntry` function to locate the `IRP_MJ_DEVICE_CONTROL` dispatch routine. Once identified, extract the IOCTL table; the following Ghidra script iterates through the dispatch table:
Ghidra Python script to enumerate IOCTL handlers
from ghidra.program.model.address import AddressSet
from ghidra.app.plugin.core.analysis import AutoAnalysisManager
ioctl_start = currentProgram.getSymbol("__imp_IofCompleteRequest").getAddress()
print("IOCTL handlers located at: {}".format(ioctl_start))
Manually review switch table around 0x140001234
Step 3 – Set up a kernel debugging environment. Use a Windows 11 virtual machine with the following BCD settings to enable kernel debugging:
bcdedit /set debug on bcdedit /set testsigning on bcdedit /dbgsettings serial debugport:1 baudrate:115200
Boot the VM with the kernel debugger attached using WinDbg. Place a breakpoint on `gdrv3!DeviceIoControlDispatch` and send an IOCTL from user mode:
bp gdrv3!DeviceIoControlDispatch g
When the breakpoint is hit, examine the IOCTL code passed to the dispatch routine:
dd @rsp inspect stack for IOCTL code db @rcx examine IRP structure
- Exploiting Primitive Chain: From Physical Memory Write to EDR Termination
Once an attacker gains arbitrary physical memory write capability via an IOCTL like 0xC3502804, they can directly modify kernel structures to disable security software. The following conceptual attack flow demonstrates how multiple primitives are chained together:
Step 1 – Locate the kernel base address. Use the physical memory read IOCTL to scan for known kernel signature patterns, such as the `MZ` header of ntoskrnl.exe. The following pseudo‑code emulates this scan:
// Scan physical memory for the kernel image
for (phys_addr = 0x1000; phys_addr < 0x1000000; phys_addr += 0x1000) {
BYTE buffer[bash];
PhysicalMemoryRead(phys_addr, buffer, sizeof(buffer));
if (memcmp(buffer, "MZ", 2) == 0 && buffer[bash] == 0x40) {
kernel_base = phys_addr - buffer[bash];
break;
}
}
Step 2 – Overwrite the `EtwpEventTracingProvRegHandle` pointer. This kernel global, when nullified, disables ETW logging and breaks many EDR sensors. An attacker calculates the physical address of the pointer and issues a physical memory write IOCTL to set it to zero.
Step 3 – Terminate EDR processes using `ZwTerminateProcess` via a kernel callback. Some BYOVD chains employ a second driver that, once loaded, uses the kernel `memcpy` primitive to install a call gate that directly invokes `ZwTerminateProcess` from user mode.
- Hardening Against BYOVD: HVCI, Smart App Control, and Driver Blocklist Deployment
Microsoft provides multiple layers of defense against BYOVD attacks. Security teams should enforce the following configurations across all Windows endpoints.
Enable Hypervisor‑Protected Code Integrity (HVCI). HVCI ensures that kernel code integrity checks are performed in a protected hypervisor context, preventing unsigned or tampered drivers from executing. The setting is found under Windows Security → Device Security → Core Isolation → Memory Integrity. The following PowerShell command enables HVCI remotely:
Enable HVCI via Registry (requires reboot) Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" -Name "Enabled" -Value 1 -Type DWord
Activate the Microsoft Vulnerable Driver Blocklist. Starting with Windows 10 20H2, the blocklist is enabled automatically when HVCI or Smart App Control is on. To verify its status:
Check vulnerable driver blocklist status
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'; ID=3095} | Format-List
Organizations can also manually add drivers to the blocklist using the `Add-VulnerableDriverBlocklist` PowerShell cmdlet (available in Windows 11 22H2 and later):
Add gdrv3.sys by SHA256 hash to the global blocklist Add-VulnerableDriverBlocklist -Hash "A12F3456..." -Description "Block gdrv3.sys"
What Undercode Say:
- BYOVD attacks are a supply chain problem. Hardware vendors continue to ship kernel drivers with debug‑grade IOCTL interfaces, turning legitimate drivers into potent attack vectors. Until Microsoft enforces mandatory driver fuzzing and access control reviews before WHQL signing, the vulnerable driver ecosystem will persist.
-
Defense must be layered and proactive. HVCI, WDAC, and the vulnerable driver blocklist are effective, but they are often disabled for compatibility reasons. Organizations must balance operational needs with the reality that a single vulnerable driver can hand attackers the keys to the kernel.
Prediction:
As EDR evasion becomes central to ransomware playbooks, BYOVD will evolve into BYOVD 2.0—attackers will increasingly deploy custom, ephemeral drivers using exploited certificate authorities or firmware‑based persistence. Microsoft will respond by enforcing stricter WHQL signing requirements, possibly moving toward mandatory driver sandboxing or formal verification for hardware access drivers. However, legacy driver support will remain a gap, and the next 12–24 months will see a surge in government‑led coordinated disclosure of vulnerable drivers, alongside automated scanning services that flag unsigned or suspicious IOCTL interfaces before they reach production. The arms race between threat actors and Microsoft’s kernel security stack has just entered its most critical phase.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Abelousova Gdrv3sys – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
