These questions started showing up in our security Slack channel after CloudSEK's BigBear 2.0 report landed. The operation harvested 5,137 credential records and 4,148 session cookies from 461 organizations, with 474 records showing successful post-MFA session capture. What made people nervous wasn't just the scale, it was realizing that MFA completion doesn't mean the session stays secure.
Here's what identity governance administrators are asking, and what you need to know.
Q: They're stealing sessions AFTER MFA? How does that work?
The attack sits between your user and Microsoft's authentication service using a reverse proxy. Your user signs in, completes MFA, and Microsoft issues an authenticated session cookie. The phishing infrastructure intercepts that cookie. Now the attacker can reuse the session without touching credentials or triggering another MFA prompt.
BigBear 2.0 uses Evilginx2 for this. It's not new, but it's now packaged as a service, allowing more operators to run these attacks without deep technical expertise.
The residential proxy layer makes it harder to catch. BigBear 2.0 selects proxies matching the victim's country, so the malicious session traffic looks geographically consistent with legitimate use. Your Conditional Access location policies might not flag it.
Q: If we enforce MFA everywhere, aren't we protected?
Not against this. One-Time Password, SMS, and push-based MFA all fail here because the attacker lets your legitimate user complete authentication. They're not stealing the password or the One-Time Password, they're stealing what Microsoft gives you after you prove you're legitimate.
You need phishing-resistant authentication: FIDO2/WebAuthn passkeys, Windows Hello for Business, or certificate-based authentication. The key word is "enforce." If you offer FIDO2 as an option but still allow SMS or push as fallbacks, attackers will steer users toward the weaker method. CloudSEK found custom code in BigBear 2.0 designed to disable FIDO2/WebAuthn on phishing pages.
Configure Conditional Access authentication strengths to require phishing-resistant methods for high-risk scenarios. Don't just make them available, make them mandatory where it matters.
Q: We already use Conditional Access. What else do we need to do?
Enable Continuous Access Evaluation (CAE) and token protection where Microsoft 365 supports them. CAE allows Microsoft to revoke access in near real-time when risk conditions change, rather than waiting for the token's natural expiration. Token protection binds tokens to the device that requested them, making replay harder.
But understand the coverage gaps. Token protection doesn't work uniformly across all platforms, clients, and workloads. Don't treat it as complete protection, treat it as one control in a layered defense.
The bigger operational problem: your identity and access management tools probably aren't well integrated with your SIEM or security operations center. When a session gets hijacked, the signals exist in Entra ID logs, but if your SOC analysts can't see them or don't know what they mean, detection fails. You need to bridge that gap, either by feeding Entra sign-in logs and risk detections into your SIEM, or by ensuring your identity team has a direct line to incident response.
Q: How do we respond if we think a session was hijacked?
Don't just reset the password. That leaves the compromised session active.
Disable or contain the account immediately. In Entra ID, revoke all sign-in sessions and refresh tokens. Force reauthentication. Then start investigating what happened during the compromised session.
Check Microsoft 365 audit logs for:
- Mailbox access patterns (unusual folders, export activity)
- New inbox rules (forwarding, deletion, moving messages to obscure folders)
- OAuth application consent grants
- Newly registered MFA devices
- Changes to user privileges or group memberships
- Access to other connected cloud applications
Don't rely on IP geolocation to clear someone. Residential proxies make attacker traffic look like it's coming from the victim's country. Focus instead on behavioral anomalies: what was accessed, when, and in what sequence.
Determine whether the compromised session was used to reach other employees, customers, or external contacts. CloudSEK identified 151 IT services and managed service providers among targeted organizations. If your environment includes privileged access to customer systems, the blast radius extends beyond your own tenant.
Q: Should we treat session cookies and tokens like credentials now?
Yes. Session cookies, access tokens, and refresh tokens are authentication material. They grant access without requiring a password or MFA prompt. If you're protecting credentials but not treating tokens with the same care, you're leaving a gap.
This means:
- Monitoring for unusual token issuance patterns
- Alerting on token replay from unexpected locations or devices (even when proxies obscure this)
- Shortening token lifetimes where feasible
- Ensuring token revocation actually works in your environment
Most enterprises still gear their controls toward detecting credential theft, phishing simulations, password spray alerts, brute-force lockouts. Those controls don't help when the attacker already has an authenticated session.
Q: What should we add to our tabletop exercises?
Run a scenario where an authenticated Microsoft 365 session is hijacked after successful MFA. Don't assume credential theft, assume the attacker already has a valid session.
Test how your identity, security operations, messaging, and cloud infrastructure teams would coordinate. Who revokes the session? Who investigates the mailbox? Who checks for lateral movement into other cloud apps? Who communicates with affected users or customers?
These gaps don't surface in ransomware or credential-theft scenarios because the response playbooks are different. Session hijacking sits in a weird middle ground where identity and SOC teams both have responsibilities, and the handoff often isn't clear.
Where to go for more
Review Microsoft's documentation on Conditional Access authentication strengths and Continuous Access Evaluation. If you're not already collecting Entra ID sign-in logs and risk detections in your SIEM, start there. And if you're still offering SMS or push MFA as primary methods for privileged accounts, it's time to migrate to FIDO2 or certificate-based authentication, not as an option, but as a requirement.
