黄金票据：一张伪造的通行证如何放倒整个域
想象这样一个场景：攻击者拿到了域控的最高权限，但你及时发现了，改了所有管理员密码，心想这下应该安全了——然而攻击者还在域里横着走，仿佛什么都没发生。这不是玄学，这是 Kerberos Golden Ticket 攻击。
Kerberos 认证的核心逻辑是：客户端向 KDC 申请票据，KDC 用只有自己知道的密钥签发 TGT，客户端拿着 TGT 去申请服务票据，整个过程信任链的根基就是 KDC 的 krbtgt 账户的密码哈希。Golden Ticket 的思路非常直接：如果你拿到了 krbtgt 的哈希，你就不需要再跟 KDC 打招呼了。你自己签 TGT，自己指定任意用户身份、任意组成员、任意票据有效期——KDC 看到这张票据，验签通过，就全盘接受。因为在 Kerberos 的设计里，krbtgt 的密钥就是信任的锚点，票据本身就是凭证，不存在二次校验。
这意味着几件让人不舒服的事：第一，即便域控已经被你重新加固，只要攻击者曾经拿到过 krbtgt 哈希并且没有被重置，他们就永远能伪造票据；第二，票据的有效期可以设成十年，比大多数企业的密码轮换周期还长；第三，伪造的用户可以是 Domain Admins 组成员，每一台机器都会认。
防御上最关键的一步是：。为什么要两次？。此外，域控的 krbtgt 密码在多域环境中每个域独立，需要逐域操作，不能漏。
整个攻击链本质上暴露的是 Kerberos 协议设计上的一个取舍：为了性能和可用性，票据一旦签发就是自包含的、离线可验证的，KDC 不维护票据状态表，也不主动撤销。这份"信任即凭证"的简洁，恰恰是黄金票据能成立的根因。
#Security
想象这样一个场景：攻击者拿到了域控的最高权限，但你及时发现了，改了所有管理员密码，心想这下应该安全了——然而攻击者还在域里横着走，仿佛什么都没发生。这不是玄学，这是 Kerberos Golden Ticket 攻击。
Kerberos 认证的核心逻辑是：客户端向 KDC 申请票据，KDC 用只有自己知道的密钥签发 TGT，客户端拿着 TGT 去申请服务票据，整个过程信任链的根基就是 KDC 的 krbtgt 账户的密码哈希。Golden Ticket 的思路非常直接：如果你拿到了 krbtgt 的哈希，你就不需要再跟 KDC 打招呼了。你自己签 TGT，自己指定任意用户身份、任意组成员、任意票据有效期——KDC 看到这张票据，验签通过，就全盘接受。因为在 Kerberos 的设计里，krbtgt 的密钥就是信任的锚点，票据本身就是凭证，不存在二次校验。
这意味着几件让人不舒服的事：第一，即便域控已经被你重新加固，只要攻击者曾经拿到过 krbtgt 哈希并且没有被重置，他们就永远能伪造票据；第二，票据的有效期可以设成十年，比大多数企业的密码轮换周期还长；第三，伪造的用户可以是 Domain Admins 组成员，每一台机器都会认。
防御上最关键的一步是：。为什么要两次？。此外，域控的 krbtgt 密码在多域环境中每个域独立，需要逐域操作，不能漏。
整个攻击链本质上暴露的是 Kerberos 协议设计上的一个取舍：为了性能和可用性，票据一旦签发就是自包含的、离线可验证的，KDC 不维护票据状态表，也不主动撤销。这份"信任即凭证"的简洁，恰恰是黄金票据能成立的根因。
#Security
