回顾：Silver Ticket与Golden Ticket

在介绍Diamond Ticket和Sapphire Ticket之前，我们需要先了解Silver Ticket和Golden Ticket的基本原理。这两种经典的Kerberos攻击手法为后续新型攻击奠定了基础，理解其机制和限制有助于更好地掌握Diamond Ticket和Sapphire Ticket的创新点。

Silver Ticket

Silver Ticket是一种伪造的服务票据（TGS，Ticket Granting Service）攻击手法。攻击者通过获取目标机器账户的密钥（machine account key），可以伪造任意用户对该机器上特定服务的TGS票据。Silver Ticket的主要用途包括：

• 横向移动：通过伪造的TGS票据，访问目标机器上的服务（如CIFS、RDP等）。
• 权限提升：在某些场景下，通过服务权限的滥用实现提权。

限制：

• Silver Ticket的适用范围受限于单一服务或单一机器。例如，攻击者只能伪造针对特定服务（如CIFS）的票据，或针对某台机器上的所有服务。
• 由于TGS票据是伪造的，Kerberos验证流程中不会生成对应的KRB_TGS_REQ请求日志，容易被安全监控工具检测到异常。

Golden Ticket

Golden Ticket是一种伪造的票据授予票据（TGT，Ticket Granting Ticket）攻击手法。攻击者需要获取域控制器（DC）的krbtgt账户密钥，通过该密钥伪造任意用户的TGT。Golden Ticket的强大之处在于：

• 全域权限：攻击者可以冒充任何用户访问域内任意服务。
• 持久化：由于TGT有效期较长（通常为10小时，可通过参数延长），Golden Ticket常用于域内权限维持。
• 跨域信任：在父子域信任（Parent-Child Trust）场景下，Golden Ticket可用于跨域横向移动。

限制：

• 获取krbtgt key的难度较高，通常需要域管理员权限或通过DCSync等攻击手段提取。
• 伪造的TGT不会产生对应的KRB_AS_REQ请求日志，且票据中的PAC（Privilege Attribute Certificate）可能与真实PAC不一致，增加被检测的风险。

检测风险

Silver Ticket和Golden Ticket的共同问题在于，它们通过完全伪造票据绕过Kerberos的正常请求流程（KRB_AS_REQ或KRB_TGS_REQ）。这导致在域控制器日志（如事件ID 4768、4769）中缺乏对应请求记录，安全监控工具（如SIEM或EDR）可以通过分析缺失的请求或异常的PAC内容检测到攻击行为。

---

Diamond Ticket：隐秘的TGT攻击

简介与优势

Diamond Ticket是一种于2022年7月前后提出的新型Kerberos攻击手法，其核心目标与Golden Ticket相同：以任意用户身份访问域内任意服务。然而，Diamond Ticket在操作安全性（OPSEC）方面显著优于Golden Ticket，主要体现在以下几点：

1. 合法TGT请求：Diamond Ticket通过向域控制器正式请求TGT（KRB_AS_REQ），而不是直接伪造TGT，从而在日志中生成合法的请求记录，降低被检测的概率。
2. PAC修改：Diamond Ticket通过解密TGT中的PAC，修改其中的权限信息（如添加特权组），然后重新签名和加密，确保票据的完整性。
3. 隐秘性：由于TGT请求流程符合Kerberos协议，检测工具难以通过日志直接识别异常。

与Golden Ticket相比，Diamond Ticket的PAC虽然经过修改，但基于合法TGT生成，格式和签名更接近真实票据，减少了因PAC异常被检测的风险。

攻击原理

Diamond Ticket的实现流程如下：

1. 请求合法TGT：攻击者使用合法用户凭据（用户名和密码，或NTLM/AES密钥）向域控制器发起KRB_AS_REQ请求，获取真实的TGT。
2. 解密TGT：利用krbtgt账户的AES256密钥解密TGT，提取其中的PAC。
3. 修改PAC：编辑PAC内容，例如添加高权限组（如Domain Admins）或修改用户RID。
4. 重新签名和加密：使用krbtgt密钥重新计算PAC的签名，并对修改后的TGT进行加密。
5. 使用票据：将生成的Diamond Ticket注入环境（如通过Mimikatz或Rubeus），冒充目标用户访问域内服务。

由于整个过程包含合法的KRB_AS_REQ请求，域控制器的日志中会记录正常的TGT请求事件（事件ID 4768），显著提高了攻击的隐秘性。

攻击命令

Diamond Ticket的实现通常依赖工具如Rubeus，以下是一个典型命令示例：

Rubeus.exe diamond /domain:contoso.com /user:user1 /password:Passw0rd /dc:dc1.contoso.com /enctype:AES256 /krbkey:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef /ticketuser:admin /ticketuserid:500 /groups:512,519

参数说明：

• /domain：目标域的FQDN（如contoso.com）。
• /user 和 /password：用于请求合法TGT的普通用户凭据。
• /dc：域控制器的地址。
• /enctype：加密类型，强制要求AES256（因krbtgt密钥通常为此类型）。
• /krbkey：krbtgt账户的AES256密钥（通过DCSync等手段获取）。
• /ticketuser：目标伪造用户（如admin）。
• /ticketuserid：目标用户的RID（如500表示管理员）。
• /groups：目标用户所属的组ID（如512为Domain Admins，519为Enterprise Admins）。

执行输出示例：

运行上述命令后，Rubeus会输出类似以下信息：

