前言在渗透测试和红队对抗中，针对 Kerberos 认证机制的攻击手段一直是 Windows 域渗透的重要突破口。其中，黄金票据 (Golden Ticket)、白银票据 (Silver Ticket)、钻石票据 (Diamond Ticket)和近期出现的 “蓝宝石票据” (Sapphire Ticket)都属于经典且高效的提权与持久化方式。本文将从 Kerberos 认证流程、原理、利用方法、常用工具、危害与防御几个维度，系统梳理这四种票据攻击的关键点。
一、Kerberos 认证流程概述Kerberos 是一种网络认证协议，它允许用户在不安全的网络环境中，通过一个可信的第三方 (Key Distribution Center, KDC) 对客户端和服务器进行相互认证。在 Windows Active Directory (AD) 环境中，域控制器 (Domain Controller, DC) 同时扮演着 KDC 的角色。
Kerberos 认证流程主要涉及三个核心组件：
客户端 (Client)：发起认证请求的用户或服务。
密钥分发中心 (Key Distribution Center, KDC)：在 AD 中就是域控制器，它包含两个逻辑服务：
认证服务 (Authentication Service, AS)：负责初始认证，为客户端颁发 TGT (Ticket Granting Ticket)。
票据授予服务 (Ticket Granting Service, TGS)：负责为客户端颁发 服务票据 (Service Ticket, TGS)，以便客户端访问特定服务。
应用服务器 (Application Server, AS)：提供服务的服务器，例如文件服务器、Web 服务器、数据库服务器等。
整个认证过程可以概括为以下四个主要步骤：
1. 第一阶段：初始认证 (Authentication Service Exchange - AS-REQ/AS-REP)客户端获取 TGT (Ticket Granting Ticket)1.1 客户端请求 (AS-REQ)：当用户首次登录域或需要访问域资源时，客户端（用户的工作站）会向 KDC 的 认证服务 (AS)发送一个 AS-REQ请求。这个请求通常包含：
用户名 (Principal Name)
预认证数据 (Pre-Authentication Data)，通常是用用户密码 Hash 加密的时间戳，用于证明请求者是真正的用户。
请求的 TGT 有效期等。
1.2 KDC (AS) 响应 (AS-REP)：KDC 的 AS 收到 AS-REQ 后：
会根据请求的用户名，从其 Kerberos 数据库 (Active Directory)中查找对应用户的密码 Hash。
使用该 Hash 解密客户端发送的预认证数据，验证用户身份和时间戳，防止重放攻击。
如果认证成功，AS 会生成两个加密的消息并发送回客户端：
消息 A (Client-TGS Session Key)：包含一个客户端与 TGS 之间使用的 会话密钥 (Session Key)，这个会话密钥用客户端自身的密码 Hash 进行加密。客户端收到后用自己的密码 Hash 解密，就能得到这个会话密钥。
消息 B (TGT - Ticket Granting Ticket)：这是核心的 TGT。它包含了客户端的身份信息 (用户名、SID)、客户端的 IP 地址、TGS 名称、TGT 的有效期以及上述的 Client-TGS Session Key。最关键的是，这个 TGT 是用 KDC 中krbtgt账户的密码 Hash (即krbtgt的密钥) 进行加密的。客户端无法解密 TGT 的内容，只能将其安全地存储在本地的 Kerberos 缓存中。
2. 第二阶段：票据授予 (Ticket Granting Service Exchange - TGS-REQ/TGS-REP)客户端获取服务票据 (Service Ticket)2.1 客户端请求 (TGS-REQ)：当客户端需要访问域内的某个特定服务 (例如，文件共享、Web 应用) 时，它会向 KDC 的 票据授予服务 (TGS)发送一个 TGS-REQ请求。这个请求包含：
之前从 AS 获得的、未解密的 TGT(消息 B)。
一个用 Client-TGS Session Key加密的 认证器 (Authenticator)，其中包含客户端的身份和当前时间戳，用于证明客户端是 TGT 的合法持有者。
客户端想要访问的特定服务的 服务主体名称 (Service Principal Name, SPN)。SPN 是服务的唯一标识符，例如CIFS/fileserver.domain.com。
2.2 KDC (TGS) 响应 (TGS-REP)：KDC 的 TGS 收到 TGS-REQ 后：
首先，TGS 会使用自己的krbtgt账户的 Hash 来解密客户端发来的 TGT。如果解密成功，TGS 就能获取到 TGT 中的 Client-TGS Session Key。
然后，TGS 使用这个 Client-TGS Session Key解密客户端发送的 认证器 (Authenticator)，验证请求的合法性，防止重放攻击。
如果验证通过，TGS 会在 Active Directory 中查找与请求的 SPN关联的服务账户 (通常是机器账户或单独的服务账户) 的 Hash。
TGS 生成两个加密的消息并发送回客户端：
消息 C (Client-Server Session Key)：包含一个客户端与目标服务之间使用的 会话密钥 (Session Key)，这个会话密钥用 Client-TGS Session Key进行加密。客户端收到后用 Client-TGS Session Key 解密，就能得到这个新的会话密钥。
消息 D (Service Ticket - TGS)：这是核心的 服务票据。它包含了客户端的身份信息、Client-Server Session Key、有效期等。这个服务票据是用目标服务账户的密码 Hash (即服务密钥) 进行加密的。客户端无法解密服务票据的内容，也只是将其安全地存储在本地的 Kerberos 缓存中。
3. 第三阶段：服务访问 (Client/Server Exchange - AP-REQ/AP-REP)客户端使用服务票据访问应用服务器3.1 客户端请求 (AP-REQ)：客户端得到服务票据后，会直接向目标 应用服务器 (AS)发送一个 AP-REQ请求。这个请求包含：
之前从 TGS 获得的、未解密的 服务票据 (TGS)(消息 D)。
一个用 Client-Server Session Key加密的 认证器 (Authenticator)，其中包含客户端的身份和当前时间戳。
3.2 应用服务器验证并授权 (AP-REP - 可选)：目标应用服务器收到 AP-REQ 后：
会使用自己的服务账户的 Hash 来解密客户端发来的 服务票据 (TGS)。如果解密成功，服务器就能获取到 Client-Server Session Key。
然后，服务器使用这个 Client-Server Session Key解密客户端发送的 认证器 (Authenticator)，验证请求的合法性。
如果验证通过，服务器就认为客户端是合法的。服务器可以选择发送一个 AP-REP响应，其中包含用 Client-Server Session Key 加密的服务器自身信息，以实现双向认证。
最终，服务器根据服务票据中包含的客户端 PAC (Privilege Attribute Certificate)信息 (包括用户的 SID、组 SID 等)，进行 授权，决定客户端是否有权限访问请求的资源。
4. 第四阶段：访问资源客户端获得授权后，就可以开始与应用服务器进行安全通信，访问请求的资源。所有的后续通信都可以使用之前协商好的 Client-Server Session Key进行加密，保证通信的机密性和完整性。
通过以上流程可以看出，Kerberos 认证的核心在于：
不传输明文密码：所有认证都是通过加密票据和会话密钥完成的。
票据的时效性：所有票据都有有效期，增加安全性。
相互认证：客户端和服务器都可以验证对方的身份。
第三方信任：KDC 作为可信的第三方，在整个认证链中扮演核心角色。
理解这个流程对于理解黄金票据、白银票据、钻石票据和蓝宝石票据的攻击原理至关重要，因为这些攻击正是利用了 Kerberos 流程中密钥和票据的信任链来伪造身份和权限。
放一张高清原图，便于理解：
二、黄金票据 (Golden Ticket)黄金票据是一种针对 Kerberos 认证中 TGT (Ticket Granting Ticket，票据授权票据)的伪造攻击，允许攻击者在获取特定凭据后，无限期地伪造任意域用户，包括域管理员。
1. 原理Kerberos 认证的核心在于 krbtgt账户，它是域控制器 (KDC) 用于签发所有 TGT 的关键账户。如果攻击者能够获取到域控上krbtgt账户的 NTLM Hash，就意味着掌握了域内所有 TGT 的签名密钥。
攻击者一旦拥有krbtgt的 Hash，就可以离线伪造任意用户身份的 TGT。这个伪造的 TGT 会被 KDC 认为是合法的，因为它用正确的krbtgtHash 签名。有了伪造的 TGT，攻击者就可以向 KDC 申请 任意服务票据 (TGS)，从而访问域内任何资源，而无需与真正的用户密码进行交互，也不受用户密码修改的影响。
核心点：只要掌握了krbtgt的 Hash (通常通过 DCSync 或域控提权后 dump 获取)，就可以持续伪造有效的 TGT，实现对域的完全控制。
2. 利用方法与工具利用黄金票据的关键在于获取krbtgt的 NTLM Hash，然后使用特定工具进行伪造。
获取krbtgtHash：
DCSync 攻击：最常用的方式，通过模拟域控制器之间的同步协议 (MS-DRSR)，从域控制器中直接请求krbtgt的 Hash。这通常需要域管理员权限或等效权限。
# mimikatz DCSync 命令示例
lsadump::dcsync /domain:yourdomain.com /user:krbtgt
域控本地 LSA Dump：在已提权的域控制器上，使用mimikatz等工具直接从 LSASS 进程中导出所有用户的 Hash，包括krbtgt。
生成伪造 TGT：获取到krbtgtHash 后，可以使用mimikatz或Rubeus等工具生成伪造的 TGT。
Mimikatz 示例：
# 假设获取到的 krbtgt hash 是 bfb69399cb7ac7828c70a1a0833119f6
# 伪造域管理员 Administrator，域名为 yourdomain.com
# SID 为 S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx (替换为实际域名 SID)
kerberos::golden /user:Administrator /domain:yourdomain.com /sid:S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx /krbtgt:bfb69399cb7ac7828c70a1a0833119f6 /ptt
ptt(Pass The Ticket) 参数会将生成的票据直接注入到当前会话中，攻击者无需重启即可直接使用。
Rubeus 示例：Rubeus是一个强大的 C# Kerberos 工具集，更适用于隐蔽的票据操作。
# Rubeus.exe golden /domain:yourdomain.com /sid:S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx /krbtgt:bfb69399cb7ac7828c70a1a0833119f6 /user:Administrator /id:500 /ptt
id:500指定了伪造用户的 RID (相对 ID)，通常域管是 500。
使用伪造票据：
sekurlsa::pth：Mimikatz 的 Pass The Hash 功能，可以结合票据注入到当前进程。
klist：Windows 自带的 Kerberos 票据列表工具，伪造的票据会被注入到这里，可以直接通过命令行查看或使用。
常见工具：
mimikatz：最经典和功能强大的 Windows 域渗透工具，其kerberos::golden模块是黄金票据攻击的核心。
Rubeus：一款由 Harmj0y 开发的 C# Kerberos 攻击工具，功能更全面，包括票据请求、注入、清除等，且支持各种 Kerberos 攻击技术，是红队行动中的利器。
Impacket的ticketer.py：Python 脚本化工具，适用于跨平台或无 Mimikatz 环境下的黄金票据生成，功能强大且隐蔽性较好。
3. 危害完全域控制：攻击者可伪造任意域用户甚至域管账户的身份，长期保持对域的完全访问权限，包括访问所有文件共享、运行任意服务、修改 AD 对象等。
持久性：即使krbtgt账户的密码被修改，只要攻击者仍然拥有旧的krbtgtHash (或没有进行双次密码重置)，他们仍然可以生成有效的黄金票据，攻击效果持久。
4. 防御手段定期更换krbtgt账户的密码：这是最核心的防御措施。官方建议每 180 天至少更换一次。在域内，krbtgt密码的更改需要进行两次操作，以确保所有 DC 都能正确同步。第一次重置后，需要等待一段时间（通常为 Kerberos 票据默认有效期），再进行第二次重置。这会使旧的krbtgtHash 失效。
启用事件日志审计：
监控 Kerberos TGT 签发：尤其关注事件 ID4768(A Kerberos authentication ticket (TGT) was requested) 和4769(A Kerberos service ticket was requested)。异常的请求源、请求账户或请求模式都可能是攻击迹象。
监控 LSASS 进程访问：检测对 LSASS 进程的异常访问，例如非特权用户尝试读取 LSASS 内存，这可能是攻击者在尝试 dump Hash。事件 ID4656(A handle to an object was requested) 结合Access Mask可以帮助识别。
使用 EDR (Endpoint Detection and Response) 检测：EDR 能够检测可疑的票据注入行为 (例如mimikatz的sekurlsa::pth操作) 以及对lsass.exe进程的异常访问和内存读取。
限制域控访问：严格限制能够物理或逻辑访问域控制器的用户和设备。
多因素认证 (MFA)：虽然黄金票据绕过密码认证，但如果 Kerberos 服务支持 MFA，可以增加攻击的难度。
三、白银票据 (Silver Ticket)白银票据是一种针对 Kerberos 服务票据 (TGS)的伪造攻击。与黄金票据不同，它不需要krbtgtHash，而是利用特定服务账户的 Hash 来伪造对该服务的访问权限。
1. 原理白银票据的原理在于：如果攻击者获取了某个 服务账户 (Service Account)的 NTLM Hash (例如：SQL Server 服务账户、Web 服务器的 IIS 应用池账户、域控制器上的 CIFS/SMB 服务账户等)，就可以离线伪造一个针对该服务的 TGS。这个伪造的 TGS 会被目标服务视为合法，因为它用正确的服务账户 Hash 加密和签名。
白银票据只影响目标服务，不会触发 KDC 日志，因此更隐蔽。KDC 并不知道存在伪造的 TGS，因为它从未参与到 TGS 的生成过程中。
2. 利用方法与工具利用白银票据的关键在于获取目标服务账户的 NTLM Hash，然后伪造 TGS。
获取服务账户 NTLM Hash：
域内凭证 Dump：在已提权的域成员服务器上，可以从 LSASS 进程中导出该机器上运行的服务账户的 Hash。
AD Dump：如果已经获得域管理员权限，可以通过 DCSync 或其他方式从 AD 中导出所有服务账户的 Hash。
PTH / PTT：如果获得了服务账户的明文密码或 Hash，可以直接利用。
例如，假设我们想伪造访问文件共享 (CIFS 服务)，我们需要获取提供 CIFS 服务的主机对应的机器账户 Hash (因为主机账户也是一种服务账户)。
# 获取目标主机机器账户 (如 DC01$) 的 NTLM Hash
lsadump::dcsync /domain:yourdomain.com /user:DC01$
或者在目标机器本地执行 Mimikatz dump LSASS。
生成伪造 TGS：使用mimikatz或Rubeus生成针对特定服务的 TGS。
Mimikatz 示例：
# 假设目标主机名是 DC01，域名是 yourdomain.com
# 假设 DC01$ 的 NTLM Hash 是 d9b4c09d3b4e3b1c1d2e3f4a5b6c7d8e
# 伪造 Administrator 用户，服务是 CIFS
kerberos::golden /user:Administrator /domain:yourdomain.com /sid:S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx /target:DC01.yourdomain.com /service:CIFS /rc4:d9b4c09d3b4e3b1c1d2e3f4a5b6c7d8e /ptt
这里的/rc4参数是目标服务账户的 NTLM Hash。target参数指定了提供服务的 SPN (Service Principal Name) 所在的主机。
Rubeus 示例：Rubeus的asktgs或tgs模块更适合白银票据生成。
# Rubeus.exe silver /service:cifs /target:DC01.yourdomain.com /rc4:d9b4c09d3b4e3b1c1d2e3f4a5b6c7d8e /user:Administrator /domain:yourdomain.com /sid:S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx /ptt
使用伪造票据：生成的 TGS 会被注入到当前会话的 Kerberos 缓存中，攻击者可以直接尝试访问目标服务。
# 注入票据后，尝试访问文件共享
net use \\DC01\C$
常见工具：
mimikatz：同样使用kerberos::golden命令，但参数不同，用于生成 TGS。
Rubeus：其silver命令或asktgs/tgs模块专门用于生成白银票据，功能丰富。
Impacket的ticketer.py：同样支持白银票据的生成，提供 Python 接口。
3. 危害隐蔽性强：由于不与 KDC 交互，KDC 的日志不会记录伪造票据的申请痕迹，使得攻击更难被察觉。
局部持久化和横向移动：攻击者可伪造访问特定服务 (如文件共享、SQL Server、WinRM 等) 的身份，实现在目标主机或服务上的持久化访问和隐蔽的横向移动。
绕过服务 ACL：即使正常用户无法访问某服务，攻击者伪造具有相应权限的白银票据后，就可以绕过 ACL 访问。
4. 防御手段最小化服务账户权限：授予服务账户的权限应严格遵循 最小权限原则。服务账户不应拥有域管理员权限，也不应拥有不必要的本地管理员权限。
绑定 SPN (Service Principal Name) 最小化：为服务账户正确配置 SPN，并避免使用共享的服务账户，每个服务尽量使用独立的账户。
定期更换服务账户密码：及时更换服务账户的密码，特别是在发生 Hash 泄露事件后。
开启服务票据签名和加密 (Kerberos AES)：确保 Kerberos 策略中启用了 AES 加密 (AES256_HMAC_SHA1 和 AES128_HMAC_SHA1)，这会增加 Hash 泄露后离线解密的难度。
使用 EDR 监控异常服务票据访问：
检测非 Kerberos 认证的访问：某些攻击工具可能会直接使用伪造的 TGS 而不经过 Kerberos 协议栈，EDR 可以检测到这种异常。
监控异常进程行为：识别尝试加载或使用 Kerberos 票据的非典型进程。
监控服务访问模式：识别异常的服务访问请求，例如来自非典型源 IP、异常时间段或异常账户的访问。
限制本地管理员权限：限制普通用户对服务器的本地管理员权限，减少服务账户 Hash 被窃取的风险。
四、钻石票据 (Diamond Ticket)钻石票据是一种更高级的 Kerberos 伪造手法，它结合了黄金票据和白银票据的思路，允许攻击者对 TGT和其内部的 PAC (Privilege Attribute Certificate)进行更细粒度的控制和伪造。攻击者可以灵活定义用户身份、权限和 SID (Security Identifier)，甚至在伪造的票据中修改组成员身份。
1. 原理钻石票据的核心在于能够不仅伪造 TGT 本身，还能对 TGT 中包含的 PAC进行完全的自定义。PAC 是 Kerberos 票据中的一个重要组成部分，它包含了用户的安全组信息、权限和 SID 等敏感数据。KDC 在签发服务票据时，会将 TGT 中的 PAC 提取出来并放入 TGS 中。服务收到 TGS 后，会验证 PAC 以确定用户的权限。
传统黄金票据伪造的 PAC 内容是基于krbtgtHash 生成的，其包含的权限是固定的。而钻石票据允许攻击者在伪造 TGT 时，自定义 PAC 中的内容，从而可以：
伪造任意组身份：在 PAC 中添加或修改用户所属的组，例如将普通用户伪造成Domain Admins组的成员，无需真实修改 AD 中的用户属性。
结合 RBCD (Resource-Based Constrained Delegation，基于资源的约束委派)：RBCD 是一种合法的委派机制，允许特定的服务账户代表其他用户访问资源。钻石票据可以伪造 PAC 中的msDSAllowedToActOnBehalfOfOtherIdentity属性，从而绕过或滥用 RBCD，实现隐蔽的横向移动或持久化。
伪造用户 SID：伪造用户在票据中的 SID，甚至可以伪造 SID History，用于绕过某些基于 SID 的访问控制。
钻石票据的实现通常依赖于对 Kerberos 协议和 PAC 结构的深入理解，并且需要获取krbtgt的 Hash 或其他域控的机密信息 (如 KDC key)。
2. 利用方法与工具钻石票据的利用通常涉及更复杂的操作和对 Kerberos 内部机制的了解。
前提条件：
拥有krbtgtHash：伪造 TGT 的基础，与黄金票据相同。
获取 KDC Key (可选但增强)：某些高级的钻石票据技术可能需要获取 KDC 的私钥，但这通常比获取krbtgtHash 困难得多。
构造自定义 PAC 的票据：这需要工具支持对 PAC 结构的修改。
Rubeus 示例 (S4U 模块)：Rubeus的s4u模块非常强大，可以结合S4U2Self和S4U2Proxy协议伪造 TGS，并允许在生成的票据中包含自定义的 PAC。
# 伪造 Administrator 用户，SID 和 krbtgt hash 与黄金票据相同
# 关键在于 Rubeus 允许你传入自定义的 PAC 数据，或者通过指定 SID 等信息来构造 PAC
# 下面是一个简化的例子，实际操作中 PAC 的构造会更复杂，可能需要从合法票据中提取PAC结构或手动构建
Rubeus.exe forge /ticketuser:Administrator /domain:yourdomain.com /sid:S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx /krbtgt:bfb69399cb7ac7828c70a1a0833119f6 /targetuser:Administrator /targetservice:cifs /ptt
Rubeus甚至提供了fullpac参数，允许你直接传入一个 Base64 编码的完整 PAC 结构，从而实现完全的自定义。
Mimikatz (自定义 TGT + PAC)：mimikatz也可以通过更底层的命令或自定义脚本来构建包含修改后 PAC 的 TGT。例如，可以先 dump 一个合法用户的 TGT，修改其中的 PAC 部分，然后重新注入。但这比Rubeus更复杂。
结合高级功能绕过访问控制：
S4U2Self / S4U2Proxy：这些 Kerberos 扩展协议用于实现委派。攻击者可以伪造一个用户 (通过钻石票据) 身份，利用 S4U2Self 获取该用户的 TGS，然后利用 S4U2Proxy 代表该用户请求其他服务的 TGS，从而绕过某些访问控制，实现跨域或跨信任边界的横向移动。
滥用 RBCD：如果目标域中配置了 RBCD，攻击者可以伪造 PAC 来模拟被委派的用户身份，从而以更高的权限访问资源。
常见工具：
Rubeus：更适合钻石票据场景，其对 Kerberos 协议的支持和s4u模块使得构造自定义 PAC 的票据变得相对容易。
mimikatz：尽管可以直接操作 TGT，但对于自定义 PAC 的复杂性而言，通常需要更高级的技巧或结合其他工具。
3. 危害极致的权限伪造：攻击者可完全控制票据中包含的组权限，伪造任何用户和任何权限，包括最高权限的域管理员。
隐蔽性极高：结合 S4U2Self/Proxy 和 RBCD，可以在不留下明显痕迹的情况下进行隐蔽的横向移动和持久化。
绕过传统检测：由于 PAC 的修改发生在票据内部，传统基于 KDC 日志的检测可能难以发现。
4. 防御手段定期更换krbtgtHash 及密钥：这是防御所有基于krbtgtHash 攻击的基础，包括黄金票据和钻石票据。
最小化委派权限配置 (慎用 RBCD)：严格审查和最小化配置 Kerberos 委派 (包括非约束委派、约束委派和基于资源的约束委派)。除非绝对必要，否则不应启用。如果必须使用，应确保委派的用户或服务账户权限最小化。
启用 PAC 签名验证策略：确保域控制器强制执行 PAC 签名验证。这可以阻止或至少检测到伪造 PAC 的票据。通过组策略计算机配置->策略->Windows 设置->安全设置->本地策略->安全选项中的网络安全：配置 Kerberos 策略以强制 PAC 签名。
持续监控异常票据特征和访问模式：
PAC 异常：检查 Kerberos 票据中的 PAC 是否存在异常 (例如，包含不存在的 SID 或不应出现的组)。这需要更高级的 Kerberos 审计工具。
异常登录事件：监控事件 ID4624(An account was successfully logged on) 和4672(Special privileges assigned to new logon)，特别是关注来自异常源 IP 或包含异常权限的登录。
LDAP 访问审计：监控对 Active Directory 的异常 LDAP 查询或修改操作，尤其是在委派配置或服务账户权限发生变化时。
实施强大的 EDR 和 SIEM 解决方案：这些工具能够关联多个安全事件，识别异常行为模式，并检测内存中的 Kerberos 票据操作。
五、蓝宝石票据 (Sapphire Ticket)蓝宝石票据是一种相对较新且更高级的 Kerberos 伪造攻击，它关注的是在 跨域信任 (Cross-Domain Trust)环境下的攻击，允许攻击者在目标域中伪造 TGT，即使没有获取到目标域的krbtgtHash。这种攻击通常利用域之间的信任关系来跨越域边界。
1. 原理在 Kerberos 跨域认证中，存在信任关系。当一个域的用户需要访问另一个域的资源时，用户的 TGT 会被发送到信任域的 KDC，信任域的 KDC 会使用 域间信任密钥 (Inter-Domain Key)对 TGT 进行验证并颁发一个跨域的 TGT (Referral Ticket)，或者直接颁发 TGS。
蓝宝石票据的攻击原理是：攻击者通过某种方式（例如，利用 信任方域的 Kerberos 密钥或通过其他中间步骤），伪造一个带有 目标域 KDC 签名的 TGT。这意味着攻击者不再需要直接获取目标域的krbtgtHash，而是通过滥用域信任机制，伪造出 KDC 认为有效的跨域凭证。
具体来说，蓝宝石票据可能涉及：
利用信任密钥：如果攻击者能够获取到域信任相关的密钥（例如，域控制器之间用于建立信任的密码），他们就可以伪造一个看起来是从信任域 KDC 颁发的 TGT，从而进入目标域。
PAC 伪造与跨域：结合钻石票据的 PAC 伪造能力，在跨域环境中构建更具欺骗性的票据，绕过信任边界的检查。
Kerberos Referrals 滥用：深入利用 Kerberos 跨域认证中的Referral机制，在票据中植入恶意信息，诱导目标域 KDC 接受伪造的凭证。
2. 利用方法与工具蓝宝石票据的利用通常更为复杂，需要对 Kerberos 跨域认证机制有深入的理解。
前提条件：
攻击者通常需要控制一个与目标域存在信任关系的域。
获取信任密钥（或域控制器中的相关密钥信息）。
具备修改 Kerberos 票据的能力（类似钻石票据）。
生成伪造 TGT (跨域签名)：
这通常涉及到利用Rubeus或其他自定义工具，根据获取到的信任密钥和目标域信息，伪造一个针对目标域的 TGT。伪造的 TGT 会被目标域的 KDC 视为有效，因为它带着“正确”的信任签名。
详细的实现方式可能因具体的信任类型和攻击者的知识水平而异，且攻击的公开资料相对较少。
使用伪造票据：
将伪造的跨域 TGT 注入到会话中。
使用该 TGT 请求目标域的服务票据，从而访问目标域资源。
常见工具：
Rubeus：随着 Kerberos 攻击技术的发展，Rubeus持续更新以支持更复杂的票据伪造，未来可能会更直接地支持蓝宝石票据攻击。
自定义脚本/工具：由于蓝宝石票据是较新的概念，其攻击实现可能需要结合研究人员的自定义代码。
利用工具：https://github.com/ShutdownRepo/impacket/blob/sapphire-tickets/examples/ticketer.py
命令：python3 ./ticketer.py -request -impersonate 'administrator' -domain 'contoso.local' -user 'emp.1' -password '1234' -aesKey '0c83d045c7428f2fee556ba0bbdf0109b3e39d38104b415fd91def363910b4b2' -domain-sid 'S-1-5-21-877380313-3945528518-819751691' 'ignored'
执行后
export KRB5CCNAME=snapattcker.cache python3 psexec.py snapattack.labs/snapattack@arrakis.snapattack.labs cmd.exe -k debug -n
重新接管域控
3. 危害跨域控制：攻击者可以在不直接攻陷目标域的情况下，通过滥用信任关系，实现对目标域的控制。这对于拥有复杂域信任架构的大型企业来说是巨大的威胁。
极高的隐蔽性：攻击流量可能被视为正常的跨域认证流量，难以被传统检测手段发现。
绕过传统防御：针对单个域的krbtgt密码轮换等防御措施，可能无法完全阻止蓝宝石票据攻击，因为它利用的是域信任本身。
4. 防御手段由于蓝宝石票据利用的是域信任机制，其防御策略需要从全局视角出发：
最小化域信任：除非绝对必要，否则应避免建立不必要的域信任关系。对现有信任关系进行定期审查，确保它们仍然是必需的且配置正确。
强化信任域安全性：如果存在域信任，那么所有参与信任的域都必须被视为高风险目标。加强对所有信任域的域控制器的安全防护，包括krbtgt密码的轮换，以及其他账户的安全。
启用 Kerberos 信任路径验证：确保 Kerberos 策略中启用了信任路径验证。
持续监控域信任密钥：监控域控制器上与域信任相关的密钥和凭据的异常访问或泄露。
跨域事件日志关联分析：实施强大的 SIEM 解决方案，能够关联来自多个域控制器的 Kerberos 事件日志，识别异常的跨域认证模式和票据请求。
定期进行信任评估和红队演练：模拟蓝宝石票据攻击，评估现有信任关系的安全性和防御有效性。
限制域控制器间通信：实施网络分段和防火墙规则，限制域控制器之间不必要的通信，特别是与外部或不受信任域的通信。
总结Kerberos 凭证伪造攻击 (黄金票据、白银票据、钻石票据、蓝宝石票据) 本质都是利用域内或域间凭证滥用，核心是获得关键 Hash 与绕过 KDC 的合法性校验。这些手段对域管控威胁极大，且多数在事件日志中不易被察觉，因此对防御者提出了更高的挑战。
对防御者来说，深入理解 Kerberos 认证机制是至关重要的。除了技术防范，定期的安全审计和渗透模拟演练也必不可少。
防御重点：
定期轮换关键账户凭据：优先处理krbtgt账户和所有服务账户的密码，确保双次重置。
严格最小化委派和服务账户权限：授予账户最小必要权限，避免权限过度配置。
强化 Kerberos 策略：启用 Kerberos AES 加密和 PAC 签名验证。
使用 EDR 和 SIEM 实时监控凭证操作：部署能够检测内存中凭证窃取、票据伪造和异常票据使用的解决方案，并关联跨域事件。
最小化域信任和强化信任域安全性：减少不必要的域信任，并对所有信任域实施同样严格的安全措施。
定期进行渗透模拟演练：通过模拟真实的攻击场景，验证现有防御措施的有效性，并识别安全短板。
只有深入理解 Kerberos 认证机制，才能更好地在攻防中找到平衡，及时修复关键安全短板，提升 Windows 域环境的整体安全性。