BigBear 2.0 (Sept 2026): 3,331 Microsoft 365 Victims and the End of MFA-Only Defense

On September 9, 2026, CloudSEK’s TRIAD research team published the guts of a phishing-as-a-service operation they had been quietly monitoring since late June. The panel they gained access to held 5,137 credential records, harvested from 3,331 unique victims across 461 organizations in more than 40 countries. The kit’s name inside the community is BigBear 2.0. Its target is Microsoft 365. Its distinguishing feature is that multi-factor authentication did not stop it.

Four hundred and seventy-four of those records were not just passwords. They were fully MFA-authenticated session cookies — the artifact Microsoft issues after a user completes a push-approval or one-time-code prompt. In other words, 474 employees in 461 organizations went through MFA correctly and still had their live Microsoft 365 session hijacked in the moment the token was minted. The attacker walked into inbox, SharePoint, Teams and OneDrive as them, from a browser that already held a valid cookie.

The scale of BigBear 2.0

The numbers CloudSEK pulled from the panel describe a mature commercial operation, not a lone actor.

• 5,137 credential records collected. 1,032 plaintext passwords. 4,148 session cookies. 474 complete post-MFA authenticated sessions — a 9.2 percent conversion from lure to full account takeover.
• 461 unique organizations touched across 40+ countries. Managed service providers and IT services led the sector list at 151 organizations — 32.8 percent of the victim base. One compromised MSP admin cascades to every downstream tenant they manage.
• 42 reverse-proxy nodes, all hosted at The Constant Company LLC (Vultr). 5 named affiliate operators sharing one back-end panel under a lead actor calling themselves General Boss. This is not a hobbyist kit; it is rented software.
• India led the victim country list with 658 records (12.8%), followed by France (463, 9.0%) and Saudi Arabia (353). Every region with a heavy Microsoft 365 footprint is in the dataset.

Why MFA did not save the 3,331 victims

BigBear 2.0 is built on Evilginx2, an open-source adversary-in-the-middle framework. The idea is surgical and boring: instead of building a fake Microsoft login page, the attacker builds a reverse proxy that sits between the victim and login.microsoftonline.com. The victim types their password into what looks like the real page — because it is the real page, being streamed through the attacker’s server. The MFA challenge Microsoft returns is streamed through too. The user completes it against real Microsoft infrastructure. Microsoft issues a real session cookie. And the proxy in the middle copies that cookie into the attacker’s panel on the way past.

The consequence is that every consumer-grade advice column about phishing detection is now wrong:

• “Check for HTTPS” — the proxy has a valid Let’s Encrypt certificate.
• “Look at the login page carefully” — it is the actual Microsoft login page, pixel for pixel, because it is being proxied live.
• “Turn on MFA” — the victims did. Their approved MFA sessions are in the dataset.

The only telltale that survives is the URL in the browser bar — because the domain has to be one the attacker controls, not login.microsoftonline.com. And that is exactly the layer Domainscan reads.

The three quiet-mode tricks that kept the panel alive for months

Evilginx2 on its own is well-known to Microsoft’s detection stack. BigBear 2.0’s operators shipped three custom JavaScript injections on top of it that measurably delayed detection.

1. FIDO2 and WebAuthn killed at the JavaScript layer. Passkeys are the one form of MFA a reverse proxy cannot forward — the cryptographic challenge is bound to the true origin login.microsoftonline.com, so a passkey attempt from login.konceptenterprises.com fails at the browser. BigBear’s injection removes that fallback so the user is silently forced back onto phishable OTP or push. The payload is one line:
   Injected on the proxied login page

   window.__bb_fido_down = true;
   Object.defineProperty(window, 'PublicKeyCredential', { value: undefined });

2. Microsoft telemetry blocked from the proxied page. A fetch / XMLHttpRequest interceptor silently drops any outbound call whose URL matches a blocklist: canarytokens, events.data.microsoft.com, OneCollector. Defender for Cloud Apps, Purview and Microsoft’s own suspicious-session heuristics lose the signal.
3. Auto-KMSI plus geo-matched residential proxies. The kit auto-checks the “Keep me signed in” checkbox and auto-submits with an 800 ms delay, extracting a refresh token that outlasts the immediate session. Traffic is then routed through 69 country-specific residential proxies using ipapi.is to pick an exit IP that matches the victim’s normal geolocation. Impossible-travel alerts do not fire, because the login looks like it is coming from the user’s home city.

Combined, these three shifts let a five-affiliate crew run a campaign that touched 461 organizations and stayed unnamed until CloudSEK pulled the panel apart. The takeaway for defenders is that the attackers have moved past the technical layer where Microsoft can help directly. Detection now depends on the domain, the hosting IP, and the mail plumbing — infrastructure the customer owns.

Where Domainscan starts looking

A phishing-as-a-service operation is domain-heavy by nature. Every affiliate needs a fresh proxy domain, wildcard DNS for the login.* subdomain, an SSL certificate, and a VPS to run Evilginx2 on. That is a fingerprint. Instead of asking does this URL look right, Domainscan asks the questions the proxy cannot lie about.

Reverse-IP and the 42-VPS map

CloudSEK’s reverse-image of the panel names 42 Vultr VPS nodes and a handful of confirmed phishing domains, including login.konceptenterprises.com, login.dnsforward.com, login.dataclust.com, login.offtic.com and login.cifutura.com. Notice what these domains do not contain: the word “microsoft,” “office365,” or any brand-lookalike keyword. Naive brand-monitor keyword filters miss them entirely. What ties them together lives one layer down.

