不可转发约束委派提升域管理员权限技术解析

不可转发约束委派提升域管理员权限技术解析 约束委派简介 约束委派是Active Directory中的一种安全机制，允许某个服务账户（如 server1$ ）以其他用户的身份访问特定的服务（如 HTTP/dc01.corp.local ）。这种机制通过AD属性 msDS-AllowedToDelegateTo 来控制哪些服务可以被委派访问。 约束委派依赖于Kerberos协议的两个扩展： S4U2Self (Service for User to Self)：允许服务获取代表用户自身的服务票据 S4U2Proxy (Service for User to Proxy)：允许服务代表用户获取其他服务的票据 正常情况下，约束委派默认开启了 协议转换 (Protocol Transition)，当请求S4U2Self时，KDC会返回代表目标用户的票据。这个票据如果具有 forwardable 属性，就可以用于请求服务票据(ST)，这是常规约束委派攻击的基础。 不可转发约束委派的特殊性 本文讨论的是 不可转发约束委派 场景，即S4U2Self返回的票据 不 具有 forwardable 属性，这使得常规的约束委派攻击方法失效。 攻击前提条件 具有约束委派的用户必须是 机器账户 (如 delegator$ ) 该机器账户必须注册了自己的SPN（服务主体名称）(机器账户创建时默认会有SPN) 攻击原理与步骤 攻击思路 既然不可转发约束委派不允许我们直接委派任意用户，我们可以： 先通过其他方式"变成"目标用户 然后利用约束委派机制访问目标服务 详细攻击步骤 识别约束委派配置 确认 delegator$ 账户配置了约束委派 确认 delegator$ 注册了自己的SPN（如 browser/dc01.rebound.htb ） 配置基于资源的约束委派(RBCD) 修改 delegator$ 的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性 将 ldap_monitor 用户添加进去，使其能够代表任意用户请求 delegator$ 的服务 获取伪造的TGS 以 ldap_monitor 身份，代表 DC01$ 机器账户请求 delegator$ 的服务票据 这样获得的TGS没有经过S4U2Self流程，不受不可转发限制 利用约束委派访问目标服务 使用获得的TGS通过S4U2Proxy请求目标服务（如HTTP服务）的票据 最终获得以 DC01$ 身份访问目标服务的权限 执行DCSync攻击 利用获得的权限执行DCSync攻击，导出域内所有用户的哈希 关键问题解答 为什么必须是 delegator$ 注册的SPN？ TGS票据是针对特定服务SPN的 KDC在处理S4U2Proxy请求时会检查：TGS的服务是否等于 delegator$ 账号注册的服务 只有匹配的SPN才能被 delegator$ "合法代理" 为什么 ldap_monitor 能获取伪造票据？ 因为我们将 ldap_monitor 添加到了 delegator$ 的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中 这使得KDC允许 ldap_monitor 代表任意用户(如 DC01$ )请求 delegator$ 服务的票据 这是基于资源的约束委派(RBCD)的基本原理 为什么有了 browser 服务的票据后还需要HTTP服务？ 获得 browser 服务的票据只是中间跳板 必须通过 delegator$ 的约束委派配置，将这个伪造的身份票据转换为能访问目标服务(如HTTP)的ST 这样才能完成最终的权限提升 技术总结 这种攻击方法实际上是绕过了不可转发约束委派的限制： SS流程 (S4U2Self)：获取代表用户的TGS（受不可转发限制） SP流程 (S4U2Proxy)：使用TGS请求ST（需要可转发的TGS） 攻击通过构造RBCD环境，直接获取了一个可转发的TGS（绕过SS流程），然后利用SP流程完成攻击。