BigBear 2.0: Microsoft 365 AiTM Phishing and Session Theft
BigBear 2.0: Microsoft 365 AiTM Phishing and Session Theft
1. Basic Information
Report Title: Tracking BigBear 2.0 Evilginx2 phishing campaign Source: CloudSEK Date Published: 2026-09-07 Original Source: CloudSEK Related Source: BleepingComputer: BigBear Microsoft 365 phishing service bypassed MFA Related Source: Microsoft Learn: Authentication strengths Associated Malware / Threat Groups / CVEs / Products: BigBear 2.0, Evilginx2, BigBear affiliates, Microsoft 365, Microsoft Entra ID, WebAuthn, FIDO2 Severity: High
1. 基本信息
报告标题： 追踪 BigBear 2.0 Evilginx2 网络钓鱼活动 来源： CloudSEK 发布日期： 2026-09-07 原始来源： CloudSEK 相关来源： BleepingComputer：BigBear Microsoft 365 钓鱼服务绕过 MFA 相关来源： Microsoft Learn：身份验证强度 关联恶意软件/威胁组织/CVE/产品： BigBear 2.0, Evilginx2, BigBear 附属机构, Microsoft 365, Microsoft Entra ID, WebAuthn, FIDO2 严重程度： 高
2. Executive Summary
BigBear 2.0 is an Adversary-in-the-Middle (AiTM) phishing service targeting Microsoft 365. The fake site disrupts WebAuthn and steers users toward alternative MFA methods. However, the attack requires the target policy to allow relayable authentication methods. It cannot bypass policies that strictly require phishing-resistant authentication strengths.
2. 执行摘要
BigBear 2.0 是一种针对 Microsoft 365 的中间人（AiTM）网络钓鱼服务。该虚假网站会干扰 WebAuthn 并引导用户使用其他 MFA（多因素身份验证）方法。然而，该攻击要求目标策略允许使用可中继的身份验证方法。它无法绕过那些严格要求防钓鱼身份验证强度的策略。
3. Attack Flow
The attacker lures the victim to an Evilginx2 AiTM page that clones the Microsoft 365 login screen. JavaScript on the fake site disrupts WebAuthn/FIDO2 APIs. If the policy permits alternative methods, it redirects the victim to relayable authentication methods such as TOTP, SMS, or push notifications. The proxy relays entered passwords and MFA responses to legitimate Microsoft servers in real time. After successful authentication, the attacker captures session cookies (such as ESTSAUTH and AppSessionId) and uses “Keep Me Signed In” (KMSI) to extend their lifetime. The attacker reuses the cookies or refresh tokens via residential proxies to access Microsoft 365.
3. 攻击流程
攻击者诱导受害者访问一个克隆了 Microsoft 365 登录界面的 Evilginx2 AiTM 页面。虚假网站上的 JavaScript 会干扰 WebAuthn/FIDO2 API。如果策略允许其他方法，它会将受害者重定向到可中继的身份验证方法，如 TOTP、短信或推送通知。代理服务器实时将输入的密码和 MFA 响应中继到合法的 Microsoft 服务器。身份验证成功后，攻击者会捕获会话 Cookie（如 ESTSAUTH 和 AppSessionId），并利用“保持登录状态”（KMSI）来延长其有效期。攻击者通过住宅代理重用这些 Cookie 或刷新令牌，从而访问 Microsoft 365。
4. Attacker Location and Execution Context
Remote attackers operating an AiTM proxy positioned between the victim browser and Microsoft 365.
4. 攻击者位置与执行环境
远程攻击者在受害者浏览器和 Microsoft 365 之间部署 AiTM 代理进行操作。
5. Visibility: Victim vs. Administrator
Victim Perspective: The user sees a login page that resembles Microsoft and completes normal MFA. The user may not be able to use FIDO2 and may be asked for an alternative MFA method. Administrator Perspective: Administrators see the authentication method, IP address, device details, and Conditional Access results in sign-in logs. Normal IdP logs do not necessarily record in-browser WebAuthn disruption or identical cookie reuse directly.
5. 可见性：受害者与管理员
受害者视角： 用户看到一个类似于 Microsoft 的登录页面并完成正常的 MFA。用户可能无法使用 FIDO2，并可能被要求使用其他 MFA 方法。 管理员视角： 管理员可以在登录日志中看到身份验证方法、IP 地址、设备详细信息和条件访问结果。正常的身份提供商（IdP）日志不一定会直接记录浏览器内的 WebAuthn 干扰或相同的 Cookie 重用行为。
6. Success and Failure Conditions
Success Conditions: The user accesses the AiTM URL and inputs credentials. The resource policy permits relayable MFA, and the user completes authentication via that method. Conditional Access policies do not block the reuse of stolen cookies or refresh tokens. Failure Conditions and Risk Reduction: Enforcing phishing-resistant MFA such as FIDO2/WebAuthn. Integrating compliant devices, device attestation, risk levels, and authentication strength into Conditional Access. When detecting an incident, revoking sessions and refresh tokens and requiring re-authentication, in addition to resetting passwords.
6. 成功与失败条件
成功条件： 用户访问 AiTM URL 并输入凭据。资源策略允许可中继的 MFA，且用户通过该方法完成了身份验证。条件访问策略未阻止被盗 Cookie 或刷新令牌的重用。 失败条件与风险降低： 强制执行防钓鱼 MFA（如 FIDO2/WebAuthn）。将合规设备、设备证明、风险级别和身份验证强度集成到条件访问中。在检测到事件时，除了重置密码外，还应撤销会话和刷新令牌，并要求重新进行身份验证。
7. Post-Exploitation Impact
Unauthorized access to Microsoft 365 accounts, emails, and files. Reuse of session cookies acquired after MFA completion. Follow-on actions such as creating inbox rules, granting OAuth consent, sending internal phishing emails, and data exfiltration.
7. 漏洞利用后的影响
未经授权访问 Microsoft 365 账户、电子邮件和文件。重用 MFA 完成后获取的会话 Cookie。后续操作包括创建收件箱规则、授予 OAuth 同意、发送内部钓鱼邮件以及数据外泄。
8. Observable Logs
Inference: The following records and scopes apply during an investigation:
- Email: If a lure email exists, inspect the preserved original URL, recipients, and click timestamps.
- Proxy / SWG / DNS: Check access to the fake login domain, redirection destinations, and timestamps. Do not treat residential proxy traffic as inherently malicious on its own.
- Endpoint / EDR: Complement findings with browser history showing visits to the phishing site. Malware execution on the endpoint is not a prerequisite for AiTM attacks.
- Identity / IdP: In Entra sign-in logs, check authentication methods, sign-in success, Conditional Access outcomes, IPs, devices, and session IDs. Do not assume raw cookie values will appear in logs.
- SaaS / Cloud: In available Microsoft 365 audit logs, look for email and file access, inbox rules, OAuth consents, and API actions.
- Network: Not used for direct verification in this attack scenario.
8. 可观测日志
推论： 调查期间适用以下记录和范围：
- 电子邮件： 如果存在诱饵邮件，请检查保留的原始 URL、收件人和点击时间戳。
- 代理 / SWG / DNS： 检查对虚假登录域的访问、重定向目标和时间戳。不要仅将住宅代理流量视为本质上是恶意的。
- 终端 / EDR： 通过显示访问钓鱼网站的浏览器历史记录来补充调查结果。终端上的恶意软件执行并非 AiTM 攻击的先决条件。
- 身份 / IdP： 在 Entra 登录日志中，检查身份验证方法、登录成功情况、条件访问结果、IP、设备和会话 ID。不要假设原始 Cookie 值会出现在日志中。
- SaaS / 云： 在可用的 Microsoft 365 审计日志中，查找电子邮件和文件访问、收件箱规则、OAuth 同意和 API 操作。
- 网络： 在此攻击场景中不用于直接验证。
9. Attack Evaluation Criteria
Inference: Criteria for internal incident assessment. These stages do not mean every organization experienced every level of harm.
- Attack Attempt Observed (Unconfirmed Success): Delivery of or access to a lure URL alone does not prove credential entry or account compromise.
- User Action Confirmed: User statements or preserved browser artifacts confirm that credentials were typed into the fake site.
- Malware Execution or Successful Authentication Confirmed: Microsoft-side authentication success corresponds to input on the fake site. Successful authentication is not treated as code execution on the endpoint.
- Data Theft or Session Compromise Confirmed: Tangible evidence proves the attacker acquired and reused sessions or accessed data without authorization. Authentication success alone does not prove subsequent email theft.
- Follow-On Compromise Confirmed: Audit logs confirm post-compromise actions, such as malicious inbox rules, OAuth consent grants, or internal phishing.
9. 攻击评估标准
推论： 内部事件评估标准。这些阶段并不意味着每个组织都经历了各个级别的损害。
- 观察到攻击尝试（未确认成功）： 仅发送或访问诱饵 URL 并不能证明凭据已被输入或账户已被入侵。
- 确认用户操作： 用户陈述或保留的浏览器痕迹证实凭据已输入到虚假网站中。
- 确认恶意软件执行或身份验证成功： Microsoft 端的身份验证成功与虚假网站上的输入相对应。身份验证成功不被视为终端上的代码执行。
- 确认数据窃取或会话入侵： 有形证据证明攻击者获取并重用了会话，或未经授权访问了数据。仅凭身份验证成功并不能证明随后发生了电子邮件窃取。
- 确认后续入侵： 审计日志确认了入侵后的操作，例如恶意收件箱规则、OAuth 同意授权或内部钓鱼。
10. Investigation Playbook
Inference: Investigation steps based on publicly documented attack mechanics:
- Trigger: Phishing URLs, lookalike Microsoft domains, URL redirects, and residential proxy connections.
- Initial Review: Identify affected users, lure URLs, input timestamps, and applied authentication strength and Conditional Access rules.
- Endpoint: Verify browser history to the fake site and confirm user actions. Do not assume endpoint malware is present.
- Identity & Cloud: Review related accounts, sessions, registered keys, API operations, and tenant administrative settings.
- Follow-On Actions: Search for outbound connections, data access, persistence, privilege escalation, and lateral movement.
- Containment: Require phishing-resistant MFA (FIDO2/WebAuthn). Add compliant devices, device attestation, user risk, and authentication strength to Conditional Access. In addition to password resets, revoke all sessions and refresh tokens, and force re-authentication.
10. 调查手册
推论： 基于公开记录的攻击机制的调查步骤：
- 触发因素： 钓鱼 URL、仿冒 Microsoft 域名、URL 重定向和住宅代理连接。
- 初步审查： 识别受影响的用户、诱饵 URL、输入时间戳以及应用的身份验证强度和条件访问规则。
- 终端： 验证访问虚假网站的浏览器历史记录并确认用户操作。不要假设终端一定存在恶意软件。
- 身份与云： 审查相关账户、会话、注册密钥、API 操作和租户管理设置。
- 后续行动： 搜索出站连接、数据访问、持久化、权限提升和横向移动。
- 遏制： 要求使用防钓鱼 MFA（FIDO2/WebAuthn）。将合规设备、设备证明、用户风险和身份验证强度添加到条件访问中。除了重置密码外，还应撤销所有会话和刷新令牌，并强制重新进行身份验证。