微软每天被攻破数百次：AI钓鱼攻击把MFA变成了摆设

3月15日以来，每24小时就有10到15波攻击同时发起，数百家企业邮箱被翻个底朝天。这不是演习，是微软安全副总裁Tanmay Ganacharya亲口确认的数字。

攻击者用上了几乎全自动化的AI流水线，从踩点到偷钱，全程不用人工干预。最讽刺的是，他们绕过的正是企业最信赖的多因素认证（MFA，Multi-Factor Authentication，一种需要两种以上验证方式的登录保护）。

设备码认证：为方便埋下的雷

你家的智能电视、打印机，那些没法直接输密码的IoT设备，怎么登录微软账号？微软设计了一套"设备码认证"（OAuth 2.0 Device Code Flow）：设备屏幕上弹出一串短码，用户拿手机或电脑去另一个页面输入，就完成授权。

这套机制的设计初衷是"让用户少敲几次键盘"，代价是安全上下文被割裂了。

攻击者正是钻了这个空子。他们伪造登录页面，诱导受害者输入设备码——而这个码其实是攻击者事先从微软服务器申请来的。用户以为自己"登录了某个服务"，实际上是在给攻击者的会话授权。

整个过程中，MFA照常触发，用户正常完成二次验证。但认证完成后，攻击者拿到的访问令牌（Access Token）和合法用户一模一样。系统视角里，这就是一次"完全合规"的登录。

Ganacharya把这叫作"显著升级的威胁 sophistication（攻击复杂度）"。翻译成人话：以前钓鱼还要蹲点守株待兔，现在AI可以批量养号、批量收割。

攻击链拆解：AI如何接管全流程

微软还原了完整的时间线。攻击不是随机撒网，而是有明确的"侦察-潜伏-收割"节奏。

第一步，踩点。攻击者调用GetCredentialType接口——这是微软公开的API，用来查询某个邮箱地址是否存在、采用哪种认证方式。Ganacharya透露，这个侦察阶段通常发生在实际攻击前10到15天。

第二步，养号。确认目标有效后，攻击者不会立刻动手。他们会等待，观察目标组织的邮件往来模式，甚至训练AI模型模仿特定员工的写作风格。

第三步，批量投放。3月15日之后，攻击进入工业化阶段。每24小时10到15个独立campaign（攻击活动），每个campaign携带"高度多样化且独特的payload（攻击载荷）"。

这种"千Campaign千面"的策略，专门用来对付基于模式的检测系统。传统安全工具靠"这条邮件像不像已知钓鱼样本"来判断，攻击者就让每封邮件都不像。

第四步，精准收割。虽然撒网范围覆盖所有行业，但"入侵后的活动显示对财务相关角色的一致关注"。攻击者的AI会自动筛选邮箱，定位财务、采购、高管账号，然后批量导出邮件。

Ganacharya没有透露具体涉案金额，但强调了"窃取财务数据"这一动机。换句话说，这不是炫技，是生意。

EvilTokens：钓鱼即服务的工业化

微软没有把这波攻击归因于特定团伙，但发现了一个关键线索：攻击工具与EvilTokens高度相似。

EvilTokens是一个今年2月中旬开始售卖的"钓鱼即服务"（PhaaS）套件。买家付费后，可以获得完整的设备码钓鱼基础设施，包括：

- 自动生成伪造的微软登录页面

- 绕过MFA的完整攻击链

- 受害者的会话劫持功能

- 即将上线的Gmail和Okta支持

这种商业模式把攻击门槛降到了历史低点。以前需要懂OAuth协议、会写代码、能搭基础设施的"技术型选手"，现在只需要会转账就能开工。

更麻烦的是迭代速度。EvilTokens的运营方承诺"即将支持Gmail和Okta"，这意味着攻击范围很快会从微软365扩展到整个企业SaaS生态。Ganacharya提到的"高度多样化的payload"，很可能就是不同买家自定义的结果。

当攻击工具变成订阅制，防御方的压力就从"抓几个黑客"变成了"对抗整个灰色产业"。

微软的应对与未解的困局

微软在周一的博客中详细披露了设备码攻击的技术细节，并提供了检测建议。但Ganacharya的表态透露出一个尴尬现实：这场战役很难靠"封堵漏洞"来解决。

设备码认证不是bug，是feature。它服务于数亿台无法交互登录的IoT设备，微软不可能简单关闭。而GetCredentialType接口的暴露，本质上是云服务的可用性设计——完全隐藏用户信息会让合法业务流程断裂。

微软给出的防御建议包括：监控异常设备码请求、限制设备码认证的使用场景、对敏感账号启用更严格的条件访问策略。但这些都需要企业主动配置，而大多数IT部门甚至不知道这个攻击面的存在。

Ganacharya提到的一个细节值得玩味：攻击者"查询目标邮箱是否存在"的行为，发生在入侵前10到15天。这意味着理论上存在"预警窗口"，但现实中，有多少企业会保存并分析这类API调用日志？

安全团队的传统思维是"守住边界"，但OAuth时代的攻击发生在认证协议内部，边界已经模糊了。

另一个未被充分讨论的变量是AI。微软强调攻击者"在几乎每一个环节都使用了AI和自动化"，但没有展开说明具体应用场景。合理的推测包括：用LLM生成个性化钓鱼文案、用机器学习优化目标筛选、用自动化工具管理大规模会话劫持。

这引出一个更深层的问题：当攻击者用AI实现"规模化的个性化"，防御方的AI准备好了吗？

行业影响：MFA信仰动摇之后

这次攻击的特殊性在于，它没有利用任何技术漏洞，而是合法功能的滥用。受害者完成了所有"正确"的操作：检查发件人、完成二次验证、在官方页面输入代码——依然中招。

这对企业安全策略的冲击是结构性的。过去十年，MFA被奉为对抗钓鱼的银弹。NIST（美国国家标准与技术研究院）、CISA（网络安全和基础设施安全局）等机构反复推荐，保险公司开始将MFA作为承保条件，合规框架把它列为基线要求。

但设备码攻击证明，MFA的保护范围是有边界的。它验证的是"你是谁"，却无法验证"你在为谁授权"。

行业已经开始响应。FIDO联盟推动的无密码认证（Passkey）试图从架构上消除钓鱼可能，但普及速度受限于硬件支持和用户习惯。条件访问策略（Conditional Access）可以限制设备码的使用场景，但配置复杂度让中小企业望而却步。

Ganacharya描述的"每天数百起入侵"，可能只是冰山一角。设备码攻击的隐蔽性意味着大量入侵尚未被发现——攻击者可以长期潜伏，选择最佳时机出手。

微软博客发布当天，安全社区的反应呈现出明显的分裂。一部分从业者呼吁彻底禁用设备码认证，另一部分则指出这会对IoT生态造成毁灭性打击。企业CISO们面临的选择是：牺牲便利性，还是承担被AI钓鱼流水线收割的风险？

EvilTokens的"即将支持Gmail和Okta"预告，暗示这场战役才刚刚开始。当设备码攻击从微软365蔓延到整个身份基础设施，今天的"数百起 daily compromise"会不会只是明天的 baseline？

你的企业邮箱，上次检查设备码登录日志是什么时候？