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 BootWindows 功能里要启用“基于虚拟化的安全性”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 版本和许可差异家庭版、专业版、企业版、LTSCWindows 10 的防护能力并不完全一致。下表把常见版本的支持情况整理一下方便判断自己手上的环境属于哪一档。防护项家庭版专业版企业版/教育版IoT Enterprise LTSC 2021Credential Guard不支持官方不建议部分配置可开限制多完整支持完整支持LSA ProtectionPPL支持支持支持支持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 GuardCredential 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 系统信息RunAsPPL1注册表查询WDigest UseLogonCredential0注册表查询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 的凭据防护到今天已经相当成熟但它成熟不等于目标环境里每一台机器都真的在用。作为管理员我们守的不是一条防护规则而是一套能持续验证、持续补齐的机制。攻击者看得到的东西你也应该看得到你看不到的东西至少要在日志层留下痕迹。这比任何一次“绕过”演练都更有意义。