8100万次登录冲击微软365，多因素认证为何没拦住？

六月十二日到二十六日，身份认证系统迎来了一场罕见的压力测试。根据网络安全公司Huntress观察到的数据，黑客在两周内向微软365账户发起了超过8100万次登录尝试，平均每天近六百万次。所有攻击都指向同一个手法：密码喷洒，配合泄露的凭据，再借助OAuth机制里一个陈旧却未被封锁的通道，直接绕过了多因素认证（MFA）。最终，64个组织的78个账户被成功攻破。

攻击者并没有发明全新的渗透技术，但他们把旧漏洞和新疏忽组合得异常高效。密码喷洒的原理并不复杂，就是用一两组从过往数据泄露中收集的常用密码，在大量账号上反复尝试，避开了传统暴力破解时单个账号多次失败触发锁定的问题。在这轮活动中，攻击者把目标锁定在全球范围内数以千万计的微软365账户上，用从暗网购得的凭证库进行地毯式匹配。一旦某个用户名和密码对上，攻击者并不会按常规流程走完MFA校验，而是直接改走另一条通道：资源所有者密码凭据（ROPC）OAuth授权流程。

ROPC是一种老旧的认证方案，它与大多数现代身份验证流程的设计思路背道而驰。常规的多因素认证、单点登录（SSO）都需要用户和身份提供方之间产生交互，比如弹出验证窗口、点击推送到手机上的确认按钮。而ROPC直接把用户名和密码发送到令牌端点，不产生任何交互提示。Huntress的研究员在分析报告中提到：“ROPC在许多方面都被认为是有问题的，其中一个原因就是它不支持MFA或SSO这类现代认证流程。也就是说，正如我们在这场活动中所见，ROPC直接将密码发往/token端点，根本没有交互性的MFA提示。”攻击者就是利用了这一点，借助Azure命令行界面（CLI）这个合法工具，把整个攻击包裹在正常的API请求里。

Azure CLI原本是管理员用来管理云资源的工具集，但在这次事件里，它被攻击者当作绕过条件访问策略的捷径。条件访问策略（CAP）是微软365安全框架中的核心组件，允许IT团队根据用户位置、应用类型、设备状态等条件设定规则，决定何时强制要求MFA。理论上，只要策略配置得当，来自不受信任位置的登录请求就会被拦住。然而，这次被攻破的组织几乎全都没能正确覆盖攻击者使用的特定认证流。Huntress明确提到：“许多受入侵的企业其实通过条件访问策略启用了MFA，但MFA没有配置为涵盖攻击者使用的这一特定流程。”也就是说，规则有，但缺口更大。

那些在防守中暴露出问题的组织，大致可以归为四种情况。最脆弱的一类根本没有实施任何MFA策略，账户处于全开放状态。第二类虽然开启了MFA，却只针对管理员角色，普通用户登录时完全不要求二次验证。第三类把信任寄托在IP地址上，规定只有从不受信任位置登录才需要MFA，如果连接来自公司内部网络或被标记为可信的IP，就自动放行。一旦攻击者设法把出口IP伪装成可信来源，或者直接在被信任的网段内发起请求，MFA就彻底失效。还有一类更隐蔽的配置错误：组织只是把MFA策略设置为报告模式，仅在后台记录事件，不做任何实时拦截。防御看起来存在，实际上形同虚设。

这四种配置缺陷单独看都不算致命，但在密码喷洒的高频尝试下，很容易被逐个击破。8100万次登录请求并不是均匀分布，攻击者可以不断切换IP、账号和凭证组合，让条件访问策略的每一次判断都面临考验。Huntress建议，响应这类攻击不应单纯依赖检测喷洒的流量大小，而应该依据每一次尝试中凭证的有效性来做决策。也就是说，一旦发现某个用户名和密码的组合被验证成功，就应当立即介入，而不是等到出现大规模异常的登录高峰时才反应。

除了响应策略的调整，源头上的加固更为关键。Huntress给出的第一项缓解措施，是为所有用户、所有云应用、所有客户端应用类型强制启用MFA，不留下任何豁免的角落。第二项，是对Azure CLI这样的工具按角色进行访问限制，只允许确有管理需求的用户使用，普通账户不应具备调用ROPC流程的权限。最后，日志和监控必须覆盖所有认证端点，包括这些容易被忽视的OAuth令牌接口。事件中的攻击者能够在不被察觉的情况下持续两周，正是因为他们绕过了常规登录页面，直接和后台的/token端点对话。

这次规模达8100万次的攻击，把微软365身份安全体系里长期被低估的弱点推到了台前。条件访问策略设计得再精细，如果存在一个不被策略覆盖的认证流，所有的保护就可能被绕过。ROPC作为遗留协议本已不推荐使用，但在默认配置中它仍然可用，并且被攻击链条中的Azure CLI调用所激活。这一发现给所有依赖云身份服务的团队提了个醒：MFA并不是一个二进制开关，不是开了就万事大吉，它是一整套需要持续审计、持续补漏的配置体系。哪怕只有一小部分流量走通了没有MFA的通道，整道防线就可能被撕开。

Huntress的统计表明，在这两周里共有78个账户失陷，分散在64个组织中。这个数字相对于8100万次尝试而言似乎不大，但每一个失陷的账户都可能成为攻击者进一步横向移动的跳板。被攻破的账户一旦进入内部，邮件规则、SharePoint站点、Teams消息都可能被用作进一步社会工程或数据窃取的媒介。攻击的后续影响往往远比初次登录的一瞬间严重，而所有后果都源于当初在配置条件访问策略时省掉的那一步。

事件也凸显了凭据泄露与协议缺陷叠加的破坏力。泄露的密码本身并不可怕，只要二次验证存在，单靠密码无法通过。可当攻击者找到一个不需要二次验证的入口，此前泄露的每一条密码都变成了潜在的开锁钥匙。密码喷洒攻击在低速率下甚至可以伪装成正常的忘记密码重试，让基于阈值的监测系统更难察觉。这次攻击之所以被发现并分析，很大程度上得益于Huntress对客户环境的深度监控，而不是微软365内置的默认告警。

对于任何依赖微软365的企业来说，事后消除隐患的优先级应该排在检查条件访问策略的覆盖范围上。需要确认所有客户端应用类型，包括那些不常用的旧版应用，都被纳入同一套MFA规则，而不是单独例外。同时，在Azure环境中查看