OAuth钓鱼攻击让"检查链接指向"建议失效

微软警告称，钓鱼攻击者正在利用OAuth身份验证协议的内置行为将受害者重定向到恶意软件，使用的链接指向合法的身份提供商域名，如Microsoft Entra ID和Google Workspace。这些链接看起来安全，但最终会导向不安全的目的地。

微软Defender安全研究团队在一篇博客文章中写道："OAuth包含一项合法功能，允许身份提供商在特定条件下将用户重定向到特定的落地页面，通常是在错误场景或其他定义的流程中。攻击者可以滥用这一原生功能，通过使用流行的身份提供商（如Entra ID或Google Workspace）制作URL，利用被操纵的参数或关联的恶意应用程序将用户重定向到攻击者控制的落地页面。"

该公司表示已禁用了与此活动相关的几个恶意OAuth应用程序，但警告称相关攻击活动仍在继续，需要持续监控。

攻击从钓鱼邮件开始

微软研究人员在博客文章中写道，攻击从钓鱼邮件开始，观察到的诱饵包括伪装成电子签名请求、人力资源通信、Microsoft Teams会议邀请和密码重置警报，恶意链接嵌入在邮件正文或PDF附件中。

该链接指向真实的OAuth授权端点，但使用故意破坏的参数构建。攻击者使用"prompt=none"值，请求无登录屏幕的静默身份验证，并将其与无效的范围值配对。这种组合被设计为失败。当失败时，身份提供商会将用户的浏览器重定向到攻击者注册的URI。

研究人员在博客文章中写道："尽管这种行为符合标准，但攻击者可以滥用它，通过受信任的授权端点将用户重定向到攻击者控制的目的地。"

Greyhound Research首席分析师Sanchit Vir Gogia表示，该技术代表了攻击者处理身份方式的结构性转变。他说："第一跳是真实的。浏览器行为正确。身份提供商行为正确。信任信号是真实的。这将钓鱼从品牌层面的欺骗转移到工作流层面的操纵。"

在微软在博客文章中详细介绍的一次攻击活动中，重定向向受害者的设备传送了一个包含恶意快捷方式文件的ZIP压缩包。打开该文件会触发一个PowerShell脚本，运行侦察命令，最终连接到攻击者控制的服务器。微软将后续活动描述为与勒索软件前期行为一致。

博客文章详细介绍的其他攻击活动将受害者路由到中间人攻击框架（如EvilProxy）以收集凭据和会话cookie。

传统安全建议已不再有效

IDC亚太区高级研究经理Sakshi Grover表示，长期以来"悬停在链接上并验证其域名"的建议是为相似域名时代构建的，在身份验证流程经常通过受信任的身份提供商的环境中不再适用。

她说："组织应该将意识信息从'检查链接'转变为'验证上下文'。应该培训员工质疑身份验证请求是否是预期的，是否与当前业务活动一致，以及应用程序请求的权限是否合理。"

Gogia表示，企业需要更进一步，完全改变底层行为。他说："永远不要从未经请求的入站链接启动身份验证过程。身份验证应该从受控的起点开始，而不是从电子邮件触发器开始。"他补充说，必须使报告意外登录过程变得无摩擦，报告速度比个人判断的信心更有价值。

两位分析师都指出，OAuth应用程序治理是此次攻击活动利用的更深层次的结构性缺口。

IDC的Grover表示，企业的治理成熟度仍然参差不齐。她说："广泛的默认同意设置和对重定向URI的有限监控仍然很常见，特别是在云和SaaS采用速度超过身份治理控制的环境中。"

根据Greyhound Research的Gogia的说法，问题的规模很容易被低估。他说："每个SaaS集成、自动化工作流和协作工具都可能需要应用程序注册。随着时间的推移，租户会累积数百或数千个注册应用程序。重定向URI在设置期间配置，很少重新审查。遥测数据存在，但缺乏解释。"

微软在博客文章中表示，组织应该限制用户对第三方OAuth应用程序的同意，定期审核应用程序权限，并删除未使用或权限过高的应用程序。该文章还公布了16个与威胁行为者的恶意应用程序相关的客户端ID，以及作为入侵指标的初始重定向URL列表。文章中包含了针对Microsoft Defender XDR客户的KQL搜索查询，以帮助识别跨电子邮件、身份和端点信号的相关活动。

Gogia警告说，只要企业不解决这些缺口，该技术就会一直有效。他说："它不需要破解加密。它需要利用管理上的自满。"

本文首次发表于CSOonline。

Q&A

Q1：OAuth钓鱼攻击是如何绕过传统安全检查的？

A：攻击者利用OAuth协议的合法重定向功能，使用指向Microsoft Entra ID或Google Workspace等真实身份提供商的链接，通过故意破坏的参数（如"prompt=none"配合无效范围值）触发失败，然后将用户重定向到攻击者控制的恶意页面。由于第一跳链接是真实的，传统的"检查链接指向"方法无法识别这种攻击。

Q2：企业应该如何防范OAuth钓鱼攻击？

A：企业应该限制用户对第三方OAuth应用程序的同意权限，定期审核应用程序权限并删除未使用或权限过高的应用程序。同时要培训员工从"检查链接"转变为"验证上下文"，质疑身份验证请求是否预期、是否与当前业务活动一致。更重要的是，不要从未经请求的邮件链接启动身份验证，而应从受控的起点开始。

Q3：OAuth应用程序治理存在哪些问题？

A：主要问题包括广泛的默认同意设置、对重定向URI的监控有限，以及企业累积了大量注册应用程序但缺乏有效管理。随着云和SaaS采用速度超过身份治理控制，许多企业的治理成熟度参差不齐。重定向URI通常在设置时配置后很少重新审查，虽然遥测数据存在但缺乏有效解释。