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

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.

3. Attack Flow

1. The attacker lures the victim to an Evilginx2 AiTM page that clones the Microsoft 365 login screen.
2. 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.
3. The proxy relays entered passwords and MFA responses to legitimate Microsoft servers in real time.
4. After successful authentication, the attacker captures session cookies (such as ESTSAUTH and AppSessionId) and uses "Keep Me Signed In" (KMSI) to extend their lifetime.
5. The attacker reuses the cookies or refresh tokens via residential proxies to access Microsoft 365.

4. Attacker Location and Execution Context

• Remote attackers operating an AiTM proxy positioned between the victim browser and Microsoft 365.

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.

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.

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.

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.

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.

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.
• Scope Categorization: Clearly separate fake site contact, credential input, Microsoft-side authentication success, session compromise, and follow-on activity.

11. Detection and Defense Ideas

Inference: Practical suggestions for security operations:

• Single Event: Flag phishing URLs, lookalike Microsoft domains, URL redirects, and suspicious residential proxy traffic.
• Timeline Correlation: Anchor on fake-site access timestamps and correlate shifts in authentication methods, IPs, and devices with subsequent Microsoft 365 activity.
• Hunting: Look for access from unusual devices or IPs following suspicious authentications, along with changes to inbox rules or OAuth consent. Do not rely solely on an IP address change to confirm compromise.
• Log Limitations: Browser-level API disruption and cookie theft do not appear directly in IdP logs. Connect user reports, URL traffic, and authentication/SaaS audit logs to complete the picture.
• Priority Actions: Enforce phishing-resistant MFA like FIDO2/WebAuthn. Integrate compliant devices, device attestation, risk signals, and authentication strength into Conditional Access. Upon detection, revoke active sessions and refresh tokens alongside password resets.

12. Facts / Inference / Hypothesis

Facts

• CloudSEK tracked BigBear 2.0 infrastructure consisting of 42 VPS servers, residential proxies across 69 countries, and 5 Telegram exfiltration channels.
• Collected datasets contained 5,137 credential records, 474 post-MFA authentications, 1,032 plaintext passwords, 4,148 session cookies, and 3,331 victim IP addresses.
• In CloudSEK metrics, 474 out of 5,137 records are categorized as completed post-MFA authentications. This number does not reflect the number of compromised organizations or data exfiltration events.
• Injected JavaScript disables PublicKeyCredential and navigator.credentials for publicKey to trigger FIDO2/WebAuthn failures and steer users toward alternative MFA.
• The infrastructure blocks Microsoft canary and telemetry requests using fetch/XHR and image elements, and automatically selects KMSI to secure long-lived sessions.
• Under Microsoft specifications, if Conditional Access mandates phishing-resistant authentication strength, only compliant methods are accepted. Successful SMS authentication does not satisfy this requirement.

Inference

• The authentication strength required by the target resource is more critical than merely registering MFA. Permitting relayable alternative methods leaves an opening for this bypass technique.

Hypothesis

No additional hypotheses. Unverified points are listed under Unconfirmed Items and Further Investigation.

13. MITRE ATT&CK Mapping

Inference: Mapping based on public analysis:

• T1566.002 Phishing: Spearphishing Link (High): Luring users to AiTM login pages.
• T1557 Adversary-in-the-Middle (High): Relaying authentication traffic to capture post-MFA session cookies.
• T1539 Steal Web Session Cookie (High): Stealing session cookies such as ESTSAUTH.
• T1078.004 Valid Accounts: Cloud Accounts (High): Accessing Microsoft 365 using stolen sessions.

14. Unconfirmed Items and Further Investigation

• The exact extent of unauthorized access and data stolen across each affected organization.
• The precise number of unique victim organizations after deduplicating records.
• The active lifespan and current revocation status of stolen cookies and refresh tokens.

15. Impact on SOCs and Organizations

In enterprise Microsoft 365 environments, organizations must not only enable MFA, but also ensure that target resources strictly require phishing-resistant authentication strengths. Correlate suspicious URL visits with changes in authentication methods, IP addresses, devices, and subsequent email or file activity. When an account is compromised, administrators should reset the password, revoke all active sessions and refresh tokens, force re-authentication, and investigate post-exploitation actions.

16. Target-Specific Summaries

• For SOC Teams: Differentiate between URL visits, successful logins, session reuse, and data access. Correlate Entra sign-in events with Microsoft 365 audit logs.
• For Administrators: Mandate phishing-resistant MFA like FIDO2/WebAuthn. Enforce compliant devices, device attestation, risk levels, and authentication strength policies in Conditional Access.
• For End Users: If a Microsoft-like login page unexpectedly asks you to switch from FIDO2 to another MFA method, stop and verify the URL. Open the service through a trusted bookmark and report suspicious prompts to your IT team.