文章总结： 本文系统解析了AD渗透中三种Kerberos委派攻击机制：非约束委派允许服务缓存用户TGT导致权限提升风险；传统约束委派通过msDS-AllowedToDelegateTo限制委派范围但仍有模拟用户风险；基于资源的约束委派RBCD通过目标资源对象的msDS-AllowedToActOnBehalfOfOtherIdentity属性配置反向信任关系。文档详细分析了各类委派的攻击链、发现方法和利用条件，并提供了防御建议包括限制机器账号创建、审计ACL权限和监控委派配置变更。 综合评分： 85 文章分类： 渗透测试,内网渗透,红队

---

AD 渗透中的委派攻击：从 Kerberos 到 RBCD 的完整理解

网安布道师 网安布道师

六边形攻防安全

2026年6月26日 08:05 河北

在小说阅读器读本章

去阅读

Kerberos 委派攻击总览

在 AD 渗透里，委派攻击是非常重要的一类提权方式。很多域内提权路径，表面上看是“拿票”“模拟用户”“机器账号提权”，本质上都绕不开 Kerberos 委派机制。

常见委派类型主要有三种：

非约束委派约束委派基于资源的约束委派，也就是 RBCD

这三类委派的共同点是：

允许一个服务代表用户访问另一个服务

区别在于：谁来决定信任关系、票据如何流转、攻击者需要控制什么。

先理解什么是委派

委派的业务场景很好理解。

假设用户访问一个 Web 服务：

User -> Web Server

Web 服务又需要代表这个用户去访问数据库：

Web Server -> SQL Server

这时 Web 服务就需要“代表用户”访问后端服务。这就是委派。

在 Kerberos 语境下，可以理解为：

某个服务拿着用户身份，向 KDC 请求访问另一个服务的服务票据

如果配置不当，这个“代表用户访问服务”的能力就会变成攻击者的提权入口。

Kerberos 里几个关键概念

理解委派攻击前，需要先记住几个 Kerberos 术语。

TGT：

Ticket Granting Ticket

用户认证成功后从 KDC 拿到的票据，用来继续申请服务票据。

TGS：

Ticket Granting Service Ticket

访问具体服务时使用的票据，例如：

cifs/DC01.domain.localldap/DC01.domain.localhttp/web01.domain.local

SPN：

Service Principal Name

服务主体名称，用来标识一个服务。例如：

cifs/RESOURCEDC.resourced.localldap/RESOURCEDC.resourced.local

S4U：

Service for User

委派攻击里最关键的机制，常见分为：

S4U2SelfS4U2Proxy

S4U2Self 的含义是：

服务为某个用户向自己申请票据

S4U2Proxy 的含义是：

服务拿着前一步票据，再代表用户去申请访问另一个服务的票据

一、非约束委派

非约束委派示意图

非约束委派英文是：

Unconstrained Delegation

这是最早、也最危险的一类委派。

当一台服务器或服务账号被配置为非约束委派时，用户访问它时，用户的 TGT 可能会被转发到这台服务器上。

也就是说，如果攻击者控制了这台服务器，就可能拿到访问者的 TGT。

攻击链可以理解为：

某服务器开启非约束委派-> 高权限用户访问该服务器-> 服务器缓存高权限用户 TGT-> 攻击者从内存中提取 TGT-> 使用该 TGT 访问域内其它服务

典型风险是：

如果域管理员访问了被攻陷的非约束委派服务器攻击者可能直接得到域管理员 TGT

如何发现非约束委派

LDAP 查询中可以关注 userAccountControl 标志：

TRUSTED_FOR_DELEGATION

PowerView 示例：

Get-DomainComputer -UnconstrainedGet-DomainUser -TrustedToAuth

BloodHound 中可以关注：

Unconstrained Delegation

NetExec 示例：

nxc ldap 192.168.147.175 \  -d resourced.local \  -u L.Livingstone \  -H 19a3a7550ce8c505c2d46b5e39d6f808 \  --trusted-for-delegation

非约束委派的利用思路

攻击者需要控制开启非约束委派的主机，然后等待或诱导高权限用户访问该主机。

常见方式包括：

监听并提取票据诱导认证结合打印机相关强制认证技术

一旦拿到高权限用户 TGT，就可以导入票据并访问域控服务。

二、传统约束委派

传统约束委派示意图

传统约束委派英文是：

Constrained Delegation

它比非约束委派更安全一些，因为它限制了服务账号只能委派到指定服务。

例如：

WEB01$ 可以代表用户访问 MSSQL/db01.domain.local

这里的配置写在发起委派的账号上，也就是 WEB01$。

核心属性是：

msDS-AllowedToDelegateTo

它表示该账号可以委派到哪些 SPN。

传统约束委派的逻辑是：

谁可以代表用户出去访问别人

约束委派的两种形态

传统约束委派又可以分为两类：

仅使用 Kerberos使用任何认证协议

如果启用了：

TrustedToAuthForDelegation

也就是协议转换，那么服务可以使用 S4U2Self 为任意用户申请到自己的票据，再通过 S4U2Proxy 申请访问后端服务的票据。

这对攻击者很关键。

如果攻击者控制了这个服务账号，就可以尝试模拟任意用户访问配置允许的目标服务。

如何发现传统约束委派

PowerView：

Get-DomainUser -TrustedToAuthGet-DomainComputer -TrustedToAuthGet-DomainObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' -Properties msDS-AllowedToDelegateTo

LDAP 查询重点看：

msDS-AllowedToDelegateTouserAccountControl

BloodHound 中可以关注：

AllowedToDelegateConstrained Delegation

传统约束委派的攻击面

传统约束委派的核心风险在于：

