域渗透-基于资源的约束委派利用
前言
打春秋云镜Certify
遇到的这个知识点 在这里记录一下 简称RBCD
(约束委派和非约束委派再新开一篇文章来写)
这里的话因为懒得搭建环境 就直接用别人的截图了
RBCD
基于资源的约束性委派:为了使⽤户/资源更加独⽴,微软在Windows Server 2012中引⼊了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置相关属性,⽽是将设置委派的权限交给了服务机器。服务机器在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity
属性,就可以进行基于资源的约束委派。
配置了基于资源的约束委派的账户的 msDS-AllowedToActOnBehalfOfOtherIdentity
属性的值为被允许基于资源约束性委派的账号的SID。如admin—pc的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为test的sid值(——这里就是说test这台计算机就对这个admin-pc这台计算机具有xxx权限 什么权限的话得看加域用户如何设置了——-)。2008 及以下的域控没有 msDS-AllowedToActOnBehalfOfOtherIdentity 这个属性,只有 Windows Server 2012 和 Windows Server 2012 R2 及以上的域控制器才有 msDS-AllowedToActOnBehalfOfOtherIdentity 这个属性
利用条件
简单来说就是你获得的用户对该主机的属性具有写权限,那么这个用户就可以对该主机进行攻击
(GenericAll GenericWrite WriteProperty WriteDacl) 具体来看就是这个权限 使用bloodhound
的时候有的话应该能看到
环境配置
域:test.local
域控为:dm2012.test.local,Windows Server 2012R2
目标主机:dm2008.test.local,windows Server 2008R2
用户:qiyou,对dm2008.test.local主机具有写权限
(这个用户就是加域用户了) 在添加新的计算机到该域中的时候就需要该用户的身份验证
其它域内主机:win10
验证qiyou这个用户对dm2008是否具有写权限,可以使用PowerView
枚举DM2008.test.local
的中的特定ACE
1 | Import-Module PowerView.ps1 //这个脚本github上就能找到 |
(这里的话用上面参考的CSDN文章给的AdFind.exe工具来判断也是可以的)
可以看到qiyou这个用户对dm2008这个计算机账户拥有完全控制权限(GenericAll),其实也不一定需要GenericAll
权限,GenericWrite
、WriteProperty
、WriteDacl
等等权限都是可以修改账户属性的。
我在本地拿之前配置好的环境试了一下也是差不多的
我们现在还需要的是一个具有SPN的账户,因为S4U2Self
只适用于具有SPN的账户,恰好的是在域中有一个属性MachineAccountQuota
,这个值表示的是允许用户在域中创建的计算机帐户数,默认为10,这意味着我们如果拥有一个普通的域用户那么我们就可以利用这个用户最多可以创建十个新的计算机帐户,而计算机账户默认是注册RestrictedKrbHost/domain
和HOST/domain
这两个SPN的,所以这里刚好符合我们的意图。
(这里不用本机用户的原因就是因为不知道机器的密码 所以就自己添加一个新的计算机到域里 并自己配置账号密码)
我们可以使用Kevin Robertson
的Powermad
中的New-MachineAccount
来创建一个用户名为evilsystem
,密码为evil
的计算机账户
1 | powershell |
可以看到成功创建一个计算机用户evilsystem
下面是修改DM2008的msDS-AllowedToActOnBehalfOfOtherIdentity
属性的值,有两种方法可以修改,Powerview
或者ActiveDirectory
模块
(就是修改该值为新加入的计算机的SID值)
这里演示还是使用PowerView.ps1
这个工具
配置evilsystem到DM2008的基于资源约束的委派
1 | $SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-662417213-3583657854-423750704-1115)" |
验证是否成功添加
1 | Get-DomainComputer DM2008 -Properties msds-allowedtoactonbehalfofotheridentity |
若想清除msds-allowedtoactonbehalfofotheridentity属性的值,可用如下命令:
1 | Set-DomainObject DM2008 -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose |
生成票据攻击
使⽤ impacket的 getST.py ⽣成票据(建议使⽤ socks5),会在当前⽬录下⽣administrator.ccache ⽂件:
1 | python getST.py -dc-ip 192.168.10.2 test.lab/test\$:123456 -spn cifs/ADMIN--PC.test.lab -impersonate administrator |
这里解释一下这个cifs是个啥东西4
(这里用的时CSDN上的一张图 不过都差不多)
如何使用mimikatz
注入内存就行
1 | mimikatz "kerberos::ptc administrator.ccache" |
导入票据之后 可以使用psexec对计算机进行远程命令执行了
解决敏感用户不可委派的问题
在域环境中,高权限用户如果没有特殊需求的情况下,考虑到安全性一般是设置为不可委派,或者是加入受保护组
下面我们把administrator设置成不可委派以及加入受保护组,如图
可以看到administrator是不可委派并且是受保护组的成员
这时候我们在通过s4u去申请一下票据,这个时候S4U2self
是成功的,但是S4U2proxy
是失败的、
1 | Rubeus.exe s4u /user:dm2008$ /rc4:b5cffac3d2bb5d5a7ded8ff2a70c29dc /impersonateuser:administrator /msdsspn:cifs/dm2008 /ptt |
也就是说账户不可委派以及受保护组的成员是不影响S4U2Self的,可以使用Rubeus describe
查看一下S4U2self返回的票据信息,可以看到该票据是没有服务名称的,并且不可转发(就是不可以执行ptt 不能注入到本地)
注: 如果该账户设置了TrustedToAuthForDelegation
为True,则S4U2Self生成的票据是可转发的,默认为False
那么我们使用下面的这两个命令来添加SPN就行了
1 | Rubeus.exe tgssub /ticket:test.kirbi /altservice:cifs/dm2008 /ptt |