文章总结： KslDump技术利用微软Defender的KslD.sys驱动漏洞，通过注册表篡改和物理内存读取绕过WindowsPPL保护，窃取LSASS凭证。攻击链完全使用微软签名组件，无需外部驱动或漏洞利用。微软拒绝修复此问题，旧版驱动仍存在于系统中。建议删除旧版驱动、启用CredentialGuard和HVCI，并监控KslD服务异常。 综合评分： 85 文章分类： 漏洞分析,红队,内网渗透,安全工具,应急响应

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服务的异常重启 | | 遵循最小权限原则 | 限制本地管理员数量，避免攻击者轻易获得高权限 |

七、工具获取

KslDump已在GitHub开源：

GitHub仓库：andreisss/KslDump

前置条件：

• 本地管理员权限
• Python 3.x + cryptography库（pip install cryptography）
• 系统必须存在旧版333KB的KslD.sys（默认路径：C:\Windows\System32\drivers\KslD.sys）

声明：该工具仅供授权安全测试和研究使用。未经授权访问计算机系统是违法行为。

版权声明：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。

👇 点击阅读原文，访问我的网站

免责声明：

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

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

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

本文转载自：黑白之道 Red Hunter Red Hunter《KslDump曝光：微软自家驱动成PPL保护克星，LSASS凭证窃取只需改注册表》