Multi-factor authentication was supposed to be the lock that even a phished password could not open. BigBear 2.0 just kicked that door off its hinges. Researchers at CloudSEK’s Threat Research and Intelligence Automation Division (TRIAD) have dismantled a commercial phishing-as-a-service (PhaaS) operation that compromised Microsoft 365 accounts at 258 distinct organizations across more than 40 countries — defeating MFA in real time on every single victim. And if you are running IT infrastructure in India, this story is personal: India recorded the highest share of victims in the entire dataset.

Key Takeaways

  • BigBear 2.0 is an Evilginx2-based adversary-in-the-middle (AiTM) PhaaS that intercepts Microsoft 365 credentials and authenticated session cookies in real time.
  • It bypassed MFA at 258 organizations, capturing 5,137 credential records from 3,331 victim IP addresses across more than 40 countries.
  • India accounts for the largest country share of victims; IT services firms and managed service providers (MSPs) were the primary targets.
  • Custom JavaScript injections actively disable FIDO2/WebAuthn in the victim’s browser, forcing a fallback to weaker OTP-based MFA that the AiTM proxy can intercept.
  • Geo-matched residential proxies across 69 countries make the authentication traffic look completely legitimate to Microsoft’s risk-scoring engines.
  • No software vulnerability is exploited — the attack abuses the design of web-based authentication flows, making patching alone an insufficient defense.
  • The immediate defense is to enforce phishing-resistant MFA (hardware FIDO2 / passkeys) and enable Conditional Access policies that block token replay.

What Is BigBear 2.0?

BigBear 2.0 is not a piece of malware or an exploited CVE. It is a commercial crime platform — a PhaaS panel leased to at least five affiliate operators who each pay for access to the tooling, infrastructure, and support needed to run large-scale Microsoft 365 account takeover campaigns. CloudSEK’s TRIAD team gained administrator access to the BigBear 2.0 control panel in June 2026 and spent weeks documenting its capabilities before publishing their full technical report on 7 September 2026.

At its core, BigBear 2.0 is a heavily customised Evilginx2 deployment — an open-source reverse-proxy framework originally designed for penetration testing. The operators have written a custom “phishlet” they call offy, tuned specifically to proxy all traffic between a victim and Microsoft’s legitimate login.microsoftonline.com authentication infrastructure. Every credential typed and every session cookie issued passes through the attacker’s relay before reaching Microsoft — giving the platform a live, authenticated session token that survives MFA completion.

According to the CloudSEK report and corroborating analysis from BleepingComputer, the platform managed 42 VPS nodes over the campaign’s lifecycle, predominantly hosted by The Constant Company LLC (Vultr), and maintained credential records for 461 organisations in its database — of which 258 had at least one fully compromised, MFA-bypassed account.

The Technical Anatomy of an AiTM Attack

Understanding how BigBear 2.0 defeats MFA requires understanding the difference between verifying identity and establishing a session. Standard TOTP or SMS MFA protects the login handshake; it says nothing about what happens to the session cookie that Microsoft issues after that handshake completes. AiTM proxies steal that post-authentication cookie, not the MFA code itself.

Here is the kill chain, step by step:

  1. Lure delivery: The victim receives a phishing email with a link to a BigBear 2.0-controlled domain. The domain uses a lookalike or typosquatted name and presents a pixel-perfect Microsoft 365 login page — because it is the Microsoft 365 login page, proxied live.
  2. Proxy interception: The victim’s browser communicates with the BigBear relay, which forwards each request to login.microsoftonline.com and relays the response back. The relay silently strips TLS in the middle, reading all plaintext.
  3. FIDO2 sabotage: Before the victim even sees the login form, BigBear injects custom JavaScript that interferes with the browser’s WebAuthn API. If the victim’s account is configured for FIDO2/passkey authentication — the one method that would defeat an AiTM proxy — the JavaScript throws an error and redirects the flow to a weaker fallback (TOTP or SMS). Microsoft’s server-side logic accommodates this gracefully, allowing the downgrade.
  4. Credential and OTP harvest: The victim types their password and OTP. Both are logged in real time to the BigBear panel, which the affiliate operator is watching.
  5. Session cookie theft: Microsoft completes authentication and issues a session cookie. The proxy captures it before forwarding to the victim’s browser. The victim believes they logged in normally; the operator now holds a valid, MFA-authenticated session token.
  6. Token replay: The operator loads the stolen cookie into their own browser or automated tooling and gains full access to the victim’s Microsoft 365 environment — email, SharePoint, Teams, OneDrive — with no further authentication required.
