目录
接上回这里回顾一个知识点：TGS_REQ& TGS_REP
一、TGS_REQ& TGS_REP
在TGS_REQ & TGS_REP阶段，用户通过AS_REP拿到的TGT票据，去向KDC申请特定服务的访问权限，KDC校验TGT票据，如果校验通过的话，会向用户发送一个TGS票据，之后用户再拿着TGS去访问特定的服务。
TGS_REQ这个阶段不需要账号密码，需要AS_REP获取到的TGT凭据。这里面工具需要指定域控的地址。连接配置里面的其他信息都在凭据里面，这里可以不用指定。
1.TGS_REQ
1.1msg-type
类型，TGS_REQ对应的就是KRB_TGS_REQ(0x0c)
1.2PA-DATA
正常的TGS_REQ的请求需要用到有
-
AP_REQ：这个是TGS_REQ必须携带的部分，这部分会携带AS_REP里面获取到的TGT票据，就放在这个结构体里面。KDC校验TGT票据，如果票据正确，就返回TGS票据。
-
PA_FOR_USER：值是一个唯一的标识符，该标识符指示用户的身份。该唯一标识符由用户名和域名组成。
-
PA_PAC_OPTIONS
值是以下flag的组合
-- Claims(0)
-- Branch Aware(1)
-- Forward to Full DC(2)
-- Resource-based Constrained Delegation (3)
1.3REQ_BODY
-
sname
这个是要请求的服务，TGS_REP获得的ticket是用该服务用户的hash进行加密的。有个比较有意思的特性是，如果指定的服务是krbtgt，那么拿到的TGS票据是可以当做TGT票据用的。
-
AddtionTicket
附加票据，在S4U2proxy请求里面，既需要正常的TGT，也需要S4U2self阶段获取到的TGS，那么这个TGS就添加到AddtionTicket里面。
2.TGS_REP
2.1 msg-type
AS_REQ的响应body对应的就是KRB_TGS_REQ(0x0d)
2.2ticket
这个ticket用于AP_REQ的认证。其中里面的enc_part是加密的，用户不可读取里面的内容。在AS_REQ请求里面是，是使用krbtgt的hash进行加密的，而在TGS_REQ里面是使用要请求的服务的hash加密的。因此如果我们拥有服务的hash就可以自己制作一个ticket，既白银票据。正因为是使用要请求的服务的hash加密的，所以我们可以通过爆破enc_part获得该服务的hash。
2.3 enc_part
注意，这个enc_part不是ticket里面的enc_part，
这部分是可以解密的，key是上一轮AS_REP里面返回的session_key,也就是导入凭据里面的 session_key，解密后得到encryptionkey，encryptionkey这个结构里面最重要的字段也是session_key(但是这个session_key 不同于上一轮里面的session_key)，用来作为作为下阶段的认证密钥。
欧克，铺垫完了，那就来聊一下白银票据具体咋个弄！
白银票据 (Silver Tickets) 是指伪造的服务票据 (ST)，只能用来访问特定的服务，通过 Kerberos 的认证原理得知 ST 是由 TGS 颁发的，使用了服务的密码 hash 加密，所以在伪造银票的时候需要知道服务的密码 Hash。因为在票据生成过程中不需要使用 KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC 颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS 不会对该 TGT 的真伪进行效验。白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt 账号的密码哈希值，因此更加隐蔽。
二、创建白银票据
为了创建或伪造白银票据，攻击者必须获得目标服务账号的密码hash值。如果目标服务正在使用中的帐户（如MS SQL）下运行，则需要服务帐户密码哈希以创建银票。使用Kerberoast（https://github.com/nidem/kerberoast）破解服务帐户密码是识别目标服务相关密码数据的一种有效防范。计算机主机服务也是最常见的服务，它是利用Windows文件共享的“cifs”服务。由于计算机本身托管此服务，因此创建白银票据所需的密码数据是关联的计算机帐户的密码哈希值。当计算机加入Active Directory时，会创建一个新的计算机帐户对象并将其添加到计算机中。密码和相关的散列哈希存储在拥有该帐户的计算机上，并且将NTLM密码散列存储在域的域控制器上的Active Directory数据库中。如果攻击者可以获得对计算机的管理权限或者能够以本地系统的身份运行代码，则攻击者可以使用Mimikatz从系统中转储AD计算机帐户密码哈希（NTLM密码哈希用于加密RC4 Kerberos门票）：
Mimikatz白银票据票命令
/domain –完整的域名称
/sid –域的SID，如：S-1-5-21-1473643419-774954089-2222329127
/user – 域用户名
/ groups（可选） - 用户所属的组RID
/ ticket（可选） - 提供一个路径和名称，用于保存Golden Ticket文件以便日后使用，或者使用/ ptt立即将黄金票据插入到内存中以供使用
/ptt - 作为/ ticket的替代品，使用它来立即将伪造的票据插入到内存中以供使用。
/ id（可选） - 用户RID，Mimikatz默认值是500（默认管理员帐户RID）
/ startoffset（可选） - 票证可用时的起始偏移（如果使用此选项，通常设置为-10或0）Mimikatz默认值是0
/ endin（可选） - 票据有效时间，Mimikatz默认值是10年，Active Directory默认Kerberos策略设置为10小时
/ renewmax（可选） - 续订最长票据有效时间，Mimikatz默认值是10年，Active Directory默认Kerberos策略设置为最长为7天
1.信息收集
攻击者要利用白银票据进行票据传递攻击，需要掌握下面几个信息：
域名
域 SID
目标服务器的 FQDN
可利用的服务
服务账号的 NTLM Hash
要伪造的用户名
下面我们使用白银票据伪造 CIFS 服务权限，CIFS 服务通常用于 Windows 主机之间的文件共享。
1.1.获取域名
whoami
net time /domain
ipconfig /all
1.2.首先，登录域控，抓取机器账号的 Hash：
Mimikatz “privilege::debug” “sekurlsa::logonpasswords” exit #需要管理员权限
privilege::debug
sekurlsa::logonpasswords
1.3获取SID
whoami /all1.4目标机器的FQDN
net time /domain
就是hostname+域名 例如：/target:\\WIN-75NA0949GFB.NOONE.com1.5可利用的服务CIFS(磁盘共享的服务)
/service:CIFS 1.6要伪造的用户名
/user:Administrator2. Mimikatz命令创建白银票据
以下Mimikatz命令会在服务器上为CIFS服务创建白银票据。为了成功创建Silver Ticket，需要从AD域转储中或在本地系统上运行Mimikatz来获获取中AD计算机帐户密码哈希值。NTLM密码哈希与 rc4参数一起使用。服务SPN类型也需要在/ service参数中标识。目标计算机的FQDA需要在/ target参数中使用以及/ sid参数中的域SID。命令如下：
kerberos::golden /domain:域名 /sid:填sid /target:完整的域控名 /service:需要访问的服务 /rc4:服务账号NTMLHASH /user:用户名 /ptt
3、成功生成了伪造的白银票据，此时进行权限验证：
dir \\Bob.test.local\c$ // 机器名要全称，注意是全称
发现已经可以访问域控制器的共享目录了：
三、金票和银票的区别
获取的权限不同
金票：伪造的TGT，可以获取任意Kerberos的访问权限。
银票：伪造的ST，只能访问指定的服务，如文件服务器（CIFS）。
认证流程不同
金票：同KDC交互，但不同AS交互。
银票：不同KDC交互，直接访问Server。
加密方式不同
金票：由krbtgt NTLM Hash 加密。
银票：由服务账号 NTLM Hash 加密。
最后要讲的内容是微软为了访问控制而引进的一个扩展PAC
四、PAC 介绍
PAC (Privilege Attribute Certificate，特权属性证书)，其中所包含的是各种授权信息、附加凭据信息、配置文件和策略信息等。例如用户所属的用户组， 用户所具有的权限等。在最初的RFC1510中规定的标准Kerberos认证过程中并没有PAC，微软在自己的产品中所实现的Kerberos流程加入了PAC的概念，因为在域中不同权限的用户能够访问的资源是不同的，因此微软设计PAC用来辨别用户身份和权限。
在一个正常的Kerberos认证流程中
-
用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳，KDC使用用户hash进行解密，如果结果正确返回用krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含用户的sid，用户所在的组。
-
用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求，KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据，这也是kerberoating能利用的原因，任何一个用户，只要hash正确，可以请求域内任何一个服务的TGS票据。
-
用户拿着TGS票据去请求服务，服务使用自己的hash解密TGS票据。如果解密正确，就拿着PAC去KDC那边询问用户有没有访问权限，域控解密PAC。获取用户的sid，以及所在的组，再判断用户是否有访问服务的权限，有访问权限(有些服务并没有验证PAC这一步，这也是白银票据能成功的前提，因为就算拥有用户hash，可以制作TGS，也不能制作PAC，PAC当然也验证不成功，但是有些服务不去验证PAC，这是白银票据成功的前提）就允许用户访问。
特别说明的是，PAC对于用户和服务全程都是不可见的。只有KDC能制作和查看PAC。
KDC返回的TGT认购权证和ST服务票据中都是带有PAC的。这样做的好处就是在以后对资源的访问中， 服务端再接收到客户请求的时候不再需要借助KDC的帮助提供完整的授权信息来完成对用户权限的判断， 而只需要根据请求中所包含的PAC信息直接与本地资源的ACL相比较做出裁决。
PAC中是有两个签名的：PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM。一个是使用服务密钥(PAC_SERVER_CHECKSUM)进行签名，另一个使用KDC密钥(PAC_PRIVSVR_CHECKSUM)进行签名。当服务端收到客户端发来的AP-REQ消息时，只能校验PAC_SERVER_CHECKSUM签名，而并不能校验PAC_PRIVSVR_CHECKSUM签名。因此，正常来说如果需要校验PAC_PRIVSVR_CHECKSUM签名的话，服务端还需要将客户端发来的ST服务票据中的PAC签名发给KDC进行校验。
但是，由于大部分服务默认并没有KDC验证PAC这一步(需要将目标服务主机配置为验证KDC PAC签名，默认未开启)，因此服务端就无需将ST服务票据中的PAC签名发给KDC校验了。这也是白银票据攻击能成功的前提，因为如果配置了需要验证PAC_PRIVSVR_CHECKSUM签名的话，服务端会将这个PAC的数字签名以KRB_VERIFY_PAC的消息通过RPC协议发送给KDC，KDC再将验证这个PAC的数字签名的结果以RPC返回码的形式发送给服务端，服务端就可以根据这个返回结果判断PAC的真实性和有效性了。 因此如果目标服务主机配置了要校验PAC_PRIVSVR_CHECKSUM签名的话，就算攻击者拥有服务密钥，可以制作ST服务票据，也不能伪造KDC的PAC_PRIVSVR_CHECKSUM签名，自然就无法通过KDC的签名校验了。
那么为什么默认情况下，KDC都不会验证PAC的签名呢？
执行KDC验证PAC的话，意味着在响应时间和带宽使用方面的成本。它需要带宽使用来在应用服务器和KDC之间传输请求和响应。这可能会导致大容量应用程序服务器中出现一些性能问题。在这样的环境中，用户身份验证可能会导致额外的网络延迟和大量的流量。因此，默认情况下，KDC不验证PAC签名。
PAC在kerberos中的优缺点
那么PAC的存在究竟给我们的验证过程带来了哪些优点，亦或是缺点呢？
正如上面所提到的那样，PAC的引入其实带来了很多的优点。客户端在访问网络资源的时候服务端不再需要向KDC查询授权信息， 而是直接在本地进行PAC信息与ACL的比较。从而节约了网络资源。
但是，PAC的引入并不是百利而无一害的，PAC在用户的认证阶段引入会导致认证耗时过长。Windows Kerberos客户端会通过RPC调用KDC上的函数来验证PAC信息，这时候用户会观察到在服务器端与KDC之间的RPC包流量的增加。而另一方面， 由于PAC是微软特有的一个特性，所以启用了PAC的域中将不支持装有其他操作系统的服务器， 制约了域配置的灵活性。并且在2014年，由于PAC的安全性导致产生了一个域内极其严重的提权漏洞MS14-068(在后面的文章中我们会介绍这个漏洞)。
在AS-REQ请求阶段，是用用户密码Hash或AES Key加密的时间戳。因此当只获得了用户密码Hash时，也可以发起AS-REQ请求，所以也就造成了PTH哈希传递攻击；当只获得用户密码的AES Key时，也可以发起AS-REQ请求，所以也就造成了PTK密钥传递攻击。
而 AS-REQ 请求包中 cname 字段的值代表用户名，这个值存在和不存在，返回的包有差异，所以可以用于枚举域内用户名，这种攻击方式被称为 域内用户枚举攻击 (当未获取到有效域用户权限时，可以使用这个方法枚举域内用户)。并且当用户名存在，密码正确和密码错误时，返回的包也不一样，所以可以进行用户名密码爆破。但是在实战中，渗透测试人员通常都会使用一种被称为 密码喷洒（Password Spraying）的攻击方式来进行测试和攻击。对密码进行喷洒式的攻击，这个叫法很形象，因为它属于自动化密码猜测的一种。这种针对所有用户的自动密码喷洒通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒是用固定的密码去跑所有的用户名。
在 AS-REP 阶段，由于返回的 TGT 认购权证是由 krbtgt 用户的密码Hash加密的，因此如果我们拥有 krbtgt 的密码 hash 就可以自己制作一个TGT认购权证，这种攻击方式被称为黄金票据攻击。同样，在TGS-REP阶段，TGS_REP里面的ST服务票据是使用服务的hash进行加密的，如果我们拥有服务的hash，就可以签发任意用户的ST服务票据，这个票据也被称为白银票据，这种攻击方式被称为白银票据攻击。相较于黄金票据，白银票据使用要访问服务的hash，而不是krbtgt的hash。
在AS-REP阶段，Login session key是用用户密码 Hash 加密的。对于域用户，如果设置了“Do not require Kerberos preauthentication”不需要预认证选项，此时攻击者向域控制器的 88 端口发送 AS_REQ 请求，此时域控不会做任何验证就将 TGT认购权证 和 该用户Hash加密的Login Session Key返回。因此，攻击者就可以对获取到的 用户Hash加密的Login Session Key进行离线破解，如果破解成功，就能得到该用户的密码明文，这种攻击方式被称为 AS-REP Roasting攻击。
在TGS-REP阶段，由于ST服务票据是用服务Hash加密的。因此，如果我们能获取到ST服务票据，就可以对该ST服务票据进行利息破解，得到服务的Hash，这种攻击方式被称为Kerberoasting攻击。这个问题存在的另外一个因素是因为用户向KDC发起TGS_REQ请求，不管用户对服务有没有访问权限，只要TGT认购权证正确，那么KDC都会返回ST服务票据。其实AS_REQ里面的服务就是krbtgt，也就是说这个攻击方式同样可以用于爆破AS_REP里面的TGT认购权证，但是之所以没见到这种攻击方式是因为krbtgt的密码是随机生成的，爆破不出来。
参考文章
881
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
