BigBear 2.0 (September 2026) — 3,331 Microsoft 365 victims, 474 MFA-authenticated sessions stolen, and the end of MFA-only defense.

The numbers CloudSEK pulled from the panel describe a mature commercial operation — five affiliate operators, one shared back-end, and a lead actor calling themselves General Boss.

• 5,137 credential records Comprising 1,032 plaintext passwords, 4,148 session cookies and 474 complete post-MFA authenticated sessions — a 9.2% lure-to-full-takeover conversion rate.
• 461 organizations across 40+ countries IT services and managed service providers led at 151 organizations (32.8% of the victim base). One compromised MSP admin cascades to every downstream tenant.
• 42 Vultr VPS reverse proxies Every node hosted at The Constant Company LLC. Reverse-IP walk from one flagged node surfaces the fleet from a single seed.
• India, France and Saudi Arabia led victim geography India 658 records (12.8%), France 463 (9.0%), Saudi Arabia 353 — every region with a heavy Microsoft 365 footprint appears in the dataset.

BigBear 2.0 is built on Evilginx2, an adversary-in-the-middle framework that streams the real Microsoft login page through an attacker-controlled reverse proxy. The password, the MFA challenge and the resulting session cookie all travel through infrastructure the attacker owns.

• HTTPS is not a signal The proxy carries a valid Let's Encrypt certificate. Browser padlock appears exactly as on the legitimate page.
• The login page is real It is the actual Microsoft page, proxied live. Pixel-for-pixel identical because it is byte-for-byte the same content.
• MFA is real too The one-time code or push is issued by Microsoft, approved by the user, and the resulting session cookie is captured by the proxy on its way back.
• The one surviving telltale The URL in the browser bar. Attackers cannot proxy login.microsoftonline.com from anything other than a domain they own — and that domain is the layer Domainscan reads.

Vanilla Evilginx2 is well-known to Microsoft's detection stack. BigBear 2.0's operators shipped three JavaScript modifications that measurably delayed detection.

• FIDO2 / WebAuthn disabled at the browser layer Passkeys are the one MFA form a reverse proxy cannot forward — the cryptographic challenge is origin-bound. The injection removes PublicKeyCredential from window, forcing the user back onto phishable OTP or push.
• Microsoft telemetry blocked from the proxied page A fetch/XMLHttpRequest interceptor drops outbound calls to canarytokens, events.data.microsoft.com and OneCollector — the endpoints Defender for Cloud Apps, Purview and Microsoft's own suspicious-session heuristics rely on.
• Auto-KMSI plus 69 residential proxies The kit auto-checks Keep-Me-Signed-In and auto-submits with an 800ms delay to extract a refresh token. Traffic is then routed through 69 geo-matched residential proxies using ipapi.is so impossible-travel alerts never fire.

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

CloudSEK named a handful of confirmed phishing domains: login.konceptenterprises.com, login.dnsforward.com, login.dataclust.com, login.offtic.com, login.cifutura.com. None of these contain the words 'microsoft' or 'office365' — brand-keyword monitors miss them entirely. What ties them together is infrastructure.

• Single-ASN concentration All 42 proxy nodes sit inside The Constant Company LLC (Vultr). Reverse-IP walk from any flagged node surfaces the neighbors — the whole fleet from a single seed.
• Wildcard login. subdomain pattern Base domains are dictionary-sounding (dataclust, offtic, cifutura). Phishing lives on the login. subdomain served by wildcard DNS. A Domainscan DNS query on the base immediately reveals the wildcard.
• Certificate Transparency correlation All proxy domains carry a free DV certificate issued within days of registration. CT-log correlation on the base domain flags the pattern in seconds.

Generic-word base names are the output of an English-word combiner because that is what they are. Bulk-registered from a low-cost registrar, paid with one wallet, spun up in tight time windows around new-affiliate onboarding.

• Recent creation_date + generic-word name + Vultr A-record A three-flag composite that a legitimate business almost never satisfies. Any one is noise; all three at once are almost always PhaaS.
• Registrar concentration A handful of bulk registrars are statistically over-represented in Evilginx2 datasets. Trust Score weights registrar reputation the way credit scoring weights lender history.
• Nameserver churn Legitimate domains sit on the same NS for years. Proxy domains flip NS as takedowns hit — a churn signal Domainscan trends historically.

Reverse-proxy phishing always starts with a lure email. Almost always, that lure impersonates an internal sender inside the victim organization — finance, IT, the CEO. A well-configured email authentication stack blocks that lure before the proxy ever comes into play.

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

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.

• Origin mismatch on form action The real Microsoft login form's action URL points at Microsoft. A proxied clone's 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. Signatures propagate to every kit derived from the same codebase.
• Network-destination auditing Legitimate Microsoft login pages call a specific 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.

CloudSEK named 26 of the 42 Vultr nodes as deleted since late July. About 14 remained live at publication. Assume the crew is rebuilding.

• Revoke and re-authenticate For any user who may have interacted with the campaign: revoke session and refresh tokens, force re-authentication, require a compliant device via Conditional Access. A stolen cookie without a compliant device is inert.
• Move MFA to FIDO2 or platform passkeys The one control Evilginx2 provably cannot forward. Push, SMS and app-OTP are all phishable through a reverse proxy; passkeys are not.
• Monitor for login.<yourbrand>.* registrations Certificate Transparency log watches on your brand name catch these at issuance, not at first-click.
• Enforce DMARC p=reject on every domain you own The lure email is where the kill chain starts. Break the lure, break the campaign.
• Trust Score any Microsoft-branded URL you did not initiate 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.

Primary research from CloudSEK's TRIAD team, authored by Gagan Aggarwal: cloudsek.com/blog/tracking-bigbear-2-0-evilginx2-phishing-campaign. Secondary reporting from BleepingComputer and The Register. Figures use CloudSEK's primary panel-extraction numbers; secondary outlets reporting narrower counts (for example 258 organizations) reflect earlier collection windows.