Unit 42 研究人员提出了一套新的检测方法，可提升对新一代 Kerberos 攻击的发现能力。这类攻击允许攻击者通过修改 Kerberos 票据来维持特权访问。其中最广为人知的是 Golden Ticket 攻击，它让威胁行为者能够伪造票据，从而冒充高权限用户。

这两种较新的攻击在思路上延伸了 Golden Ticket：伪造票据不是从零生成，而是基于一张已有票据进行修改，从而获得高权限访问。本文将比较这三类攻击的差异，并解释为何后两者更难被发现。

由于 Active Directory 的广泛部署，Kerberos 攻击已成为许多威胁行为者的"家常便饭"。研究人员发现了以下新技术，可让对手在一个 Active Directory (AD) 域内，对所有服务与资源获得不受约束的访问：

• Diamond Ticket
• Sapphire Ticket

由于与知名的 Golden Ticket 攻击高度相似，威胁行为者也可能在未来的行动中采用这些手法。通过采用本文讨论的新检测方法，可以更好地防护这些新的 Kerberos 攻击。

要理解这些票据攻击及其影响，先回顾 Kerberos 的工作原理会更有帮助。这包括这些攻击中用到的常见术语，以及票据的结构与使用流程。

Kerberos 是一种网络身份验证协议，主要用于 Active Directory (AD) 环境。不同行业成千上万的公司使用 Active Directory 技术来管理组织内的用户账号与各类资源。Active Directory 的首个版本随 Windows Server 2000 发布；此后，它在企业与大型组织中尤为常见，这些组织往往需要管理大量用户与资源。

Kerberos 通过向用户签发票据提供强身份验证，使其能够访问服务。票据由 Key Distribution Center (KDC) 分发；在大多数环境中，KDC 安装在 Domain Controller (DC) 上。

在初始身份验证阶段，Ticket Granting Ticket (TGT) 会分配给用户。之后，客户端使用 TGT 向 KDC 证明身份，并从 Ticket Granting Service (TGS) 请求服务票据。服务票据用于向具体服务完成身份验证。

一次 Kerberos 身份验证通常包含以下步骤：

1. 用户向 KDC 发送 (AS-REQ) 请求 TGT，KDC 验证并校验凭据与用户信息。
2. 用户认证通过后，KDC 发送加密的 TGT（AS-REP）作为响应。
3. 用户向 DC 出示 TGT，并发送 (TGS-REQ) 请求 TGS。
4. KDC 返回加密的 TGS（TGS-REP）。
5. 用户连接到承载所请求服务的服务器，并出示 TGS（AP-REQ）以访问服务。
6. 应用服务器向客户端返回 (AP-REP)。

图 1. Kerberos 身份验证流程。

Kerberos 票据包含哪些组件？

每个 Kerberos ticket 包含以下字段：

enc-part 中包含多个字段，但本文将重点关注以下两项：

1. cname – 客户端主体标识符 (principal identifier) 的名称部分。
2. authorization-data – 用于将"代表某主体签发票据"时的授权数据从该主体传递给应用服务。该部分包含 Privileged Attribute Certificate (PAC)。

什么是 Kerberos Privileged Attribute Certificate (PAC)？

PAC 是一种结构，用于承载由 DC 提供的授权相关信息。验证身份的认证协议会借助 PAC 传输授权信息，而这些信息用于控制对资源的访问。

DC 会在 PAC 中包含授权数据，例如 security identifiers (SIDs) 和 relative identifiers (RIDs)。

Kerberos 委派

Kerberos delegation 的一个常见场景是：Web 服务器从数据库服务器获取用户数据。数据库服务器只会向该用户授予数据访问权限，因此 Web 服务器需要以该用户身份完成访问，这种"代为冒充"称为 Kerberos 委派。

本文将重点讨论受限委派 (constrained delegation)。

Constrained Delegation： Microsoft 为避免将用户的 TGT 保存在内存中，实现了 Kerberos 的 S4U (Service for User) 扩展。该扩展由 S4U2Self 与 S4U2Proxy 组成。S4U2Self 允许服务代表任意用户向自身请求票据；S4U2Proxy 则允许服务向另一个服务进行认证。

S4U2Self 扩展

如上所述，S4U2Self 扩展允许某个 service 在票据中获得用户的 authorization data（即 PAC）。

要使用该协议扩展，发起 KRB_TGS_REQ 的用户至少需要一个 Service Principal Name (SPN)，以便 DC 能用服务的长期密钥加密生成的服务票据。

