Kerberos 资源约束性委派误配置下的 S4U2self → S4U2proxy → DCSync 提权高阶手法链

目录

[🌌 Kerberos 资源委派误配置下的 S4U2self → S4U2proxy → DCSync 攻击链详解](#🌌 Kerberos 资源委派误配置下的 S4U2self → S4U2proxy → DCSync 攻击链详解)

[🔐 为什么能攻击域控制器？](#🔐 为什么能攻击域控制器？)

[🧩 攻击总体逻辑概览](#🧩 攻击总体逻辑概览)

[🚀 第一步：S4U2self ------ 伪装成域管理员](#🚀 第一步：S4U2self —— 伪装成域管理员)

[🔄 第二步：S4U2proxy ------ 以管理员身份访问域控制器服务](#🔄 第二步：S4U2proxy —— 以管理员身份访问域控制器服务)

[🧬 第三步：DCSync ------ 复制域控制器的账户哈希](#🧬 第三步：DCSync —— 复制域控制器的账户哈希)

[🏁 整体攻击链总结与防护建议](#🏁 整体攻击链总结与防护建议)

---

🌌 Kerberos 资源委派误配置下的 S4U2self → S4U2proxy → DCSync 攻击链详解

• 在 Active Directory 环境中，Kerberos 协议的委派机制本是为便利性设计的，但误配置可能导致严重安全隐患。

🔐 为什么能攻击域控制器？

Kerberos 的委派机制允许服务代表用户访问其他资源，这在企业环境中常见。但当资源-based 约束委派（RBCD）出现误配置时，攻击者可利用受控账户冒充任意用户，最终访问域控制器（DC）。

通俗解释：想象门禁系统，RBCD 误配置就像给一个"门卫"过度权限，让他能"声称"任何人已授权，从而打开所有门。

底层原理详解：

1. Kerberos 委派基础：Kerberos 使用票据（Ticket）验证身份，委派允许服务A代表用户U访问服务B，而不需U反复输入凭证。

2. RBCD 机制：不同于传统委派，RBCD 由资源拥有者（如服务B）指定谁可代表用户访问它。通过 msDS-AllowedToActOnBehalfOfOtherIdentity 属性配置。

3. 误配置风险：如果攻击者控制的账户被设置为"可代表任意用户访问特定服务"，KDC（密钥分发中心）会信任此声明，导致身份冒充。

案例解释：假设域中一台机器账户被误设为可代表任何人访问 LDAP 服务。攻击者控制此账户，即可伪装域管理员，进而提取敏感数据。

通讯流程图（文本模式）：

用户U → 服务A: 请求访问服务B
服务A → KDC: S4U 请求（代表U）
KDC → 服务A: 转发票据（如果委派允许）
服务A → 服务B: 使用票据访问（RBCD 检查 msDS 属性）

🧩 攻击总体逻辑概览

攻击链分为三个阶段，逻辑清晰：从冒充用户，到访问服务，再到数据提取。每个阶段依赖前一步的票据。

通俗解释：这像连锁反应------先偷钥匙（S4U2self），再开门（S4U2proxy），最后抢宝库（DCSync）。

底层原理详解：

1. 整体链条依赖：依赖 Kerberos 扩展协议（S4U），允许服务自我请求票据，而不需用户TGT（Ticket Granting Ticket）。

2. 权限绕过：RBCD 不验证用户真实意图，只检查配置属性，导致"信任链"断裂。

3. KDC 角色：KDC 作为信任锚点，但协议设计中不深度审计委派请求，仅验证签名和配置。

案例解释：在测试域中，攻击者用工具如 PowerView 设置 RBCD，然后用 Rubeus 执行链条，最终导出所有哈希。

通讯流程图（文本模式）：

攻击者 → KDC: S4U2self (冒充Admin)
KDC → 攻击者: Admin ST
攻击者 → KDC: S4U2proxy (访问LDAP)
KDC → 攻击者: LDAP ST
攻击者 → DC: DCSync (使用ST)
DC → 攻击者: 哈希数据

🚀 第一步：S4U2self ------ 伪装成域管理员

在 RBCD 误配置下，攻击者用控制账户向 KDC 请求代表管理员的票据。

通俗解释：这步像"自封皇帝"------攻击者说"我代表管理员"，KDC 信了，发票据。

底层原理详解：

1. S4U2self 协议：服务用自己的 TGT 请求代表用户的服务票据（ST），用于非交互场景。

2. RBCD 触发：KDC 检查 msDS-AllowedToActOnBehalfOfOtherIdentity，如果允许，则生成 forwardable ST。

3. 票据属性：返回的 ST 标为"forwardable"，但初始仅限本地服务使用。

4. 不验证用户：KDC 只验证请求者签名，不检查用户真实存在或意图。

案例解释 ：用 Rubeus 工具：rubeus.exe s4u /user:attacker_machine$ /impersonateuser:Administrator /msdsspn:HOST/dc.domain.com。结果获得 Admin ST。

通讯流程图（文本模式）：

攻击者 (控制账户) → KDC: S4U2self 请求 (代表Admin, 服务SPN)
KDC: 检查 RBCD 配置 → 验证签名
KDC → 攻击者: Admin 的 forwardable ST (限本地)

🔄 第二步：S4U2proxy ------ 以管理员身份访问域控制器服务

用上步 ST，向 KDC 请求访问 DC 上 LDAP 的新票据。

通俗解释：拿着"假皇帝诏书"，去要"进宫钥匙"------KDC 又信了。

底层原理详解：

1. S4U2proxy 扩展：用 S4U2self 的 ST 请求转发到其他服务，必须 ST 为 forwardable。

2. KDC 检查：验证原始 ST 的 PAC（Privilege Attribute Certificate），确认用户权限。

3. RBCD 作用：如果配置允许转发到目标 SPN（如 ldap/dc），生成新 ST。

4. 权限提升：新 ST 继承用户 SID 和组，允许管理员级访问。

案例解释 ：继续 Rubeus：rubeus.exe s4u /ticket:AdminST.kirbi /msdsspn:ldap/dc.domain.com /altservice:ldap。获得 LDAP ST，可用于目录操作。

通讯流程图（文本模式）：

攻击者 → KDC: S4U2proxy 请求 (用Admin ST, 目标 ldap/dc)
KDC: 验证 ST forwardable → 检查 RBCD
KDC → 攻击者: 新 LDAP ST (Admin 身份)
攻击者 → DC LDAP: 呈现 ST → 访问授权

🧬 第三步：DCSync ------ 复制域控制器的账户哈希

用 LDAP ST 执行目录复制，导出哈希。

通俗解释：用"宫钥匙"偷库房------模拟 DC 间同步，拿走所有密码。

底层原理详解：

1. DCSync 基础：基于 DRS（Directory Replication Service）接口，允许 DC 间复制对象。

2. 权限要求：需要"Replicating Directory Changes All"权限，通常域管理员才有。

3. LDAP 桥梁：用 ST 绑定 LDAP，调用 GetNCChanges 方法提取属性如 unicodePwd。

4. 哈希导出：包括 NTLM 哈希和 krbtgt，用于后续攻击如 Golden Ticket。

5. 不留痕迹：模拟合法复制，日志中难辨真伪。

案例解释 ：用 Mimikatz：lsadump::dcsync /domain:domain.com /user:krbtgt。导出 krbtgt 哈希，可伪造票据控制域。

通讯流程图（文本模式）：

攻击者 → DC LDAP: 绑定 (用LDAP ST)
攻击者 → DRS 接口: GetNCChanges 请求 (所有对象)
DC: 验证权限 → 打包数据
DC → 攻击者: 账户哈希 (NTLM, AES 等)

🏁 整体攻击链总结与防护建议

这条链利用 RBCD 误配置，实现从低权限到域接管的跃升。成果：伪造 Golden Ticket，完全控制域。

防护原理详解：

1. 审计 RBCD：定期检查 msDS 属性，避免过度委派。

2. 最小权限：仅授予必要账户委派权。

3. 监控工具：用 Sigma 规则检测 S4U 和 DCSync 日志。

4. 多因素：启用 MFA 降低初始 compromise 风险。

这玩意属于高阶渗透手法，要掌握的知识点角度，首当其中的就是Ｋｅｒｂｅｒｏｓ协议的理解哟