Contain Microsoft 365 session theft

BigBear 2.0 captures Microsoft 365 session material after a victim completes a phishable authentication factor, so changing the password alone does not address an already copied bearer session.

Once theft is suspected, evidence preservation, sign-in blocking, revocation, and replay hunting must begin before access is restored.

This position reflects the Roundtable evidence available through 8 September 2026 and remains qualified because application-specific Microsoft revocation documentation is absent.

Microsoft 365 account holders who complete push, OTP, or another proxyable factor through a BigBear 2.0 or Evilginx2-proxied login face credential and session-cookie capture followed by bearer-session replay.

Microsoft 365 and relying applications that accept the copied session remain exposed until revocation, expiry, or another control makes it unusable.

Identity and security operators must preserve evidence, remove unauthorized grants and persistence, verify each application’s revocation state, and control restoration.

For users required to use FIDO2/WebAuthn without a proxyable fallback, the packet does not show a cryptographic bypass; the reported tactic instead steers users away from that method.

Support — The identity architect’s account of the cited CloudSEK reporting says Evilginx2 proxied the genuine Microsoft 365 login, captured credentials and the resulting session cookie after a phishable factor, and enabled replay of that bearer session.

Support — The moderator’s synthesis confirms that BigBear 2.0 used a downgrade tactic to steer victims away from FIDO2/WebAuthn rather than bypassing WebAuthn cryptography.

Support — The evidence audit found the synthesis and expert discussion consistent in supporting sign-in blocking, session and refresh-token revocation, credential reset, persistence investigation, and phishing-resistant authentication.

Evidence gap — A retrieval record contains only a search summary, not substantive Microsoft documentation that verifies revocation behavior across applications and token types.

The decision scout identified containment as the operational question because BigBear 2.0 uses Evilginx2 to steal Microsoft 365 credentials and post-authentication session material.

The identity architect and moderator resolved the central terminology dispute: this is session theft after a phishable factor, not a cryptographic break of MFA or WebAuthn.

The evidence auditors supported the containment sequence but found no substantive Microsoft documentation verifying revocation behavior across applications and token types.

The boundary reviewer confirmed that qualified defensive guidance was public-safe, the linker found no prior record to update, and the arbiter selected a new operational decision while retaining the vendor-evidence caveat.