S4U2Self KRB_TGS 交换流程：

1. 服务填写 PA_FOR_USER 数据结构，其中包含服务将代表其请求服务票据的用户信息，并向 TGS 发送 KRB_TGS_REQ 消息。
2. TGS 会在对 KRB_TGS_REQ 的响应中将服务票据返回给服务端。服务票据中的 PAC 包含授权数据。

U2U 认证

User-to-User authentication 在 Kerberos RFC 中被描述为一种方法，它"允许客户端请求：KDC 签发的票据使用一张签发给负责验证的一方的 TGT 中的会话密钥进行加密"。

KRB_TGS_REQ 将具备以下特征：

• additional-tickets：包含用于提取秘密密钥的 TGT
• ENC-TKT-IN-SKEY：该选项表示末端服务器 (end server) 的票据应使用 additional-tickets 中 TGT 的会话密钥加密
• 服务名称 (sname) 可以指向用户，而不一定是带 SPN 的服务

U2U + S4U2Self

将两种方法结合起来，即使用户没有 SPN，也能使用 S4U2Self 扩展。该交换中获得的服务票据会使用服务器的长期密钥加密（在此特定场景中，服务器可以是一个没有 SPN 的用户），因此可以使用服务器的密钥解密目标用户的 PAC。

KRB_TGS_REQ 数据包将同时具备两种方法的全部特征。

Sapphire Ticket 与 Diamond Ticket 攻击都会解密一张合法的 TGT，并修改其中的 PAC。要做到这一点，对手需要获取 KRBTGT 账户的密钥（密码哈希）。根据 Microsoft TechNet（现为 Microsoft Docs）的描述，KRBTGT 是一个本地默认账户，充当 KDC 服务的服务账户。

Sapphire Ticket

Sapphire Ticket 攻击（由 Charlie Bromberg 提出）需要先获取域内任意用户的凭据。我们将该用户称为 Joe。Joe 的凭据用于通过常规的 KRB_AS_REQ 获取一张 TGT，并在后续用于解密高权限用户的 PAC。

获得 TGT 后，对手会使用 U2U + S4U2Self：

1. 确定想要冒充的用户（高权限用户）。
2. 生成具备以下属性的 KRB_TGS_REQ：
   1. PA_FOR_USER 结构包含被冒充的用户
   2. 服务名称 (sname) 为 Joe 的用户名
   3. Joe 的 TGT 会被添加到 additional-tickets 字段
   4. 在 KDC Option 中设置 ENC-TKT-IN-SKEY 标志
3. 获取被冒充用户的服务票据。

图 2. 使用 U2U + S4U2Self 方法创建的 KRB_TGS_REQ。 图 3. 在 KDC Option 中设置 ENC-TKT-IN-SKEY 标志。 图 4. U2U + S4U2Self 的 TGS-REP。

众所周知，服务票据会使用服务的长期密钥加密，因此只要对手掌握 Joe 的凭据，就能解密该服务票据。对手同时掌握 KRBTGT 账户密钥，因此也能解密并修改由该密钥加密并签名的 Joe 的 TGT。

为了伪造 Sapphire Ticket，攻击者会提取被冒充用户的 PAC，并通过两处修改 Joe 的 TGT：

1. 用高权限 PAC 替换 Joe 原始的 PAC。
2. 将 cname 字段改为被冒充用户的名称。

这样，攻击者就能获得一张可用的高权限用户 TGT。

Diamond Ticket

Diamond Ticket 攻击的第一步（由 Charlie Clark 与 Andrew Schwartz 提出）是获取一张 TGT，可以通过以下任一技术实现：

• 对手使用低权限用户的凭据发起 KRB_AS_REQ，从而获得一张合法的 TGT。
• 工具 Rubeus 提供名为 tgtdeleg 的选项，滥用 Kerberos 的 Generic Security Services Application Program Interface (GSS-API) 来为当前用户检索一张可用的 TGT，且无需在主机上提升权限。

在 KRB_AS_REP 中收到 TGT 后，对手就可以使用 KRBTGT 账户密钥解密该 TGT，并修改票据的各个部分。

修改票据后，攻击者可以通过以下方式之一提升权限：

• 生成一张 TGT，用于冒充域管理员或域内任意用户。

在该场景中，攻击者需要修改票据中的 cname 字段以及 PAC。该方法会生成一张以域管理员（或域内其他用户）名义签发的伪造票据，这与 Golden Ticket 攻击非常相似。

