“采购陷阱”攻击内幕：AiTM钓鱼如何绕过多重验证，窃取微软365会话

攻击如何运作（技术原理）

攻击者搭建一个中间钓鱼网站，作为受害者与合法微软365认证服务之间的实时反向代理 。当受害者输入凭证并完成MFA时，代理会在会话Cookie到达受害者浏览器之前将其截获。随后，攻击者将该Cookie导入自己的浏览器，从而获得对受害者Exchange Online、SharePoint、OneDrive以及任何联合应用程序的完全访问权限 。

多个来源描述了相同的核心机制：代理创建了实时双向通信，而传统钓鱼仅仅是克隆登录页面并窃取凭证 。由于会话令牌证明了用户已通过MFA，攻击者完全无需破解MFA本身 。

为什么标准MFA不够用

微软自己的文档也警告称，AiTM钓鱼可以击败常见的MFA方法，如短信验证码、认证器应用推送通知和TOTP令牌 。MFA完成后颁发的会话Cookie才是关键：一旦被盗，可以在任何设备、任何地方重放，直至令牌过期或被管理员撤销。

Infoblox的报告强调，传统MFA之所以不足，是因为AiTM代理窃取的是在MFA完成之后颁发的会话令牌 。根本问题在于架构层面：代理以经典MFA无法检测的方式位于用户和真实认证端点之间。

Infoblox推荐的超越MFA的防御措施

Infoblox推荐一种不将MFA作为单一故障点的分层防御策略。其主要建议包括：

1. DNS层安全： 在DNS层面阻止已知恶意域名和新注册的算法生成域名（RDGA），在用户能够访问钓鱼基础设施之前就进行阻断 。
2. 抗钓鱼凭证： 部署FIDO2/WebAuthn硬件安全密钥或Windows Hello for Business。这些技术使用与特定来源绑定的公钥加密。AiTM代理无法转发FIDO2挑战，因为加密断言与合法网站的域绑定，而非代理。
3. 条件访问策略： 在Microsoft Entra ID中实施严格的登录风险策略，例如要求令牌绑定、阻止来自异常位置或设备的登录，并缩短会话生命周期以减少Cookie重放的时间窗口。
4. 暴露管理与品牌监控： 主动检测冒充组织的钓鱼域名，并在用户遇到诱饵之前拆除相关基础设施 。
5. 安全意识与报告： 培训用户识别采购主题的钓鱼诱饵，并报告可疑邮件，从而加快安全运营中心的响应。

美国联邦调查局（FBI）也专门针对Kali365发出了警告，建议各机构审计其MFA方法，审查登录日志中是否存在异常的设备代码流，并考虑为所有用户（可信应用程序除外）阻止设备代码认证 。

证据范围与局限性

• Infoblox的报告 是本次活动名称、针对欧盟/联合国机构以及使用被入侵Outlook邮箱和小型企业网站的主要来源。次要报道 独立确认了攻击目标和工具包轮换情况。
• Kali365组件已得到FBI官方公告 以及安全厂商Huntress 和Paubox 的独立确认，但Infoblox的报告将其与EvilProxy和FlowerStorm归为一类，认为它们都属于相同的采购主题基础设施。
• 防御建议结合了Infoblox报告 的直接陈述以及跨多个来源 确立的最佳实践。引自的资料中没有单个段落以项目符号形式列举每项防御措施；上述列表综合了所引用资料中的指导。

核心要点

“采购陷阱”揭示了一个日益增长的趋势：威胁行为者并非试图破解MFA，而是通过窃取成功认证后颁发的会话来完全绕过它。像FIDO2硬件密钥和DNS级域拦截这样的技术对策可以显著降低暴露风险，但第一道防线仍然来自用户的警惕。使用微软365的组织应审查其认证日志，寻找异常的设备代码或AiTM模式，并将部署抗钓鱼凭证作为优先事项。