A hybrid static-dynamic analysis for identifying BYOVD vulnerabilities

2026/10/27

Categories: Blogpost Tags: Windows Malware BYOVD Vulnerability Research

A Windows driver can be legitimately signed and still give malware a way into the kernel. That is the uncomfortable premise behind the Bring Your Own Vulnerable Driver (BYOVD) paradigm: attackers load a trusted but vulnerable driver and abuse its privileges to disable security products, manipulate memory, or bypass Code Integrity.

In our NDSS 2026 paper, we showed how to expose these attacks by observing what drivers actually do at runtime. Our new paper in Computers & Security, “A hybrid static-dynamic analysis for identifying BYOVD vulnerabilities”, goes a step further: we combine that kernel-level visibility with symbolic execution to find dangerous capabilities even when no available malware sample triggers them.

The outcome? 13 previously undocumented vulnerable drivers, five distinct CVEs, and a substantially more capable analysis pipeline. The article was published online in October 2026 and appears in Volume 173 (2027).

The Blind Spot We Left Open at NDSS

Our original system extended the DRAKVUF sandbox with kernelmon, a plugin that observes driver behavior from outside the guest operating system. By tracing the interactions between user-mode applications and kernel drivers, we could reconstruct suspicious actions invisible to ordinary user-space monitoring. We analyzed 8,779 execution-parent samples and disclosed seven previously unknown vulnerable drivers.

But dynamic analysis has an unavoidable limitation: it can only observe code that actually runs. A driver might expose an unsafe IOCTL handler, yet the malware in our dataset might never call it, supply the right inputs, or satisfy the required runtime conditions. No observed exploit does not mean no vulnerability.

This raised the natural follow-up question: Can we combine evidence of what a driver does with analysis of what it could do?

Two Complementary Ways to Inspect a Driver

Our new pipeline integrates two complementary techniques:

We expanded the taxonomy from 7 to 15 observable security-relevant behaviors. The original five stages of a BYOVD attack and these fifteen behaviors are different concepts: the former describe the attack workflow, while the latter describe what we try to detect.

The two analyses are integrated: a driver can be inspected statically on its own, while executables running in the sandbox are monitored dynamically; drivers loaded during execution are also forwarded to the static analyzer. One technique explores potentially reachable paths, while the other supplies concrete runtime evidence.

How Much Did We Improve?

The new evaluation covers 6,508 signed driver binaries and 9,109 execution-parent samples. Compared with the earlier study, some of the most useful figures are:

Metric NDSS 2026 Computers & Security follow-up
Observable BYOVD behavior categories 7 15
Execution-parent samples analyzed 8,779 9,109
Known-vulnerable driver groups showing suspicious runtime behavior, among groups actually loaded 44 / 106 (41.5%) 67 / 106 (63.2%)
Previously undocumented vulnerable drivers reported 7 13

The enhanced IOCTLance also identified suspicious capabilities in 115 additional potentially vulnerable driver binaries (44 additional name-based driver groups) compared with the earlier IOCTLance version. Overall, static analysis reported at least one suspicious behavior in 72.1% of the known-vulnerable binaries and 23.2% of the potentially vulnerable binaries. These are candidate findings, not automatic proofs of exploitation.

Importantly, improvement does not always mean generating more alerts. After we corrected an over-approximation in the memory-remapping detector, the proportion of loaded potentially vulnerable driver groups flagged dynamically decreased from 40.7% to 31.9%. That change reflects a more conservative detector, not a claim that fewer drivers are dangerous.

13 Vulnerable Drivers, Five CVEs

The most tangible result is the identification and coordinated disclosure of 13 previously undocumented vulnerable drivers, and -so far- we got assigned reports five distinct CVEs:

One particularly revealing example is Qualcomm’s btfilter.sys (CVE-2026-24076). Our static analyzer uncovered a type-confusion issue involving RtlQueryRegistryValues that can lead to an arbitrary kernel-memory write, potentially disabling Code Integrity. It is worth emphasizing that there was no suitable execution-parent sample for this driver, so, a purely dynamic pipeline would not have found it in our experiment.

The reverse situation also occurs. In the IObitUnlocker.sys case study, kernelmon observed a protected-process termination behavior that symbolic analysis missed because the effect emerged indirectly from file-unlocking logic. With iscflashx64.sys, both techniques identified an unsafe registry-query pattern. These examples illustrate why neither static nor dynamic analysis is sufficient on its own.

We followed coordinated disclosure procedures with the affected vendors, Microsoft, and MITRE, allowing vendors a remediation window before publication. At manuscript time, three driver reports were still under review.

What This Means for Defenders

Our results suggest that driver assessment needs both sides of the picture: static analysis to reveal capabilities that might remain dormant, and dynamic analysis to show which security-relevant behaviors are actually exercised. Even their combination is not a magic vulnerability oracle: candidate findings still require careful analysis and, where appropriate, manual validation.

The broader lesson is simple: trusting a driver because it is signed is not enough, and watching a driver run is not enough either. Combining different perspectives helped us uncover vulnerabilities that either one could miss.

Learn More

Authors

>> Home