[*] Action: Diamond Ticket
[*] No target SPN specified, attempting to build 'cifs/dc1.contoso.com'
[*] Initializing Kerberos GSS-API w/ fake delegation for target 'cifs/dc1.contoso.com'
[+] Kerberos GSS-API initialization success!
[+] Delegation request success! AP-REQ delegation ticket is now in GSS-API output.
[*] Found the AP-REQ delegation ticket in the GSS-API output.
[*] Authenticator etype: aes256_cts_hmac_sha1
[*] Extracted the service ticket session key from the ticket cache: +mzV4aOvQx3/dpZGBaVEhccq1t+jhKi8oeCYXkjHXw4=
[+] Successfully decrypted the authenticator
[*] Decrypting TGT
[*] Retrieving PAC
[*] Modifying PAC
[*] Signing PAC
[*] Encrypting Modified TGT
[*] base64(ticket.kirbi): doIFgz [...snip...] MuSU8=

从输出中可以看到，Rubeus首先请求合法TGT，然后解密、修改PAC、重新签名并加密，最终生成可用的Diamond Ticket（以.kirbi文件形式保存）。攻击者可通过mimikatz kerberos::ptt或Rubeus的ptt功能将票据注入当前会话，用于后续访问。

优势与局限

优势：

• 合法的KRB_AS_REQ请求使日志记录更自然，难以被检测。
• 修改后的PAC基于真实TGT生成，格式规范，降低异常检测风险。
• 可冒充任意用户访问域内任意服务，功能与Golden Ticket相当。

局限：

• 仍需获取krbtgt AES256密钥，这要求较高的初始权限。
• 修改PAC可能导致与AD中用户实际组信息不一致，高级检测系统可能通过比对发现异常。

---

Sapphire Ticket：更进一步的隐秘性

简介与优势

Sapphire Ticket是2022年9月底披露的最新Kerberos攻击手法（参考@_nwodtuhs的推文）。它在Diamond Ticket的基础上进一步优化了隐秘性，核心区别在于PAC的获取与替换方式。

与Diamond Ticket的区别

• Diamond Ticket：通过直接修改合法TGT的PAC，添加特权组（如Domain Admins）或伪造组信息。这种方式可能导致PAC中的组信息与AD实际用户组不一致。例如，若普通用户userA的PAC被修改为包含Domain Admins组，检测工具可通过查询AD验证userA是否真正属于该组，从而发现异常。
• Sapphire Ticket：通过S4U2self和U2U（User-to-User）协议扩展，获取高权限用户的真实PAC，并将其完整替换到目标TGT中。由于替换的PAC来自合法高权限用户（如域管理员），检测工具在验证PAC中的组信息时会认为其合法，从而极大降低被发现的概率。

为什么更隐秘？

Sapphire Ticket的核心优势在于，其PAC直接来源于高权限用户的合法TGT，包含真实的组信息和签名。检测系统在比对PAC与AD记录时，无法发现不一致之处。这种方法利用了Kerberos协议的S4U2self机制（允许服务为用户请求票据）和U2U扩展（允许用户请求其他用户的票据），通过合法流程获取高权限PAC，绕过了直接伪造的痕迹。

攻击原理

Sapphire Ticket的实现流程如下：

1. 获取普通用户TGT：使用普通用户凭据通过KRB_AS_REQ请求合法TGT。
2. 利用S4U2self获取高权限PAC：通过S4U2self协议，以普通用户身份请求高权限用户（如域管理员）的TGT，获取其PAC。
3. 替换PAC：将普通用户TGT中的PAC替换为高权限用户的PAC。
4. 重新签名和加密：使用krbtgt密钥对修改后的TGT重新签名和加密。
5. 使用票据：将生成的Sapphire Ticket注入环境，冒充高权限用户访问域内服务。

由于S4U2self和U2U是Kerberos协议的合法扩展，相关请求会生成正常的日志记录（如事件ID 4768、4769），进一步提升了攻击的隐秘性。

攻击命令

Sapphire Ticket的实现目前主要依赖UNIX-based工具Impacket的ticketer.py模块，Windows环境下尚未有成熟工具支持。以下是一个典型命令示例：

ticketer.py -request -impersonate 'domainadmin' -domain 'contoso.com' -user 'user1' -password 'Passw0rd' -aesKey '1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef' -domain-sid 'S-1-5-21-3623811015-3361044348-30300820' 'baduser'

参数说明：

• -request：触发TGT请求。
• -impersonate：目标伪造的高权限用户（如domainadmin）。
• -domain：目标域的FQDN。
• -user 和 -password：普通用户凭据，用于发起S4U2self请求。
• -aesKey：krbtgt账户的AES256密钥。
• -domain-sid：域的SID，用于构造票据。
• baduser：最终伪造的用户名。

优势与局限

优势：

• 使用高权限用户的真实PAC，检测工具难以发现异常。
• 结合S4U2self和U2U的合法请求流程，日志记录自然，隐秘性极高。
• 与Diamond Ticket类似，可冒充任意用户访问域内任意服务。

局限：

• 需获取krbtgt AES256密钥，权限要求较高。
• S4U2self和U2U协议的实现较复杂，当前仅限于UNIX环境（如Impacket），Windows工具支持尚不完善。
• 对域环境中S4U2self配置（如是否启用）有一定依赖。

---

总结

Diamond Ticket和Sapphire Ticket作为Golden Ticket的改进版本，通过合法TGT请求和PAC替换技术显著提升了攻击的隐秘性。Diamond Ticket通过修改PAC实现权限提升，而Sapphire Ticket利用S4U2self和U2U获取高权限PAC，进一步降低了检测风险。两者均需krbtgt密钥，适合高权限场景下的持久化或横向移动。