前言
最近安全圈又出了一起针对Microsoft 365的精准钓鱼攻击，搞得各大企业的安全团队都紧张兮兮地排查风险。这事儿比较特别，攻击者没有用传统的恶意软件或钓鱼网站，而是巧妙地滥用了Microsoft自己的OAuth授权流程。作为一个安全从业者，我第一时间研究了这个案例，不得不说攻击者的手法确实很有创意，写点笔记记录一下。
与其硬刚企业的安全设备，不如直接利用目标已信任的系统和服务，毕竟谁会拦截微软自己的登录页面呢？
事件回顾：看似正常的请求，暗藏玄机
故事要从2025年3月初说起。据Volexity的报告，他们发现多个与俄罗斯相关的APT 组织开始针对性地攻击与乌克兰有关联的组织和人权组织。这些攻击者没有使用传统的钓鱼邮件，而是通过Signal和WhatsApp等加密通讯软件直接联系目标。
厉害的是，这些攻击者会冒充各种欧洲国家的官员（包括乌克兰驻欧盟代表团、保加利亚常驻北约代表团和罗马尼亚常驻欧盟代表团的成员），邀请目标加入一些"重要会议"。他们的社工手法相当高明，会通过详细的背景故事和专业的语气建立信任，甚至会推迟"会议"时间，以便不引起怀疑。（Signal - 划重点，后面要考）
一旦目标回应，攻击者就会发送看似官方的PDF文件，并要求目标点击一个链接加入所谓的会议：
这就是攻击的关键所在。这些链接看起来完全合法，因为它们确实指向微软官方的OAuth认证页面（
login.microsoftonline.com
）！安全团队再厉害，也很难拦截指向微软官方域名的请求吧？
OAuth钓鱼：借用Visual Studio Code的合法权限
Volexity将最初观察到的攻击归因于一个代号为UTA0352的 APT 组织。这个组织使用了一种精妙的技术，利用了Visual Studio Code（微软官方产品）的OAuth授权流程来获取目标的账户访问权。
链接格式大致如下：
这个链接中有几个关键参数值得注意：
-
client_id=aebc6443-996d-45c2-90f0-388ff96faa56：这是Visual Studio Code的官方客户端ID -
scope=
https://graph.microsoft.com/.default
：请求对Microsoft Graph API的默认访问权限 -
redirect_uri=
https://insiders.vscode.dev/redirect
：认证后重定向到VSCode的Web版本
当用户点击链接并完成认证后，他们会被重定向到VSCode的网页版，看到如下界面：
看起来很正常，对吧？但这里的问题是，攻击者会要求用户将页面上显示的代码发回给他们。一旦获得这个代码，攻击者就能生成访问令牌，从而获得对用户M365账户的完全访问权限。
下图展示了整个攻击流程：
这个攻击的巧妙之处在于，整个流程中没有任何恶意网站或恶意软件，全部使用的是微软自己的基础设施和合法的应用程序。用户在整个过程中只与官方微软域名交互，这使得传统安全工具很难检测到异常。
攻击升级：永久设备注册漏洞利用
2025年4月初，Volexity又发现了一个新的攻击变种，归因于另一个代号为UTA0355的APT 组织。这次的手法更加高级，首先使用了一个被入侵的乌克兰政府邮箱向目标发送邮件：
然后，攻击者通过Signal或WhatsApp跟进，引用之前发送的邮件以增加可信度：
这次攻击中使用的链接与前一种攻击不同：
这个URL请求的不是Microsoft Graph API的访问权限，而是针对Microsoft设备注册服务的权限。当用户认证后，会被要求分享他们看到的重定向URL：
https://login.microsoftonline.com/WebApp/CloudDomainJoin/8?code=[redacted]&session_state=[redacted]
这才是真正危险的地方：攻击者可以使用这个授权码在用户的Microsoft Entra ID（前Azure AD）中永久注册一个新设备。一旦设备被注册，攻击者可以利用一个API设计缺陷，将有限的设备注册权限提升为对Microsoft Graph API的完全访问权限。
Volexity的研究人员使用ROADTools项目复现了这一攻击，并确认了这种提权技术的可行性。最终，攻击者甚至还会引导用户批准一个双因素认证请求，以便完全访问用户的电子邮件。
Visual Studio Code钓鱼的早期变种
研究人员还发现了一个可能是UTA0352使用的早期攻击变种，使用了稍有不同的URL格式：
hxxps://&ui_locales=en-US&mkt=en-US&client-request-id=
这个早期版本使用了AzureAD
v1.0认证流程（而非v2.0），并将重定向URL设置为
vscode-redirect.azurewebsites.net
。用户认证后会被进一步重定向到本地地址127.0.0.1，产生一个只在URL中可见的授权码。
攻击者会要求用户分享他们最终看到的URL，从而获取授权码，这进一步说明攻击者在不断调整和改进他们的技术。
攻击亮点：合法工具的恶意用途
分析这整个攻击链，有几个技术亮点特别值得关注：
-
完全利用官方基础设施：整个攻击链全部使用微软官方域名和服务，没有使用第三方钓鱼网站或恶意软件。
-
OAuth协议深度滥用：攻击者对OAuth协议有深入了解，巧妙利用了合法应用（如Visual Studio Code）已有的权限。
-
状态参数伪装技术：攻击者在
state参数中放入了看似合法的URL（如政府网站），增加了链接的可信度。 -
复杂的社会工程手段：攻击者精心设计了完整的社会工程话术，包括伪造官方身份、提供详细背景故事等。
-
巧妙的设备注册权限提升：第二种攻击方法利用了微软设备注册API与Graph API之间权限设计的缺陷，实现了权限提升。
检测与防御建议
Volexity提供了一系列检测和防御这类攻击的建议，我总结如下：
-
监控特定客户端ID：为Visual Studio Code的客户端ID（
aebc6443-996d-45c2-90f0-388ff96faa56）设置登录告警，特别是当它与Microsoft Graph结合使用时。 -
检测可疑OAuth URL格式：在代理日志和邮件网关中识别包含特定重定向URI的OAuth授权URL，如
insiders.vscode.dev/redirect
或
vscode-redirect.azurewebsites.net
。 -
考虑网络阻断：评估阻止
insiders.vscode.dev
和
vscode-redirect.azurewebsites.net
域名的业务影响，如可行则实施阻断。 -
加强用户教育：提醒用户警惕通过加密通讯应用（如Signal、WhatsApp）收到的未经请求的联系，尤其是那些要求共享Microsoft生成的代码或URL的请求。
-
监控设备注册活动：关注新设备注册，特别是那些使用低信誉IP或代理IP的注册请求。
-
实施条件访问策略：限制组织资源仅允许已批准设备访问，这可以有效防止未授权设备注册。
思考与启示
这类OAuth钓鱼攻击的难点在于平衡安全和用户体验。你不能简单地阻止所有OAuth请求，因为这会影响正常业务；但如果不采取措施，又会让攻击者有机可乘。
从长远来看，我认为微软需要重新思考他们的OAuth实现，尤其是授权码的处理方式。也许未来的认证流程应该加入更多上下文感知能力，而不是仅依赖于一个可以轻易转发的代码。
作为安全团队，我们必须意识到，现代攻击者越来越倾向于"活在阳光下"，使用合法工具和服务进行攻击，而不是依赖容易被检测的恶意软件。这就要求我们不断更新防御思路，关注异常行为而非仅仅关注已知的恶意指标。
以前总觉得只要用户不点击可疑网站、不下载可疑附件就安全了，现在看来，点击官方链接一样可能中招。安全真是一场永无止境的猫鼠游戏啊。（身边很多朋友都脱坑去创业搞AI应用了，这是第四次工业革命啊，人的一生能碰到几次呢？）
（完整的事件分析可以查看volexity的原始报告）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论