安全研究机构Proofpoint近日揭露并持续追踪一系列高度狡猾的网络钓鱼活动。攻击者正在系统性地滥用微软合法的OAuth 2.0设备代码授权流程，成功绕过多因素认证（MFA）等传统强身份验证手段，直接劫持企业Microsoft 365账户。这种攻击并非利用软件漏洞，而是对身份验证协议设计本身的“合规滥用”，使其具有极高的隐蔽性和欺骗性。
技术原理深度剖析：攻击链是如何完成的？
理解此次攻击的关键，在于厘清合法的设备代码流程如何被恶意逆转。
1. 合法流程（微软OAuth 2.0设备代码授权）
该流程专为输入受限的设备（如智能电视、游戏机、IoT设备）设计：
- 用户在受限设备上选择“通过设备登录”。
- 设备从微软身份平台（如
login.microsoftonline.com）获取一个短效的用户代码和一个设备代码。 - 用户需在另一台具备浏览器的设备（如手机/电脑）上访问微软验证页面（如
microsoft.com/devicelogin），并输入该用户代码。 - 输入后，用户在其浏览器中完成常规登录（包括密码和MFA挑战）。
- 一旦浏览器端认证成功，微软身份平台会将访问令牌（Access Token）颁发给最初那个输入受限的设备，授权其访问用户资源。
2. 攻击者如何恶意利用此流程
攻击者巧妙地颠倒了流程中的角色，将受害者变成了攻击者的“授权设备”：
- 攻击者发起请求：攻击者（模拟为“输入受限设备”）向微软发起一个设备代码授权请求，并获得一组用户代码A和设备代码A。
- 社会工程学诱导：攻击者通过精心设计的钓鱼邮件（如伪装成“紧急验证”、“薪资更新通知”），诱导受害者点击链接，跳转至完全合法的微软设备登录页面（microsoft.com/devicelogin）。
- 受害者输入“毒药”代码：钓鱼页面或邮件正文会要求（或诱导）受害者在上述合法页面中输入一个“验证码”。这个码正是攻击者持有的用户代码A。
- 受害者完成认证：当受害者在合法微软页面输入该代码后，页面会提示其登录。受害者毫无戒备地输入自己的账号、密码，并完成MFA验证（如点击手机通知）。
- 令牌拱手相让：一旦受害者在浏览器端完成认证，微软身份平台即判定：“持有设备代码A的设备（实为攻击者）已获得授权”。于是，访问令牌将被发送给攻击者初始控制的终端，而非受害者的浏览器。
- 攻击者获得持久访问权：凭借获得的令牌，攻击者可以访问受害者的邮箱、OneDrive、SharePoint等所有授权资源，并可刷新令牌以维持长期访问，实现完全账户接管。
攻击活动的特征与工具化趋势
根据Proofpoint追踪，此类攻击至少自2025年9月起活跃，并呈现出专业化、工具化特征：
- 攻击工具包：攻击者广泛使用 “SquarePhish2”（生成含恶意二维码的诱饵页面）和 “Graphish”（自动化执行整个OAuth设备代码攻击流程的工具包），降低了攻击门槛。
- 攻击主体：以经济利益驱动的团伙（如追踪编号TA2723）为主，常利用与工作高度相关的主题（薪资、福利、合规审查）提升诱骗成功率。
- 检测困境：由于整个认证过程发生在合法的微软域名上，传统的基于恶意URL或证书检测的钓鱼防护工具完全失效。用户的密码和MFA信息也并未泄露给第三方，而是“合法”地提交给了微软。
【主机帮】企业级防御与响应指南
面对这种“降维打击”式的攻击，企业必须升级防御策略，超越传统的MFA依赖。
第一阶段：立即技术控制（治标）
- 审查并限制OAuth设备代码授予：在Azure AD/Microsoft Entra管理中心，审查“设备设置”或条件访问策略，评估是否对非托管设备或所有用户禁用设备代码授予流程，或将其限制在极少数必需的服务账户。
- 实施严格的令牌生存期和会话策略：在Azure AD中缩短访问令牌和刷新令牌的默认生存期，并配置条件访问策略要求定期重新认证，以限制攻击者利用被盗令牌的时间窗口。
- 启用并监控风险检测：确保启用Microsoft Entra ID Protection，并密切关注 “匿名IP地址”、“不熟悉的登录属性” 与“设备代码授予”动作相关联的风险事件。设立告警，对任何设备代码授予行为进行日志审查。
第二阶段：架构与策略加固（治本）
- 推行无密码认证：推广使用FIDO2安全密钥或Windows Hello企业版进行无密码登录。此类强身份验证方式与特定设备绑定，攻击者无法通过远程获取令牌的方式复用。
- 部署条件访问（CA）策略作为核心防线：
- 创建策略，对来自非合规设备、非受信任网络位置的访问，即使拥有有效令牌，也阻止访问或要求二次验证。
- 对访问敏感应用（如Exchange Online， SharePoint）的会话实施持续访问评估（CAE），确保实时撤销风险会话的访问权。
- 用户意识培训的针对性升级：必须向全体员工明确传达：“永远不要在任何页面输入非你本人主动请求生成的验证码或设备代码。” 将“设备代码”纳入钓鱼演练的识别特征。
第三阶段：监控与狩猎
- 审计OAuth应用和设备授予：定期使用PowerShell或Microsoft Graph API脚本，审计租户内所有通过设备代码流程授予权限的应用和设备列表，清理异常项。
- 关注异常邮箱规则和转发设置：账户接管后，攻击者常设置邮件转发规则以窃取信息或维持访问。监控此类配置变更是有效的检测手段。
微软的回应与行业启示
微软已启动 “In Scope by Default” 计划，旨在扩大其安全响应范围，以便更快速地对类似滥用合法服务机制的攻击做出反应。这反映了云服务商在应对“协议层面社会工程攻击”时面临的挑战。
根本启示：此次事件表明，在云身份体系中，任何允许用户交互并授予第三方访问权的合法流程，都可能被转化为攻击媒介。企业安全团队必须深入理解所依赖的云身份协议（如OAuth 2.0的各种授权流），而不仅仅是配置MFA开关。安全的重心必须从“验证用户是谁”部分转向 “控制会话在何时、何地、以何种方式被建立和使用” 的全流程治理。
结论
利用OAuth设备代码流程的攻击，是网络钓鱼进化史上的一个危险里程碑。它成功地将社会工程学的欺诈性与合法云身份协议的权威性相结合，绕过了过去十年建立的最强身份验证防线（MFA）。
这警示所有依赖云身份服务的企业：在零信任架构中，MFA仅是身份验证的一个环节，而非终点。必须构建一个包含设备健康状态、网络位置、用户行为、应用程序敏感度等多维信号的持续自适应信任评估体系，才能在攻击者不断寻找和利用“合法漏洞”的战争中保持主动。
