文章总结： 本文分析AI提示词生成驱动级木马Rootkit的技术文档，揭示利用大模型代码生成能力向内核级木马蔓延的趋势。文档详细剖析了基于WDM框架的驱动实现规格书，包含进程伪装、TCP连接过滤、文件隐藏等六项内核干预能力，采用注册表轮询配置热更新机制。作者指出AI在规范引导下能完成任务，但存在蓝屏风险，需较强内核开发功底进行二次调试，网络对抗形势将更艰巨。
综合评分： 75
文章分类： 恶意软件,AI安全,红队,免杀,安全开发

分析AI提示词生成驱动级木马Rootkit有感

原创

MicroPest
MicroPest

MicroPest

2026年9月25日 18:27
安徽

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

读到《对一款Windows木马开源提示词的测评》一文，震惊之余也颇为释然。那是一份针对Windows/linux底层的自生成Rootkit木马的提示词，本文仅以windows驱动为例。曾几何时，驱动级木马由于涉及到系统底层，编写/调试均非常复杂困难，故一直是木马中的皇冠，难以发现，常是最高级木马的首选。随着大模型代码生成能力的持续增强，“开源提示词”这种模式已开始向内核级木马蔓延，其潜在危害不容忽视。

多年前，曾学习过张帆的《Windows驱动开发技术详解》、谭文的《天书夜读—从汇编语言到windows内核编程》，以及张银奎的《软件调试》《格蠹汇编》，这些都是陪伴我成长的历程。内核编程遵循自己的一套api以及框架，上面用到的就是后者WDM。遥想当年的挑灯夜战现如今被一夜抹平，试问：在AI面前，我们还需要读书吗？

下面，我们借助AI来分析该文档开发的驱动。

一、文档定位

这是一份驱动实现规格书(Implementation Spec),交给 AI 编码智能体,要求产出一个可加载于 Windows 7 SP1 ~ Windows 11(x86/x64)的 纯 WDM 内核驱动(.sys)。

• 架构约束

  :纯 WDM,不用 KMDF/UMDF;VS2010 + WDK 7600.16385.1

• 模块划分

  :7 个协作子模块

• 能力清单

  :进程 PID 伪装、TCP 连接过滤、文件路径 MiniFilter 隐藏、注册表项隐藏、驱动文件关机回写、DriverObject 元数据克隆伪装

二、整体框架:三层结构

设计特点:配置与执行分离——上层用注册表轮询驱动规则热更新,下层各模块只负责执行,互不感知配置来源。

三、编排层:生命周期

初始化顺序(§3,严格)

关键约束:

• Writeback 必须在 Spoof 之前(伪装后读不到真实驱动路径)
• 任一步失败只 KdPrint,不阻断,最终必返回 STATUS_SUCCESS(非致命初始化)

清理顺序(§4,依赖逆序)

四、配置层:RegConfig(§5)

核心机制:系统线程 + KeWaitForSingleObject(StopEvent, 5s) 轮询。

规则热更新:值变化触发 NetHide_ResetRules(),5 个键全部重放;PidSpoofRestoreAll 仅在 Process 串变化时调用。

五、功能层:六个子模块

各模块的挂钩/回调框架:

• C(NetHide)

  :替换 \Driver\nsiproxy 的 MajorFunction[IRP_MJ_DEVICE_CONTROL],在 IRP 完成例程里删 TCP 表条目——典型的 IRP 拦截 + 完成例程

• D(PathHide)

  :标准 MiniFilter 框架,FLT_OPERATION_REGISTRATION 声明回调,FltRegisterFilter 注册

• E(RegHide)

  :标准 注册表通知框架,CmRegisterCallbackEx 注册,REG_NOTIFY_CLASS 分派

• F(WriteBack)

  :设备对象 + 关机通知 + 电源回调

• G(DriverObjectSpoof)

  :修改 _DRIVER_OBJECT 及 KLDR_DATA_TABLE_ENTRY(PsLoadedModuleList 节点)

六、贯穿性约束(§0.1 + §13 + §14)

1. 强制加固项(§0.1,14 条)

文档用一张表列出相对”参考实现”的加固要求,涉及:

• x86/WoW64 共用完成例程

• OutstandingIrp

  计数与卸载轮询

• 目录隐藏的子树匹配

• 服务名运行时解析(不硬编码)

• 同名进程全部伪装

• 卸载时恢复 IRP_MJ_SHUTDOWN 等

2. 工程配置(§13)

• 链接库:ntoskrnl.lib;hal.lib;wdm.lib;bufferoverflowK.lib;fltMgr.lib

• 4 种配置:Debug/Release × Win32/x64

• 入口点:x64 = DriverEntry,x86 = DriverEntry@8

• ALLOC_PRAGMA

  分页策略

3. 线程安全(§14)

4. 文件命名与头文件规范(§1)

• PascalCase;统一只 #include&nbsp;<ntifs.h>
• PathHide 额外需 <fltKernel.h> 等

七、框架关系图(模块依赖)

注意:G(DriverObjectSpoof)与 F(WriteBack)的触发时机在 DriverEntry 内固定(不通过配置),其余 4 个功能模块由 RegConfig 的规则驱动。

八、一句话总结这个框架

它是一个”注册表轮询驱动配置 + 六项内核级干预能力”的 WDM 驱动:

• 用 DriverEntry/DriverUnload 做生命周期编排
• 用 RegConfig 后台线程做配置热更新
• 用 IRP 拦截、MiniFilter、CmCallback、PowerCallback、DRIVER_OBJECT 改写 五套不同的内核机制实现干预能力
• 全部采用 “失败不阻断” 的容错风格

总结 ：在上文中，作者按照提示词实现了一个驱动文件的编写并作了源码的分析，并指出了会蓝屏BSOD（提示词存在“坑”，需要“较强的内核开发功底进行二次调试和适配”）。通过上面的剖析，我感到AI在提示词的规范引导下，能够很好地完成任务，假以时日，AI能够很好解决细节问题，如硬编码带来的不稳定性，以及更隐蔽的Hook位置等。可以想象，网络对抗问题更加艰巨。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：MicroPest MicroPest
MicroPest《分析AI提示词生成驱动级木马Rootkit有感》