CloudSEK Tracks BigBear 2.0 Phishing Campaign Targeting Microsoft 365

CloudSEK Uncovers BigBear 2.0 Phishing-as-a-Service Operation

CloudSEK researchers have uncovered BigBear 2.0, a rebranded Evilginx2-based phishing-as-a-service operation targeting Microsoft 365 users.

According to CloudSEK's investigation, the campaign used a centralized management panel, multiple VPS nodes, residential proxy infrastructure, Telegram-based credential exfiltration and automated session-cookie replay.

The investigation began in June 2026, when CloudSEK's TRIAD team gained access to the threat actor's administration panel. Researchers found that the infrastructure had managed 42 VPS nodes over the campaign lifecycle and was configured primarily to target Microsoft 365 authentication.

CloudSEK says the panel contained 5,137 credential records, including 1,032 captured passwords, 4,148 session cookies and 474 complete authentications where MFA-bypassed sessions were obtained.

The records were associated with 461 organizations and 3,331 unique victim IPs across more than 40 countries, with India, France, Saudi Arabia, New Zealand and Germany among the leading locations identified by the researchers.

The operation also used at least five affiliate operators who received stolen information through dedicated Telegram bots, reinforcing CloudSEK's assessment that BigBear 2.0 operated as a phishing-as-a-service platform.

The Campaign Used Evilginx2 for Adversary-in-the-Middle Phishing

At the center of BigBear 2.0 was an Evilginx2 configuration known as "offy", which CloudSEK found configured specifically for Microsoft 365 authentication.

Unlike traditional phishing pages that simply collect credentials, Evilginx2 can act as an Adversary-in-the-Middle (AiTM) proxy.

The victim is presented with a phishing URL but is then proxied through the attacker's infrastructure toward the legitimate Microsoft authentication service.

The authentication flow observed by CloudSEK works broadly as follows:

1. The victim opens the phishing link.

2. The proxy forwards the authentication request toward Microsoft.

3. The victim enters an email address and password.

4. Microsoft processes the authentication and MFA request.

5. After successful authentication, the proxy captures the resulting session information.

6. The attacker can then replay the captured session.

This means the attacker does not necessarily need to defeat MFA itself. Instead, the attack abuses the authenticated session created after the victim successfully completes authentication.

CloudSEK reports that 80% of password entries observed by the panel resulted in session-cookie capture.

Residential Proxies Helped Hide the Attack Infrastructure

BigBear 2.0 also used a network of country-specific residential proxies.

CloudSEK identified 69 country-specific residential proxies that could automatically match traffic to a visitor's apparent geographic location.

The approach was intended to make authentication traffic appear more consistent with the victim's normal location while also preventing researchers and automated systems from easily accessing the phishing infrastructure.

The panel used ipapi.is to identify datacenter, VPN and proxy traffic and could block those visitors before serving the phishing page.

CloudSEK says this created an additional barrier for security researchers and automated analysis systems.

A Multi-User Panel Supported the Phishing-as-a-Service Model

CloudSEK's investigation found that BigBear 2.0 was not simply a collection of independent phishing servers.

The operation used a centralized panel with administrative and user roles. Researchers identified at least five affiliate operators receiving stolen information through separate Telegram bots.

The panel could manage VPS infrastructure and distribute captured credentials and session information to different operators.

This structure is consistent with a Phishing-as-a-Service (PhaaS) model, where an infrastructure operator provides phishing capabilities to multiple users or affiliates.

CloudSEK assessed the operation as cybercriminal rather than state-sponsored based on the infrastructure and available open-source intelligence.

The report also describes automated processing in which captured information could move from the phishing infrastructure to Telegram notifications and then into a cookie replay workflow.

BigBear 2.0 Added Custom JavaScript Modifications

CloudSEK identified several JavaScript modifications that it says were not part of standard Evilginx2.

The researchers identified three significant injections.

1. FIDO2 and WebAuthn Disablement

The first modification attempted to disable browser support for FIDO2/WebAuthn authentication.

CloudSEK observed JavaScript that changed the availability of PublicKeyCredential and modified credential-related browser functions.

The objective was to prevent the phishing page from using phishing-resistant authentication and encourage fallback to other authentication methods.

2. Anti-Phishing Telemetry Blocking

The second modification attempted to block specific Microsoft telemetry and canary-token-related requests.

The observed code referenced:

['canarytokens', 'events.data.microsoft.com', 'OneCollector']

CloudSEK says the phishing page modified fetch and XMLHttpRequest behavior and used a MutationObserver to remove matching elements.

The reported objective was to interfere with telemetry that could help identify the phishing activity.

3. Automatic "Keep Me Signed In"

The third modification automatically interacted with Microsoft's Keep Me Signed In functionality.

CloudSEK observed code that checked the relevant page element and automatically triggered the associated action after a short delay.

The purpose was to increase session persistence.

These modifications demonstrate that BigBear 2.0 was not relying solely on the default capabilities of Evilginx2. The operators had added custom functionality around authentication, telemetry and session persistence.

