BigBear 2.0 Evilginx2 Phishing Campaign: How Attackers Bypassed Microsoft 365 MFA With Session Cookie Theft
Quick Answer: BigBear 2.0 is an Evilginx2-based phishing-as-a-service that proxies real Microsoft 365 logins, then steals the authenticated session cookie issued after MFA — letting attackers hijack accounts without ever knowing the one-time code.
Last verified: September 11, 2026
Picture a SOC analyst pulling up a sign-in alert at 2 a.m. Multi-factor authentication succeeded. The device looked normal. The IP address even matched the user's home country. Nothing in the log screamed "breach" — except that twenty minutes later, the same account was creating mailbox forwarding rules it had never touched before. This is exactly the pattern CloudSEK's TRIAD researchers say they found while tracking a phishing-as-a-service operation called BigBear 2.0, and it's a pattern that MFA alone was never designed to stop.
Table of Contents
- What Happened: The BigBear 2.0 Campaign
- How Evilginx2-Based AiTM Phishing Actually Works
- Campaign Statistics and Scale
- Indicators of Compromise
- Detection: Hunting for Stolen Session Cookies
- Prevention and Enterprise Vulnerability Management
- Expert Tips for SOC Teams
- FAQ
What Happened: The BigBear 2.0 Campaign
According to CloudSEK's report, TRIAD researchers discovered BigBear 2.0 in June 2026 and managed to gain administrator access to the threat actor's own control panel — an unusually direct window into an active criminal operation. The panel was tied to an operator using the alias "General Boss" and was actively leased out to at least five affiliate operators, each pulling stolen credentials in real time through dedicated Telegram bots.
This wasn't a one-off phishing email blast. It was a functioning phishing-as-a-service (PhaaS) business, complete with its own infrastructure, a multi-tenant panel, and internal metrics tracking conversion rates — the same operational maturity you'd expect from a legitimate SaaS product, just aimed at stealing Microsoft 365 sessions.
How Evilginx2-Based AiTM Phishing Actually Works
BigBear 2.0 is built on Evilginx2, a well-known open-source adversary-in-the-middle (AiTM) framework. Understanding why it defeats MFA requires separating two things people often conflate: authenticating a user, and trusting a session afterward.
Here's the flow, in plain terms:
- A victim clicks a link in a phishing email that leads to a domain the attacker controls.
- Instead of showing a fake login page, the Evilginx2 proxy relays the victim's traffic to the real Microsoft login endpoint. The page the victim sees is genuinely coming from Microsoft — just routed through the attacker's server.
- The victim enters their password. Microsoft validates it. The victim then completes their normal MFA step — a push approval, an OTP, whatever their organization enforces.
- Once Microsoft is satisfied, it issues an authenticated session cookie back to the browser. Because the proxy sits in the middle of that exchange, it silently copies the cookie before passing the response along.
- The attacker replays that cookie in their own browser and steps directly into the live session — Outlook, Teams, SharePoint, OneDrive, and any connected single sign-on app — without needing the password or MFA code again.
Per CloudSEK's technical write-up, BigBear's specific phishlet — codenamed "offy" — went further than a stock Evilginx2 deployment. Researchers say it included custom JavaScript injections that:
- Actively discouraged FIDO2/WebAuthn security key prompts, pushing victims toward weaker, phishable MFA fallback methods.
- Attempted to suppress Microsoft's own canary-token and anti-phishing telemetry.
- Auto-selected "Keep me signed in," extending how long a stolen cookie would remain usable.
The operation also reportedly used residential proxies matched to each victim's country, which can make attacker traffic look geographically consistent with the real user — a detail that specifically undermines location-based Conditional Access rules that many enterprise security teams rely on.
Campaign Statistics and Scale
Numbers matter here because they show this wasn't a niche experiment. Per CloudSEK's disclosure, the panel logged the following before researchers observed the operator beginning to delete VPS infrastructure — apparently in response to detection:
| Metric | Reported Value |
|---|---|
| Total stolen records | 5,137 |
| Plaintext passwords | 1,032 |
| Session cookies | 4,148 |
| Complete MFA-bypassed sessions | 474 (~9.2%) |
| Organizations affected | 461 |
| Unique victim IPs | 3,331 |
| Countries reached | 40+ |
| VPS nodes observed | 42 (mostly Vultr-hosted) |
| Affiliate operators identified | 5+ |
Researchers noted that IT services and managed service providers made up the single largest affected sector — a targeting choice that raises the stakes considerably, since a compromised MSP account can become a launchpad into every downstream customer environment it has privileged access to.
Indicators of Compromise
CloudSEK published a full indicator set alongside its report. A representative sample is below — all IPs and domains are defanged. Re-fang these only inside a controlled threat-intel platform such as MISP, VirusTotal, or your SIEM before using them operationally.
| Type | Indicator | Description |
|---|---|---|
| IP | 38[.]60[.]250[.]157 | BigBear 2.0 VPS node |
| IP | 95[.]179[.]233[.]79 | BigBear 2.0 VPS node |
| Domain | konceptenterprises[.]com | Phishing domain |
| Domain | rootreseller[.]com | Phishing domain |
| Filename | cookie.js | Credential/session-processing script |
| HTTP header | x-evg-token / x-evg-session | Evilginx2 application headers |
| Cookie | bigbear_session / bigbear_token | BigBear-specific session/token cookies |
The full IoC list, including all 40+ historical and active VPS nodes plus Telegram bot identifiers, is available in CloudSEK's original technical report.
Detection: Hunting for Stolen Session Cookies
Traditional sign-in alerting misses AiTM attacks because, from Microsoft's perspective, the authentication itself was legitimate. Detection has to shift toward session behavior rather than the login event alone. A few patterns SOC teams should build hunts around:
- Impossible travel on an already-authenticated session — the same session token used from two geographically distant IPs within a short window.
- Token replay with a mismatched device fingerprint — session reused on a browser/OS combination that never performed the original interactive sign-in.
- Post-auth mailbox rule creation — new inbox forwarding rules or transport rules created shortly after a sign-in, a common next step after session hijack.
- New OAuth application consent grants immediately following a sign-in from an unfamiliar network.
A starting KQL query for Microsoft Sentinel/Defender to flag session token reuse across inconsistent locations looks like this:
SigninLogs
| where ResultType == 0
| summarize IPs = make_set(IPAddress), Countries = make_set(LocationDetails.countryOrRegion) by UserPrincipalName, AppDisplayName, bin(TimeGenerated, 1h)
| where array_length(IPs) > 1 and array_length(Countries) > 1
This query groups successful sign-ins by user and app within a rolling one-hour window and flags any case where the same session activity spans multiple IP addresses and countries — a strong signal of cookie replay rather than a normal single-device login. Treat any hit as a starting point for investigation, not automatic confirmation of compromise; expected causes like VPN split-tunneling or mobile carrier IP rotation can also trigger it, so validate against device compliance and app-consent logs before escalating.
Prevention and Enterprise Vulnerability Management
The uncomfortable truth in this campaign is that MFA did exactly what it was supposed to do — it just wasn't enough on its own. Effective defense against AiTM phishing means treating identity as infrastructure, not a checkbox:
- Phishing-resistant authentication — FIDO2 security keys or platform passkeys bind the login cryptographically to the legitimate domain, which makes a proxied lookalike page far less useful to an attacker.
- Conditional Access with device compliance — require managed, compliant devices for sensitive apps rather than relying on location or IP reputation alone.
- Shorter session token lifetimes and continuous access evaluation reduce the window a stolen cookie remains usable.
- Enterprise vulnerability management and endpoint detection and response (EDR) tooling that flags anomalous OAuth consent and mailbox-rule changes, not just malware signatures.
- Email filtering that inspects sign-in look-alike links, even when they present a valid TLS certificate — certificate validity says nothing about domain intent.
If a stolen cookie is confirmed or suspected, treat it as an identity incident: revoke all active sessions and refresh tokens for the account, force re-authentication, reset the password regardless of whether it appears in the stolen dataset, and audit for new forwarding rules, OAuth grants, and unfamiliar application access before considering the incident closed.
Expert Tips for SOC Teams
- Don't wait for a full incident to prioritize passkey rollout — start with your highest-privilege accounts (IT admins, help desk, MSP technicians) since they were disproportionately targeted in this campaign.
- Bake "session cookie theft" into your tabletop exercises. Most teams still rehearse password-compromise scenarios far more than session-hijack scenarios, even though the latter is now the more common real-world path.
- When reviewing sign-in logs, cross-reference user-agent strings against known device history — Evilginx2 proxy traffic often shows subtle inconsistencies here that a busy analyst can miss on a quick glance.
Related Cybersecurity Topics You Should Explore
- Veradigm Data Breach: How a Stolen Vendor Login Exposed Patient SSNs
- Hackers Hide Windows Backdoor Inside HiveMQ and Element Chat
- Plex Emailed Users Over Hidden Security Flaws — Update Now
- TP-Link Archer AX55 Flaws Let Hackers Steal Admin Access
- Trezor ShipMonk Breach Widens to 80,000+ US Customers
- Microsoft Teams QR Code Protection: What Changes in October 2026
- Dahua Camera Backdoor Survives Password Resets and Factory Resets
- Is Your Driver's License for Sale? 153 Million Records Leaked, FBI Investigates
- QR Code Phishing Just Hit Record Levels: What SOCs Must Know Now
FAQ
Is BigBear 2.0 a new vulnerability in Microsoft 365?
No. It doesn't exploit a flaw in Microsoft's code — it abuses the trust placed in an already-authenticated session by stealing the session cookie itself.
Does MFA stop this attack?
Standard MFA methods like SMS codes, authenticator app OTPs, and push approvals do not stop AiTM cookie theft, because the attacker lets the victim complete MFA normally and then steals the resulting proof of authentication.
What actually stops it?
Phishing-resistant authentication such as FIDO2 security keys or passkeys, since these cryptographically bind the login to the legitimate domain and are far less effective to proxy.
Who was targeted?
Per CloudSEK's report, 461 organizations across 40+ countries were affected, with IT services and managed service providers representing the largest targeted sector.
Is BigBear 2.0 still active?
CloudSEK reported the operation was still active at the time of its investigation, though the operator had begun deleting VPS nodes, which researchers interpreted as an attempt to evade further detection.
How can I tell if my session was hijacked?
Look for sign-ins with no corresponding user-reported activity, new mailbox forwarding rules, unfamiliar OAuth app consents, or the same session token appearing to originate from geographically inconsistent locations in a short time window.
Conclusion
BigBear 2.0 is a reminder that the phishing threat model has moved on from "steal the password" to "steal the proof that MFA already happened." Evilginx2-based AiTM kits are only getting easier to deploy as a service, and CloudSEK's report makes clear this is an active, evolving operation rather than a closed case. If your organization hasn't started moving toward phishing-resistant authentication, this campaign is a solid reason to move that plan up the priority list — not next quarter, but now.
Found this breakdown useful? Share it with your SOC team, and drop a comment if you've seen similar AiTM patterns in your own environment.
Analysis based on SOC monitoring and public threat intelligence review.