FIDO2 也挡不住这段代码

BigBear 2.0：商业化 PhaaS 平台的全貌

CloudSEK 于 6 月首次发现 BigBear 2.0。研究员 Gagan Aggarwal 通过获取管理员权限深入其运营面板，揭示了该黑色产业链的规模：涉及 42 个 VPS 节点、5 个独立犯罪团伙，受害者覆盖 40 多个国家，IP 地址达 3,331 个。外泄数据显示，该平台已记录 5,137 条凭据，其中 474 条为已成功攻破的 MFA 会话。这意味着攻击者不仅能窃取密码，还能在受害者完成 MFA 验证后，劫持有效的会话 Cookie 进行重放攻击。

技术原理：利用 JS 注入绕过 FIDO2 防线

BigBear 2.0 基于开源框架 Evilginx2 构建，通过反向代理拦截用户与 Microsoft 登录页之间的流量。传统代理型钓鱼可轻易绕过 SMS、TOTP 及推送通知，因为这类 MFA 仅保护“登录瞬间”，生成的会话 Cookie 一旦泄露即成通用通行证。

FIDO2/WebAuthn 曾被视为唯一例外，因其通过密码学将密钥与真实域名绑定。然而，BigBear 2.0 通过注入以下 JavaScript 代码禁用了 WebAuthn API：

Object.defineProperty(window, 'PublicKeyCredential', { value: undefined });navigator.credentials.get = function() { /* 拒绝所有 publicKey 选项 */ }

此举强制浏览器隐藏硬件密钥选项，迫使用户回退至 SMS、推送或 TOTP 等易被拦截的验证方式。尽管 Proofpoint 和 HYPR 此前曾记录过类似的降级攻击案例，但 BigBear 2.0 是首个将其产品化并商业运营的平台。

运营架构：SaaS 化运作与精准目标选择

BigBear 2.0 由代号"General Boss"的团队运营，采用 SaaS 模式出租给至少 5 个加盟团伙。每个团伙通过 Telegram 机器人实时接收窃取的会话 Cookie，从受害者输入密码到攻击者获取 Cookie 的时间窗被压缩至分钟级。其后端具备完善的租户管理、节点调度及日志监控功能。

基础设施方面，42 个 VPS 节点主要部署于 Vultr，均配备独立的 Let's Encrypt 证书。为规避检测，平台接入 ipapi.is 反爬机制，拒绝数据中心及代理 IP 访问，仅允许住宅 IP 进入。流量出口利用分布在 69 个国家的住宅 IP 池，模拟本地登录行为，成功绕过基于地理位置的条件访问策略（Conditional Access）。

攻击目标具有高度针对性。数据显示，印度是首要受害地区（占比 12.8%），其次是法国、沙特等国。行业分布上，IT 服务及托管服务商（MSP）受害最深（151 家）。攻陷一家 MSP 意味着可获得其下游数十家客户的访问权限，这与 Kaseya 等供应链攻击剧本如出一辙。

应对策略：清除会话与重构身份安全体系

紧急响应：清除泄露会话

若怀疑组织遭受 BigBear 攻击，首要任务是撤销所有可能泄露的会话。由于窃取的 ESSTSAUTH Cookie 在过期前均有效，仅修改密码不足以止损，必须强制关键账户重新认证并撤销 Refresh Token。在 Microsoft Entra 登录日志中，应重点排查“住宅 IP"、“陌生地理位置”及“突发登录”等异常信号。

长期治理：消除结构性风险

根本解决之道在于消除 MFA 的回退选项。建议采取以下措施：

• 彻底移除管理员账户上的 SMS、TOTP 等易受代理攻击的验证方式，仅保留 FIDO2/Windows Hello/Passkey。
• 将"FIDO2"设为身份验证强度（Authentication Strength）策略，而非简单启用 MFA。
• 在条件访问策略中强制要求“受管设备”或“合规设备”，防止被盗 Cookie 在非受信设备上重放。
• 针对邮件、代码仓库等高敏系统，增设 Identity Protection 异常信号检测。

此外，需特别关注“保持登录状态”（KMSI）选项。该功能可将 Cookie 寿命延长至近一个月，极大增加了攻击窗口。建议重新评估默认设置，尤其是针对管理员和开发者账户。

BigBear 2.0 的出现标志着攻击面的转移：FIDO2 并非绝对安全，只要 WebAuthn 调用依赖浏览器 JavaScript，就存在被篡改的风险。鉴于这是浏览器架构的固有属性而非单纯漏洞，真正的防御重心应转向身份提供商侧的策略管控——禁用回退、设备合规及持续验证。对于安全团队而言，当前的核心问题不再是“是否部署了 MFA"，而是"MFA 的回退选项是否已彻底清除”。