• 通过修改 PAC，将普通域用户的权限提升为域管理员权限。

该方法会让攻击者获得一张以低权限用户名义签发、但具备域管理员权限的票据。

Diamond Ticket 与 Sapphire Ticket 都是通过修改合法 TGT 伪造出的 TGT，用来添加额外权限或更换身份。许多 Golden Ticket 的检测依赖于一个特征：未观察到由合法 DC 签发 TGT 的过程；而新的攻击篡改的是由 DC 签发的合法 TGT，因此更难被检测。

在伪造出 TGT 后，攻击者会用它向任意服务或资源申请服务票据（TGS）。例如，他们可以请求访问域内所有计算机、文件与文件夹。

Diamond Ticket 与 Sapphire Ticket 攻击有什么区别？

两种攻击都是在合法 TGT 的 PAC 上做手脚，但主要差异在于修改方式：Diamond Ticket 直接在原始 PAC 上添加额外权限，或整体替换；Sapphire Ticket 则利用 Kerberos 委派获取一份高权限用户的合法 PAC，并用其替换原票据中的 PAC。

任何人都能伪造 TGT 吗？

要实施此类攻击，基本要求是对手必须能够获取 KRBTGT 账户的密码哈希。

KRBTGT 账户会为域内所有 Kerberos TGT 票据进行加密与签名。Kerberos 票据的校验工作（包括为 KDC 服务加解密 TGT）也由 KRBTGT 完成。因此，只要伪造的 TGT 使用 KRBTGT 账户密钥加密，就会被视为有效票据。

此外，在伪造出 TGT 后，对手还必须使用 KRBTGT 密码哈希对伪造的 TGT 重新加密，以确保新的 TGT 能通过 KDC 校验，并为目标服务签发服务票据。

即便如此，仍需要牢记：获取 KRBTGT 密码哈希并不容易。成功获取不仅意味着可以访问域内所有服务与资源，也意味着可以在网络中建立持久化。

伪造票据攻击已在真实环境中被观察到，例如 Playful Taurus (又称 APT15、Ke3chang 与 NICKEL) 的攻击行动。该组织被归因于来自中国的行为者，自 2010 年以来针对全球的石油、政府、外交、军事与非政府组织开展攻击。

NCC Group 的 IR 团队在 2017 年 5 月的调查指出，为了在受害网络中保持持久化并应对潜在的清理修复措施，Playful Taurus 使用 Mimikatz 转储凭据并生成 Kerberos Golden Ticket。

在另一场约发生于 2021 年 12 月的行动中，MSTIC 发现同一威胁行为者使用了 Mimikatz、WDigest、NTDSDump 等恶意工具及其他密码转储工具，在目标系统上收集凭据。

Mimikatz 允许攻击者执行以下活动：

• 收集凭据
• 执行 DCSync attacks

这些攻击会模拟 Active Directory replication 过程并检索用户的密码哈希，可用于收集 KRBTGT 密码哈希。

• 伪造 Golden Ticket

我们的判断是：由于 Sapphire Ticket 与 Diamond Ticket 在形态上类似 Golden Ticket、但更难被发现，不同威胁行为者（如 Playful Taurus）很可能在未来会采用这些攻击。

由于获取 KRBTGT 密码哈希本身就很困难，这类攻击在真正落地之前往往会伴随大量噪声。在这种情况下，针对 Golden Ticket 的检测思路在这里同样适用。

Sapphire Ticket

由于 Sapphire Ticket 看起来应当是有效的（即包含合法 PAC 的票据），仅靠分析票据内容很难发现其使用。不过，我们可以在主机侧检测其他可疑活动：

• KRBTGT 密码哈希被窃取的迹象
• 可疑工具的使用
• 环境内的 DCSync 攻击，或从主机到 DC 的可疑连接
• 带有 U2U + S4U2Self 属性的异常 KRB_TGS_REQ
• 来自该主机、由高权限用户发起的 KRB_TGS_REQ

如果对手在完成攻击后立刻使用该票据，我们可能会观察到同一个 IP 为两个不同用户发起了 TGT 请求与 TGS 请求。同时，第二个用户（即出现在 TGS 请求中的用户）并没有任何迹象表明其曾在该机器上完成过认证。此类行为可结合 Windows 事件 4768 和 4769 以及网络流量进行监控。

