2026-10-23 21:32:55 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

cover_image

KslDump曝光：微软自家驱动成PPL保护克星，LSASS凭证窃取只需改注册表

原创

Red Hunter
Red Hunter

黑白之道

2026年7月2日 08:43
韩国

在小说阅读器读本章

去阅读

导语：为什么每次提到\"凭证窃取\"，都绕不开Mimikatz？因为——Windows的PPL保护，在内核面前就是一张纸。最新披露的KslDump技术证明：攻击者甚至不需要自己带刀，微软Defender已经\"贴心\"地在厨房里留了一把。而这把刀，恰恰是微软自己签名的。

一、事件背景：厨房里本来就有一把刀

2026年7月1日，安全研究员\"Dinosn\"在社交媒体上发布了一条简短却震撼的技术推文：

\"Why bring your own knife when Defender already left one in the kitchen?\"

（既然Defender已经在厨房里留了一把刀，为什么还要自己带？）

这条推文指向的是一款名为KslDump的开源工具，由研究人员andreisss开发并发布在GitHub上。该工具能够从启用了PPL（Protected Process Light，受保护进程光）保护的LSASS进程中提取凭证，而整个攻击链使用的全部是Microsoft签名的组件——没有外部驱动，没有漏洞利用，没有恶意软件部署。

换句话说：攻击者什么都不需要带，系统里全都有。

二、核心技术：PPL保护的\"死亡途径\"

2.1 什么是PPL？

\\PPL（受保护进程光）\\是Windows为了防止凭证盗窃而设计的一种进程保护机制。从Windows 11 22H2开始，LSASS进程默认以PPL模式运行，即使用户是本地管理员，也无法直接用OpenProcess或ReadProcessMemory访问LSASS的内存空间。

这本是微柔和安全社区力推的\"凭证保护终极防线\"。

然而，PPL只保护了用户态API路径——它对内核模式的物理内存访问没有任何约束力。

2.2 KslD.sys：微软自己留下的\"侧门\"

问题出在微软Defender自带的一个内核驱动——KslD.sys。

这个驱动是Microsoft签名、受信任的内核模块，在系统中暴露了一个设备对象\\\\.\\KslD。它被设计用来做某些内核级别的安全检测操作，并向用户态程序提供接口。

该驱动支持一个IOCTL控制码0x222044，其中有一个关键子命令——SubCmd 12：

子命令	功能	影响
2	返回CR3、IDTR等CPU控制寄存器	立即瓦解KASLR
12	调用MmCopyMemory()，可读任意物理/虚拟地址	任意内核/物理内存读写

SubCmd 12本质上是一个无限制的MmCopyMemory()包装器。而MmCopyMemory()是微软自己的内核API，用于按物理地址或虚拟地址复制内存——它不检查PPL，不验证进程保护级别，只要地址和大小对，就能读。

2.3 补丁为何变成\"二次伤害\"？

真正讽刺的还在后面。

2026年3月7日，研究人员向微软安全响应中心（MSRC）报告了这个问题。但微软的回应是：这不是漏洞，因为攻击者需要先具备管理员权限。

于是微软发布了新版KslD.sys（82KB），将SubCmd 12的MmCopyMemory指针直接清零——相当于堵住了这个功能。

但微软只是更新了wd\目录下的新版本，而旧版漏洞驱动（333KB）仍然躺在System32\drivers\目录里，从未被删除。

攻击者只需要做一件事：把注册表里的ImagePath指回旧版驱动，重启服务，齐活。

两个版本都是微软签名的，操作系统照单全收。

三、攻击流程：六步拿到明文密码

根据GitHub上的技术报告，KslDump的完整攻击链如下：

第一步：注册表篡改

修改HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\KslD下的ImagePath，指向旧版漏洞驱动（System32\drivers\KslD.sys）
修改AllowedProcessName为攻击者控制的进程名
重启KslD服务

第二步：绕过KASLR

调用SubCmd 2，获取CR3和IDTR
从IDT最低ISR地址推算出ntoskrnl.exe基址

第三步：内核漫游

通过PsInitialSystemProcess找到SYSTEM进程的EPROCESS
通过ActiveProcessLinks遍历找到lsass.exe
从EPROCESS+0x28读取lsass的DTB（页目录基址）

第四步：物理内存读取（绕过PPL的关键）

使用SubCmd 12配合flags=1（物理读取）
基于lsass的DTB进行页表遍历，直接读取lsass进程的物理页面
这一步完全绕过PPL，因为物理内存访问不经过OpenProcess/ReadProcessMemory

第五步：密钥提取

通过PEB遍历lsasrv.dll
在.text段扫描LSA密钥签名
沿BCRYPT链提取AES、3DES算法参数及IV

第六步：凭证导出

遍历LogonSessionList
解密MSV1\_0凭证
输出NT哈希

整个过程不需要任何第三方驱动，不需要加载未签名代码，不需要漏洞利用——全部由微软自己的组件完成。

四、微软的回应：\"这不是漏洞\"

研究人员将这一问题报告给MSRC后，得到了令人啼笑皆非的答复：

\"所述攻击依赖于预先存在的管理员权限。没有证据表明这些权限是如何获得的。在不证明权限获取漏洞的情况下，假设拥有管理员或root权限的攻击已经lower impact，因为拥有此类权限的攻击者已经可以执行更严重的操作。\"

翻译成人话就是：你都已经是管理员了，还偷密码干嘛？

MSRC拒绝为此分配CVE，也未发布任何官方修复方案。

而那个旧版漏洞驱动，依然安安静静地躺在全球数以亿计的Windows系统里。

五、为什么这个漏洞如此危险？

1. 攻击门槛极低 需要的一切都在系统里。攻击者只需要有本地管理员权限——而这个权限在工作站环境中非常常见（比如IT管理员、合规扫描工具、某些企业软件安装需求）。

2. 签名信任机制被滥用 HVCI（虚拟机代码完整性）和内核驱动块列表本是为了防止BYOVD（自带漏洞驱动）攻击而设计。但微软自己的驱动不在块列表之列——这是合理的设计决策，却恰好被这个漏洞所利用。

3. 检测困难 整个攻击链使用的都是正常签名的系统组件，传统的EDR监控（如API钩子、驱动加载监控）对这种手法几乎无效。

4. 影响面极广 所有Windows 11 22H2+（LSASS默认PPL）和Windows Server 2025（已加入域的非域控制器）都可能受影响。

六、缓解建议

措施	说明
删除旧版KslD.sys	清理System32\drivers\下的旧版驱动文件（如果存在）
启用Credential Guard	硬件虚拟化隔离的凭证保护，即使读取LSASS也无法获得明文
启用HVCI	强制代码完整性策略，限制内核内存修改
监控KslD服务重启	关注注册表ImagePath变动和KslD服务的异常重启
遵循最小权限原则	限制本地管理员数量，避免攻击者轻易获得高权限