1. RTCore64这个驱动是怎么变成内核算噩梦的1.1 从MSI Afterburner到恶意利用的转变先聊聊RTCore64.sys的出身。它是微星Afterburner显卡超频工具自带的一个内核驱动。Afterburner在超频圈子里几乎是装机必备用来拉显存频率、调风扇曲线、解锁功耗墙。这种工具必须直接操作显卡硬件寄存器光靠用户态API做不到所以它必须带一个具备底层硬件访问能力的内核驱动。当时的路径也很标准微软做WHQL签名驱动文件进了Windows生态的可信名单。但问题恰恰出在这个可信上。CVE-2019-16098公布后很多人做本地验证才发现这个驱动对外暴露的能力大得离谱用户态进程只要打开对应的设备对象就能让它执行任意物理内存读写、任意MSR读写、甚至把物理内存直接映射进用户态地址空间。我强调一下这个打开设备对象的门槛极低——默认配置下普通权限用户就能做到。等于说一台装了Afterburner的Windows机器任何没有管理员权限的程序都能通过这个驱动拿到接近内核级的硬件控制能力。这不是微星故意留后门更像超频工具的功能需求和安全管理没做好平衡。超频软件需要给用户态程序提供高位精度的硬件控制接口但那个年代的驱动开发普遍没把调用者是否可信当回事。这个疏忽后来直接让RTCore64成了恶意软件圈最常用的已签名漏洞驱动之一安全行业专门给这类攻击起了个名字叫BYOVDBring Your Own Vulnerable Driver自带易受攻击驱动。1.2 CVE-2019-16098的根因IOCTL接口没做调用者校验CVE-2019-16098说白了是RTCore64的一批IOCTL控制码缺少必要的输入参数和调用者权限校验。驱动和设备通信走的是Windows标准的IOCTL机制。用户态程序用DeviceIoControl发命令给设备内核驱动在分发例程里解析命令并执行。RTCore64里最致命的几个功能是这样的任意物理内存读写调用方传入物理地址和长度驱动直接读写那一段物理地址对应的内存内容任意MSR读写MSR是CPU底层的控制寄存器涉及缓存控制、性能监控、电源管理等核心状态物理内存映射把指定物理内存段映射到调用进程的虚拟地址空间让用户态代码直接看物理内存。这三件事放在正常的Windows权限模型里都只有内核最高权限代码才能碰。普通应用只能访问自己的虚拟地址空间任何对物理内存的直接访问都必须经过内核的内存管理器授权。而RTCore64把这些能力全部用IOCTL开放了出去既没有校验调用方的权限级别也不区分是用户态还是内核态发来的请求甚至没检查传入地址的合法性。这个案例在攻防研究里的价值在于攻击者根本不需要写内核Shellcode不需要找溢出点不需要对抗PatchGuard。驱动文件本身带合法签名Windows加载器放心放行驱动一进入内核恶意程序就拿到了一个官方内置的万能读写接口。这也是BYOVD手法的经典逻辑。2. 签名校验为什么拦不住这类攻击2.1 Windows加载驱动的正常信任流程要理解漏洞驱动为什么能畅通无阻得先弄清Windows驱动签名校验的生效边界。在64位Windows系统上从Vista时代起内核驱动就强制要求有数字签名。Windows 10的驱动签名强制策略更是严格未签名的驱动默认无法加载。这个校验动作由CI.dllCode Integrity模块在驱动文件被加载的瞬间执行读取PE文件签名、验证证书链、确认发布者身份、确认文件未被篡改。校验通过之后驱动才被映射进内核空间执行DriverEntry入口。签名校验解决的本质问题只有一个这个驱动文件的作者到底是谁。只要签名链有效Windows就认定这是可信开发者制造的良性代码至于驱动运行起来之后干了什么签名机制一律不管不问。2.2 绕过路径不是破解签名而是钻信任模型的空子回到标题说的绕过Windows签名校验严格讲攻击者根本没有破解签名算法。RTCore64.sys的签名是完整的、有效的、被Windows认可的。攻击者做的是钻信任模型的空子签名只保证文件源头可信不保证行为后果安全。典型的攻击流程也不复杂攻击者从公开渠道拿到RTCore64.sys原版驱动文件通过服务管理器创建指向该文件的服务这一步需要管理员权限——大多数恶意程序已经通过社工、UAC绕过或者其他漏洞拿到了启动服务Windows签名校验放行驱动正常加载进内核恶意程序在用户态打开RTCore64设备对象通过IOCTL获得内核读写能力之后的操作就进入属于内核该干的事了比如修改安全进程的内存保护标志、篡改内核回调、注入系统进程等。整个过程里攻击者没有对签名校验本身做任何攻击。校验机制依然在工作只是它审查的对象从整个内核访问行为缩小到了单个文件加载时的身份检查。这就是我经常在分析报告里强调的一个观点签名是信任链的入口不是安全边界。信任链一旦纳入了一个签了名的不可信组件整条链就从内部被瓦解了。2.3 同类驱动不止一个已签名漏洞驱动的生态RTCore64并不是孤例。安全界这些年挖出了一批类似的问题驱动很多都带WHQL签名功能上都开放了硬件级访问能力驱动文件来源暴露能力RTCore64.sysMSI Afterburner任意物理内存读写、MSR读写WinIo.sys第三方硬件工具端口I/O、物理内存访问dbk64.sys调试工具内核读写、进程操作SpeedFan相关驱动硬件监控工具物理内存访问问题Gmer驱动顽固恶意软件清理工具内核回调、SSDT操作能力这些驱动的共同特征很明显厂商出于功能需要开放了强能力接口但没做调用方权限隔离。都通过了微软签名认证所以Windows高层一律放行。对恶意软件作者来说这就像有人在系统安全边界上开了几扇带门禁卡的后门而且门禁卡是官方统一发放的。这里说句实在话这类攻击的技术门槛低得惊人。恶意程序只要把目标驱动文件放到磁盘、注册服务、发几个IOCTL剩下的操作全部是调用普通Windows API。这也解释了为什么近几年头部勒索软件家族几乎都把漏洞驱动利用做成了标准模块。3. 从攻防视角拆解利用链路签名只是敲门砖3.1 攻击链的概念拆解不公开具体利用代码的前提下我把这条链路的步骤抽象出来方便理解它的成功率和隐蔽性来源。攻击链的环节大概是这样的驱动文件落地。恶意程序把RTCore64.sys释放到本地可能伪装成驱动包的一部分、藏进临时目录、或者直接由内存释放。创建驱动服务。通过服务管理器注册一个指向该.sys的服务条目。这一步需要管理员权限但很多恶意变种已经通过提权漏洞或UAC绕过拿到了。触发加载。启动服务内核执行文件加载流程CI.dll验证签名通过驱动进入内核。打开设备句柄。用户态恶意代码用CreateFile打开RTCore64设备对象。执行内核操作。通过DeviceIoControl发起各种读写请求操作目标根据攻击目的变化。这个链路里恶意程序的执行体本身完全停留在用户态没有一段恶意代码真正被加载进内核空间。在内核里运行的是那个带合法签名的RTCore64.sys。这给安全产品的检测造成了很大的麻烦——传统的杀毒引擎很难靠行为特征断定用户态程序向RTCore64设备发IOCTL这件事是恶意还是良性因为超频玩家自己也会做一模一样的操作。3.2 RTCore64提供的内核特权具体能干什么拿到RTCore64的任意读写能力之后攻击者能做什么我按实际危害排列一下Patch内核回调列表EDR和AV在内核注册的回调函数比如注册表回调、对象回调可以被枚举并定点修改安全产品内核态的监控能力直接失效修改进程令牌把普通进程的Token替换成System令牌无痕提权到系统最高权限篡改内存完整性在HVCI没有部署的机器上可以修改内核关键结构比如当前进程的EPROCESS标志位实现隐藏和反分析绕过内核级防护策略包括禁用ETW、干扰驱动强制签名策略、操作PatchGuard保护范围之外的模块。这些能力让攻击者获得了对一台机器的最高解释权。恶意软件不再需要一点一点提权、找漏洞它直接从用户态跳到了内核态的控制面。这就是为什么这类漏洞驱动的危害评级普遍很高——它把内核攻防的距离缩短到了一个IOCTL的调用之间。3.3 勒索软件为什么偏爱这种手法这几年分析恶意样本我注意到一个趋势勒索软件内置漏洞驱动利用组件越来越多。样本里带着RTCore64.sys、或者同类驱动文件运行后先加载驱动做提权和安全软件对抗然后才开始加密文件。攻击者选择这种方案的原因很现实兼容性极好。RTCore64.sys是同一个文件驱动接口不变不受系统版本、补丁级别差异的影响稳定性高。漏洞利用提权需要匹配操作系统版本和硬件架构一个失误就蓝屏驱动利用只要驱动能加载操作就是稳定的复用成本低。一套利用代码可以在多个目标上反复用代码框架固定只需要替换驱动文件和目标参数。也就是说这是一种一次编写、到处运行的稳定攻击手段。从防御角度看这类攻击已经成了驱动层面的常态威胁而不是偶发事件。微软研究院和各大安全厂商这些年发布的威胁报告里漏洞驱动滥用占了相当大的比例。4. 检测一个合法签名驱动的反击策略4.1 静态层面用哈希和签名元数据定位已知漏洞驱动防守方最直接的对抗办法是维护已知漏洞驱动的指纹库。RTCore64.sys虽然存在多个版本但每个版本的SHA-256都是唯一的。拿到样本后先算文件哈希再跟情报库比对一分钟就能确认身份。安全产品做这件事的流程大概是抽取驱动文件的SHA-256、证书指纹、公司名、版本信息等元数据跟已知漏洞驱动库比对这类库有微软官方的驱动阻止列表、也有安全厂商聚合的威胁情报源如果匹配直接阻止服务创建动作或驱动加载动作。这里有一个细节值得提只比对文件名是远不够的。RTCore64.sys这个文件名太普通恶意代码可能改名换姓。一定得把哈希指纹和证书序列号都纳入检测维度才能有效识别改名的样本。4.2 动态层面盯住服务创建和驱动加载时的行为特征攻击链里有一段逃不开的动态特征监控住了就能尽早拦截驱动文件落盘特征一个系统目录里突然出现新的.sys文件且路径不在正常产品目录这是最基础也是最先触发的点服务注册行为服务管理器事件ID 7045记录新服务安装的名称、文件路径、服务类型。如果驱动路径指向临时目录或中文名/随机名路径告警价值很高异常加载时间线RTCore64.sys如果在一台没安装Afterburner的机器上加载或者在凌晨三点突然加载而当前没有任何超频工具的进程在运行基本可以判定出问题了IOCTL调用行为通过ETW的Threat Intelligence通道可以捕捉部分内核操作结合驱动设备对象的访问模式做异常检测。我处理过的事件里不少攻击者加载完驱动后迅速删掉.sys文件、删掉服务条目试图把静态痕迹擦干净。但ETW日志里驱动加载事件、文件创建事件、服务创建事件已经记录在案。只要这些日志做了集中收集依然能拼出完整的时间线。这也是为什么我一直强调动态监控绝不能只依赖磁盘扫描。4.3 应急响应时的取证线索如果你正在排查一台可疑机器重点检查这几个位置服务管理器里的驱动服务列表尤其注意ImagePath指向Driver目录之外的可疑服务项C:\Windows\System32\drivers\目录的新增文件看是否存在RTCore64.sys或同目录下多出来的异常驱动Windows事件日志中的7045服务安装、7040服务配置变更事件按时间线过滤内存取证里检查内核模块列表寻找名称可疑、或和当前安装软件对不上号的驱动模块。还有一个必须养成的习惯看时间线关联。正常用户装了Afterburner后驱动加载时间往往在软件安装前后很短的时间窗内并且该机器上存在对应软件的主程序。恶意场景里驱动文件落地时间和恶意进程首次落盘时间基本重叠但Agent上并没有对应的超频工具Trace。这类时间差在单个可疑机器的分析中往往是最强的证据点。5. 防御体系里的真刀真枪三个层面的具体落地5.1 平台侧用黑名单和WDAC把漏洞驱动拒之门外对抗已知漏洞驱动最成熟的手段还是黑名单。微软的Recommended Driver Blocklist已经覆盖了大量公开的易受攻击驱动通过Windows Update推送到各版本系统。Windows Defender也内置了这些规则命中直接拦截加载。但只靠微软默认规则是不够的。在企业环境里更好的做法是配合WDACWindows Defender Application Control做驱动白名单管理。落地的优先级可以参考这个顺序确保Windows Defender的实时保护、云保护和内核安全功能全开支持HVCI的机器打开内核隔离的内存完整性选项部署WDAC策略配置为仅允许微软签名和本企业签名的驱动加载这是对自定义环境彻底可控的方案在EDR和SIEM里建立自定义检测规则把RTCore64、WinIo等已知漏洞驱动文件名和哈希加入阻断名单不等厂商默认规则更新。这里专门说一下HVCI。它能对抗BYOVD的核心原因是Hypervisor会保护内核代码和关键数据区域的内存页即使RTCore64加载成功、想继续patch内核结构Hypervisor会阻止对受保护内存的写入。这是一种架构层的防御从根本上掐死了加载驱动之后改内核的攻击路径。代价是性能损失3%-5%还有少量旧驱动的兼容性问题但大中型企业这个成本我建议值得付出的。5.2 主机侧让漏洞驱动在加载阶段就失败主机侧的经验是行为阻断要比事后检测高效得多。很多EDR产品已经具备驱动加载阻断能力建议把以下配置做成标准基线对系统驱动目录开启写入审计并设置只允许SYSTEM和TrustedInstaller写入利用WDAC或AppLocker设置驱动加载限制非白名单驱动一律拦截部署EDR的漏洞驱动防护策略开启对服务创建、驱动加载的实时行为分析保持系统补丁和驱动阻止列表更新让微软的漏洞驱动黑名单及时生效。如果你管理的环境里存在特殊硬件工具需要加载自定义驱动别图省事给整个系统放行。更合理的做法是为那几台特定的机器做白名单例外其余机器维持严格策略。宁可先放行再观察日志也不要全局放开——这是我复盘多个安全事件得出的教训全局放开往往意味着给攻击者留了敞开的门。5.3 应急响应侧发现已加载驱动之后的处理顺序如果排查中发现某台机器已经加载了RTCore64.sys或者安全产品告警命中处理流程建议这样走立即隔离主机保留证据先别急着恢复服务保存内存镜像和事件日志用内存取证工具看驱动加载时的完整上下文确认驱动通过什么途径落地的是否存在恶意进程、恶意脚本、宏文档或横向移动痕迹收集样本计算哈希检查是否还有其他漏洞驱动文件被同时释放确认是攻击行为后按企业既定的取证和处置流程走不要单独把驱动删除就完事。我遇到过团队在发现RTCore64.sys后直接删文件、停服务结果系统出现内核不稳定甚至蓝屏。原因不难理解驱动加载后可能已经patch了系统的某些结构直接暴力删除驱动文件或者停掉服务等于在运行中的内核里抽掉一块砖。正确做法是先采集、后清理最好在安全模式或者取证镜像分析之后再做清除。6. 安全研究的合法边界与这个案例带来的思考6.1 研究驱动漏洞的正确姿势讲到这里必须花点篇幅说说这道线的具体位置。RTCore64的漏洞分析、POC代码在安全圈已经流传了几年很多公开技术文章都还原过完整分析过程。作为研究人员公开分析这类漏洞的正当价值在于推动厂商修复、帮助防守方建立检测规则。但这里有几条红线要守住只在自己搭建的隔离虚拟机或物理靶机上复现不公开发布可直接武器化的利用代码涉及厂商产品的问题按协调漏洞披露流程CVD提交给厂商留修复窗口写技术文章时细节深度控制在防守方可检测、纯复现者需要一定门槛的层次。我写这篇内容也是按这个标准自我约束的。原理和链路讲清楚能帮你理解攻击模式和做防御判定但不会喂给你一个拷贝就能打的利用包。6.2 从RTCore64事件看内核攻防的长期命题这个案例真正值得反复琢磨的是它对信任这件事的颠覆一个厂商花了大功夫拿到的WHQL签名最终成了恶意代码冲击内核安全的通行证。签名机制本身没有失效它只是没法回答一个更深的问题签名的代码是否适合运行在所有人的内核里对防守方来说应对思路必须从单一控制点转向纵深防御。应用层有EDR行为检测内核层有HVCI平台层有驱动黑名单和WDAC加上漏洞驱动的威胁情报持续更新。任何单一控制点都有可能被绕过但组合起来会让攻击者的成本明显上升。对驱动开发者来说这个案例更是个警示只要驱动对外暴露了IOCTL接口就要把这些接口当做面向系统所有进程开放的硬件控制端口来设计。必须做到所有调用都做权限校验、参数校验、完整性级别校验别抱着普通用户不会碰这个接口的侥幸心理。内核驱动的任何一个对外借口都要默认攻击者已经掌握了机器上的最低权限用户身份。看到这里如果你正在做Windows内核相关的开发或安全评估我建议找一台隔离的测试机把这个案例从头到尾复现一遍——不是复现攻击而是完整温习一遍加载链路、签名校验点、驱动对象创建机制和IOCTL分发流程。这套知识对理解Windows内核的信任边界比看十篇概念文章都管用。