在之前的约束委派文章中提到,如果配置受约束的委派,必须拥有SeEnableDelegation特权,该特权是敏感的,通常仅授予域管理员。为了使用户/资源更加独立,Windows Server 2012中引入了基于资源的约束委派。基于资源的约束委派允许资源配置受信任的帐户委派给他们。
基于资源的约束委派和传统的约束委派非常相似,但是作用的方向实际上是相反的。引用《Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory》文中的图解。
传统的约束委派:在ServiceA的msDS-AllowedToActOnBehalfOfOtherIdentity属性中配置了对ServiceB的信任关系,定义了到ServiceB的传出委派信任。
资源约束委派:在ServiceB的msDS-AllowedToActOnBehalfOfOtherIdentity属性中配置了对ServiceA的信任关系,定义了从ServiceA的传入信任关系。
而重要的一点在于,资源本身可以为自己配置资源委派信任关系,资源本身决定可以信任谁,该信任谁。
在那篇文章中给出了一种利用环境。
在域中有一个属性MachineAccountQuota,这个值表示的是允许域用户在域中创建的计算机帐户数,默认为10,这意味着我们如果拥有一个普通的域用户那么我们就可以利用这个用户最多可以创建十个新的计算机帐户,而计算机账户默认是注册RestrictedKrbHost/domain和HOST/domain这两个SPN的,所以第一个条件就满足了。
但当我们只是一个普通的域用户时,并没有权限(如GenericAll、GenericWrite、WriteDacl等)为服务修改msDS-AllowedToActOnBehalf OfOtherIdentity属性,不满足第二个条件。所以这里一般用的是中继,通过中继机器账户来修改该机器账户自身的msDS-AllowedToActOnBehalf属性。
ateam的《这是一篇“不一样”的真实渗透测试案例分析文章》中对于基于资源的约束委派利用中,非常经典。
webdav$
账户到手。evilpc$
evilpc$
到webdav$
的资源约束委派请求,就有了webdav$的tgs。webdav$
本地没环境,有机会再补上。
感谢daiker师傅的一顿指点。这个东西写了很长一段时间,写完了还不是很明白,只是明白了ateam的那种利用场景,没参透有无别的场景,自己以后有空回过头来再看一下吧。
文笔垃圾,措辞轻浮,内容浅显,操作生疏。不足之处欢迎大师傅们指点和纠正,感激不尽。