Kerberoasting 与黄金票据攻击

要理解 Kerberoasting 和 Golden Ticket 攻击，您需要清楚了解Kerberos 服务票据的签发过程。当客户端想要访问某项服务（例如 SQL 服务器）时，它会向 Domain Controller 的票据授予服务（TGS）出示其票据授予票据（TGT）。TGS 会签发使用service account 的密码 hash加密的Service Ticket。客户端将此票据出示给服务，服务使用自己的 hash 解密票据，以验证其真实性。这种设计意味着 Service Ticket 使用目标服务的凭据进行加密——这是 Kerberoasting 能够利用的关键细节。

Kerberoasting 是一种攻击，它利用了这样一个事实：任何经过身份验证的域用户，都可以为注册了 SPN（Service Principal Name）的任何服务请求 Kerberos Service Ticket。攻击者为带有 SPN 的 accounts 请求 Service Ticket，捕获加密的票据数据块，然后尝试离线破解 service account 的密码——无需再与 Active Directory 交互，也不会有触发 account 锁定的风险。Service accounts 通常使用弱密码、早于现代复杂性要求的旧密码，或永不过期的密码，因此极易受到离线破解攻击。

Kerberoasting 捕获的 Service Ticket hash 默认使用 RC4-HMAC (NTLM hash) 加密（出于兼容性考虑），破解速度快于 AES-256 Kerberos 票据。攻击者会将捕获的 $krb5tgs$23$ hash 输入 Hashcat 或 John the Ripper，进行离线字典攻击和暴力破解。使用 RockYou 等常见词表以及规则集，在消费级 GPU 硬件上通常可以在几分钟到几小时内破解大多数弱 service account 密码。破解成功后，攻击者即可获得 service account 的明文密码，并使用该密码直接进行身份验证。

Kerberoasting 的缓解措施主要涉及四个方面：密码强度——service accounts 应使用长度较长的随机密码（25 个字符以上），即使面对 GPU 集群也能抵抗离线破解；组托管 service accounts（gMSA）——Windows 会自动管理 gMSA 密码（每 30 天轮换一次 240 个字符的随机值），使 Kerberoasting 在计算上不可行；仅使用 AES 加密——将 service accounts 配置为要求使用 AES-256 票据（msDS-SupportedEncryptionTypes），其破解速度比 RC4 慢几个数量级；以及检测——针对来自非标准工作站、面向 service accounts 的异常数量 TGS 请求（Event ID 4769）发出警报。

KRBTGT account 是 Active Directory 内置的特殊 account，其密码 hash 用于签名和加密域中的所有 Kerberos TGT。Domain Controller 使用 KRBTGT hash 创建 TGT，并验证收到的 TGT。这使 KRBTGT hash 成为 Active Directory 环境中最有价值的单一凭据——任何拥有它的人，都可以为任何用户创建任意的、完全有效的 Kerberos 票据，包括为不存在的用户创建票据，并设置任意 Group membership 和有效期。许多组织通常从未更改过 KRBTGT 密码，因为更改过程需要进行谨慎协调。

Golden Ticket 攻击使用已被攻陷的 KRBTGT account 的密码 hash，创建一个伪造且完全有效的 Kerberos TGT。攻击者使用 Mimikatz 的 kerberos::golden Command，为任意用户（通常是虚假的、类似 Administrator 的 account）生成 TGT，并设置任意 Group membership（通常包括 Domain Admins）和任意有效期（通常设为 10 年）。由于该票据在密码学上有效——它使用真实的 KRBTGT hash 签名——因此 Domain Controller 无法将其与合法票据区分开来。Golden Ticket 可提供完整、持久且无限制的域控制权。

Golden Ticket 尤其危险，因为即使原始攻击被发现并清理，它们仍然可以继续存在。更改目标用户的密码毫无作用——该票据是伪造的，并非基于用户的真实凭据。唯一的补救措施是将 KRBTGT 密码更改两次（第一次使现有票据失效，第二次则是因为任意时刻都有两个用于轮换的 KRBTGT keys）。不过，更改 KRBTGT 密码需要谨慎协调：如果更改不当，可能导致整个域的 Kerberos 身份验证中断。许多组织不愿执行这项补救措施，导致 Golden Ticket 可以无限期保持有效。

Silver Ticket 与 Golden Ticket 类似，但 scope 更有限。它使用目标 service account 的 hash（而不是 KRBTGT）来伪造仅适用于该特定服务的Service Ticket。例如，攻击者获得 SQL 服务器 service account 的 hash 后，就可以伪造 Service Ticket，从而取得该 SQL 服务器上的任意访问权限。Silver Ticket 比 Golden Ticket 更难检测，因为它们完全绕过 Domain Controller——伪造的票据直接从攻击者发送到服务，不会联系 KDC。缓解措施要求保护 service account hash，并监控敏感服务上的异常访问模式。

攻击者使用 DCSync attack 获取 KRBTGT hash。该攻击滥用了 Active Directory 合法的域 replication 协议。Directory Replication Service（DRS）允许 Domain Controllers 相互同步 AD 数据，包括密码 hash。拥有DCSync 权限的攻击者（通常是 Domain Admin、Enterprise Admin，或拥有 Replicating Directory Changes All 权限的任意 account）可以冒充 Domain Controller，请求同步任何 account 的 hash。Mimikatz 的 lsadump::dcsync Command 完全通过网络执行此攻击——无需在 DC 本身运行任何代码。

检测 Golden Ticket 的使用颇具挑战，但可以通过查找 Kerberos 票据元数据中的异常来实现：有效期异常长的 tickets（真实票据的 TGT 有效期为 10 小时，而 Golden Ticket 通常设置为 10 年）；Event ID 4769 中的 ticket encryption type 为 RC4 (0x17)，而域默认值为 AES-256 (0x12)；tickets 中的 account 名称在 AD 中不存在；以及在 Event ID 4769（Service Ticket 请求）之前缺少 Event ID 4768（TGT 请求）——Golden Ticket 会跳过 TGT 请求阶段，因为 TGT 本身就是伪造的。Microsoft Sentinel 或 Defender for Identity 规则可以自动标记这些模式。

针对 Kerberos 攻击的分层防御措施包括：对所有 service accounts 使用 gMSA，使 Kerberoasting 不可行；为所有 accounts，尤其是高价值 service accounts 启用仅使用 AES 的加密，最大限度提高破解难度；限制 DCSync 权限——审计拥有 replication 权限的 accounts，并移除不应拥有这些权限的 accounts；启用 Microsoft Defender for Identity（前身为 ATA），它能够提供了解 Kerberos 的威胁检测，并实时发出 Golden Ticket、Kerberoasting 和 DCSync 警报；以及实施分层管理模型，确保即使 Tier 2 account 被攻陷，也无法用于获取 DC 级别的凭据。

测试您对本课 CompTIA Security+ (SY0-701) 概念的理解。

在本课中，您学到了：Kerberoasting 会为注册了 SPN 的 accounts 请求 Service Ticket，并对其进行离线破解——可通过 gMSA、强密码和仅使用 AES 的加密来防御；Golden Ticket 攻击使用 KRBTGT hash 伪造不受限制的 TGT，从而提供持久的域控制权，直到 KRBTGT 密码被重置两次；以及DCSync 攻击会通过网络复制 KRBTGT hash，无需在 DC 上运行代码——因此必须严格审计 DCSync 权限。接下来，我们将探讨用于将攻击者技术映射到防御措施的 MITRE ATT&CK 框架。