图 5. 低权限用户的 TGT 请求。 图 6. 高权限用户的 TGS 请求。

Diamond Ticket

为 Domain Admin 账户生成票据

这里的检测思路与常见的 Golden Ticket 检测方法或前述的 Sapphire Ticket 检测思路非常相似。

提升普通域用户的权限

如果对手使用该技术，其行为更接近合法认证：TGT 与 TGS 请求都是同一个用户发起的，因此上面建议的检测器并不适用。

可以通过监测资源访问数量与访问资源类型的异常来发现此类活动。攻击者很可能会访问高权限资源，因此这些访问对该用户而言会是"新的"。然而，在大型环境中做异常检测可能较为棘手，甚至可能造成干扰，而非真正发现攻击。

需要强调的是，Diamond Ticket 与 Sapphire Ticket 的主要差异在于：Sapphire Ticket 使用的是一个真实高权限用户的真实 PAC；而在 Diamond Ticket 与 Golden Ticket 攻击中，PAC 由攻击者修改，因此可能不准确。该信息可用于检测这些攻击。

组成员关系检测

为使该检测方法更易理解，这里引入 Windows event 4627 (S): Group membership information。该事件会与 Windows event"4624 (S): An account was successfully logged on"一起生成，用于展示已登录账户所属的组列表。

图 7. Windows Event 4627。

这要求操作系统版本为 Windows Server 2016、Windows 10 及以上。要启用它，必须为 Audit Logon 子类别启用 Success Audit。

监控该事件可以帮助发现用户组成员关系中的异常。当攻击者希望为伪造票据赋予域管理员权限时，会在 PAC 中加入 Domain Admins 的 RID (512)。因此，在登录过程中会显示该用户属于 Domain Admins。

例如，使用 Diamond Ticket 攻击将低权限用户（继续使用"Joe"）提升为域管理员权限，如图 8 与图 9 所示。

图 8. 低权限用户显示为 Domain Admins 成员。 图 9. Joe 并不是 Domain Admins 的成员。

值得注意的是，如果对手使用伪造 TGT 冒充高权限用户，可能会导致组成员关系被错误分配，因此也值得关注此类异常。

为避免误报（例如用户被有意加入高权限组），可以将事件 4627 与 Windows 事件 4732 与 4728 进行关联，这些事件表明用户何时被加入某个组。

本文在简要介绍相关 Kerberos 术语与攻击方式后，讨论了实施这些攻击所需的权限，以及监控不同伪造票据攻击的重要性。此外，我们也分析了若干可能的检测思路，这些思路既能覆盖 Golden Ticket 攻击，也能覆盖新的攻击手法。

伪造票据攻击可能很难通过粗略查看发现，因为它们起初看起来像是合法行为。但如果能收集到足够多关于可疑网络活动、恶意工具使用或 Windows 事件的信息，我们就有机会检测到一些最有效的 Kerberos 攻击。

此外，部署诸如 Cortex XDR 的安全平台，还能为攻击的各个阶段提供额外的防护能力与可视性。

Constrained delegation – 一种更安全的委派形式，可供服务使用。配置后，受限委派会限制指定服务器可代表用户访问的服务范围。 DCSync Attack – 滥用 Windows 域控制器 (Domain Controller) 的 application programming interface (API)，从远程域控制器模拟复制过程。 Domain controller (DC) – 在计算机网络域内响应安全认证请求的服务器计算机。它负责允许主机访问域资源，并在 AD 环境中充当 KDC。 ENC-TKT-IN-SKEY – 该选项表示末端服务器的票据应使用 additional-tickets 中 TGT 的会话密钥加密。 Golden Ticket attack – 当对手获取 KRBTGT 账户密码哈希后，可伪造 Kerberos 的 Ticket Granting Ticket (TGT)，即"Golden Ticket"，使其能为 Active Directory 中任意账户生成认证材料。 Kerberos – 一种网络身份验证协议，主要用于 Active Directory 环境。 Kerberos delegation – 一种委派设置，允许应用代表发起用户请求终端用户的访问凭据，从而访问相关资源。 Key Distribution Center (KDC) – 密码学中的 Key Distribution Center (KDC) 是一个负责向网络中的用户提供密钥的系统，该网络用于共享敏感或私有数据。 KRBTGT account – 一个本地默认账户，充当 KDC 服务的服务账户。 PA-FOR-USER – 用于标识用户的结构；服务代表该用户请求服务票据时，会使用其中的