Why MFA Did Not Stop the Attack

One of the most important findings in the CloudSEK report is that the campaign did not need to directly break MFA cryptography.

Instead, the AiTM proxy positioned itself between the victim and the legitimate authentication service.

When a victim successfully completes MFA, the legitimate service creates an authenticated session. Because the traffic passes through the attacker-controlled proxy, the session information can potentially be intercepted before it reaches the user's browser.

This creates a fundamental difference between credential theft and session hijacking.

A stolen password can potentially be blocked by MFA.

A stolen authenticated session can allow an attacker to operate as an already authenticated user until that session is invalidated or otherwise prevented from being used.

CloudSEK specifically describes FIDO2 and WebAuthn as resistant to this type of AiTM phishing because their authentication assertions are tied to the legitimate origin.

Technical Infrastructure Helped Conceal the Operation

CloudSEK found that each Evilginx2 instance terminated TLS at the phishing domain before establishing a separate encrypted connection to the legitimate Microsoft service.

This architecture meant that Microsoft could receive authentication traffic from the attack infrastructure rather than directly from the victim's original connection.

The infrastructure also used Let's Encrypt certificates and wildcard DNS configurations for phishing domains.

The centralized panel provided role-based administration and real-time engine-log streaming, allowing operators to monitor phishing activity and captured information.

CloudSEK also observed anti-analysis functionality that blocked traffic associated with datacenter, VPN and proxy infrastructure.

The Campaign Targeted Hundreds of Organizations

CloudSEK identified 461 organizations in the captured records.

The researchers found 438 unique domains spanning more than 40 countries.

The IT Services and Managed Service Provider sector represented the largest identified industry group, with 151 organizations. SaaS and technology organizations followed with 38, while Oil & Gas, Pharmaceuticals and Consulting were also represented.

CloudSEK describes the campaign as combining broad targeting with more concentrated activity against sectors considered valuable because of their access to infrastructure and business systems.

India accounted for 658 records in the report, followed by France with 463 and Saudi Arabia with 353.

CloudSEK says the campaign evolved from an earlier dataset containing 1,442 records and expanded as additional infrastructure and victim organizations appeared in later exports.

What Stolen Sessions Could Expose

According to CloudSEK, captured authenticated sessions could provide access to Microsoft 365 services associated with the compromised account.

Potentially exposed environments included:

• Email and calendars

• Microsoft Teams

• SharePoint Online

• OneDrive

• Entra ID

• Connected SaaS applications

The report highlights risks including business email compromise, data theft, internal phishing and potential movement into connected cloud environments.

For organizations that use Microsoft 365 as an identity layer for other applications, the significance of session theft can extend beyond a single mailbox.

The actual impact of any compromised account, however, depends on its permissions, connected services and the controls applied by the affected organization.

MITRE ATT&CK Techniques Identified by CloudSEK

CloudSEK mapped BigBear 2.0 to several MITRE ATT&CK techniques, including:

The mapping reinforces that the campaign combined phishing, credential capture, session theft, infrastructure acquisition and web-based exfiltration rather than relying on a single technique.

CloudSEK's Recommended Mitigations

CloudSEK recommends several defensive measures for organizations concerned about this class of attack:

• Reset passwords for affected accounts.

• Revoke active session and refresh tokens.

• Force users to authenticate again.

• Enable phishing-resistant MFA such as FIDO2 or WebAuthn.

• Enforce Conditional Access policies.

• Require compliant devices.

The emphasis on session and refresh-token revocation is particularly important because changing a password alone may not address every already-established authenticated session.

Detection: SIGMA Rules From the CloudSEK Report

CloudSEK also published SIGMA detection rules covering BigBear and Evilginx-related indicators.

These rules are useful for defenders because they focus on observable artifacts such as session cookies, custom HTTP headers, known infrastructure and Telegram-based credential exfiltration.

Evilginx and BigBear Session Cookies

title: Evilginx BigBear Session Cookies
id: 0b8d50f4-fc0f-4ef5-9001
status: stable
description: Detects known Evilginx and BigBear session cookies.

logsource:
  category: webserver

detection:
  selection:
    http_cookie|contains:
      - "evginx_session"
      - "bigbear_session"
      - "evginx_admin"

  condition: selection

falsepositives:
  - Unknown

level: high

tags:
  - attack.credential-access

Communication With Known Evilginx Infrastructure

title: Communication With Known Evilginx Infrastructure
id: 0b8d50f4-fc0f-4ef5-9002
status: experimental
description: Detects outbound communication to known Evilginx infrastructure.

logsource:
  category: network_connection

detection:
  selection:
    destination_ip:
      - 130.94.82.180
      - 70.34.208.46
      - 130.94.113.184
      - 78.141.193.59
      - 64.176.72.180
      - 38.54.124.58
      - 208.85.18.18

  condition: selection

falsepositives:
  - IP reassignment

level: critical

tags:
  - attack.command-and-control

Evilginx Custom Headers

title: Evilginx Custom Headers
id: 0b8d50f4-fc0f-4ef5-9003
status: experimental
description: Detects uncommon Evilginx-specific HTTP headers.

