内核驱动
概念
**内核驱动（Kernel-mode Driver）**是在 Windows 内核态执行的组件，通常以 .sys 文件交付。它既可以服务于硬件，也可以承担文件过滤、网络过滤、安全监控等软件功能。运行在内核态意味着拥有较强的系统操作能力，但仍受代码完整性、内存保护和其他安全机制约束。
分析驱动时，应区分三个问题：
谁有权限请求安装或加载
↓
这个驱动能否通过系统准入并实际加载
↓
加载后谁在使用它，它实际做了什么
拥有管理员权限不保证任何驱动都能加载；签名有效不证明功能无害；驱动加载成功也不等于攻击已经成功。
驱动加载条件
安装、加载与使用
| 阶段 | 含义 | 需要验证的证据 |
|---|---|---|
| 安装或配置 | 驱动文件、驱动包或服务配置已准备好 | 文件、驱动包、服务或设备安装记录 |
| 加载 | 驱动映像进入内核并尝试完成初始化 | 实际加载记录、代码完整性结果及运行状态 |
| 使用 | 进程或其他组件访问驱动提供的接口 | 设备访问、控制请求与相关行为 |
| 产生影响 | 对目标对象的操作成功并造成变化 | 权限变化、安全组件状态、内存或其他结果证据 |
服务注册表项存在、安装命令成功或磁盘上出现 .sys，都不能单独证明驱动已加载。驱动也可能只在设备出现、服务启动或下一次开机时才加载。
请求加载需要什么权限
最直接相关的是 SeLoadDriverPrivilege（加载和卸载设备驱动程序特权）。它是令牌中的特权，区别于针对某个文件、注册表项或服务对象的访问权限。微软特权定义
| 路径或操作 | 主要权限条件 |
|---|---|
用户态直接调用 NtLoadDriver | 调用者有效令牌中具有并启用 SeLoadDriverPrivilege，并准备可访问的驱动配置和文件 |
| 通过服务控制管理器创建驱动服务 | 对 SCM 获得 SC_MANAGER_CREATE_SERVICE；默认配置下通常需要提升后的管理员进程 |
| 启动已有驱动服务 | 对该服务获得 SERVICE_START；后续加载由系统服务管理器执行，发起者不必亲自调用 NtLoadDriver |
| 写入驱动文件或注册表配置 | 对相应文件、目录、注册表对象具有写权限；系统位置通常需要较高权限 |
| PnP 驱动安装与自动加载 | 由设备安装、驱动包与系统策略决定；不能把所有自动设备安装都等同于用户直接调用 NtLoadDriver |
SCM 与服务的权限定义见服务安全与访问权限。常见驱动服务配置位于：
HKLM\SYSTEM\CurrentControlSet\Services\<DriverName>
需要区分管理员账户和提升后的管理员进程。UAC 下，管理员普通启动的程序通常使用过滤后的令牌；提升后才使用完整管理员令牌。令牌中存在某项特权，也可能尚未启用；调整特权状态不能凭空获得令牌里不存在的特权。UAC 令牌机制
常规场景下，提升后的管理员通常能够发起安装或加载请求，不必先成为 SYSTEM。SeDebugPrivilege 不是加载驱动所需的特权，管理员或 SYSTEM 身份也不自动豁免驱动签名检查。
Windows 自身的准入检查
即使没有第三方 EDR，Windows 自身也有驱动准入机制。以下以正常安装、未主动削弱防护的现代 64 位 Windows 为主要背景；具体结果仍取决于版本、更新、硬件和有效策略。
| 检查 | 主要作用 | 判断边界 |
|---|---|---|
| 内核签名与代码完整性 | 检查驱动是否满足系统信任和完整性要求 | 普通商业代码签名验证通过，不等于获得内核加载资格 |
| 漏洞及恶意驱动阻止规则 | 拒绝已知危险驱动或相关签名证书等 | 新样本未命中某条规则，不等于被认证为安全 |
| HVCI／内存完整性 | 在 VBS 隔离环境中强化代码完整性与执行内存约束 | 不是对所有驱动功能进行恶意意图判断 |
| Windows Driver Policy | 在适用系统上进一步限制驱动签名准入 | 需要核对审计或强制执行状态 |
| 企业应用控制 | 按组织策略限制批准的驱动、发布者等 | 只有策略已部署并强制执行，才具有相应阻断效果 |
微软的驱动签名政策说明，Windows 10 1607 起的新内核驱动通常需要通过微软 Dev Portal 签名；历史兼容例外与系统条件有关。不能将“买证书并给文件签名”直接写成“现代 Windows 一定允许加载”。
截至 2026 年 10 月，微软的Windows Driver Policy 说明还描述了对旧交叉签名信任的收紧：在适用且启用强制执行的系统上，要求符合 WHCP 签名或其认可的旧驱动允许列表。该功能先经过审计阶段，重装后也会重新评估，因此“全新安装”不代表所有新增策略立即强制阻断。
Windows 11 2022 更新起，漏洞驱动阻止列表默认启用；它也不保证覆盖每一个危险驱动。规则可能包含文件、证书和其他匹配条件，不能简化成只比对文件 SHA-256。微软驱动阻止规则
兼容硬件上的全新 Windows 11 安装默认启用内存完整性，但仍应核对实际状态。内存完整性启用条件 HVCI 要求可执行内核页不能同时可写等约束；符合这些约束的驱动仍可能具有危险功能。HVCI 驱动兼容性
驱动被恶意利用的方式
BYOVD：滥用已有漏洞驱动
**BYOVD（Bring Your Own Vulnerable Driver）**是携带或部署已有的合法签名漏洞驱动，再利用它暴露的漏洞或危险接口获得内核操作能力。
已有加载条件
↓
部署并加载漏洞驱动
↓
访问驱动设备接口
↓
利用缺陷取得危险能力
↓
提权、读取敏感数据或干预安全组件
驱动原本可能用于硬件管理、诊断或安全软件。漏洞可能涉及设备访问控制不足、控制请求缺少授权、输入地址或长度未验证，以及暴露任意内核或物理内存访问能力。具体能做什么取决于漏洞，不能把所有 BYOVD 都等同于任意内核读写。
利用已经加载的驱动
攻击者不一定需要自己安装驱动。目标主机可能已经安装并运行一个有缺陷的组件；若设备接口允许低权限进程访问，且请求处理存在漏洞，普通用户态进程就可能通过它突破权限边界。
加载权限和使用权限是两道检查。 SeLoadDriverPrivilege 控制特定加载请求，不代表只有持有它的进程才能使用已经加载的驱动。驱动设备对象的 ACL、IOCTL 访问要求和驱动内部授权共同决定谁能调用接口。驱动开发者的 Windows 安全模型
DeviceIoControl 与 IOCTL 本身是正常的控制机制。危险在于接口提供了什么能力、调用者能否访问，以及参数和目标对象是否经过正确验证；不能把出现控制请求就判为攻击。IOCTL 安全要求
自编写恶意内核驱动
另一种路径是把攻击功能直接写入自定义驱动。它与 BYOVD 的区别在于：前者部署攻击者自己的内核组件，后者滥用已有驱动的缺陷。
CN-SEC 的银狐“双链路攻击”文章介绍了用户态组件识别目标、请求自编写驱动干预安全进程的思路，并提到签名和 VMP 加壳。其样本能否实际加载、获得哪种签名、能否操作特定受保护进程，仍须用具体样本和系统记录验证。
新驱动可能缺少已知文件特征，但仍需通过准入检查，也可能命中证书规则、企业允许列表、静态分析或行为检测。加壳只可能增加分析成本，不会产生有效签名或自动绕过代码完整性。签名流程也可能被滥用；微软曾调查经过其签名流程的恶意驱动，并实施检测与阻断。
常见攻击目标
| 目标 | 可能的行为 | 需要确认的结果 |
|---|---|---|
| 提权与权限边界 | 利用内核缺陷影响令牌、对象或访问检查 | 实际权限变化与被访问对象 |
| 安全产品致盲 | 干预安全进程、组件或采集路径 | 服务、传感器、遥测或响应能力确实异常 |
| 敏感信息获取 | 滥用内存或底层设备访问能力 | 实际读取范围、数据获取及后续用途 |
| 隐藏与持久控制 | 隐藏对象、干扰枚举或持续加载恶意组件 | 跨数据源不一致与持久化证据 |
| 完整性破坏 | 修改系统或进程中的敏感状态 | 具体被改对象、修改主体与后续影响 |
具有内核能力不代表能任意修改所有对象；PatchGuard、HVCI、VBS、PPL 和产品自保护各有不同作用，最终效果需要实证。
检测方法
先建立驱动与准入基线
对驱动记录文件路径、整体哈希、厂商、版本、签名链和签名验证结果，同时保留目录签名（catalog）信息。驱动文件没有嵌入签名，不应立即等同于没有任何有效驱动签名；还需检查驱动包及目录签名。
结合主机的用途、硬件、批准软件和历史版本，确认驱动来源及安装原因。再记录 Windows 版本与更新、Secure Boot、HVCI、阻止列表和应用控制策略的实际状态。规则处于审计模式与强制执行模式会产生不同结果。
区分系统日志与额外遥测
| 数据源 | 观察内容 | 使用边界 |
|---|---|---|
| System／Service Control Manager 7045 | 新服务安装，可筛选驱动服务类型和路径 | 创建服务不等于驱动加载成功；不是所有驱动加载都会新增服务 |
| Security 4697 | 服务安装、主体与服务配置 | 依赖相关审计设置；不是所有主机默认都记录 |
| CodeIntegrity／Operational | 签名、完整性和策略相关事件 | 应按具体事件及策略解释，不能把所有失败都归因于恶意软件 |
| App Control 3076／3077、3089 | 审计拒绝、强制拒绝及相关签名信息 | 3076 是“会被阻止但因审计而允许”，3077 是实际策略阻止；需关联策略与文件 |
| Sysmon 6 | 驱动加载、哈希和签名信息 | 需要部署 Sysmon 并确认配置及日志健康；不自动提供完整的加载发起者链 |
| Sysmon 1、11、12–14 等 | 进程、文件创建与注册表变化 | 依赖采集配置，用于补充驱动落地和配置主体 |
| EDR 或专门驱动遥测 | 设备访问、请求、目标对象与内核行为 | 覆盖取决于产品；不能假定所有 IOCTL 和内核内存修改都有记录 |
服务日志与审计见微软的 4697 说明；准入事件见 App Control 事件说明；额外采集能力见 Sysmon 事件文档。驱动加载应优先看 Sysmon 6，不能把用于进程模块加载的 Sysmon 7 当作等价证据。
刚装好的 Windows 不会因为有事件查看器就自动拥有 Sysmon 或 EDR 遥测。没有某条记录时，先核对是否部署、是否启用、是否过滤，以及日志是否被覆盖或受损。
关联落地、加载、使用与影响
可采用以下分析链，并允许“已有驱动被直接使用”等缺少前置阶段的情况：
异常进程写入驱动文件或修改驱动配置
↓
驱动加载或加载失败的证据
↓
可疑进程访问相关设备接口（若可采集）
↓
权限或目标对象异常变化
↓
安全组件退出、遥测下降或后续恶意活动
高价值线索包括：
- 驱动从用户目录、临时目录或不符合软件安装基线的位置落地和加载。
- 加载主体来自陌生安装器、脚本链或已确认的恶意进程。
- 驱动版本对应已知漏洞，或签名证书与恶意样本存在关联。
- 驱动加载后，安全组件状态与中心心跳、事件接收量同步异常。
- 已经加载很久的驱动突然被非预期进程访问，并出现权限变化。
- 可疑驱动加载前后，代码完整性、应用控制或安全配置发生变化。
这些是调查线索，不是单点定性条件。合法硬件工具、反作弊、备份、虚拟化与安全软件同样可能使用驱动和 IOCTL，应结合批准软件、维护时段、部署来源及实际操作对象降低误报。
证据与结论边界
| 观察到的事实 | 能支持什么 | 不能直接推出什么 |
|---|---|---|
.sys 文件落地 | 存在候选驱动文件 | 已安装、已加载或已利用 |
| 驱动服务创建 | 准备了某种加载配置 | 已通过签名检查 |
| 驱动加载事件 | 系统观察到驱动加载 | 漏洞利用或恶意操作已成功 |
| 数字签名有效 | 相应验证过程通过 | 驱动安全、满足所有准入策略 |
| 安全进程退出 | 组件退出这一事实 | 必然由某个驱动造成 |
| 用户态日志减少 | 某条采集路径可能异常 | 内核也没有行为或攻击完全隐身 |
保留完整驱动和驱动包，将文件、配置、签名、加载记录与目标变化按时间关联。若怀疑内核已经被恶意控制，不应仅依赖该主机自行枚举的结果，应结合中心遥测、网络侧记录、可信的离线检查和必要的内存取证。