1. mimikatz 到底是什么，为什么安全圈绕不开它
1.1 它到底做了什么
mimikatz 这名字在任何 Windows 10 安全运维讨论里，基本等同于“凭据提取”四个字。它其实不神秘，是 Benjamin Delpy 写的一个开源研究工具，最初目的就是演示 Windows 在处理认证凭据时的设计缺陷：内存里居然会保存明文密码、NTLM 哈希、Kerberos 票据。很多刚入行的人会问，这玩意儿是不是和病毒一样。恰恰相反，它挂在开源仓库里，被各色渗透测试框架反复集成，也几乎每天出现在 EDR 的告警名单里。
在 Windows 10 时代，微软陆续上了 Credential Guard、LSA 保护、WDigest 默认关闭这一整套组合防护，但 mimikatz 依然是安全运维绕不开的研究对象。原因很简单：攻击者真正拿到的往往不是“破解出来的密码”，而是“系统自己缓存下来的凭据”。它更像一面镜子，映出的是 Windows 凭据管理链路的真实状态。
1.2 为什么防御者也要研究它
很多人听到“研究 mimikatz”会下意识觉得这是攻击者才做的事。实际上，蓝队不研究它才怪。你要知道攻击者手上有什么牌，才能知道自己防线缺在哪一格。它常被用来做攻击路径验证：防护规则配好了，到底挡没挡住？不用它测一遍，你根本不知道答案。
这篇文章我不打算写任何可以直接拿去用的攻击命令，而是站在防御视角，把 Windows 10 的防护到底防住了什么、剩下的攻击路径有哪些、以及作为管理员和安全运维应该怎么补，一条一条说清楚。理解攻击思路只是手段，目的永远是加固和检测。
1.3 适合谁看
适合看这篇内容的读者有三类：第一是做渗透测试和红队评估的人，可以通过它了解 Windows 10 默认防护到哪一步了；第二是做安全运维和蓝队的，可以直接把后面的加固清单拿去落地；第三是纯好奇的系统管理员，看完至少能明白为什么现在很多加固指南都在提 Credential Guard 和 LSA 保护。我默认你手上有一台 Windows 10 测试机，可以是 22H2，也可以是 IoT Enterprise LTSC 2021，后面章节会专门提版本差异。
2. Windows 10 的默认防护，到底防住了什么
要理解“绕过”，得先理解“防护边界”。Windows 10 从 1607 版本开始逐步引入了一套凭据防护体系，今天在 22H2 上已经比较成熟。很多人以为它只是加了个杀毒，其实不是，它是在凭据存储、进程隔离、内存保护三个层面同时动手。
2.1 Credential Guard：把凭据关进独立虚拟机
Credential Guard 是 Windows 10 企业版和教育版才有的功能。它的思路非常硬核：用 Hyper-V 的虚拟化技术，把 LSA 进程的关键部分放到一个隔离的虚拟机环境里运行。这个环境里存着 NTLM 哈希、Kerberos 票据密钥，还有缓存的域凭据。由于这些数据根本不在常规操作系统内核和用户态内存里，普通的进程注入、内存读取手段都够不到。
更关键的是，即使攻击者拿到管理员权限、强制读取了 lsass.exe 的内存，得到的也只是被隔离之后的密文结构，而不是一张可以直接拿去用的哈希表。很多针对老版本 Windows 的经典操作，在开了 Credential Guard 的机器上会直接失效。这就是为什么测试环境里模拟攻击时，第一步永远是看目标机器到底开没开 VBS 和 Credential Guard。
这里要注意一个容易踩坑的地方：Credential Guard 不是装完就生效的。它要求 CPU 支持虚拟化扩展，主板要开 UEFI 和 Secure Boot，Windows 功能里要启用“基于虚拟化的安全性”（VBS）。很多机器表面上看策略开了，但硬件不满足，导致功能静默不工作。后面加固章节我会给验证方法。
2.2 LSA Protection：给 LSASS 进程上了一把 PPL 锁
LSA Protection，也叫受保护进程轻量级机制（PPL），是另一层独立防护。它做的事可以类比成给 lsass.exe 进程加了一个“调试免疫”标签。普通进程再去尝试打开 LSASS 句柄，会被系统直接拒绝，连 OpenProcess 都过不了。早期很多凭据提取操作之所以能轻松读 LSASS 内存，很大程度就是因为 LSASS 对任何进程都敞开大门；PPL 机制出现后，非受信任进程想访问 LSASS，会触发访问拒绝，注入就更不用说了。
当然，“受信任”的定义是由微软签名的机制决定的。PPL 不是一把绝对锁，它是把门槛大幅抬高，让攻击者在到达这一步之前就必须先解决进程认证和加载链的问题。对绝大多数自动化和脚本化攻击来说，这个门槛已经能挡掉一大半。Windows 10 的所有版本都可以手动开启 LSA Protection，通过注册表把 RunAsPPL 设为 1 即可，不一定非要是企业版。
2.3 默认禁用 WDigest，让内存里不再有明文
早期 Windows 在内存里保存明文密码的原因之一，是 WDigest 协议需要它。当初为了方便 HTTP 摘要认证，协议会在 LSA 内存中保留一份明文密码。很多老教程里那些直接读内存拿明文密码的演示，核心都围绕这层缓存展开。从 Windows 10 1607 开始，微软默认把 UseLogonCredential 设置为 0，也就是默认关闭 WDigest 的明文缓存。这导致很多老操作直接失效。
但是这个开关是可以被人为打开的，一些旧软件或兼容性配置脚本会悄悄把它设回来。所以加固时不仅要确认默认值，还要检查有没有第三方策略把它改回去。这一点在合规检查和攻防演练里尤其常见：一台机器干干净净上架，跑了一个老业务组件后，WDigest 又变回开启了。
2.4 版本和许可差异：家庭版、专业版、企业版、LTSC
Windows 10 的防护能力并不完全一致。下表把常见版本的支持情况整理一下，方便判断自己手上的环境属于哪一档。
| 防护项 | 家庭版 | 专业版 | 企业版/教育版 | IoT Enterprise LTSC 2021 |
|---|---|---|---|---|
| Credential Guard | 不支持（官方不建议） | 部分配置可开，限制多 | 完整支持 | 完整支持 |
| LSA Protection（PPL） | 支持 | 支持 | 支持 | 支持 |
| WDigest 默认关闭 | 支持 | 支持 | 支持 | 支持 |
| VBS 基本隔离 | 支持 | 支持 | 完整支持 | 完整支持 |
22H2 是 Windows 10 最后的正式功能更新版本，这些防护机制在 22H2 上已经比较完备。如果你维护的是 IoT Enterprise LTSC 2021 这类长期服务版，系统更新节奏不同，反而要更注意防护特性的默认状态是否真的启用了——LTSC 镜像可能存在组件裁剪，某些安全功能的初始状态不一定和普通企业版一致。我自己在排查时就遇到过一台 LTSC 机器，策略显示 Credential Guard 已启用，但 VBS 底层组件缺失，实际一直处于半失效状态。
3. “绕过”这三个字，在真实攻击里究竟指什么
很多标题党的文章会把“绕过”写成一条简单的命令，好像输入完就能穿透一切。但真做攻防的人会说，绕过是有前提的：攻击者首先要拿到一个能执行代码的本地权限，而且通常得是管理员权限，否则连打开进程句柄的机会都没有。Windows 10 的防护体系有一个共同假设——系统可能已经被部分入侵，所以防护要解决的从来不是“不让入侵”，而是“入侵后不让你拿到更深的东西”。
3.1 切入点一：LSASS 依然是凭据必经的中转站
普通用户每次登录、每个服务启动，凡是涉及身份验证的，LSASS 几乎都要参与。这意味着，就算 Credential Guard 把一部分凭据隔离走了，LSASS 进程本身仍然在处理大量的登录会话信息。攻击者最常见的思路就是盯住这个进程：要么直接读取它的内存，要么等设备上出现一次新的登录后，在内存里抓取刚缓存下来的凭据副本。
这个切入点的核心难点已经从“能不能读”变成了“要不要过 PPL”以及“能不能躲过 EDR 的进程访问监控”。对防御者来说，防护核心也相应变成：确保 PPL 开启、确保检测工具能监控对 LSASS 的异常访问。很多 EDR 和 Sysmon 规则集，核心就是盯着 lsass.exe 的进程访问事件。注意，我这里说的是攻击思路，不是操作步骤，防御者需要知道思路才能对应布防，这个逻辑和医生看病理报告是一样的。
3.2 切入点二：系统为了可用性，保留了大量“顺手缓存”
Windows 不会为了绝对安全牺牲可用性。比如域环境里的缓存登录凭据，为了在离线状态还能登录，系统会在本地保留一份哈希；比如 DPAPI 的用户密钥，为了加密文件和解密浏览器密码，会依附在用户凭据链上；再比如服务进程以某账户身份运行时，该账户的令牌和相关信息也会在内存里短暂驻留。
攻击者不一定只盯着“密码”，他们更愿意捞“哈希”和“票据”。哈希不能反解成明文，但可以被重放；Kerberos 票据在有效期内也能被滥用。换句话说，尽管明文密码被藏起来了，可是“可用于冒充身份的凭据副本”不能完全消失。这就是“绕过”二字的真实含义之一：不是绕过密码技术本身，而是绕过“系统对访问者身份的确认”这道逻辑判断。
3.3 切入点三：拿到哈希就横向，不需要明文密码
Pass-the-Hash，哈希传递，在 Windows 域环境里是老经典了。简单说，NTLM 认证时，攻击者不需要知道密码明文，只需要持有密码对应的 NTLM 哈希，就能向其他服务发起身份验证。mimikatz 被广泛关注的一个重要原因，就是它能很方便地把内存里的哈希捞出来，然后被用于横向移动。
同样地，这不是“破解”密码，而是“借用”认证材料。Windows 10 的 Credential Guard 能防一部分这类的滥用，因为隔离区里的哈希出不来；但千万别忽略：如果攻击者是从另一台老版本机器，或者从一个未开 Credential Guard 的域成员上拿到的哈希，照样能往你开了防护的机器上打。所以这个切入点的防御，单靠一台机器的防护远远不够，必须结合账户最小权限、本地管理员密码随机化、网络分段一起看。
4. 从绕过路径倒推加固方案
接下来是真正能落地的部分。我会把防御措施按层次拆开，每一层都尽量给出可以直接执行的方式。这套逻辑我在实际加固项目里验证过多次，你不需要全做，按自己环境的容忍度取舍就好。
4.1 先确认硬件条件，再启用 Credential Guard
Credential Guard 对硬件有真实要求。按下面顺序检查：
- CPU 支持虚拟化扩展（Intel VT-x 或 AMD-V），且 BIOS/UEFI 里已开启。
- 主板启用了 UEFI 模式，Secure Boot 为开启状态。
- Windows 功能里启用“基于虚拟化的安全性”（VBS）。可以在可选功能里打开 Virtual Machine Platform 和 Windows Hypervisor Platform 相关组件。
- 通过组策略启用 Credential Guard：计算机配置 -> 管理模板 -> 系统 -> 设备保护 -> 打开基于虚拟化的安全性，选择“已启用”，并确保“Credential Guard 配置”为“带 UEFI 锁定”或默认的“已启用”。
验证是否真的生效，最直接的办法是打开“系统信息”，查看“基于虚拟化的安全性”这一项是否显示“正在运行”。如果显示“未启用”，通常就是硬件条件或固件设置不满足。还有一条更严格的思路：刻意在启用 Credential Guard 的机器上做一次模拟凭据提取测试，看是否空手而归。这一步对安全团队来说是最有说服力的验收，比自己对着设置项猜要可靠得多。
4.2 手动开启 LSA Protection
如果你的版本不支持 Credential Guard，或者主机是 LTSC 环境不方便开虚拟化，LSA Protection 是性价比最高的替代加固。操作很简单，在注册表路径 HKLM\SYSTEM\CurrentControlSet\Control\Lsa 下，新建 DWORD 类型的 RunAsPPL，设置值为 1，然后重启系统。
这个开关背后的含义是把 lsass.exe 标记为受保护进程。开启之后，你可以再用一个普通权限的进程尝试打开 lsass 句柄，正常情况会收到“拒绝访问”错误。这能挡住绝大多数脚本化的凭据抓取工具，包括那些把工具打包成内存执行的自定义变体。唯一要注意的是，某些老牌杀毒软件或特权进程管理工具可能与此机制冲突，上线前建议先做一版兼容性回归。
4.3 借助 Windows Defender 的 ASR 规则拦截 LSASS 访问
很多人不知道，Windows 10 自带的 Microsoft Defender 里有一组“攻击面减少规则”（ASR），其中专门有一条规则就是阻止针对 LSASS 进程的可疑访问。开启它之后，Defender 会拦截未受信任进程打开 lsass.exe 的句柄，效果类似给 PPL 加了一道第二道门。
实际操作路径：打开 Windows 安全中心 -> 应用和浏览器控制 -> 攻击面减少规则 -> 添加规则，在规则列表里找到“阻止凭据窃取（针对 lsass.exe 进程的访问）”。可以选择“仅审核”模式先跑一到两周，观察误报情况，再改为“强制阻止”。生产环境直接开强制往往会把一些正常运维工具也拦掉，所以我都会建议先审核，看日志再切换。如果环境里已经有专业的 EDR 产品，可以不依赖 Windows Defender 的 ASR，但一定要确认 EDR 在监控 LSASS 的进程访问。这是检测能力的底线，不是可选项。
4.4 账户与网络侧的配套补丁
凭据窃取类攻击能得手的背后，还有两个常常被忽略的因素：管理员账户太多、以及本地密码高度重复。
- 所有服务器的本地 Administrator 密码建议部署 LAPS 进行随机化。这是防哈希传递最经典的配套措施之一，因为就算哈希被抓到了，每台机器密码不同，横向移动就会断掉。
- 严格限制域管理员账户的使用，禁止普通运维日常交互登录时使用高权限账号。最好做到高权限账号仅用于跳板机或特定管理机。
- 网络层面对管理协议（RDP、WinRM、SMB 等）做来源限制，只允许管理网段访问。这个听起来基础，但多数横向移动成功案例都栽在管理协议对全网开放上。
- 如果开了 Credential Guard，受保护的用户组（Protected Users）可以作为第二道保险，它从协议层面禁止了部分凭据被缓存。
4.5 手工检查加固清单
给一张我常用的检查表，你可以拿去做日常巡检：
| 检查项 | 期望值 | 检查方式 |
|---|---|---|
| VBS 状态 | 正在运行 | msinfo32 系统信息 |
| RunAsPPL | 1 | 注册表查询 |
| WDigest UseLogonCredential | 0 | 注册表查询 |
| ASR LSASS 规则 | 审核或阻止 | 安全中心查看 |
| 本地管理员密码 | 已随机化 | LAPS 报表 |
这份检查表不需要像论文那样严格，但至少每季度跑一遍。很多故障和漏洞不是防护没装，而是装好之后被某次升级或某台机器的策略覆盖悄悄改掉了。配置管理基线比一次性加固更重要，这句话我在交付报告里几乎每次都会写。
5. 在日志与遥测里识别“被绕过之后”的痕迹
防护永远有兜不住的一天，所以最后一道防线是“看得到”。我见过不少团队到被勒索才知道攻击者在自己环境里横着走了两周，问题就出在根本没有做进程访问类的审计。日志不提前接好，事后就全瞎。
5.1 Sysmon 事件 ID 10：进程访问审计
Sysmon 是微软 Sysinternals 套件里的免费工具，部署成本很低，但它记录的进程访问事件是发现凭据窃取的关键。事件 ID 10 会记录一个进程尝试打开另一个进程句柄的动作，配合 SourceProcess 和 TargetProcess 字段，可以快速筛选出访问 lsass.exe 的请求。
正常环境下，除了系统进程和杀毒软件，普通进程不该有理由去打开 lsass.exe。一旦看到某个未知进程的名称、路径、签名都不对劲，却在持续访问 lsass.exe，这几乎就是凭据提取的前兆。构造告警规则的思路可以是：当目标进程为 lsass.exe 且来源进程不在已知白名单内时，触发中危告警。这种规则误报可控，而且部署成本低，没有 EDR 的团队务必加上。
5.2 Windows 安全日志：4624、4625、4776
安全日志里最常规的几项听上去无聊，但很管用。事件 ID 4624 是成功登录，4625 是失败登录。关注的重点不是次数，而是登录类型和来源。比如类型 3（网络登录）大量从非管理网段发起，或者来源主机名和你环境命名规则完全不符，都值得查。
另外，4776 事件对应域控的凭据验证。如果工作站上出现了大量发往域控的验证请求，可能不是误报，而是有人在批量尝试哈希或票据重放。建议把工作站上的 4776 事件也纳入集中日志管理，单独建一个告警基线。时间同步别忽视，所有设备的时间不一致，分析跨主机日志时会产生很大的噪音。
5.3 文件与进程痕迹
攻击者抓取完凭据总得把结果放在某个地方，最常见的是在临时目录或当前目录留下一个转储文件，文件名往往非常直白，比如 lsass.dmp、memory.dmp、dump.bin。文件系统监控里可以加一条规则：任何 exe 或脚本进程在同一目录下连续创建新文件时，如果进程路径可疑，直接进入人工排查流程。
在内存取证层面，如果环境里允许部署内存采集工具，怀疑被入侵时可以把可疑主机的内存镜像拉一份出来，千万别急着关机——关机反而把最重要的证据丢掉了。拿到内存镜像后，分析是否存在可疑模块、可疑钩子、异常签名驱动，是确定是否真被突破的关键步骤。
5.4 蜜标账户：主动钓“偷凭据的人”
我强烈推荐在 AD 域环境里加一个蜜标账户。它不是真实员工，密码复杂度可以故意设置得出众一些，不归属任何业务组，也永远不该登录。正常环境里根本不会有人使用它进行身份验证。一旦日志里出现该账户的 4624 事件，基本上可以确定有人在域里进行横向试探。
蜜标账户的价值不在于防守，而在于缩短发现时间。很多攻击者进入环境后会先枚举高权限账户，蜜标账户模拟的就是那个“看起来很好惹”的目标。这一招的前提是日志要完整、集中保存，否则它登录了你也看不到。另外提醒一句，蜜标账户千万别加入任何组，也不要被任何日常脚本引用，否则误报会搞得你很烦躁。
6. 最后说点我的实操体会
6.1 每季度验证一次防护有效性
做了这些年后，我自己最深的感触是：别把“绕过 Windows 10 防护”当成一个非黑即白的话题。防护体系的每一层都有代价，Credential Guard 吃资源、PPL 可能挡运维工具、ASR 规则要养误报，这些成本是实打实的。但也正因为有代价，很多团队选择“不开最省事”，把机器裸奔着挂进了生产网，这才是最危险的决定。
我建议安全团队都做一件简单的事：每季度找个测试机，在开了对应防护的前提下，用合规允许的手段做一次凭据提取模拟测试，并保留完整结果记录。不是去进攻生产，而是验证自己的防护到底立不立得住。结果通常会出乎意料——要么发现某台机器 WDigest 又被人为打开了，要么发现域环境里根本没法开 Credential Guard，要么发现 ASR 规则一直在审核模式下空转。问题暴露得越早，越不用等到攻击者来提醒你。
6.2 把防护状态纳入配置基线
另外一个很实际的小习惯：把这台机器的 RunAsPPL 注册表值、VBS 状态、ASR 规则状态全部纳入配置管理基线，任何偏离都触发告警。我处理过不少“防护失效”的工单，最后查下来不是配置错了，而是后期有人为了装一个不兼容软件偷偷关掉了，事后又忘了恢复。有了基线，这类“静默降级”就能第一时间浮出水面。
Windows 10 的凭据防护到今天已经相当成熟，但它成熟不等于目标环境里每一台机器都真的在用。作为管理员，我们守的不是一条防护规则，而是一套能持续验证、持续补齐的机制。攻击者看得到的东西，你也应该看得到；你看不到的东西，至少要在日志层留下痕迹。这比任何一次“绕过”演练都更有意义。