logsource:
  category: proxy

detection:
  selection:
    http_headers|contains:
      - "x-evg-"

  condition: selection

falsepositives:
  - Unknown

level: high

tags:
  - attack.credential-access

Telegram Credential Exfiltration

title: Telegram Credential Exfiltration
id: 0b8d50f4-fc0f-4ef5-9004
status: experimental

logsource:
  category: proxy

detection:
  telegram:
    url|contains: "api.telegram.org"

  methods:
    url|contains:
      - "/sendMessage"
      - "/sendDocument"

  secrets:
    http_request_body|contains:
      - "cookie"
      - "session"
      - "password"
      - "credential"

  condition: telegram and methods and 1 of secrets

falsepositives:
  - Approved Telegram automation

level: critical

tags:
  - attack.exfiltration

Multiple Evilginx Indicators

title: Multiple Evilginx Indicators
id: 0b8d50f4-fc0f-4ef5-9005
status: stable

logsource:
  category: webserver

detection:
  cookies:
    http_cookie|contains:
      - "evginx_session"
      - "bigbear_session"

  headers:
    http_headers|contains:
      - "x-evg-"

  condition: cookies and headers

falsepositives:
  - Unknown

level: critical

tags:
  - attack.credential-access

These rules are reproduced from the detection material published by CloudSEK. Organizations should validate them against their own telemetry, logging architecture and SIEM requirements before deployment.

Indicators of Compromise

CloudSEK published defanged indicators associated with the campaign, including VPS infrastructure and phishing domains.

Selected infrastructure indicators include:

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

CloudSEK also identified phishing domains including:

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
kgsscans[.]com
soil-management[.]com

The full IOC list, including historical infrastructure, is available in CloudSEK's original investigation.

What the BigBear 2.0 Campaign Shows About Modern Phishing

The BigBear 2.0 investigation highlights a significant change in the way phishing attacks can operate against cloud identity systems.

The objective is no longer limited to obtaining a username and password.

Instead, attackers can attempt to place themselves between users and legitimate authentication services, capture authenticated sessions and automate the subsequent handling of stolen session information.

The campaign also shows how phishing infrastructure can increasingly resemble a commercial service. A centralized management panel, affiliate access, automated notifications, residential proxy infrastructure and session replay can turn individual phishing pages into a coordinated operation.

For organizations, this means identity security cannot rely on passwords and conventional MFA alone.

Phishing-resistant authentication, session management, Conditional Access, device controls and detection of suspicious authentication infrastructure all form part of the defensive picture.

Analysis: Why Session Security Matters as Much as Credential Security

Analysis: The BigBear 2.0 findings highlight a broader shift in cloud identity attacks from credential theft toward session theft.

An organization may successfully deploy MFA and still face risk if an attacker can manipulate the authentication flow and obtain an authenticated session after the legitimate user completes MFA.

This does not mean MFA is ineffective. Rather, the report demonstrates why organizations need to distinguish between authentication-factor protection and protection of the authenticated session that follows.

For enterprises using Microsoft 365 and other cloud platforms, the practical lesson is to treat session revocation, phishing-resistant authentication and identity telemetry as important parts of incident response.

The report also demonstrates why security teams need to monitor the infrastructure surrounding authentication, not just failed login attempts.

What Organizations Should Do Now

Organizations using Microsoft 365 can review whether their identity controls address AiTM phishing and session theft.

Priority areas include:

Use phishing-resistant authentication.
FIDO2 and WebAuthn provide stronger protection against AiTM attacks because authentication is tied to the legitimate origin.

Review Conditional Access.
Policies should consider device state, authentication strength and other contextual signals rather than relying solely on geographic location.

Have a session-revocation procedure.
Incident-response teams should know how to revoke active sessions and refresh tokens when account compromise is suspected.

Monitor identity activity.
Security teams should investigate unusual authentication behavior, suspicious infrastructure and indicators associated with session theft.

Validate detection rules.
The SIGMA rules published by CloudSEK can provide a starting point for defenders, but they should be tested against each organization's own logging environment.

Conclusion

CloudSEK's investigation into BigBear 2.0 provides a detailed look at how an Evilginx2-based phishing-as-a-service operation can combine AiTM interception, session-cookie theft, residential proxies, custom JavaScript and centralized infrastructure.

The campaign recorded thousands of credentials and session artifacts across hundreds of organizations, while its affiliate-oriented architecture demonstrated how phishing capabilities can be packaged and distributed at scale.

The most important defensive takeaway is that successful MFA does not automatically mean an authentication session is protected from every form of phishing.

Organizations should therefore combine phishing-resistant authentication with strong session controls, Conditional Access, device requirements, identity monitoring and incident-response procedures.

CloudSEK's findings also reinforce the value of threat-informed detection. The included SIGMA rules and defanged indicators give defenders concrete starting points for identifying BigBear and Evilginx-related activity.

The campaign shows that modern phishing increasingly targets the authentication session itself, making identity and session security a central part of cloud defense.