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

微软警告称，钓鱼攻击者正在利用 OAuth 认证协议的内置功能，将受害者重定向到恶意软件。这些链接指向合法的身份提供商域名（如 Microsoft Entra ID 和 Google Workspace），看似安全，实则将用户带往别处。

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

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

攻击工作原理

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

该链接指向真实的 OAuth 授权端点，但被故意构造了破损的参数。攻击者使用 prompt=none 值（请求无登录界面的静默认证），并搭配无效的 scope 值。这种组合被设计为必然失败。当失败发生时，身份提供商会将用户的浏览器重定向到攻击者注册的 URI。

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

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

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

博客中描述的其他活动将受害者路由到 EvilProxy 等"中间人"框架，以窃取凭据和会话 Cookie。

上下文，而非 URL，是新的危险信号

IDC 亚太区高级研究经理 Sakshi Grover 表示，长期以来"将鼠标悬停在链接上验证域名"的建议是为仿冒域名时代设计的，在认证流程常规通过受信任身份提供商的环境中已不再适用。

她说："组织应将安全意识宣传从'检查链接'转向'验证上下文'。员工应接受培训，质疑认证请求是否为预期之内、是否与当前业务活动一致，以及应用程序请求的权限是否合理。"

Gogia 表示，企业需要更进一步，彻底改变底层行为。"切勿从未经请求的入站链接发起认证流程。认证应从受控的起点开始，而非来自邮件触发。"他补充说，报告意外登录流程必须做到无障碍，报告速度的价值高于对个人判断的信心。

攻击者利用的治理漏洞

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

IDC 的 Grover 表示，各企业的治理成熟度仍然不均衡。"广泛的默认同意设置和对重定向 URI 的有限监控仍然普遍，尤其是在云和 SaaS 采用速度超过身份治理控制的环境中。"

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

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

Gogia 警告称，只要企业不解决这些漏洞，该技术就将继续有效。"它不需要破解加密。它利用的是管理上的自满。"