文章总结： 本文揭露了黑客组织利用OAuth2.0设备授权流发起的新型钓鱼攻击。攻击者通过诱骗用户在微软官方登录页输入代码，绕过传统安全检测获取账户令牌。文章详细解析了攻击原理及黑产工具滥用情况，建议企业通过配置EntraID条件访问策略阻断设备代码流、实施白名单机制及加强用户教育来防御此类逻辑漏洞攻击。
综合评分： 91
文章分类： 威胁情报,WEB安全,漏洞分析,安全运营,红队
致IT人：别只盯着钓鱼链接了，这种利用 OAuth 2.0 机制的攻击正在席卷企业内网
原创
Kit Chung
安全圈动向
2025年12月24日 08:00
广东
大家好，做安全防御这么多年，我们最常挂在嘴边教导员工的一句话就是：“一定要看清 URL，不要在陌生的域名下输入密码。”
但如果有这么一种攻击，它引导用户打开的是 正版、合法、带有微软官方证书的 microsoft.com 登录页面，甚至还能“完美”配合用户完成 MFA（多因素认证），最后却把账户权限拱手送给了黑客，你该如何应对？
最近，安全厂商 Proofpoint 披露了一个名为 UNK_AcademicFlare 的疑似俄罗斯背景黑客组织，他们从今年 9 月开始，正在疯狂利用 Microsoft 365 设备代码网络钓鱼（Device Code Phishing） 技术，对欧美政府、智库和高校发起“降维打击”。
今天，我们就扒开表象，从技术原理层面聊聊这种攻击是怎么绕过我们苦心经营的防线的，以及作为 IT 人，我们该如何填补这个“逻辑漏洞”。
01 完美的伪装：从“套近乎”开始
这次被曝光的 UNK_AcademicFlare 组织，手段非常老练。
他们不像那种群发“发票逾期”邮件的低端“脚本小子”。他们会使用已经攻陷的政府或军方邮箱账号，以“学术交流”、“采访邀约”等名义，跟目标（通常是智库专家或高校教授）建立联系。
第一步，博取信任。
等到双方聊得火热，黑客会抛出一个“诱饵”：“这是我们为了会议准备的采访提纲，请您先过目。”
第二步，技术下套。
随之而来的链接指向一个 Cloudflare Worker URL（这种无服务器架构最近很受黑客青睐，用来规避静态检测）。页面做得跟 OneDrive 一模一样，但这都不重要，重要的是弹出的提示：
“为了安全查看文档，请复制下方代码，并点击‘下一步’进行验证。”
一旦用户照做，灾难就开始了。
02 硬核拆解：OAuth 2.0 设备流的滥用
这里是本文的核心，各位搞技术的兄弟们请坐直了。
为什么用户点击“下一步”后，会跳转到微软官方的登录页 https://microsoft.com/devicelogin？
这其实是利用了 OAuth 2.0 协议中的 设备授权授予流（Device Authorization Grant）。
原理是这样的：
这个流程最初是为了那些 输入受限的设备 设计的，比如智能电视、打印机或者没有浏览器的 IoT 设备。因为这些设备没法方便地输入用户名密码，所以流程设计如下：
-
设备端（黑客端）
向微软的身份验证服务器发起请求：“我想登录。”
-
微软服务器
返回一个 设备代码（Device Code） 和一个 用户代码（User Code） 给设备。
-
设备端
把这个“用户代码”展示出来，并告诉用户：“去 microsoft.com/devicelogin 输入这个码。”
-
用户（受害者）
在自己的电脑/手机上打开微软官方页面，输入代码，并登录自己的账号进行授权。
-
微软服务器
验证通过后，会向 设备端（黑客端） 发放 访问令牌（Access Token） 和 刷新令牌（Refresh Token）。
攻击点在哪里？
在这个攻击场景中，黑客的脚本扮演了那台“智能电视”。
-
黑客在后台启动登录流程，拿到微软生成的代码。
-
黑客通过钓鱼页面，把这个代码展示给受害者。
-
受害者以为这是查看文档的验证码，于是乖乖去微软官网输入。
-
关键点来了：
受害者在微软官网看到的登录界面是完全合法的，甚至连 MFA 弹窗也是真的。受害者完成登录后，微软认为授权成功。
-
结局：
令牌（Token）不会发给受害者的浏览器，而是发给了发起请求的 黑客终端。
这就是所谓的“中间人”攻击的高级变种——我们甚至不需要拦截流量，我们只是利用合法的业务逻辑，让用户帮我们完成了授权。
03 门槛降低：黑产工具的泛滥
如果这只是国家级黑客（APT）的专属武器，我们可能还不用这么焦虑。但问题是，这种技术正在 平民化。
Proofpoint 的报告指出，像 Graphish 和 SquarePhish 这类红队工具（本意是用于渗透测试）正在被网络犯罪分子滥用。
-
Graphish：
一个开源的钓鱼工具包，专门针对 Microsoft Graph API。
-
SquarePhish：
利用二维码和设备代码流进行攻击的工具。
这些工具把复杂的 OAuth 交互封装得非常“傻瓜化”。现在的攻击者根本不需要懂 OAuth 协议细节，只要会运行脚本，就能发起一次复杂的设备代码钓鱼。
从今年 2 月微软和 Volexity 披露 Storm-2372 等组织使用该技术，到现在的 UNK_AcademicFlare，甚至是一些以搞钱为目的的 e-crime 团伙（如 TA2723），大家都在用。这也是为什么这类攻击在 2025 年下半年呈现爆发式增长的原因。
04 防御指南：我们能做什么？
面对这种利用“机制特性”而非“软件漏洞”的攻击，传统的杀毒软件和防火墙基本是瞎的。作为企业 IT 管理员，我们需要从 身份策略（Identity Policy） 层面入手。
以下是我的建议，建议大家做完测试后尽快在生产环境落地：
1. 阻断设备代码流（Conditional Access Policy）
这是最直接的办法。如果你管理的是 Microsoft 365 环境，请去 Entra ID (原 Azure AD) 的条件访问策略里看一看。
配置路径：
Microsoft Entra admin center -> Protection -> Conditional Access -> New policy
-
创建新策略：
针对所有用户（建议排除紧急访问账号）。
-
条件（Conditions）：
在“客户端应用程序”或“身份验证流”中，找到与 Device Code Flow 相关的选项。
-
授予（Grant）：
直接选择 Block access（阻止访问）。
说实话，绝大多数企业的员工根本不需要在没有浏览器的设备上登录 Office 365。关掉它，能减少 90% 的风险。
2. 白名单机制
如果你们公司真的有某些会议室设备或 IoT 设备需要这个功能，那就必须上白名单。限制只能从特定的 IP 地址范围，或者特定的合规设备（Intune 纳管设备）发起设备代码认证。
3. 也是最难的：用户教育
虽然很难，但还得讲。要告诉用户：
微软的 devicelogin 页面出现的代码，只能是你自己主动发起的（比如你在配置一台全新的智能会议室设备），绝对不应该是“为了看个文档”而被动输入的。
结语：
技术在进步，黑客也在进化。UNK_AcademicFlare 的案例再次提醒我们：身份（Identity）已经成为新的边界。当 URL 和 SSL 证书都不可疑时，我们对“业务逻辑”的理解和防御就成了最后的防线。
这种攻击不仅精妙，而且不仅限于微软，Google 体系同样支持类似的设备流，原理大同小异。
各位 IT 战友，你们在日常运维中遇到过类似的“逻辑漏洞”攻击吗？或者在配置 Azure AD 策略时有什么心得？欢迎在评论区和我交流！
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全圈动向 Kit Chung《致IT人：别只盯着钓鱼链接了，这种利用 OAuth 2.0 机制的攻击正在席卷企业内网》