• Single-ASN concentration. All 42 nodes sit inside The Constant Company LLC’s address space. A reverse-IP walk from any one flagged node surfaces the neighbors — the entire fleet, from a single seed.
• Wildcard-login.-subdomain pattern. The base domains are dictionary-sounding (dataclust, offtic, cifutura). The phishing lives on the login. subdomain, served by wildcard DNS. Any Domainscan DNS query on a suspicious base immediately reveals the wildcard.
• Shared certificate authority + issuance velocity. All proxy domains carry a free DV certificate issued within days of the domain’s registration. Certificate Transparency log correlation on the base domain flags the pattern in seconds.

WHOIS velocity and registrar fingerprint

The generic names — dnsforward, dataclust, offtic — read like the output of an English-word combiner precisely because that is what they are. Bulk-registered from a low-cost registrar, paid with the same wallet, spun up in tight time windows around new-affiliate onboarding. Domainscan reads that timeline directly:

• Recent creation_date plus generic-word name plus Vultr A-record is a three-flag composite that a legitimate business almost never satisfies. Any one is noise; all three at once are almost always PhaaS infrastructure.
• Registrar concentration. A handful of bulk registrars are statistically over-represented in Evilginx2 domain sets. The Trust Score composite weights registrar reputation the way credit scoring weights lender history — most of it is background, but the tail is very meaningful.
• Nameserver stability. Legitimate domains sit on the same NS for years. Proxy domains flip NS as takedowns hit — a churn signal Domainscan can trend historically.

Email authentication is the prevention layer nobody wants to talk about

Reverse-proxy phishing starts with a lure email. Almost always, the lure impersonates an internal sender inside the victim organization — the finance team, IT, the CEO — because the click-through rate on an internal-looking “please re-authenticate” message is orders of magnitude higher than on a random spoof. That lure is what a well-configured email authentication stack blocks before the proxy ever comes into play.

• DMARC in p=reject on every domain the organization owns — including parked and marketing subdomains. Not p=none, not p=quarantine. Reject.
• SPF hard-fail (-all), not soft-fail. Managed service providers in the BigBear dataset almost universally ran ~all, which is why the lure emails landed in inboxes instead of getting bounced at the perimeter.
• DKIM key rotation and monitoring. Long-lived, unrotated DKIM keys are a silent liability. An MSP with a stale key across dozens of customer tenants is one leak away from a blanket spoofing disaster.

Prism AI catches the proxy the browser is trying to hide

A reverse proxy’s whole trick is looking identical to the real target. Prism AI is built on the observation that identical is not actually possible — every proxy has to inject something. In BigBear’s case, three somethings: the PublicKeyCredential override, the telemetry blocklist, and the KMSI auto-submitter. All three are JavaScript that does not exist on the real Microsoft login page. Prism AI reads the rendered page and looks for them.

• Origin mismatch on form action. The real Microsoft login form’s actionURL points at Microsoft. A proxied clone’s form action points at the proxy’s own handler. Prism AI follows the form destination and reports the actual endpoint — not the domain the URL bar shows.
• Injected-script fingerprinting. Any script tag whose contents match known Evilginx2 modifications — __bb_fido_down, the fetch-interceptor blocklist, the KMSI auto-submitter — is a hard flag. The signatures propagate to every kit derived from the same codebase.
• Network-destination auditing. Prism AI records every outbound endpoint the page calls. Legitimate Microsoft login pages call a specific, well-known set of Microsoft telemetry endpoints. A page claiming to be Microsoft login that never contacts any of them is either extraordinarily broken or extraordinarily hostile.

What to do this week

CloudSEK named 26 of the 42 Vultr nodes as deleted since late July; 14 or so were still live at publication. Assume the crew is rebuilding. Practical steps in priority order:

1. If you administer Microsoft 365: revoke session and refresh tokens for any user who may have interacted with the campaign (CloudSEK’s recommended mitigation), force re-authentication, and turn on Conditional Access policies that require a compliant device — a stolen cookie without a compliant device is inert.
2. Move MFA to FIDO2 or platform passkeys. This is the one control that Evilginx2 provably cannot forward. Every push, SMS and app-generated-OTP factor is phishable through a reverse proxy; passkeys are not.
3. Monitor for login.<yourbrand>.* registrations. Certificate Transparency log watches on your brand name catch these at issuance, not at first-click. Domainscan’s monitors handle the polling.
4. Enforce p=reject DMARC on every domain you own. The lure email is where the kill chain starts. Break the lure, and the proxy never gets a click.
5. Run a Trust Score on any Microsoft-branded URL you did not initiate yourself. Reverse-IP, WHOIS velocity, SSL age, MX reputation and blacklist — twelve checks that would have flagged the entire BigBear 2.0 fleet on day one.

Source

Primary research from CloudSEK’s TRIAD team, authored by Gagan Aggarwal: Tracking BigBear 2.0: an Evilginx2 phishing campaign — CloudSEK. Secondary reporting from BleepingComputer and The Register. Figures in this post use CloudSEK’s primary panel-extraction numbers; secondary outlets reporting narrower counts (for example “258 organizations”) reflect earlier collection windows.