Most phishing kits still fail the moment a target has multi-factor authentication turned on. BigBear 2.0 does not. Researchers on CloudSEK’s TRIAD team found the operator’s control panel and got into it directly, and what they saw was a Microsoft 365 credential-theft operation built specifically to survive MFA, at a scale that had compromised 258 organizations by the time the report went public.
Getting Inside the Operator’s Own Panel
BigBear 2.0 is an Evilginx2-based adversary-in-the-middle kit, a rebrand of an earlier tool sold under the same name. Evilginx2 works as a reverse proxy: the victim clicks a link, lands on a page that mirrors Microsoft’s real login flow pixel for pixel, and every field they type, password and one-time code alike, passes through the attacker’s server on its way to Microsoft’s actual servers. Microsoft issues a real session, and the proxy captures the session cookie along with it. CloudSEK’s researchers found that BigBear runs a single phishlet, built exclusively for Microsoft 365, and tracked the operation across 42 VPS nodes over the campaign’s lifetime, the bulk of them hosted through Vultr. Inside the panel itself sat the operation’s own numbers: 5,137 stolen credential records, 1,032 of them still in plaintext, 4,148 captured session cookies, and 474 completed post-MFA authentications logged against 3,331 distinct victim IP addresses.
Three Additions That Make the Difference
Stock Evilginx2 already defeats basic MFA by relaying the code in real time. BigBear’s operators layered three custom injections on top of it that specifically target the defenses organizations add after they think MFA has solved the problem. One blocks the prompt for FIDO2 and WebAuthn hardware keys, forcing the login flow to fall back to a phishable method like an SMS code or an authenticator app push. Another suppresses the telemetry and canary-token signals Microsoft uses to detect that a login is passing through a proxy rather than a real browser. The third auto-selects “Keep me signed in,” which stretches how long a stolen session cookie stays valid before it needs to be refreshed. None of these are exotic zero-days. They are small, deliberate edits aimed at the exact controls a security team would point to as proof their MFA program is solid.
Matching the Victim’s Own Location
The kit routes login attempts through geo-matched residential proxies spanning 69 countries, picking an exit IP near the actual victim before the credentials ever reach Microsoft. Impossible-travel and IP-reputation checks are built to catch a login appearing from a data center on the other side of the world seconds after the real user’s last session. When the attacker’s traffic looks like it is coming from the victim’s own city, that entire category of detection has nothing to flag.
Why This Is a DMARC Story, Not Just an MFA Story
A stolen password and a defeated MFA prompt are the headline, but the part that should worry a DMARC program specifically comes after. Once BigBear’s operator has a live session cookie, they have working access to the real mailbox, on Microsoft’s own infrastructure, under the real user’s identity. Mail sent from that access is not spoofed, borrowed, or routed through a lookalike domain. It goes out through the same servers, with the same DKIM key, from the same authenticated account the victim uses every day, and it passes SPF, DKIM, and DMARC because every one of those checks is answering honestly: yes, this mailbox is authorized to send as this domain. A follow-up message built from a hijacked session can also land inside a real, existing reply thread with a genuine colleague or vendor, which is exactly the kind of context a recipient uses to decide a message is safe.
What This Means for Your Program
MFA stops credential stuffing. It does not stop a real-time proxy that relays your MFA code back to the real service the instant you type it. Hardware keys close that gap for a login, but only when the login flow lets the device actually complete its challenge, which is precisely the step BigBear’s FIDO2 injection is built to block.
A compromised mailbox is a DMARC blind spot by definition, because DMARC was never designed to catch it. The protocol verifies that a domain authorized a message. It has no way to verify that the human or process behind an authorized send is still the one your organization trusts.
Session cookie theft deserves the same operational attention as password theft, and most detection programs still under-invest in it. Conditional access policies that force reauthentication on new devices, shortened session lifetimes, and monitoring for impossible or anomalous session reuse all close gaps that a clean DMARC pass will never reveal on its own.
“Keep me signed in” is a convenience feature with a security cost that most users, and many admins, never weigh against each other. Every hour a session stays valid without reauthentication is an hour a stolen cookie keeps working.
The Takeaway
BigBear 2.0 did not beat DMARC. It went around the entire question DMARC answers by taking over an account DMARC already trusts. Two hundred fifty-eight organizations learned that a green authentication result on an outbound message says nothing about whether the person sending it is still the person who should be. As AiTM kits keep adding purpose-built defenses against FIDO2 and telemetry detection, the mailboxes your domain has already authenticated are worth watching as closely as the ones trying to impersonate you.
DMARC confirms that a message was authorized to send as your domain. It cannot tell you when the account doing the sending has been quietly taken over by someone else. Excello Mail gives you continuous visibility into everything sending as your domain, so unusual authenticated activity stands out instead of blending into a passing DMARC report. Sign up for free to Excello Mail and get that visibility in place before an AiTM kit finds the gap first.