如何防范Mimikatz凭证窃取攻击？

Mimikatz在攻击者手中是把锋利的刀，在防御者看来则是一面需要时时照见的镜子。它之所以能长期成为内网渗透的“标配”，恰恰反映了Windows身份认证体系中那些经年累月的弱点。防范它，远不止是封堵一个工具那么简单，这是一场围绕凭证生命周期的系统性防御战争。

核心战场：内存与LSASS进程

Mimikatz的魔力源于其从LSASS进程内存中提取明文密码、哈希和Kerberos票据的能力。因此，防御的第一道前线，就是保护LSASS。微软近年来推出了几项关键措施，但默认并未开启。启用Credential Guard是最彻底的一招，它利用基于虚拟化的安全技术，将凭证隔离到常规操作系统无法访问的安全“保险箱”里。对于不支持Credential Guard的系统，LSASS保护模式也能显著增加攻击难度，它能阻止非受信进程进行内存转储。

然而，现实很骨感。许多企业因为兼容性问题，特别是依赖旧式认证或特定安全软件的环境，不敢轻易启用这些功能。攻击者早就摸透了这点，他们甚至开发了专门绕过这些保护的Mimikatz变种。所以，技术控制必须与强硬的运维策略结合：定期审计组策略，确保所有符合条件的终端都强制开启了这些保护；同时，将LSASS进程的访问权限限制到最低，非必要账户绝不给SeDebugPrivilege这类危险权限。

限制横向移动的燃料

就算攻击者拿到了一台主机的凭证，我们也绝不能让他用这些凭证畅通无阻。这里的关键是实施最小权限原则和网络分段。普通用户账户的权限应该被严格限制在其本职工作所需的主机和服务上。通过部署微软的本地管理员密码解决方案或类似工具，可以确保每台计算机的本地管理员密码都不同且定期随机更改，这能有效阻止使用本地管理员账户进行的横向跳转。

网络层面，精细的防火墙规则和微分段技术可以将内网划分成多个隔离区域。研发部门的机器，凭什么能直接访问财务部门的服务器？把这种默认的“全通”模式改成“按需申请”，攻击者即便窃取了某个网段的凭证，也会发现自己被困在孤岛里。

监测：听见攻击的脚步声

完全阻止所有攻击是奢望，但我们必须能在第一时间发现异常。安全团队应该配置SIEM或EDR工具，重点监测与Mimikatz活动高度相关的告警事件。例如，大量出现的事件ID 4688（新进程创建）中，如果进程名是mimikatz.exe或它的各种“化名”，那几乎就是铁证。对LSASS进程的直接内存访问操作、异常的Kerberos票据请求（事件ID 4769），也都是需要高亮显示的危险信号。

更高级的狩猎，可以关注“攻击链”。一次成功的Mimikatz使用，往往前置了初始入侵和提权。如果一个低权限账户短时间内突然获得了调试特权，并紧接着尝试访问LSASS，这串连起来的异常行为，其威胁等级远高于单个孤立事件。

釜底抽薪：减少凭证暴露面

所有防御措施中，最根本也最困难的，是改变我们使用和管理凭证的方式。推广使用Windows Hello for Business或智能卡等基于硬件的认证，可以彻底避免密码或哈希在内存中缓存。对于服务账户，坚决使用组托管服务账户，它由域自动管理密码，且支持Kerberos委派，避免了在脚本或配置文件中硬编码密码的风险。

最后，别忘了人的因素。强制使用复杂密码并定期更换，在攻击者眼里，其价值可能还不如禁止密码在内存中缓存这一条策略。因为再复杂的密码，一旦被Mimikatz从内存中抓取出来，也就毫无意义了。防御Mimikatz，本质上是在与攻击者争夺对身份这个最核心资产的掌控权。这是一场没有终点的赛跑，而起点，就在于你是否真的了解自己系统中那些脆弱的“记忆”究竟散落在何处。