在包括在伪造票证的 SID 历史记录中包含任意 SID 的功能。
SID 历史记录是一项旧功能，可实现跨 Active Directory 信任的回溯。此功能在 Active Directory 首次发布以支持迁移方案时就已到位。当用户通过身份验证时，用户所属的每个安全组的 SID 以及用户 SID 历史记录中的任何 SID 都将添加到用户的 Kerberos 票证中。由于 SID History 旨在跨信任工作，因此它提供了跨信任“模拟”。
在我们进一步深入研究之前，让我们回顾一下金票是什么以及它们是如何工作的。
金票
Golden Tickets 是伪造的 Ticket-Granting Tickets (TGT)，也称为身份验证票。
如下图所示，没有与域控制器的 AS-REQ 或 AS-REP（步骤 1 和 2）通信。由于 Golden Ticket 是伪造的 TGT，它作为 TGS-REQ 的一部分发送到域控制器以获取服务票证。
Kerberos Golden Ticket 是有效的 TGT Kerberos 票证，因为它由 域 Kerberos 帐户 (KRBTGT)加密/签名。TGT 仅用于向域控制器上的 KDC 服务证明用户已通过另一个域控制器的身份验证。TGT 由 KRBTGT 密码哈希加密并且可以由域中的任何 KDC 服务解密的事实证明它是有效的（以及 PAC 验证，但这是另一回事）。
金票要求： * 域名 [AD PowerShell 模块：(Get-ADDomain).DNSRoot] * 域 SID [AD PowerShell 模块：(Get-ADDomain).DomainSID.Value] * 域 KRBTGT 帐户 NTLM 密码哈希 * 用于模拟的用户 ID。
一旦攻击者拥有对域控制器的管理员访问权限，就可以使用 Mimikatz 提取 KRBTGT 帐户密码哈希。
金票“限时”
与 Golden Tickets 一样令人难以置信的是，它们被“限制”在欺骗当前域的管理员权限。当 KRBTGT 帐户密码哈希在属于多域 AD 林的子域中公开时存在限制。问题在于父（根）域包含林范围的管理员组 Enterprise Admins。由于 Mimikatz 通过相对标识符 (RID) 将组成员身份添加到票证中，因此在 Kerberos 票证中将 519（企业管理员）RID 标识为在其中创建它的域的本地（基于 KRBTGT 帐户域）。如果通过获取域 SID 并附加 RID 创建的域安全标识符 (SID) 不存在，则 Kerberos 票证的持有者不会获得该级别的访问权限。
换句话说，在多域 AD 林中，如果创建 Golden Ticket 的域不包含 Enterprise Admins 组，则 Golden Ticket 不会为林中的其他域提供管理员权限。
在单个域 Active Directory 林中，不存在此限制，因为 Enterprise Admins 组托管在此域中（这是创建黄金票证的地方）。
图形：除非在 EA 域中，否则 Golden Ticket 不能跨信任工作。
标准 Golden Ticket 仅限于创建它的子域，所以现在我们将 SID History 添加到等式中……
金票 SID 历史 = 中奖！
在迁移方案中，从 DomainA 迁移到 DomainB 的用户将原始 DomainA 用户 SID 添加到新的 DomainB SIDHistory 属性。当用户使用新帐户登录到 DomainB 时，DomainA SID 与确定访问权限的 DomainB 用户组一起被评估。这意味着可以将 SID 添加到 SID 历史记录以扩展访问权限。
一旦 Mimikatz 在金票（和银票）中支持 SID 历史记录，事情就会变得更加有趣，因为 AD 森林中的任何组都可以包含并用于授权决策。为了支持我对如何在 Kerberos 票证中使用 SID 历史记录跨信任（森林内和外部）扩展访问权限的研究，我在 6 月下旬联系了 Benjamin Delpy 并请求添加 SID 历史记录。
使用最新版本的 Mimikatz，我们现在可以将 SID 历史记录添加到 Forest Enterprise Admins 组的 Golden Ticket。一旦暴露了单个域的 KRBTGT 帐户密码哈希，这将启用整个林范围的危害。
总而言之，Golden Tickets 现在可用于破坏 AD 森林中的任何域，只要一个域受到破坏。
更新：
已经注意到，在 Active Directory 林中的信任之间启用 SID 过滤可以缓解这种情况，因为 SID 历史记录不起作用。这可能是真的，尽管这种方法存在一些潜在问题：1）我从未在生产环境中看到过这种配置，2）我不确定 Microsoft 对此的支持态度，以及 3）启用 SID 过滤AD 林中的信任可能会破坏依赖于跨域的通用组成员身份的应用程序（这可能是一件大事，因为通用组通常在多域 AD 林中经常使用）。这些可能看起来像小问题，但我已经看到几个大型企业 AD 环境在采用非标准方法时会中断，因为开发人员在测试时没有考虑配置。
请注意，Active Directory 域不是 安全边界；AD森林是。这意味着如果您需要帐户隔离，则需要 AD 林，而不是 AD 林中的域。
