BigBear Phishing Bypasses Microsoft 365 MFA at 258 Organizations

A phishing service captured 474 authenticated Microsoft 365 sessions after users completed multifactor authentication, according to research from CloudSEK’s Threat Research and Information Analytics Division. CloudSEK counted at least one completed MFA-bypass compromise at 258 organizations in the BigBear 2.0 panel data.

The vendor research describes an Evilginx2-based adversary-in-the-middle service aimed exclusively at Microsoft 365. BigBear relayed a victim’s sign-in through an attacker-controlled server, collected the resulting session cookie, then offered automated cookie replay to its operators. A valid password plus push, SMS or time-based one-time-password MFA did not stop that relay.

Panel access measured the campaign

CloudSEK says it gained administrator access to the threat actor’s panel in June 2026. That access exposed 42 virtual private server nodes, at least five affiliate operators and real-time Telegram delivery of stolen credentials. The researchers attributed the service to a cybercriminal using the alias General Boss; they found no overlap between the panel metadata and known state-backed groups.

“The panel has exfiltrated 5,137 credential records,” the researchers wrote. That total included 1,032 plaintext passwords, 4,148 session cookies and 474 complete sessions marked as MFA bypasses. The records mapped to 3,331 unique victim IP addresses across more than 40 countries.

The target and compromise counts describe different populations. CloudSEK found 461 organizations in the broader targeting dataset and 258 with at least one completed MFA-bypass compromise. IT services and managed service providers led the sector breakdown at 151 organizations, followed by SaaS and technology at 38, oil and gas at 22, pharmaceuticals at 20 and consulting at 16.

CloudSEK also documented a shrinking infrastructure footprint. The operator had deleted 26 of the 42 observed VPS nodes since late July, and the campaign table showed one active node. The researchers nevertheless described the operation as active when they wrote the report. CloudSEK said it notified law enforcement and affected organizations; the public report did not include a Microsoft response or name the affected organizations.

Proxy captures the authenticated session

The service’s offy phishlet sat between a victim and Microsoft’s legitimate login.microsoftonline.com sign-in host. The victim entered an email address and password into a page relayed through the proxy. Microsoft then validated the user’s MFA action and returned a session token through the same connection, allowing the proxy to capture it before forwarding the response.

BigBear’s panel stored the cookie and exposed an /api/jobs endpoint that replayed captured sessions in bulk. CloudSEK says the panel could also refresh captured credentials to extend access. A replayed Microsoft 365 session can reach the victim’s mailbox, Teams, SharePoint, OneDrive and applications connected through Entra ID, subject to that account’s actual permissions.

The relay does not break MFA cryptography. It lets the real authentication finish and steals the authenticated result. CloudSEK identifies ESTSAUTH for Entra ID and AppSessionId for Outlook Web Access as session artifacts in this flow, and it reports that ordinary TOTP, push, SMS and voice factors remain phishable because the session is issued after the factor succeeds.

Figure details

The figure separates the attack into two consecutive phases. First, a victim submits a password and MFA response through the BigBear proxy, which relays the real Microsoft 365 sign-in and receives an authenticated session. Second, BigBear keeps the captured session cookie, imports it through its replay API and uses the replayed session to reach cloud mailboxes and files. The note distinguishes CloudSEK's measured panel records from victim identities, which the researchers did not publish.

BigBear weakens stronger sign-in

FIDO2 and WebAuthn change the result because the browser binds their cryptographic assertion to the real site origin. A security key or platform authenticator registered to login.microsoftonline.com will not produce the same assertion for an attacker domain. CloudSEK calls this the structural defense against the relay.

BigBear tried to avoid that check. On a live phishing page hosted under the attacker-controlled daengrentacar[.]com domain, researchers found custom JavaScript that set window.__bb_fido_down, replaced PublicKeyCredential with an undefined value and patched navigator.credentials.get and navigator.credentials.create to reject public-key requests. The intended effect was to make the phishing-resistant method appear unavailable so users would choose SMS, TOTP or push instead.

