传统方法通常依赖从终端提取主刷新令牌 (PRT),这可通过信标(如使用 aad_prt_bof 或 Kozmer 的 request_aad_prt 之类的 BOF)实现。然而,当信标运行在未加入域的 BYOD 设备上时,PRT 提取方法会遇到阻碍,因为此类设备缺乏必要的域环境支持。本文将探讨在此类受限环境下,如何通过替代方法获取刷新令牌,以确保在信标失效时仍能维持对被攻陷身份的访问。
背景知识
主刷新令牌 (PRT) 是 Azure Active Directory (现称为 Entra) 中用于身份验证的关键组件。它存储在已加入域或 Azure AD 的设备上,允许用户无缝访问 Entra 资源。然而,未加入域的 BYOD 设备通常不存储 PRT,或者存储方式使得传统提取方法失效。
替代解决方案:基于浏览器的授权码流程利用
TrustedSec 的 Remote Ops Repo 中新增的 get_azure_token BOF(由 Christopher Paschen 开发)提供了一种创新解决方案。该 BOF 利用已通过浏览器向 Entra 进行身份验证的用户会话,通过以下步骤获取访问和刷新令牌:
此方法的核心优势在于所有请求均源自最终用户的机器和 IP 地址,与正常用户行为高度相似,从而降低了被检测的风险。然而,使用该 BOF 时需特别注意以下事项:
重定向 URI
不幸的是,由于将redirect_uri参数设置为localhost,它限制了可以用于此技术的客户端ID的数量——特别是当你想利用客户端ID系列(FOCI )滥用时。
搜索目前已知的支持 FOCI 且支持“ http://localhost ”的第一方客户端 ID,结果非常少。我只找到了三个:
对于窥探者(SOC)来说,对其中任何三个应用进行身份验证都可能对普通用户来说显得异常,并触发警报。更棘手的是,在成熟的租户中,这些特定的应用可能未获得租户的同意。
Microsoft 的 Native Client 重定向 URI
微软提供了一个预定义的重定向 URI,称为原生客户端重定向 URI ( https://login.microsoftonline.com/common/oauth2/nativeclient),它用于桌面或移动应用等原生应用程序的 OAuth 流程中。它本质上允许这些应用程序无需托管 Web 服务器或使用自定义 URI 方案即可从 Entra 接收授权码——浏览器只需使用“code”参数重定向到此 URI,应用程序即可捕获该 URI 并交换访问令牌和刷新令牌。
为了更好地理解授权码的实际流程,请查看 JUMPSEC 的工具TokenSmith(由Sunny Chau开发),它可以自动完成授权码的获取(尽管 URL 和授权码必须手动复制到目标服务器)。如果您将 URL 粘贴到已登录的浏览器中(并且允许使用客户端 ID),您将几乎立即看到授权码返回。
如果我们从那里提取它,就可以使用原生客户端重定向 URI,从而访问更大范围的 FOCI,并解除只能使用允许“ http://localhost ”作为重定向 URI 的 FOCI 的限制。
实现这一点的方法有很多,但能想到的最简单的 PoC 是通过GetWindowTextAAPI 提取。通过这种方法,可以针对更多 FOCI 执行授权码流程——包括常用的 Teams、Copilot、Edge 等。
以下第一方 FOCI 允许“本机客户端”重定向 URI:
BOF 否则就没有发生
作为基本的概念验证,我构建了一个 BOF,它可以执行以下操作:
beacon> entra-authcode-flow <clientid> <scope>
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有