Windows 认证体系：NTLM与Kerberos交互细节及哈希传递攻击
Windows 认证体系：NTLM与Kerberos交互细节及哈希传递攻击
在理解了 Windows 内部的 Token（令牌）和 DACL（权限控制）后，我们需要弄清楚一个更前置的问题：当我们输入密码，或者在内网中访问一台共享文件服务器时，Windows 是如何验证我们的身份的？
Windows 拥有两套平行的认证体系：古老的 NTLM 和现代的域环境基石 Kerberos。它们不仅是网络管理员必须掌握的基础架构，更是红队渗透测试中“横向移动（Lateral Movement）”的必争之地。
本文将结合底层协议交互，深度剖析这两种认证机制的运作流程，以及随之衍生的 Pass-the-Hash (哈希传递) 和 Pass-the-Ticket (票据传递) 攻击。
1. 密码的存储形式：Hash 与 SAM 表
Windows 绝对不会在内存或硬盘中明文存储用户的密码。
当你在电脑上设置密码 P@ssw0rd 时，Windows 会使用单向散列算法（通常是 MD4 或更新的变种）对其进行计算，生成一个固定长度的十六进制字符串，这就是 NTLM Hash。
- 本地账户：NTLM Hash 存储在
C:\Windows\System32\config\SAM文件中（本地安全账户管理器）。 - 域账户：NTLM Hash 存储在域控服务器的
C:\Windows\NTDS\ntds.dit数据库中。
⚠️ 致命安全推论： 既然 Windows 在网络认证中只认 NTLM Hash，不认明文密码。那么对于黑客来说，拿到 NTLM Hash 就等同于拿到了明文密码！这就是所有哈希传递攻击的核心理论支撑。
2. NTLM 认证协议：挑战-响应机制 (Challenge-Response)
在非域环境（工作组环境），或者通过 IP 地址直接访问内网服务时，Windows 默认使用 NTLM 协议进行身份验证。
2.1 Type 1, 2, 3 交互过程
假设客户端 (Alice) 要访问服务器 (Server) 的 SMB 共享，NTLM 会经历经典的三步交互：
- Type 1 (协商 Negotiate)： Alice 告诉 Server：“我想登录，我支持 NTLMv2 等加密算法，这是我的主机名。”
- Type 2 (挑战 Challenge)： Server 收到请求后，生成一个 16 字节的随机数 (Challenge) 发给 Alice，并说：“证明你是 Alice。用你的密码 Hash 把这串随机数加密一下发给我。”
- Type 3 (响应 Authenticate)： Alice 收到随机数后，使用自己本地存储的 NTLM Hash 作为密钥，对这个随机数进行加密计算（如 HMAC-MD5），生成 Response 发给 Server。
- 服务端验证： Server 去本地的 SAM 表（或去向域控请求）找到 Alice 的 NTLM Hash。Server 用这个 Hash 对刚才自己生成的随机数进行同样的加密计算。如果算出来的结果和 Alice 发过来的 Response 完全一致，则认证成功。
2.2 经典攻击：Pass-the-Hash (PtH)
攻击场景：
黑客通过某个漏洞拿到了服务器 A 的最高权限，并用工具（如 Mimikatz）从内存 (LSASS 进程) 或 SAM 表中导出了管理员的 NTLM Hash：31d6cfe0d16ae931b73c59d7e0c089c0。
此时，黑客想登录服务器 B（A和B使用了相同的管理员密码）。
黑客不需要去破解这个 Hash 还原出明文密码。他只需修改自己机器内核中的 Token 结构，或者使用特定的工具（如 Impacket），在 NTLM 认证的 Type 3 阶段，直接把这个 NTLM Hash 喂给算法去加密服务器 B 发来的 Challenge 即可。
💻 实战接触：使用 Mimikatz 执行 PtH
这条命令会弹出一个新的 CMD 窗口。在这个新的 CMD 中，如果你执行
dir \\ServerB\c$，你会发现原本会被拒绝的访问，现在畅通无阻了！
3. Kerberos 认证体系：域环境的信任基石
在 Active Directory (AD) 域环境中，成千上万台机器如果都用 NTLM 认证，效率极低且不安全。Windows 引入了基于票据 (Ticket) 的 Kerberos 协议。
在 Kerberos 中，有一个绝对权威的第三方信任机构：KDC (Key Distribution Center，密钥分发中心)。在 Windows 中，域控制器 (Domain Controller) 就扮演着 KDC 的角色。
3.1 游乐场比喻与 Kerberos 六步交互
理解 Kerberos 最好的方式是把它比作去游乐场玩：
第一阶段：大门买票 (AS 交互)
- AS-REQ：客户端 (Alice) 走到大门售票处 (Authentication Service, AS)，说：“我是 Alice，我要买一张通票”。
- AS-REP：AS 在数据库中查到了 Alice，于是发给她一张TGT (Ticket Granting Ticket，认购权证/黄金通票)。（注意：TGT 是用 KDC 自己的私密密钥加密的，Alice 打不开，只能保管着）。
第二阶段：换取特定项目门票 (TGS 交互) 3. TGS-REQ：Alice 拿着 TGT 走到过山车售票亭 (Ticket Granting Service, TGS)，说：“我要玩过山车，这是我的通票 TGT”。 4. TGS-REP：TGS 验证了 TGT 的真实性后，发给 Alice 一张专门用于过山车的Service Ticket (ST，服务票据/白银票据)。（ST 是用过山车服务器的密码 Hash 加密的）。
第三阶段：游玩项目 (AP 交互) 5. AP-REQ：Alice 拿着 ST 走到过山车检票口 (Application Server)，出示 ST。 6. AP-REP：过山车服务器用自己的 Hash 解密 ST，发现确实是 KDC 颁发的，允许 Alice 上车。
3.2 Kerberos 中的 PAC (特权属性证书)
在标准的 Kerberos 协议中，服务票据只证明了“你是 Alice”，但没证明“Alice 是不是管理员”。 微软在 Kerberos 中塞入了一个自己的扩展：PAC (Privilege Attribute Certificate)。 KDC 在颁发票据时，会把 Alice 的 SID 和所属的组 SID 封装在 PAC 中一起加密放入票据。当过山车服务器解密票据时，不仅知道了你是 Alice，还顺便解析 PAC 生成了我们在上一篇文章中提到的 Token，从而完成权限控制 (DACL 校验)。
4. Kerberos 的高级渗透攻击
既然 Kerberos 这么复杂，黑客还有机会吗？由于 Kerberos 的票据是基于对称加密（NTLM Hash）生成的，这导致了极其严重的安全隐患。
4.1 Pass-the-Ticket (PtT，票据传递)
如果黑客拿下了内网某台机器的管理员权限，他可以使用 Mimikatz 从内存中把其他用户（如刚才登录过的域管）留下的 TGT 或 ST 票据导出来（通常是 .kirbi 格式的文件）。
然后黑客将这张票据注入到自己的会话中，接下来的访问就可以直接跳过密码验证，冒充域管横向移动。
4.2 黄金票据 (Golden Ticket)
还记得第一阶段的 TGT 吗？它是用 KDC（也就是域控）自己的一个特殊隐藏账户 krbtgt 的 NTLM Hash 加密的。
如果黑客攻陷了域控，导出了 krbtgt 的 Hash。那么他就不需要去向 AS 申请 TGT 了！
黑客可以自己伪造一张 TGT，在里面塞入伪造的 PAC（声明自己的 SID 是域管），然后用 krbtgt 的 Hash 加密。这张自己印的、有效期可以长达 10 年的假通票，就是黄金票据。只要域管不修改 krbtgt 账户的密码，黑客就能永远控制整个域。
4.3 白银票据 (Silver Ticket)
同理，第二阶段的 ST (服务票据) 是用目标服务器（过山车）的计算机账户 Hash 加密的。 如果黑客只拿到了某一台特定服务器（如 SQL Server）的 Hash，他就可以自己伪造一张只针对该服务器的 ST，这被称为白银票据。
5. 总结
- NTLM 是一种点对点的挑战-响应机制，基于 NTLM Hash 进行认证。它的弱点造就了经典的 Pass-the-Hash 攻击。
- Kerberos 是一种中心化的票据信任机制（AS -> TGS -> AP）。它的弱点造就了 PtT 以及足以导致域环境彻底沦陷的黄金/白银票据攻击。
理解这两种认证机制的底层数据流转，是看懂任何内网域渗透文章、排查横向移动日志（如 Windows 事件日志 4624 登录事件、4768/4769 票据申请事件）的绝对基础。
下一篇预告： 我们讨论了访问控制，也讨论了身份认证。但是在现代 Windows 中，即使你用 Administrator 账户登录，你依然发现很多系统文件无法修改，运行某些程序时屏幕会变暗并弹出一个框让你点“是”。 下一篇，我们将解密 Windows 保护系统的最后一道防线：UAC（用户账户控制）与特权提升机制。