Two other injections extended the same objective. One blocked requests associated with Microsoft telemetry and canary tokens. Another selected the Keep Me Signed In option and triggered the next button after an 800-millisecond delay. These modifications were additions to the BigBear service, according to CloudSEK, rather than features in standard Evilginx2.

The operator also configured 69 country-specific residential proxies. Microsoft sign-in records would therefore show a residential proxy near the victim’s country, not the victim’s actual address or an obvious datacenter host. That can reduce the value of location-only Conditional Access rules. CloudSEK reports this evasion design, but its public evidence does not establish that every proxied sign-in escaped Microsoft’s risk detection.

Match cookies and infrastructure

CloudSEK published application markers that distinguish the service from a generic suspicious sign-in. Web or proxy telemetry can match the headers x-evg-token, x-evg-server and x-evg-session, along with cookies named evginx_session, evginx_token, evginx_admin, bigbear_session and bigbear_token. The report’s Sigma examples treat those strings as high-severity signals, with unknown false-positive rates for the cookie and header rules.

The report lists these attacker-controlled VPS addresses. Search them in DNS, proxy, firewall and identity records as historical campaign pivots; hosting reassignment can produce false positives:

38[.]60[.]250[.]157, 95[.]179[.]233[.]79, 80[.]240[.]27[.]55, 65[.]20[.]103[.]58, 38[.]54[.]124[.]88, 208[.]85[.]20[.]79, 95[.]179[.]169[.]154, 107[.]191[.]46[.]14, 130[.]94[.]82[.]180, 38[.]54[.]124[.]58, 208[.]85[.]18[.]18, 45[.]32[.]147[.]239, 208[.]76[.]222[.]214, 130[.]94[.]82[.]230, 65[.]20[.]102[.]80, 70[.]34[.]208[.]46, 130[.]94[.]113[.]184, 78[.]141[.]193[.]59, 64[.]176[.]72[.]180, 136[.]244[.]114[.]85, 70[.]34[.]244[.]122, 199[.]247[.]10[.]14, 152[.]39[.]137[.]60, 91[.]245[.]235[.]208 and 45[.]32[.]64[.]165.

The associated current and historical phishing domains are:

konceptenterprises[.]com, ccpipharma[.]com, annastudios-paros[.]com, dnsforward[.]com, hotelmidtownsurat[.]com, dataclust[.]com, cifutura[.]com, hoaivt[.]com, dronalms[.]com, virextec[.]com, offtic[.]com, rootreseller[.]com, management[.]michaelmarcotte[.]com, kgsscans[.]com, soil-management[.]com, daengrentacar[.]com, arrmmy[.]com, captelind[.]com, planisteradmin[.]com, hnospascualfadon[.]com, haliotisbar[.]com, knowncontractor[.]com and valtteri[.]net.

The report also says BigBear used the legitimate ipapi.is service to identify datacenter, VPN and proxy addresses before serving a phishing page. Traffic to that shared service is context, not a malicious indicator by itself. Likewise, Telegram is a legitimate platform that the campaign abused for credential exfiltration.

Revoke sessions and verify access

For an account that touched BigBear infrastructure or shows the published markers, reset the password, revoke active sessions and refresh tokens, then force reauthentication. Password rotation alone leaves a captured session available until its token state is invalidated.

Require phishing-resistant FIDO2 or WebAuthn methods for the affected Entra users and enforce Conditional Access that requires a compliant, managed device. A location match is weak evidence here because BigBear deliberately selected residential proxies near the victim. Review sign-in records for new browsers, unfamiliar devices, unusual session reuse and addresses from the published infrastructure set.

Test the recovery with the affected account from a fresh browser session. The expected result is that every pre-response session has stopped working, the user must authenticate again with an origin-bound method, and access fails from an unmanaged device where the policy requires compliance.

BigBear succeeded by carrying a legitimate authentication result across an attacker-controlled boundary. Recovery has to remove that result wherever it still works. A clean password change is only one part of that job; invalidated sessions and enforced origin-bound sign-in are the evidence that the stolen path is gone.