Kali里跑mimikatz很多人第一反应就是“破解Windows密码”这话对一半错一半。mimikatz真正做的事是把Windows系统内存里已经存在的登录凭据“取”出来而不是像跑字典那样去试密码。它提取的对象可以是明文密码、NTLM哈希、Kerberos票据只要这些凭据还留在内存里它就有办法拿到手。这也是为什么它一直是红队工具链里非常靠前的选手同时也是蓝队排查时需要重点盯防的对象。很多新手第一次在Kali里敲mimikatz命令要么权限不够什么都拿不到要么拿到了哈希却不知道怎么用要么被目标机器上的杀毒软件直接干掉。这篇文章不谈那种“三步入侵某系统”的段子而是把mimikatz的原理、在Kali里的常见用法、以及防御方怎么阻止和检测它一次讲透。适合做渗透测试、红蓝对抗、安全运营、以及内网安全评估的读者参考也适合那些刚接触Windows凭据安全、想知道“密码到底是怎么被泄漏”的初学者。1. 先把概念理清mimikatz不是“破解”是“提取”1.1 它拿到的到底是什么要理解mimikatz为什么厉害先得搞清楚Windows是怎么保存登录凭据的。用户登录系统之后操作系统不可能每次访问资源都重新问一遍密码所以会把凭据缓存在内存里由LSASS进程Local Security Authority Subsystem Service统一管理。这个进程就是整个Windows安全体系的核心所有本地登录、域登录、服务登录的验证动作都会经过它。问题就出在“缓存”这两个字上。LSASS进程运行在系统内存里而内存是可以被读取的。只要有足够高的权限理论上就能把这个进程内存空间里的数据翻出来。mimikatz干的就是这件事它找到LSASS进程读取内存中的凭据数据解析出明文密码、NTLM哈希、Kerberos票据等敏感信息。这里有个关键认知要纠正mimikatz并不是通过暴力猜解来“破解”密码的。如果某个用户登录过系统并且他的凭据还留在内存里mimikatz提取出来的就是“现成的、有效的”凭据。很多时候连哈希都不用解直接用哈希就能做后续的横向移动。这也是业内常说的“Pass-the-Hash”哈希传递攻击的基础。反过来如果目标用户并没有在系统上登录过内存里没有他的凭据那mimikatz再厉害也拿不到东西——巧妇难为无米之炊。1.2 为什么Windows会把密码留存在内存里很多人不理解为什么Windows不把密码用完就丢掉这其实是安全和体验之间的一个老矛盾。早期Windows为了让某些老协议比如WDigest能够正常工作会把用户的明文密码存在内存里。WDigest协议本来是为了支持HTTP摘要认证设计的它需要拿到明文密码才能工作。那个年代大家的安全意识没现在这么强微软为了方便默认开启了WDigest。这一开就等于在每台Windows机器的内存里埋了一颗雷。后来的Windows版本尤其是Windows 10 1607版本之后默认禁用WDigest但很多企业内网机器常年不更新、不做安全基线配置仍然保留着旧状态。就算没有明文密码NTLM哈希和Kerberos票据也一样会留在LSASS进程里因为后续的免密访问、单点登录都依赖这些凭据。所以mimikatz的价值一直没衰减过只是提取的内容从“明文密码”更多变成了“哈希”和“票据”。1.3 什么时候你会真的用到它需要把话说在前面mimikatz这类工具只有在合法授权的前提下使用才是正当的。我的习惯是在项目授权书范围内、且明确了测试范围之后才会在目标环境中使用。它的典型场景包括红队模拟演练中拿到一台主机权限后验证是否可以从内存中提取域管凭据进而评估内网横向扩散风险。安全基线核查时抽查机器是否存在WDigest未禁用、LSASS保护未开启等高风险配置。应急响应和取证分析时在已授权的主机上确认攻击者是否可能通过内存提取过凭据或者分析当前系统的凭据暴露面。内网弱口令整治时用提取出的哈希验证是否能够直接登录其他机器找出“一套密码走天下”的账号。这些场景有一个共同前提你是被允许在这台机器上做评估的。2. 工具在Kali里的常见形态与实战姿势2.1 Kali里怎么拿到mimikatz很多初学者会在Kali里直接敲mimikatz命令然后发现提示找不到。原因很简单mimikatz是Windows平台的程序Kali本身是Linux没法原生执行。在Kali里使用mimikatz无非两种思路。第一种把静态编译好的mimikatz.exe传到目标Windows机器上运行。Kali里可以通过apt install mimikatz安装软件包装好后在/usr/share/mimikatz/x64/等目录下找到对应的exe文件。不过要做好这个exe在目标机器上被杀毒软件查杀的准备后面我们会专门讨论绕过和规避的边界问题。第二种不从Kali直接跑而是用Kali里的远程工具去读取目标Windows机器的凭据。最典型的就是impacket套件里的secretsdump.py它可以通过Windows的远程服务接口在拥有一定权限的前提下远程导出机器的SAM数据库和LSASS凭据信息全程不用在目标机器上落地任何文件。这种方式在红蓝对抗里非常实用因为不落地文件就意味着被杀软查到的概率更低也更容易在应急响应时“不留痕迹”地做凭据评估。坦白说Kali本身只是一个载体mimikatz真正发挥威力的地方是Windows环境。你完全可以在Kali里用wine去运行mimikatz的exe但那更像是在测试工具本身的功能实战里没人这么干。更多人会选择把mimikatz投递到目标Windows机器上执行或者用其他远程提取方式间接达成目的。2.2 最常用的一组命令逻辑mimikatz的命令看起来很多但核心套路其实非常固定。在拿到一台Windows机器并取得管理员权限后通常按这样的顺序操作privilege::debug sekurlsa::logonpasswords lsadump::sam第一步privilege::debug是启用SeDebugPrivilege调试权限。许可证里讲得直白一点没有这个权限LSASS进程的内存你连碰都碰不了。普通权限下执行这步会直接报错也相当于一个“权限自检”。第二步sekurlsa::logonpasswords从LSASS进程内存中提取当前所有登录会话的凭据信息。只要这个系统上有人登录过并且凭据还留在内存里这里就能看到用户名、域名、明文密码或NTLM哈希。输出结果会按照登录会话分块展示格式不复杂但信息量非常大。第三步lsadump::sam读取本地SAM注册表数据库中保存的本地账户哈希。SAM存储的是本地用户的NTLM哈希即使内存里没有用户的登录记录SAM数据库的哈希也可以拿来做本地口令猜测或哈希传递。这只是最基础的几个命令。在域环境里往往还会配合lsadump::dcsync这样的命令它的原理是通过域控制器的复制协议模拟域控之间的同步直接拉取整个域的用户哈希库。这属于比较高阶的用法前提是你已经拿到域管权限。这里不展开写更多细节核心想表达的是mimikatz的命令虽多但一套流程下来无非就是“提权、读内存、读SAM、连接域控”这几件事。2.3 权限要求与执行前提每次看到有人问“为什么我执行logonpasswords没输出”第一反应应该先确认权限。mimikatz提取LSASS凭据至少需要本机管理员权限而且最好是SYSTEM权限。普通管理员和SYSTEM还是有区别的有些操作比如访问某些受保护的内存区域需要SYSTEM权限才能执行。在Kali的视角看权限提升通常发生在你通过漏洞利用、弱口令或其他方式拿下目标主机之后。如果你已经是一个标准用户需要先利用本地提权漏洞或已有方法把权限提到管理员或SYSTEM级别然后再运行mimikatz。权限不够的情况下mimikatz会直接提示“Unable to query system‘s debug privilege”之类的错误。还有一点要提醒Windows对LSASS做了额外保护的版本开启LSA保护比如RunAsPPL即使你是SYSTEM权限mimikatz默认也读取不了LSASS。这相当于把大门从里面反锁了没有钥匙就只能考虑其他思路。这个放在后面防御部分细说。2.4 一个完整的本地凭据评估示例假设在一次授权测试中我们通过弱口令拿到了某台Windows服务器的管理员权限。接下来评估这台机器上的凭据暴露情况操作步骤如下编译或下载mimikatz到内存执行或者用其他加载方式避免在磁盘上留下文件。在mimikatz交互式环境中执行privilege::debug确认调试权限已开启。执行sekurlsa::logonpasswords重点观察输出中出现的“Username”“Domain”“NTLM”字段。如果发现某个域管账号的哈希出现在内存中就说明该机器曾经被域管登录过当前这台机器实际上是通往域控的重要跳板。将提取到的哈希记录下来在目标环境中验证能否直接用于访问其他服务器。这个流程看起来很简单但每一步都相当关键。尤其是第4步的判断——mimikatz输出里出现域管账号并不代表你拿到了域控权限只代表内存里有这个账号的凭据。能不能用、能访问哪些机器才是下一步更重要的验证。真正有经验的测试人员看mimikatz输出不会只看有没有“Administrator”字样而会看哪个账号出现的会话最多、哪个账号的哈希具有域内高权限属性这就是所谓“凭据价值评估”。个人建议在一个比较大的内网环境里做凭据梳理时可以把mimikatz的输出结果保存成日志文件再批量筛选高权限账号哈希。在几十台机器上逐台肉眼看输出效率太低了自动化提取、筛选、复用才是正经做法。3. 从防御视角看怎样让mimikatz失效3.1 系统自身防线很多人觉得mimikatz防不住实际上它能成功往往是因为目标系统本身没有做好最基础的加固。如果下面的措施都落地了攻击者在普通主机上跑mimikatz大概率拿不到任何有价值的东西。第一道防线是升级并打补丁。老版本Windows在默认配置下允许LSASS进程保存明文密码补丁和系统更新后情况会有明显改善。很多知名漏洞利用也和旧系统状态有关打补丁是最低成本的基础操作。第二道防线是禁用WDigest。Windows 10 1607版本开始默认禁用但为了兼容老应用很多管理员会手动把WDigest再开回来。在注册表HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest里将UseLogonCredential设置为0可以停用明文密码缓存。注意更改后需要重启才能完全生效。第三道防线是开启LSA保护。将注册表HKLM\SYSTEM\CurrentControlSet\Control\Lsa下的RunAsPPL设置为1会让LSASS以受保护进程方式运行默认情况下mimikatz的常规命令就无法读写LSASS内存了。不过LSA保护并不等于绝对安全配合其他机制使用才是王道。第四道防线是开启Credential Guard。这是基于虚拟化安全的方案把凭据存储从LSASS进程隔离到独立虚拟化容器中即使拿到了SYSTEM权限也读不到原始的LSASS凭据。对于Windows 10企业版、Windows Server 2016及以上版本这是比较推荐的加固路径但部署时需要注意与现有驱动和应用程序的兼容性。3.2 检测与响应怎么发现机器上正在跑mimikatz光加固还不够攻击者总有办法绕过单点防护所以检测层面的工作同样重要。我们日常排查时重点看几个方向的证据。事件日志方面关注以下ID很有价值4624登录成功事件。攻击者通过哈希传递等方式登录时会留下非常规的登录类型记录。4672特殊登录赋予管理员权限。运行mimikatz之前通常会先提权这个事件会有记录。4688进程创建。启用审核后可以记录mimikatz.exe或者不常见进程创建的行为。4104PowerShell脚本块日志。如果攻击者通过PowerShell反射加载mimikatz这个日志里会留下痕迹比如LogonPasswords、Invoke-Mimikatz这类关键字符串。Sysmon事件也是检测利器。其中Event ID 10进程访问专门记录一个进程打开另一个进程的行为。攻击者访问lsass.exe进程内存时会触发对该进程的访问记录通过分析访问来源进程和访问权限能直接发现可疑的凭据提取行为。还有一种很常见的防御思路在LSASS进程上配置额外的访问控制策略例如添加拒绝读取的ACE条目让非系统组件无法打开LSASS进程句柄。这个操作对系统自身功能影响不大但对mimikatz这类工具的效果影响很大。当然具体设置方式需要谨慎评估盲目修改可能导致系统异常。3.3 一个快速自查清单如果你是在做安全运营或者对可疑主机做排查我建议先按下面几步走查看本机WDigest注册表键值确认UseLogonCredential是否为0。查看LSA保护RunAsPPL是否已启用。检查系统版本和补丁更新时间。通过Sysmon或安全产品的日志搜索lsass.exe的访问记录。检查进程创建日志中是否有可疑的PowerShell调用或者不认识的可执行文件。如果机器上装有EDR直接查看关于LSASS访问的告警记录。有一次在某客户的服务器上排查时我发现那台机器WDigest是开着的老系统而且至少有三台服务器被同一个域管账号登录过。攻击者只要在其中一台机器上运行一条命令就能拿到域管的NTLM哈希然后在整个域内畅通无阻。当时梳理完现有配置后第一时间就把它列成了最高优先级整改项。这种问题在真实内网里远比想象的普遍。4. 常见问题与排查技巧实录4.1 为什么执行之后没有输出这应该是最常见的问题。测试人员在目标机器上运行mimikatzsekurlsa::logonpasswords执行完结果什么都没显示。排除思路按优先级来先确认是否以管理员或SYSTEM权限运行如果权限不够工具会明示失败信息再确认LSA保护是否开启如果开启同样的命令也会被拒绝访问还要确认目标系统上是否确实有用户在交互式登录过。如果这是一台刚开机、没人登录过的服务器内存里自然没有可提取的登录凭据。4.2 为什么拿到的是哈希不是明文密码很多新手拿到哈希之后会很困惑以为需要“解出”明文。实际情况是在真实攻击和防御评估中哈希本身就是非常有价值的凭据。Windows的很多认证协议允许直接用哈希进行身份验证这叫哈希传递Pass-the-Hash。也就是说不需要破解出明文密码哈希就能用来登录其他机器。如果确实需要明文来做弱口令分析可以尝试用hashcat这类工具离线跑字典。跑不跑得出来要取决于密码强度、字典覆盖度和算力投入。如果目标密码足够长、足够复杂可能跑几个月都跑不出来。业内常规做法是把明文和哈希分开看待能不能破解是一回事哈希能不能直接用是另一回事后者往往更重要。4.3 执行工具被杀软拦截了怎么办这个问题要分两种情况说。如果是经过授权的红队测试投递到目标机器上的mimikatz被端点防护软件拦截这其实是防护起作用的正常表现。应对思路一般是结合目标环境现有的白名单机制、使用合法签名的加载器、或者直接用内存加载的方式运行。也可以用impacket的secretsdump.py从Kali远端提取不落地文件从根上规避磁盘查杀。另一种情况是自己在有EDR的企业环境里做验证这时需要特别注意绕过杀软的方式有很多但在未取得授权的情况下做任何绕过行为都可能是违规操作。我的建议非常明确所有绕过尝试都必须限定在已授权测试范围内并且要在测试计划中预先说明。真正的安全评估要模拟真实攻击但不能把自己变成真实的“攻击者”。4.4 常见问题速查表现象可能原因验证与处理建议privilege::debug报错权限不足用管理员权限运行或提升到SYSTEM权限logonpasswords无输出LSA保护已开启检查RunAsPPL验证是否可绕过或改用其他方式logonpasswords无输出系统没有交互登录记录确认目标主机是否有人登录过提取的是哈希而非明文Windows版本默认禁用WDigest哈希可通过哈希传递直接使用输出中全是S-1-5-18等系统账号没有普通用户登录换一台有用户登录的目标机器再评估exe被杀软清除端点防护生效授权范围内改用内存执行或远程导出方案域控上无法使用dcsync权限不够域管dcsync要求域管理员级别权限先做权限提升提示mimikatz运行结束后记得清理输出日志文件。很多测试报告里需要附上凭据提取的证据这些日志是关键材料但实战环境下如果留下日志也可能会被其他检测策略捕获所以保存与销毁要按项目要求来处理。4.5 一些藏在细节里的经验操作次数多了之后有几个细节特别想分享。第一mimikatz在不同版本Windows上的输出格式差异不大但字段含义略有不同。早期Windows 7和Windows Server 2008的版本会显示明文密码而Windows 10 1607之后基本只剩哈希和票据。评估报告里出现“明文密码”或“仅哈希”的结论其实是受系统版本影响的不能笼统地说“密码可获取”。第二域环境中mimikatz从普通机器上提取到域管账号哈希的情况并不少见。原因往往不是域管密码简单而是某位管理员在一台普通服务器上通过远程桌面登录过凭据残留在了那台机器的内存里。这种“高权限账号出现在低权限机器”的组合才是最值得警惕的攻击者拿到一个入口后就能沿着这个凭据直接跳向域控。第三如果在一次应急响应中发现mimikatz的痕迹不要只盯着攻击者用哪条命令执行了提取。更要紧的是搞清楚目标机器上到底哪些账号的凭据被提取过、那些账号在哪些机器上还有权限。这是一条从“单一主机被入侵”延伸到“整个内网暴露面”的线索链条价值远大于确认“mimikatz确实被运行过”这件事。5. 写在最后的一点实操体会最近这几年做安全评估我的一个明显感受是mimikatz这类工具的“威力”并没有因为Windows版本更新而消失反而因为内网环境里老机器多、配置不统一、管理员习惯复用密码它的命中率一直很高。相比之下很多防御团队花了大价钱上了各种安全产品却连基础的WDigest配置都没有核查过实在有些可惜。如果是在做防御建设我个人建议优先盯住三件事第一把内网机器的WDigest配置拉一遍第二约束域管账号的使用边界不许域管随意登录普通服务器第三开启LSASS相关日志采集。这三件事做扎实mimikatz的利用门槛和造成的影响都会大幅下降。如果是在做入侵测试或红队评估我的体会是不要一上来就想着在每台机器上都跑一遍mimikatz。更高效的做法是先梳理目标环境的账号体系判断哪些账号是高价值目标再围绕这些账号的登录位置做定点提取。盲目的“遍地撒网”既容易触发告警也让报告变得杂乱无章。这一行经验和工具的熟练度同样重要理解凭据在系统中的流转规律比记住更多命令更有用。