Windows 域环境下的本地提权系列研究(终)
前言
经过两篇系列文章的铺垫，终于来到了Windows 域环境下的本地提权系列研究的最终篇，在本文中通过对域内提权可能遇到的多种环境进行了分析并最终完成自动化提权。
研究背景
随着攻防演练的白热化，攻防双方能力大幅提升。强悍的防守方在流量、应用、系统、网络各层面重重布防，稍有风吹草动就能快速检测并响应，这对攻击方提出了更高的要求。一个很直接的问题是，攻击方如何在拿到权限后快速完成提权，以方便稳定的权限维持？作为自动化本地提权方案的一部分，本文将介绍该方案中的域环境提权内容。
从 RBCD 说起
早在 2019 年，Elad Shamir 发布了关于 RBCD（基于资源的约束委派） 滥用的研究：微软通过基于资源的约束委派，将委派的设置权限下放至资源所有者，即资源所有者可以主动配置哪些服务能够委派至该资源。这意味着委派不再是域管的特权，任何人都可以设置自己的 RBCD 属性，也就为 RBCD 滥用提供了可能。
具体来讲，资源所有者可以将资源的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性设置为另一个可控的机器账户（通常为主动添加，默认 ms-DS-MachineAccountQuota 10），然后携带可控机器账户 TGT 发起 S4U2proxy 请求完成委派，获取仅限该资源范围内的域管 ST。通过 RBCD 滥用，可以很好的实现域环境下的本地提权，比如钓鱼拿下一台域机器，当前权限为域用户，且该域用户正好是当前域机器的 mS-DS-CreatorSID，即可配置域机器的 RBCD 完成提权。
但有时会遇到当前域用户并非当前域机器的 Creator 的情况，此时域用户没有权限设置域机器的 RBCD。好在除了 Creator 外，域机器账户本身也可以设置自身的 RBCD。回到钓鱼场景，当前权限为域用户，如何在域用户权限下以域机器账户身份去设置 RBCD 成为问题的关键。
通过中继实现域机器身份窃取
通过 NTLM Relay[1] 可以实现上述目的：攻击者手动设置账户头像路径，将其指向 NTML 中继服务端，这会触发 WebDAV 客户端连接 UNC 路径，迫使系统以 SYSTEM 身份访问中继服务端。此时，在网络上的身份就是域机器身份。
之后，中继服务端将域机器身份中继至 Ldap，修改该域机器 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，下一步完成提权。
更方便的触发中继
但上述方法几乎无法在实战中用于本地提权，试问攻击者如何在仅有域用户 Beacon 的情况下，通过 GUI 完成设置头像的操作。因此，需要另外寻找其他可编程的 Relay 方法，Google P0 的 James Forshaw 提出可以通过 Kerberos Relay 完成域机器身份窃取。
Kerberos Relay 曾被认为是无法实现的。NTLM Relay 之所以可以被轻松滥用，一大原因是 NTLM 并不认证服务端，中间人可以将凭据转发至任意服务端完成中继。而 Kerberos 通过 SPN 指定服务，且 SPN 由会话密钥加密，中间人无法篡改 SPN，导致"无法中继"。事实上，攻击者的确很难在认证过程中篡改 SPN，但如果攻击者能够控制客户端在认证开始前将请求的 SPN 设置为将要中继的服务、而连接的地址仍是恶意服务器，通过这种方式从源头修改 SPN，则仍然可以实现 Kerberos Relay。James Forshaw 在 文中[2] 详细介绍了利用 DCOM 协议指定任意 SPN 完成 Kerberos Relay 的实验。
应用于本地提权场景，DCOM Kerberos Relay 还需克服许多难题：1. 如何将 Oxid 解析器监听在本地并欺骗防火墙"开放"端口；2. 并非所有 DCOM 都能中继回本地，需要选择 AuthnLevel 大于等于 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY；3. DCOM 的 ImpLevel 为 RPC_C_IMP_LEVEL_IDENTIFY 时，只能创建 SecurityIdentification 级别 Token，无法用于资源访问。所幸中继至 Ldap 只需进行访问检查，无需打开资源。当然，可以寻找 ImpLevel 为 RPC_C_IMP_LEVEL_IMPERSONATE 且 AuthnLevel 大于等于 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY 的 DCOM，此时可以中继至本地 SMB，直接创建服务提权。更多细节，建议阅读原文。
至于中继的利用，与 Rotten Potato 一样，不是将凭据中继至 ntlmrelayx.py 等服务端，而是直接在本地 Hook SSPI API，直接窃取身份（这里是机器账户身份），用该身份完成后续操作。
顺便一提，微软曾在 18 年通过禁止 Oxid 解析器监听在本地的方法"修复" Rotten Potato，P0 在 Rotten Potato 和 RemotePotato 等土豆系列的基础上绕过了微软限制并提出 Kerberos Relay，土豆作者又受到启发，将上述绕过运用回土豆开发出 JuicyPotatoNG，非常奇妙。
本地 ST 利用
前面只是说到设置 RBCD 属性后，通过 S4U2proxy 请求获取域管 ST，但如何使用这张 ST 并没有提到。红队同学可以很直观的想到通过 PTT 的方式远程执行命令完成提权，但这种方式容易触发告警，且不符合"自动化本地提权方案"的初衷。
一个想法是通过 LsaCallAuthenticationPackage() 与 lsass.exe 通信，将 ST 打入内存，然后通过 LsaLogonUser() 根据缓存的凭据直接获取域管 Token，但实验后发现获得的 Token 模拟级别为 SecurityIdentification，无法用于冒充客户端创建高权进程，提权失败。
另一种方法是，通过 创建 SCM 连接的方式进行本地 ST 利用[3]。首先，通过 OpenSCManagerW() 连接本地 127.0.0.1 SCM，这属于 Network Logon，lsass.exe 会使用内存中缓存的凭据进行网络认证，打开 SCM 后再创建本地服务并执行，最终提升至本地 SYSTEM 权限。需要注意的是，默认情况下会存在使用 NTLM 协议进行认证的情况，需要在认证前 Hook SSPI API 将 Negotiate 强制设为 Kerberos，以便使用提前打入内存的 ST 进行认证。至此，完成 ST 本地利用。
利用工具
基于上述原理，再搭配一点 Session 隔离穿透实现前台服务交互用于 spawn cmd.exe，以及使用命名管道实现进程通信用于命令执行结果获取，即可完成自动化提权的域环境部分。当然，除了 RBCD 外，还能利用 ADCS、ShadowCred 等方法实现域内本地提权。
修复
针对土豆系列里那些中继相关的利用方法，微软曾经的态度是"服务器必须保护自己免受 NTLM 中继攻击"，鲜有在 90 天内通过安全更新修复的，但又总会在将来某个版本中不经意间"修复"。上述 RemotePotato 和 Kerberos Relay 曾被认为是不会修复的特性问题，但微软在 2022.11.8 日的 KB5019966 补丁中将 DCOM 身份验证级别提高到了 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY：
这阻止了 Kerberos Relay，在一定程度上缓解了本地提权，但攻击者仍然可以寻找其他本地触发 SYSTEM 网络认证的方式（比如 Change-Lockscreen[4]），再次恢复利用链。
总结
这篇文章结束，我们的Windows 域环境下的本地提权系列研究暂时也就告一段落了，感谢大家的阅读，我们下次再见。
参考资料
Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory[5]
Windows Exploitation Tricks: Relaying DCOM Authentication[6]
Bypassing UAC in the most Complex Way Possible![7]
Change-Lockscreen[8]
引用链接
[1] NTLM Relay: https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#case-study-2-windows-1020162019-lpe
[2] 文中: https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html
[3] 创建 SCM 连接的方式进行本地 ST 利用: https://www.tiraniddo.dev/2022/03/bypassing-uac-in-most-complex-way.html
[4] Change-Lockscreen: https://github.com/nccgroup/Change-Lockscreen
[5] Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory: https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#case-study-2-windows-1020162019-lpe
[6] Windows Exploitation Tricks: Relaying DCOM Authentication: https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html
[7] Bypassing UAC in the most Complex Way Possible!: https://www.tiraniddo.dev/2022/03/bypassing-uac-in-most-complex-way.html
[8] Change-Lockscreen: https://github.com/nccgroup/Change-Lockscreen