那个(几乎)被遗忘的漏洞驱动

原文链接: https://mp.weixin.qq.com/s?__biz=MzAxODM5ODQzNQ==&mid=2247489231&idx=1&sn=f034dede5b891d2bb48876f82e18742a

那个(几乎)被遗忘的漏洞驱动

decoder securitainment 2025-07-04 14:49

The (Almost) Forgotten Vulnerable Driver 

免责声明:本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

Windows 驱动漏洞仍然是攻击者获取内核访问权限的主要利用方式之一。已知的漏洞驱动列表似乎永无止境,其中一些甚至没有被 AV/EDR 解决方案拦截,也未包含在微软的驱动阻止列表中。

之前,我重新审视了一篇关于通过利用已签名的漏洞驱动 StopZilla 创建令牌的旧文章。这个漏洞驱动不知为何避开了检测:它仍然未被拦截,不在坏驱动列表中,甚至没有出现在 “loldrivers” 数据库中,至少目前如此 😉

研究人员发现了 9 个漏洞:

那个(几乎)被遗忘的漏洞驱动

最有趣且最容易利用的 IOCTL 是 

0x80002063

和 

0x8000206F

,它们通过输出缓冲区提供任意(尽管有限)的写访问,且不验证传递的输出缓冲区地址。

那个(几乎)被遗忘的漏洞驱动

使用 METHOD_NEITHER
 时,用户模式地址会直接传递到内核空间而不进行验证,如果处理不当可能导致严重问题。

这些 IOCTL 的利用依赖于驱动设置初始值 1,然后在后续调用中将其递增 1 到用户模式传递的返回缓冲区:

那个(几乎)被遗忘的漏洞驱动

通过在 IOCTL 调用的返回缓冲区中传递当前进程的 token 地址,

_SEP_TOKEN_PRIVILEGES_TOKEN

结构会被多次覆盖,每次递增 1。值得注意的是,

uVar7

变量是一个由 4 字节组成的无符号整型。

该驱动漏洞不仅允许激活 SeCreateToken
 权限,通过一些耐心,还可以获得更直接有用的权限,如 SeTcb
,特别是与 SeAssignPrimaryToken
 权限结合使用时:

那个(几乎)被遗忘的漏洞驱动

我很好奇这个漏洞是否可用于其他场景。

首先,我尝试取消 LSASS 进程中的 PPL
(Protected Process Light)。

当 PPL 启用时,尝试运行 mimikatz 转储密码会得到预期的访问拒绝:

那个(几乎)被遗忘的漏洞驱动

_EPROCESS

结构中的重要字段包含这些值:

那个(几乎)被遗忘的漏洞驱动

理论上,如果我将  EPROCESS 结构的正确地址与偏移量 0x878 传递给驱动调用,它会将 SignatureLevel 设置为 1 并将接下来的三个字节清零,结果为 [0x01, 0x00, 0x00, 0x00]

可以通过 NtQueryInformation()
 API 调用获取 EPROCESS 地址:

那个(几乎)被遗忘的漏洞驱动

让我们看看是否有效:

那个(几乎)被遗忘的漏洞驱动

4 个字节被正确覆盖:

那个(几乎)被遗忘的漏洞驱动

是的,成功了!

那个(几乎)被遗忘的漏洞驱动

这也可以通过 System Informer 或类似工具观察到。LSASS 进程的 Protection 现在为空了 😉

那个(几乎)被遗忘的漏洞驱动

到目前为止一切顺利,但有一些注意事项:
– 使用 NtQuerySystemInformation
 获取 LSASS 进程地址需要管理员权限。但请注意,即使有新的限制要求配置必须在 HKEY_LOCAL_MACHINE\SYSTEM 注册表项下,也只需要 SeLoadDriver
 权限即可加载和启动驱动。这是因为该注册表项下仍有许多标准用户可写的位置

  • 从 Windows 11 24H2 / Windows Server 2025 开始,查询 LSASS 进程还需要启用 
SeDebugPrivilege
  • 这些版本中的偏移量也发生了变化。尽管注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
     下的 ReleaseId
     仍显示 2009,但 SignatureLevel
     现在从 0x05F8
     开始,而不是 0x0878
    。请务必检查 DisplayVersion 以确认是否为 24H2

完成这个实验后,我很好奇是否能更进一步。为什么不尝试将我的进程线程的 PreviousMode
 设置为 0
 呢?

将其设置为 

0

表示 内核模式
,意味着该线程被认为在当前执行之前运行在内核模式。内核模式下的线程是受信任的,绕过了用户模式线程所需的许多验证检查,并被授予对内核空间的完全访问权限

_KTHREAD 结构中 

PreviousMode

的偏移量可以使用 WinDbg
 等工具轻松识别,并且在 Windows 11 24H2 之前保持一致:

那个(几乎)被遗忘的漏洞驱动

在这种情况下,我们需要从偏移量 0x231 开始,因为我们需要将 

PreviousMode

设置为 0 而不是 1 😉

这次不需要管理员权限,因为进程是我们自己的。只需要将当前线程的句柄传递给 NtQuerySystemInformation
,当然前提是驱动已经在运行。

为了验证我们确实处于内核模式,我们将尝试以完全访问权限打开受保护的 SYSTEM
 进程(PID 4),如果成功,任务就完成了:

那个(几乎)被遗忘的漏洞驱动

是的,又成功了 🙂

那个(几乎)被遗忘的漏洞驱动

获得内核空间访问权限后,恶意行为者可能会做任何事情,例如禁用 EDR、修改系统进程和绕过安全控制。幸运的是,许多 EDR 解决方案会拦截这些操作并在为时已晚之前阻止它们。

如果你使用的是 Windows 11 24H2 或 Windows Server 2025,别担心!你只会得到一个漂亮的蓝屏,告诉你之前模式不匹配。 🙂

那个(几乎)被遗忘的漏洞驱动

这就是全部内容了!这篇文章只是为了展示即使是一个愚蠢的递增操作,被遗忘的坏驱动也可能有多危险。我不声称自己是这个领域的专家,如果你想深入研究,外面有很多资源。

对于那些想要深入了解这种黑魔法的人,我强烈推荐我才华横溢的朋友 Alessandro 写的优秀系列博客文章。

特别感谢我的老搭档 @splinter_code,他帮我解密了一些 Windows 内部机制,并协助我使用我最讨厌的工具 WinDbg!😉