Attack Component Technology Used Purpose
AiTM Proxy Evilginx2 + custom “offy” phishlet Intercept credentials and session cookies
FIDO2 Sabotage Injected JavaScript (WebAuthn API manipulation) Force downgrade to weaker OTP MFA
Geolocation Cloaking Residential proxies in 69 countries Match victim’s IP to bypass Microsoft risk scoring
Infrastructure 42 VPS nodes (primarily Vultr) Scalable, distributed operation
Panel Multi-tenant PhaaS (5+ affiliate operators) Credential management and real-time monitoring
Token Replay Captured session cookies Persistent, MFA-exempt access to M365

Why India Is the Hardest-Hit Country

The CloudSEK report identifies India as the country with the largest share of victims in the 3,331-record victim IP dataset. This is not accidental. Several structural factors make India disproportionately attractive to BigBear-style campaigns:

  • IT services and MSP concentration: India hosts a dense ecosystem of IT services providers, BPOs, and managed service providers — precisely the segment BigBear most frequently targets. A compromised MSP account often cascades into access to dozens of downstream clients.
  • Rapid Microsoft 365 adoption with legacy MFA: Many Indian enterprises migrated to M365 during the pandemic and configured SMS or TOTP MFA — which is exactly what BigBear’s FIDO2-downgrade attack is designed to circumvent.
  • High-value supply-chain targets: Indian IT firms serve Fortune 500 clients globally. Credential access to their Microsoft tenants is a gateway to sensitive client data and proprietary source code.
  • Awareness gap on AiTM techniques: Most Indian security teams are still calibrated against credential-stuffing and classic phishing. The AiTM paradigm — where MFA is not “hacked” but architecturally circumvented — remains poorly understood outside specialist circles.

This finding should be a wake-up call for every CIO and CISO in the subcontinent. The traditional advice to “turn on MFA” is no longer sufficient. The question is now: which type of MFA, and what compensating controls are in place for the session that follows authentication.

What You Should Do — Sanjay Seth’s Expert Recommendations

Having spent three decades hardening enterprise networks across India, including zero-trust deployments and perimeter replacements for organisations from BFSI to manufacturing, here is what I advise any Microsoft 365 administrator to action immediately:

1. Enforce Phishing-Resistant MFA — No Exceptions

TOTP authenticator apps and SMS OTPs are defeated by AiTM proxies. Deploy FIDO2 security keys (YubiKey, Microsoft Entra Passkeys, Windows Hello for Business) for all privileged accounts and as many user accounts as operationally feasible. These methods bind the authentication to the legitimate domain at the browser level — an AiTM proxy cannot intercept them because the credential never leaves the legitimate origin context. BigBear’s own JavaScript injection targets this protection, so ensure your Conditional Access policies require phishing-resistant MFA methods and block fallback to weaker alternatives.

2. Enable Continuous Access Evaluation and Token Binding

Microsoft Entra ID’s Continuous Access Evaluation (CAE) shortens the window during which a stolen session token is useful. Enable it across your tenant and configure token lifetime policies to reduce access token lifetimes. Additionally, evaluate Token Protection Conditional Access policies (GA as of 2025) which bind tokens to the device on which they were issued — a token stolen by BigBear from one machine cannot be replayed on another.

3. Deploy Microsoft Defender for Cloud Apps Anomaly Detection

AiTM session hijacks leave detectable artefacts: the authenticated session originates from a residential proxy IP in a country that may not match the user’s usual location, immediately after a login from the victim’s real IP. Configure Defender for Cloud Apps (formerly MCAS) to alert on impossible travel and token-replay-pattern anomalies. Pair this with Microsoft Entra ID Protection risk policies that automatically require step-up authentication when risk is flagged.

4. Segment and Monitor Privileged M365 Access

Not all Microsoft 365 accounts carry the same blast radius. Apply Privileged Identity Management (PIM) so that Global Admin and Exchange Admin roles require just-in-time elevation with approval. This means that even a fully hijacked standard user account cannot be used to grant persistent admin access without triggering a separate approval workflow.

5. Audit Your Conditional Access Policies for Gaps

Run a Conditional Access policy audit looking for: (a) policies that allow “any MFA method” — replace with a policy requiring Authentication Strength set to Phishing-resistant MFA; (b) legacy authentication protocols (IMAP, SMTP Auth, POP3) still enabled — block them entirely; (c) named locations and trusted networks — verify these are current and narrow. A misconfigured CA policy is the gap that AiTM campaigns most commonly exploit.