如果攻击者控制了被配置委派的服务账号就可能模拟用户访问配置允许的后端服务

它的限制也很明显：攻击者通常只能访问 msDS-AllowedToDelegateTo 中指定的 SPN。也就是说，约束委派不是“拿到账号就全域横着走”，而是要看这个账号被允许委派到哪里。

因此分析传统约束委派时，重点不是只看“有没有委派”，而是看：

被委派账号是谁是否可被攻击者控制允许委派到哪些 SPN这些 SPN 是否对应高价值服务

三、基于资源的约束委派 RBCD

RBCD 基于资源的约束委派示意图

RBCD 全称是：

Resource-Based Constrained Delegation

中文一般叫：

基于资源的约束委派

RBCD 和传统约束委派最大的区别是配置方向反过来了。

传统约束委派是：

A 配置自己可以委派到 B配置点在 A 上

RBCD 是：

B 配置自己允许 A 委派到我配置点在 B 上

也就是说，RBCD 的信任关系写在目标资源对象上。

核心属性是：

msDS-AllowedToActOnBehalfOfOtherIdentity

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

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

RBCD 为什么常见

RBCD 在靶场和真实环境中都很常见，因为它经常和两个问题组合出现：

普通域用户可以创建机器账号目标机器对象 ACL 配置过宽

普通域用户是否能创建机器账号，通常由：

SeMachineAccountPrivilegems-DS-MachineAccountQuota

决定。

如果当前用户可以创建机器账号，例如：

ATTACK$

并且当前用户对目标机器对象有：

GenericAllGenericWriteWriteDACLWriteOwnerAddAllowedToAct

那么就可以考虑 RBCD。

RBCD 利用条件

可以总结为三句话：

1. 我有一个可控机器账号2. 我能写目标机器对象的 RBCD 属性3. 我能用可控机器账号完成 S4U 请求

常见路径如下：

低权限域用户-> 创建 ATTACK$ 机器账号-> 修改目标机器 RESOURCEDC$ 的 RBCD 属性-> 允许 ATTACK$ 代表用户访问 RESOURCEDC$-> 使用 ATTACK$ 模拟 Administrator 请求服务票据-> 使用服务票据访问目标机器

RBCD 背后的 Kerberos 流程

RBCD 看起来像是“写一个属性，然后拿高权限票据”，实际中间仍然是 S4U 流程。

第一步是 S4U2Self：

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

第二步是 S4U2Proxy：

ATTACK$ 拿上一步票据，向KDC请求“Administrator 到 cifs/ResourceDC.resourced.local”的服务票据

KDC 会检查目标资源 RESOURCEDC$ 的：

msDS-AllowedToActOnBehalfOfOtherIdentity

如果其中包含 ATTACK$，就允许这次代理请求。

最终攻击者拿到的是：

Administrator -> cifs/ResourceDC.resourced.local

的服务票据。

这里先点到为止。RBCD 的具体利用技巧，包括机器账号创建、属性写入、票据申请、常见报错和清理动作，后面单独展开成一篇实战文章。

三种委派攻击对比

可以用一张表来记：

| 类型 | 配置位置 | 攻击者需要什么 | 典型结果 | | — | — | — | — | | 非约束委派 | 被委派服务器或账号 | 控制该服务器，等待高权限用户访问 | 提取用户 TGT | | 传统约束委派 | 发起委派的账号 | 控制该服务账号 | 模拟用户访问指定 SPN | | RBCD | 目标资源对象 | 能写目标对象 RBCD 属性，有可控机器账号 | 模拟用户访问目标资源 |

简单记忆：

非约束委派：别人带着 TGT 来找我传统约束委派：我被允许去访问指定服务RBCD：目标服务允许我代表用户访问它

防御建议

委派攻击的防御重点不是只看某一个工具告警，而是要系统性审计委派配置和 AD 对象 ACL。

建议关注：

1. 禁止普通用户随意创建机器账号2. 审计高价值机器对象的 GenericAll / GenericWrite / WriteDACL / WriteOwner3. 监控 msDS-AllowedToActOnBehalfOfOtherIdentity 变更4. 监控 msDS-AllowedToDelegateTo 配置5. 减少或禁用非约束委派6. 高权限账号设置 Account is sensitive and cannot be delegated7. 定期使用 BloodHound 检查委派路径

可以将：

ms-DS-MachineAccountQuota

调整为：

0

或根据业务需要设置更小的值。

对域控、关键服务器、核心服务账号，应重点审计以下权限：

GenericAllGenericWriteWriteDACLWriteOwnerAddAllowedToActAllowedToDelegate

总结

AD 委派攻击的核心不是某个单独命令，而是 Kerberos 中“代表用户访问服务”的信任模型。

非约束委派关注：

谁能缓存用户 TGT

传统约束委派关注：

谁被允许委派到哪些服务

RBCD 关注：

目标资源允许谁代表用户访问自己

在渗透测试中，看到下面任意组合都要敏感：

SeMachineAccountPrivilegems-DS-MachineAccountQuota > 0GenericAll / GenericWrite 到机器对象WriteDACL / WriteOwner 到机器对象msDS-AllowedToActOnBehalfOfOtherIdentity 已有值msDS-AllowedToDelegateTo 已有高价值 SPN

如果能把这些点串起来，就能从一个普通域用户，沿着 Kerberos 委派机制完成到高权限服务票据的转换。

下一篇我们聊聊AD 委派攻击之约束委派，敬请期待～

---

免责声明：

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

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

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

本文转载自：六边形攻防安全 网安布道师 网安布道师《AD 渗透中的委派攻击：从 Kerberos 到 RBCD 的完整理解》