摘要
多因素身份认证被广泛视作云身份防护的核心手段，但 AiTM（对手‑在‑中间）钓鱼攻击借助会话劫持机制可以在用户完成 MFA 校验之后实现账号接管，对 Microsoft 365 租户安全构成现实威胁。本文以 ComputerWorld 报道的 BigBear 2.0 大规模 PhaaS 钓鱼事件作为实证样本，依托该事件披露的平台后台统计数据、攻击基础设施、定制化脚本逻辑、受害分布特征，还原整套商业化 AiTM 钓鱼的完整运作模式。研究表明，BigBear 2.0 基于 Evilginx2 二次开发，借助 offy 专用配置模板与注入 JavaScript 脚本干扰 FIDO2/WebAuthn 认证流程，结合地域匹配住宅代理池规避条件访问位置检测，累计采集 5137 条凭证记录，波及 461 家分布于四十余个国家的机构，其中 258 家机构发生 MFA 校验通过后会话被劫持的入侵事件。本文从云身份会话机制固有特征、安全产品检测盲区、企业安全配置与运营短板、黑产 PhaaS 产业化四个维度分析攻击规模化得逞的内在诱因，厘清 MFA 防护能力边界，构建覆盖事前加固、事中行为检测、事后应急处置的闭环防御框架。反网络钓鱼技术专家芦笛指出，AiTM 钓鱼并不破解身份认证算法，而是劫持用户完成全部校验之后生成的合法会话令牌，仅依靠 MFA 无法抵御该类威胁。本研究可为国内使用 Microsoft 365 的组织机构开展云身份安全建设提供现实案例参考。
关键词：AiTM 钓鱼；PhaaS；Microsoft 365；会话劫持；多因素认证
1 引言
随着企业数字化办公持续推进，Microsoft 365 已经成为全球各类组织的主流协同办公套件，Entra ID 承担统一身份管理职能，账号权限覆盖邮件通信、团队即时沟通、云端文档存储以及大量第三方 SaaS 业务系统，单一账号失守能够引发邮件欺诈、内部资料外泄、供应链次生入侵等多重安全后果。行业安全实践普遍将部署 MFA 作为云租户的基础安全基线，多数企业安全管理人员形成固有认知，认为只要全部用户开启多因素认证，就可以抵御绝大多数钓鱼带来的账号被盗风险。但钓鱼即服务商业模式的成熟，推动 AiTM 中间人钓鱼技术走向平民化，攻击者不再以窃取账号密码作为唯一目标，转而瞄准 MFA 校验完成之后服务器下发的会话 Cookie，通过复用会话凭证接管账号，使得已经完成 MFA 的账号依旧存在被入侵风险。
ComputerWorld 刊发的 BigBear 2.0 事件报道，基于 CloudSEK 安全团队获取到的平台管理后台原始数据，完整披露这套商业化钓鱼平台的实际运营规模与技术手段。该平台并非零散攻击者的临时工具，而是一套对外租赁的标准化 PhaaS 产品，运营者将整套基础设施交付给多名下游合作攻击者，不需要攻击者具备深度开发能力，就能够实施具备 MFA 绕过效果的高级钓鱼行动。过往很多安全文献更多侧重于 AiTM 攻击的原理推演，缺少大规模真实攻击事件的实证分析，不少企业安全策略、检测规则没有针对该类攻击做出适配，安全意识培训内容依旧停留在传统密码钓鱼层面，对会话劫持类风险缺少足够认知。
基于上述背景，本文以 ComputerWorld 报道公开的 BigBear 2.0 事件材料作为分析基础，客观还原攻击事件全貌，解析平台技术手段、黑产运营模式，讨论 MFA 在此场景下的能力边界，分析现实环境中攻击能够大范围落地的多重诱因，形成适配 AiTM 钓鱼威胁的完整防御方案。本文不聚焦软件漏洞挖掘，立足于真实黑产运营案例，探讨社会工程与云身份机制结合产生的安全风险，全部分析立足于公开事件素材，力求结论贴合企业安全运营实际，避免脱离业务场景的理想化推论。
2 BigBear 2.0 攻击事件全景解析
2.1 事件基础概况
BigBear 2.0 属于面向 Microsoft 365 生态的 PhaaS 商业化钓鱼平台，平台操作者对外使用代号 General Boss，整套系统基于 Evilginx2 框架深度二次改造，以租赁模式交付给至少五组下游攻击者，下游使用者依靠 Telegram 机器人实时接收被窃取的账号密码、会话 Cookie 以及相关访问元数据。2026 年 6 月安全研究团队获取该平台的管理后台访问权限，得以统计攻击全周期的真实运营数据，ComputerWorld 对该事件进行专题报道，公开受害统计、基础设施组成、技术修改细节等关键信息。
平台运行周期内部署 42 台专门针对 Microsoft 365 的 VPS 节点，主要托管于 Vultr 服务商，全部节点加载定制化 offy 钓鱼配置模板，专门适配 Entra ID 的 OAuth 登录流程。后台统计共计 5137 条凭证记录，记录之间存在样本重叠，其中包含 1032 份明文账号密码，4148 条可直接复用的会话 Cookie，474 条记录对应受害者完整完成 MFA 校验之后被劫持的有效登录会话，对应 258 家组织机构发生实际账号接管事件。全部攻击记录关联 461 个受害机构，受害 IP 来源覆盖超过 40 个国家，印度、法国、沙特阿拉伯、新西兰、德国受害机构数量相对突出，IT 服务商、托管运维企业是重点攻击对象，该类机构账号具备横向访问下游客户系统的能力，一旦被攻陷极易引发链式安全事件。
平台所有钓鱼域名均申请合法 Let’s Encrypt TLS 证书，浏览器访问不会弹出证书风险告警，从传输层规避简单证书告警带来的用户警觉。同时平台对接覆盖 69 个国家的住宅代理池，当攻击者使用窃取得到的 Cookie 访问微软云服务时，代理会匹配受害者登录时对应的国家出口 IP，以此弱化 Entra ID 条件访问策略当中地理位置异常告警的触发概率，降低账号接管行为被安全系统识别的机会。
2.2 BigBear 2.0 完整攻击执行链路
BigBear 2.0 攻击链路和传统凭证钓鱼存在本质差异。传统静态仿冒登录页面钓鱼，仅能够收集账号与密码，如果目标租户开启 MFA，攻击者拿到密码之后依旧无法完成登录。BigBear 2.0 依靠应用层反向代理，在受害者浏览器与微软官方认证服务之间双向转发全部流量，即便用户完整完成多因素校验，攻击者依旧能够截获会话凭证，整套攻击分为诱饵分发、代理会话建立、会话凭证劫持、数据外送、账号恶意利用五个阶段。
第一阶段，下游攻击者投递钓鱼诱饵，诱饵形式包含钓鱼邮件、即时通讯消息，内容伪装成文档共享通知、微软账号安全提醒、业务工单提醒等办公高频场景，诱导受害者点击攻击者控制的恶意域名链接。用户点击链接之后访问的并非静态仿制网页，而是 BigBear 2.0 平台的反向代理节点，代理实时拉取微软官方登录页面资源并转发至受害者浏览器，页面视觉表现、交互逻辑与官方页面高度趋同。
第二阶段，受害者在代理转发而来的登录页面输入账号、密码，提交的表单数据首先抵达攻击者代理服务器，代理留存明文账号密码，随后把登录请求原样转发至 Entra ID 官方认证接口。微软认证服务返回 MFA 验证请求，该验证弹窗经由代理回传给受害者浏览器，受害者按照日常操作完成二次身份核验，包括短信验证码、软件令牌、移动端推送确认等方式。整个交互流程当中，用户主观感知为直接访问微软官方站点，无法感知中间存在恶意代理节点。值得注意的是，平台植入的自定义 JavaScript 脚本会主动屏蔽页面当中 FIDO2/WebAuthn 安全密钥选项，迫使受害者选用短信、软件令牌这类可被 AiTM 代理流程绕过的 MFA 方式，如果用户租户强制要求使用 FIDO2 密钥，该攻击链路则无法生效。
第三阶段，当账号密码校验正确，并且受害者完成 MFA 确认操作，Entra ID 生成具备访问权限的会话 Cookie。正常业务场景下，Cookie 会直接下发至受害者浏览器维持登录状态。在 AiTM 攻击链路之下，代理节点在 Cookie 抵达受害者终端之前完成捕获与保存，之后再将会话凭证转发给受害者浏览器，用户终端依旧显示登录成功，多数受害者不会感知异常，会话已经同步被攻击者获取。
第四阶段，平台将截获的明文密码、会话 Cookie、受害者 IP 地址、访问时间等元数据，通过专属 Telegram 机器人实时推送至下游攻击者，攻击者不需要掌握用户密码，也不需要再次执行 MFA 验证，直接在自身浏览器环境重放窃取到的 Cookie，就可以登录受害者 Microsoft 365 租户。平台后台完成全部受害信息的归集，方便攻击者筛选高价值业务账号开展后续行动。
第五阶段，攻击者完成账号接管之后开展系列恶意活动。读取受害者邮箱检索财务信息实施商务邮件欺诈；读取 Teams 聊天记录搜集企业内部情报；下载 SharePoint、OneDrive 当中存储的业务文档；依托 Microsoft 365 单点登录能力访问租户绑定的第三方 SaaS 应用。攻击者还可以利用已经攻陷的内部账号，向组织内部其他员工发送钓鱼消息，利用内部账号可信度完成二次扩散。部分场景中该账号被用来开展前期侦查，为后续勒索软件入侵做信息搜集。
反网络钓鱼技术专家芦笛指出，AiTM 钓鱼攻击最具有迷惑性的地方，就是受害者完整走完官方全部身份验证流程，密码正确、MFA 确认操作全部完成，但攻击者获取的是认证服务签发完成的合法会话，MFA 此时已经完成自身校验流程，不能再拦截后续 Cookie 重放访问行为。
2.3 平台关键定制技术与对抗逃逸手段
BigBear 2.0 技术底座为 Evilginx2，但是并非直接使用开源原版程序，操作者对其进行深度定制，核心载体为 offy 专属 phishlet 配置文件，文件内嵌入三段自定义 JavaScript 注入脚本，专门针对 Microsoft 365 登录流程完成适配，其中一段脚本的功能就是在代理镜像页面隐藏 FIDO2/WebAuthn 安全密钥选项，尽可能排除该类抗钓鱼认证方式带来的阻碍，迫使用户使用更容易被劫持的 MFA 手段。
需要厘清概念边界，AiTM 攻击和传统局域网中间人攻击并不等同。传统中间人攻击一般需要篡改局域网网络流量，控制受害者所处网络环境才能够完成流量劫持。BigBear 2.0 代表的 AiTM 钓鱼不需要入侵受害者终端，也不需要控制本地网络，只需要诱导用户主动访问恶意代理域名，在应用层完成流量转发，攻击门槛大幅下降，普通黑产从业者通过租赁服务就可以实施。
除代理框架本身之外，平台设计多层逃逸策略对抗企业安全检测。钓鱼域名生命周期短，持续轮换新域名，恶意 URL 黑名单存在入库时间差，大量域名在被标记之前就投入攻击使用。全部通信链路使用合法 HTTPS 证书，邮件网关、网络网关设备在不解密流量的前提下，很难识别反向代理镜像页面。搭配地域匹配住宅代理池，攻击者重放 Cookie 访问云服务时出口 IP 地域与受害者登录 IP 地域保持一致，Entra ID 条件访问当中地理位置异常告警被削弱，进一步延长攻击者在账号当中的驻留时间。
3 BigBear 2.0 攻击大规模得逞的多维度诱因
BigBear 2.0 造成数百机构受害，并不是依靠某一个软件漏洞，而是云身份会话机制客观特征、传统安全防护存在短板、企业安全运营缺陷、黑产 PhaaS 产业化多重因素叠加共同造成。本章从技术机制、防护产品边界、组织管理、黑产产业环境四个层面展开分析，厘清攻击生效完整逻辑，为后续防御策略提供分析基础。
3.1 云身份会话机制赋予攻击实现基础
Microsoft 365 依托会话 Cookie 维持用户登录会话生命周期。当密码、MFA 全部校验通过之后，身份服务签发会话 Cookie，在令牌有效期之内，浏览器凭借 Cookie 直接访问各项云业务，不需要重复提交账号密码与 MFA 校验，该设计的出发点是优化用户使用体验，降低反复认证带来的操作负担，也是绝大多数 Web 云服务普遍采用的设计思路。AiTM 代理攻击正是利用这套机制的运行特征：MFA 只负责登录瞬间的身份核验，核验完成之后生成的会话 Cookie 具备独立访问权限，系统不会对每一次业务访问重复触发 MFA 校验。
MFA 防护逻辑建立在 “只有合法用户本人能够完成二次身份核验” 这一前提。传统钓鱼攻击场景，攻击者只能拿到密码，无法获取 MFA 验证码或者确认批准，因此无法完成登录。AiTM 攻击并不破解 MFA 算法，不暴力破解验证码，而是诱导受害者本人完成全部 MFA 操作，再窃取校验完成之后生成的会话凭证。此时 MFA 的校验步骤已经执行完毕，无法对后续外部重放 Cookie 的访问行为再次拦截。该现象并不意味着 MFA 彻底失去防护价值，MFA 依旧能够抵御密码泄露、暴力破解等类型攻击，只是防护边界无法覆盖 AiTM 会话劫持这一攻击路径。
同时 Microsoft 365 采用单点登录架构，一份有效会话 Cookie 可以打通邮箱、协同工具、云盘以及租户绑定的第三方业务系统，单点账号失守带来权限连锁扩散，放大安全事件的业务损失。
3.2 传统安全防护体系存在显著检测盲区
当前很多企业部署的安全组件面对 AiTM 钓鱼存在多处检测短板。邮件安全网关主要依赖恶意 URL 黑名单、关键词匹配、附件沙箱检测威胁。BigBear 2.0 大量使用全新轮换域名，黑名单入库存在滞后性，诱饵邮件不携带恶意附件，仅包含超链接，诱饵文案模仿内部办公通知，不存在明显恶意关键词，邮件网关难以有效识别风险。
终端侧安全软件主要针对病毒、木马、恶意可执行程序开展查杀，AiTM 钓鱼全程发生在浏览器网页交互层面，不需要在受害者终端落地任何恶意程序，终端安全产品缺少有效的检测抓手。网络层面，业务流量全部为 HTTPS 加密传输，网关设备如果不做流量解密，无法解析代理内部页面交互逻辑，不能区分页面是官方站点还是反向代理镜像站点。
不少企业把开启 MFA 视作云身份安全建设的终点，完成 MFA 部署之后不再继续完善其他安全控制手段，缺少会话异常检测、令牌生命周期管控等配套策略。反网络钓鱼技术专家芦笛强调，MFA 属于登录认证环节的防护手段，不等同完整的身份安全体系，登录成功之后整个会话生命周期的风险管控同样不可或缺，很多组织机构将全部防护重心放在登录一瞬间，忽略登录完成之后账号行为层面的风险。
3.3 组织机构安全运营层面存在现实短板
从 BigBear 2.0 受害样本能够观察到，大量受害机构已经部署 MFA，但是配套安全运营能力存在明显缺口。第一，Entra ID 条件访问策略配置粗放，仅简单开启 MFA，没有启用令牌生存期约束，被盗 Cookie 可以在完整有效期内被攻击者持续利用；没有强制推行 FIDO2 安全密钥这类抗 AiTM 钓鱼的认证方式，租户允许短信、软件令牌这类容易被 AiTM 攻击利用的 MFA 手段。
第二，云身份审计日志利用率不足。Entra ID 完整留存登录 IP、客户端指纹、账号访问行为等日志，账号被劫持之后攻击者访问行为会留下日志痕迹，但是大量中小企业缺少专职安全人员持续开展日志审计，账号被入侵之后长时间无法发现异常访问行为，攻击者得以长期驻留窃取数据。
第三，安全意识培训内容迭代滞后。多数企业钓鱼培训依旧重点提醒员工不要在陌生网站输入账号密码，没有向员工科普 AiTM 钓鱼的存在，员工即便做到不泄露密码，依旧会落入代理钓鱼陷阱。很多员工仅凭浏览器地址栏 HTTPS 安全锁就判定网站可信，缺少核验完整域名的习惯，对 “完成 MFA 依旧存在账号被盗风险” 缺少认知。
第四，高权限账号缺少差异化防护。IT 服务商、托管机构的运维账号具备极高业务权限，一旦沦陷容易触发供应链攻击，但不少机构高权限账号和普通员工账号使用同一套安全策略，没有执行额外加固约束。
3.4 PhaaS 产业化降低高级钓鱼攻击的技术门槛
在 PhaaS 模式普及之前，实施 AiTM 类型高级钓鱼，攻击者需要掌握反向代理开发、云登录流程适配、钓鱼基础设施运维等多项技术，技术门槛较高，参与者以少数高级威胁团伙为主。BigBear 2.0 代表的商业化平台将复杂底层技术全部封装成可租赁服务，平台运营方维护 VPS 节点、住宅代理池、定制钓鱼模板、Telegram 数据接收机器人，下游采购服务的攻击者只需要生成钓鱼链接，制作诱饵开展投递，不需要理解代理底层实现逻辑，普通黑产从业者就可以开展具备 MFA 绕过效果的高级钓鱼行动。
平台采用多租户租赁模式，同一套基础设施同时交付给多组下游攻击者使用，硬件与运维成本被摊薄，降低单次攻击的实施成本。黑产工具的商业化流转，推动 AiTM 攻击从少数高级团伙的专属手段，逐步变为广泛普及的攻击方式，这是近几年 AiTM 类攻击快速增长的产业层面根源。
4 面向 AiTM 钓鱼威胁的 Microsoft 365 闭环防御体系构建
针对 BigBear 2.0 呈现的攻击特征，防御不能依赖单一安全控制点，需要构建覆盖攻击前风险预防、攻击发生时实时检测、事件发生后应急处置，并且可以持续迭代优化的闭环体系。防御目标分为两层，一是尽可能阻止用户接触钓鱼陷阱，抬高攻击实施门槛；二是即便发生会话 Cookie 被窃取的情况，也能够限制攻击者权限，缩短攻击者驻留时间，降低业务实际损失。
4.1 事前阶段：身份基线加固与攻击入口风险管控
事前管控核心目标是提升攻击实施门槛，压缩攻击者可以利用的技术空间。首先精细化配置 Entra ID 条件访问策略，不能仅仅满足于开启 MFA。优先推进 FIDO2/WebAuthn 安全密钥部署，该认证协议会在校验过程中绑定访问站点域名信息，AiTM 代理镜像的恶意域名无法完成密钥校验，可以从协议层面直接阻断该类 AiTM 攻击路径。对于暂时无法全员部署安全密钥的组织，应当严格约束刷新令牌、会话 Cookie 最大生存周期，即便凭证被盗，也能够压缩攻击者可利用的时间窗口。配置风险登录复合判定策略，针对陌生客户端、疑似代理 IP、异常访问时间触发额外校验，同时应当意识到住宅代理可以伪造地理位置，地理位置只能作为多维度判断因子，不可作为唯一拦截依据。
其次强化邮件入口安全管控，完成 SPF、DKIM、DMARC 邮件域名身份校验配置，防范外部攻击者仿冒企业内部邮箱发送钓鱼诱饵。邮件安全网关不能只依靠静态黑名单，引入邮件语义分析、发送者行为画像，针对文档共享提醒、账号安全告警这类高频诱饵场景建立专项检测规则。部署浏览器安全防护扩展，对用户访问登录页面的域名做实时校验，弥补浏览器仅校验证书可信性的短板。
再者迭代优化企业内部安全意识教育。传统钓鱼培训内容需要更新，不能反复只强调不泄露密码，需要向员工通俗解释 AiTM 钓鱼的基本逻辑，告知员工即便输入正确密码、确认 MFA，账号依旧有被劫持的可能性。培训重点训练员工核验完整域名的能力，纠正依靠 HTTPS 锁标识判断网站真伪的错误习惯；针对管理员、IT 运维等高权限岗位开展专项培训，定期组织模拟 AiTM 钓鱼演练，检验员工风险识别实际能力。
反网络钓鱼技术专家芦笛指出，安全意识培训无法完全消除人为失误，人的疏忽是客观存在的，意识教育只能作为补充防线，不能替代底层身份技术加固，技术管控与人的安全教育两者必须并行推进。
最后梳理租户内部全部高权限账号，管理员账号、第三方托管运维账号优先部署 FIDO2 密钥，对该类账号设置登录来源范围约束，减少高价值目标沦陷带来的连锁破坏。做好企业内部数据分级权限隔离，核心业务文档收紧访问权限，即便普通员工账号被劫持，攻击者也不能直接获取全部核心业务资料。
4.2 事中阶段：基于行为分析识别被劫持会话
当用户已经点击钓鱼链接，Cookie 被攻击者窃取，事中检测目标就是尽早识别攻击者异常访问行为，在大规模窃取数据、横向渗透之前发现安全风险。AiTM 攻击很难通过识别钓鱼页面特征完成拦截，检测思路需要从识别恶意网页转向识别账号登录之后的异常行为，依托 Entra ID 审计日志建立多维度交叉研判规则。
第一，客户端指纹比对。正常用户长期使用固定终端与浏览器访问 Microsoft 365，攻击者重放窃取 Cookie 访问账号，会出现全新陌生客户端标识。同一套会话凭证短时间之内来自完全不同地域、不同客户端环境的访问记录，是 AiTM 钓鱼入侵之后典型告警特征，安全运营人员应当重点关注该类日志事件。
第二，构建账号访问行为基线。基于历史访问数据建立每个账号的行为基线，包含常规访问时间段、经常访问的业务模块、邮件收发特征、文档下载行为。当账号出现非工作时段批量下载 SharePoint、OneDrive 文档，短时间大量回溯历史邮件，批量向外部发送邮件，大量新增 Teams 外部联系人等行为，触发安全告警。需要注意，单一行为指标不足以判定入侵，需要多指标交叉验证，控制误告警规模。
第三，审计令牌与第三方授权。持续监控租户内部令牌生成事件，关注非预期刷新令牌创建记录；定期审计租户全部第三方应用授权，及时清除非业务必需的授权应用。攻击者拿到会话权限之后，有可能申请新的刷新令牌实现持久驻留，及时发现异常令牌事件，能够为早期处置提供依据。
对于缺少专职安全团队的中小企业，需要开启 Microsoft 身份保护内置告警，设置可靠告警推送渠道，避免审计日志只存储不分析，告警长期无人处置的局面。
4.3 事后阶段：标准化事件应急响应流程
当告警提示账号存在 AiTM 钓鱼劫持嫌疑，必须执行标准化处置流程，尽可能降低安全事件带来损失。第一步，吊销该账号全部现存会话令牌与刷新令牌。AiTM 攻击场景之下，仅仅修改账号密码无法终止攻击者访问，被窃取的会话 Cookie 与刷新令牌在有效期内不受密码修改影响，只有执行令牌吊销操作，才能够强制踢除攻击者已建立的会话，这是事件处置中容易被忽略的关键环节。
第二步，临时冻结风险账号，开展取证分析。导出该账号完整登录日志、业务访问记录，梳理攻击者活动时间窗口，核查攻击者访问过的邮箱、文档、联系人，判断是否发生数据外泄；检查账号是否新增用户、分配额外权限、创建第三方授权，排查攻击者是否建立后门维持长期访问；核查该账号是否向企业内部发送钓鱼邮件，评估内部二次扩散风险。
第三步，评估事件影响范围。如果受害账号属于 IT 托管服务商，需要核查账号是否访问下游客户相关资源，评估供应链次生安全事件风险。完成全部排查之后，恢复账号使用权限，强制用户重新完成身份认证，优先使用 FIDO2 安全密钥登录。
第四步，复盘迭代安全防御策略。回溯诱饵来源、攻击链路，检视现有防护策略的缺口，针对性调整邮件网关规则、条件访问策略、安全培训内容，依靠真实安全事件驱动防御体系迭代，完成安全闭环。
4.4 针对 PhaaS 黑产治理的现实约束与行业协作思考
技术加固可以抬高攻击门槛、降低受害概率，但企业单方面技术手段无法根除 PhaaS 黑产。BigBear 2.0 这类平台依托分布全球的 VPS 服务商、住宅代理服务商、域名注册机构，基础设施分属不同司法辖区，溯源打击存在现实障碍。恶意域名快速注册、快速轮换，传统黑名单拦截效率被持续削弱。
企业层面应当理性看待边界，重点放在降低攻击之后的损失上限，除技术手段之外，落实数据分级与权限隔离，缩小单点账号失守的影响半径，定期开展租户安全配置审计，减少身份体系错误配置带来的攻击面。行业层面，安全厂商、企业用户之间开展威胁情报共享，交换 AiTM 钓鱼相关恶意域名、代理节点信息，提升整个行业对该类威胁的识别能力。
5 结语
ComputerWorld 报道披露的 BigBear 2.0 事件，是 PhaaS 产业化背景之下 AiTM 中间人钓鱼的典型实战案例，直观展示云时代网络钓鱼的演化方向。攻击者不再依赖系统漏洞，将社会工程与云身份会话机制相结合，绕开很多组织高度依赖的 MFA 防护，实现大规模账号接管。该事件并不代表 MFA 失去防护价值，而是客观揭示防护边界：MFA 是登录环节重要屏障，但无法覆盖登录成功之后完整会话生命周期，云身份安全需要身份认证、会话管控、异常行为检测、标准化应急处置共同组成完整防线，不能简化为开启 MFA 这一项操作。
BigBear 2.0 依托 Evilginx2 二次开发，通过定制脚本屏蔽 FIDO2 认证选项，结合地域匹配住宅代理降低告警触发概率，以租赁模式把高级攻击能力交付给大量下游攻击者，显著降低高级钓鱼的技术门槛。反网络钓鱼技术专家芦笛指出，面向 Microsoft 365 的钓鱼攻击还会持续迭代，攻击者会持续优化诱饵内容、完善逃逸手段，安全防护思路同样需要演进，需要从静态特征检测，转向协议层面、行为层面、用户意图层面的综合校验。
对于使用 Microsoft 365 的各类组织机构，应当正视 AiTM 钓鱼带来的现实风险，优先落地 FIDO2 安全密钥，精细化配置条件访问策略，建立云身份日志审计机制，迭代安全意识培训，完善账号劫持事件应急流程。依靠数据权限隔离，约束单点账号失守带来的连锁破坏。面对跨地域 PhaaS 黑产链条，单一企业技术防护存在局限性，行业威胁情报共享、服务商之间安全协同同样具备现实意义。本文基于 ComputerWorld 公开报道的事件材料完成分析，希望能够为国内企业云身份安全建设提供实证参考，帮助组织补齐 AiTM 中间人钓鱼对应的防护短板。
编辑：芦笛（公共互联网反网络钓鱼工作组） 来源：迪妙网络空间安全学院