For a comprehensive assessment of your Microsoft 365 identity posture and zero-trust readiness, including Conditional Access audit and FortiGate perimeter integration, book a consultation with our team at P J Networks. We have helped organisations across Delhi NCR and nationally to move from legacy MFA to phishing-resistant identity architecture — before the attackers arrived.

You may also want to review our earlier analysis of authentication bypass trends in enterprise remote access infrastructure, which shares structural similarities with the BigBear attack model.

The Broader Threat: PhaaS Is Democratising Enterprise Compromise

BigBear 2.0 is symptomatic of a broader shift in the criminal threat landscape. AiTM frameworks like Evilginx2, Modlishka, and Muraena have been available to red teamers for years. What BigBear represents is their commercialisation and packaging into affiliate-friendly crime platforms — analogous to ransomware-as-a-service, but for identity theft.

The implications for enterprise security teams are profound. You are no longer defending against a sophisticated nation-state actor with custom tooling. You are defending against an affiliate operator who paid a subscription fee to access a turnkey platform that handles proxy infrastructure, phishlet updates, credential management, and customer support. The barrier to conducting a sophisticated AiTM campaign against your Microsoft 365 tenant is now comparable to the barrier to setting up a small e-commerce business.

The CloudSEK TRIAD report is essential reading for any identity security team. Pair it with Microsoft’s guidance on defending against AiTM phishing attacks and the BleepingComputer technical write-up for a complete picture.

Frequently Asked Questions

Does BigBear 2.0 exploit any software vulnerability or CVE?

No. BigBear 2.0 does not exploit a vulnerability in the traditional sense — there is no CVE, no patch, and no software to update to close the attack vector. The campaign abuses the design of web-based authentication flows: specifically, the fact that Microsoft 365 session tokens are browser-resident cookies that can be stolen and replayed from any device. The FIDO2 downgrade is achieved through JavaScript injection on a page the attacker controls, not through a browser vulnerability. This is why defensive measures must focus on identity architecture and Conditional Access policy, not patch management.

If I already enforce MFA, am I protected?

Only if your MFA method is phishing-resistant. TOTP authenticator apps (Google Authenticator, Microsoft Authenticator in push-notification mode) and SMS OTPs are not protected against AiTM attacks — they verify the login attempt but cannot prevent session cookie theft after authentication. Only FIDO2/WebAuthn hardware keys or passkeys bound to the legitimate domain provide protection, because they cryptographically verify the origin domain and will refuse to authenticate against a proxy. Additionally, Microsoft Entra’s Token Protection policies add a device-binding layer that defeats token replay even if the session cookie is stolen.

How do I know if my organisation has already been compromised by BigBear or similar PhaaS attacks?

Review your Microsoft Entra ID sign-in logs for: (a) successful authentications followed immediately by token use from a different IP address or geographic region; (b) sign-ins from residential VPN or proxy ASNs such as Vultr, The Constant Company, or common residential proxy providers; (c) sign-ins where the MFA method used was TOTP or SMS for accounts that should be using passkeys. Microsoft Defender for Cloud Apps should surface impossible-travel and token-replay alerts automatically if your policies are correctly configured. Threat intelligence feeds can also be cross-referenced against known BigBear infrastructure indicators published in the CloudSEK report.

Are other cloud platforms — Google Workspace, Salesforce, AWS — equally at risk?

Yes. The AiTM technique is platform-agnostic. BigBear 2.0’s current implementation targets Microsoft 365 exclusively via the offy phishlet, but Evilginx2 supports phishlets for virtually any web-based application, including Google Workspace, Salesforce, GitHub, and AWS Console. The CloudSEK report notes that the BigBear operators appear to be expanding their phishlet library. Any organisation relying on web-based SSO or OAuth flows without phishing-resistant MFA and token-binding controls is structurally vulnerable to this class of attack regardless of platform.

The BigBear 2.0 campaign is not an abstract threat-intelligence briefing. With India recording the highest victim share in the dataset and IT services firms explicitly identified as the primary target segment, this is an active, ongoing operation targeting organisations that may include your company, your clients, or your supply chain partners.

The era of “turn on MFA and you’re done” is over. Identity security now requires phishing-resistant authentication, token-binding controls, Conditional Access depth, and continuous monitoring of post-authentication session behaviour. These are achievable — but they require deliberate architectural decisions, not default configurations.

If you want a clear picture of your Microsoft 365 identity exposure and a roadmap to phishing-resistant zero-trust authentication, contact our team at sanjayseth.com/contact/ for a security assessment. We work with organisations across India and the region to build defences that match the sophistication of the threats they actually face today.