BigBear 2.0: why MFA alone may not stop every phishing attack

Phishing attacks are becoming better at copying the sign-in experience people use every day. The latest example is BigBear 2.0, a phishing-as-a-service operation uncovered by CloudSEK researchers.

CloudSEK reports that the campaign targeted hundreds of organisations across more than 40 countries, focusing on Microsoft 365 tenants. Its investigation found an attacker control panel, an affiliate network and phishing infrastructure used to collect credentials and authenticated session cookies. [1]

The campaign matters because it shows how attackers can move beyond stealing a username and password. In an adversary-in-the-middle attack, the fake website sits between the victim and the real Microsoft sign-in service. It relays the login process while capturing information that can be reused by the attacker.

The process described by CloudSEK follows a familiar sequence, with one important difference: the attacker targets the authenticated session as well as the credentials.

1. The user clicks a phishing link. The message may look like a routine request from Microsoft, an administrator or another trusted service.
2. The user reaches a convincing sign-in page. The page is controlled by the attacker, but it can pass the login request through to Microsoft's genuine authentication service.
3. The user enters their credentials. The phishing proxy captures the username and password while passing them to Microsoft.
4. The user completes MFA. The sign-in appears to work normally, so the user may believe the account is protected.
5. The authenticated session is captured. Microsoft issues the session information needed to continue the sign-in. The proxy captures the session cookie before it reaches the user's browser.
6. The attacker replays the session. The stolen cookie can then be used to access resources as an already authenticated user, without prompting for the original MFA step again.

Microsoft describes this type of activity as token theft. If an attacker steals and replays a token issued to a user, they may gain access even after the user has completed multifactor authentication because the authentication requirement has already been satisfied. [2]

No. MFA remains an important control and blocks many common credential attacks. The lesson from BigBear 2.0 is more specific: some MFA methods can still be relayed through a fake sign-in page, and the resulting session can then be stolen.

That is why organisations should treat MFA as one layer of identity protection, not the whole identity strategy.

Microsoft recommends phishing-resistant MFA for high-value and privileged accounts. Methods such as passkeys, FIDO2 security keys and Windows Hello for Business are designed to bind the authentication to the legitimate website or application, making them harder for an adversary-in-the-middle proxy to relay. [3]

Microsoft also provides guidance on protecting tokens and reducing the impact of token theft through controls such as Conditional Access, detection and response measures, and token protection where supported by the environment. [4]

The most useful response is still to stop the attack before a session is created.

• Be cautious with unexpected sign-in links. If an email asks you to log in, open Microsoft 365 through your usual bookmark or approved company route instead of following the link.
• Check the website address. A familiar-looking page does not prove that the site is genuine. Look at the full domain before entering any information.
• Do not approve an MFA request you did not initiate. If an unexpected prompt appears, deny it and report it.
• Do not assume that a successful sign-in means everything is fine. If you entered credentials into a suspicious page, or approved an unexpected MFA request, report it immediately.
• Ask when you are unsure. A message that looks unusual, urgent or out of context should be checked through an approved support or security channel.

If you have already entered details into a suspicious website, do not wait to see what happens. Contact your IT or security team straight away and explain what you clicked, what information you entered and whether you completed MFA.

BigBear 2.0 is a useful prompt for organisations to review the controls around identity, devices, email and incident response together.

Require stronger authentication for higher-risk accounts

Start with privileged administrators, finance teams, executives and other users whose accounts could give an attacker access to sensitive data or systems. Review where phishing-resistant MFA can be introduced, then plan a wider rollout based on user roles, devices and business risk. [3]

Review Conditional Access policies

Check that access decisions take account of more than a password and an MFA result. Policies can be used to assess signals such as user risk, device compliance, location and application access. Microsoft recommends using authentication strengths to define the level of authentication required for different scenarios. [3]

Confirm that token theft is part of the incident response plan

A password reset may not be the only action required after a suspected AiTM attack. Microsoft advises administrators to revoke access and invalidate sessions when responding to a compromised account. The exact sequence should follow your organisation's incident response process, but it should be documented and tested before an incident occurs. [5]

Improve reporting and detection

Users need a simple way to report suspicious emails and websites. Security teams should also know how they will investigate unusual sign-ins, session activity, impossible travel, unfamiliar devices and other signs that a valid session may have been replayed.

Security awareness training and phishing simulations can help people recognise suspicious messages, but they work best alongside technical controls. The aim is not to make employees responsible for stopping every attack. It is to give them a clear route to raise a concern quickly, while the organisation's controls do the rest.

Treat the report as useful security information, even if the user is unsure whether anything happened.

Ask the user to share the original message through the approved reporting route, along with the approximate time, the link they clicked and whether they entered credentials or completed MFA. Avoid asking them to revisit the website. Escalate to the security and compliance team if there is any uncertainty.

Fast reporting gives the organisation more options. It can help security teams revoke sessions, reset credentials, check for suspicious activity and warn other users before the same campaign reaches them.

BigBear 2.0 is a reminder that phishing attacks are targeting the sign-in session, not just the password. MFA remains essential, but organisations also need phishing-resistant authentication, sensible access policies, token protection, monitoring and a well-rehearsed response process.

For users, the safest habit is simple: pause before signing in, use trusted routes to access Microsoft 365 and report anything that feels wrong. If you are unsure, ask. A quick report is easier to handle than a stolen session.

[1] CloudSEK, “Tracking BigBear 2.0 Evilginx2 Phishing Campaign”

[2] Microsoft Learn, “Token theft playbook”

[3] Microsoft Learn, “Require phishing-resistant multifactor authentication for Microsoft Entra resources”

[4] Microsoft Learn, “Protecting tokens in Microsoft Entra ID”

[5] Microsoft Learn, “Revoke user access in an emergency in Microsoft Entra ID”