Skip to content
Security & Trust

Stolen session cookies get past MFA, and one Microsoft 365 guide sets out a fix

An IT guide on the Mirage2FA incident says login checks are not enough once the session is stolen

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Stolen session cookies get past MFA, and one Microsoft 365 guide sets out a fix
In brief
  • A technical guide says Mirage2FA stole 4,561 Microsoft 365 sessions despite MFA. It argues that the session cookie, not the login, is what attackers now take.
  • The guide says a password reset alone leaves a stolen cookie valid. Revoke sessions first, and have detection and revocation ready before an incident.
  • It recommends Windows Hello for Business, which ties sign-in to the real Microsoft site. Its figures come from one author's account and lab tests.

Multi-factor authentication checks who you are at the door. It says nothing about what happens to the pass you are handed afterwards. A new technical guide for small-business IT teams is built on that gap.

The guide was published on November 1 by an independent author at doit4everyone.github.io. It is aimed at IT consultants and in-house IT staff who support small firms on Microsoft 365 Business Premium. It is written in French and is dated August 2026. This story reports what that guide says. We have not verified its figures against a second source.

What the guide says happened

The guide describes a phishing-as-a-service platform called Mirage2FA, run by a group it names LinX Coders. It says the platform used a proxy that relays traffic over WebSockets, so the victim sees a normal Microsoft sign-in.

According to the guide, 9,426 Microsoft 365 accounts were targeted on August 20, and 4,561 session thefts were confirmed. That is a success rate of about 48%. The guide says a password reset alone was an insufficient response.

It also cites CVE-2026-69836, which it says Microsoft disclosed on August 21. The guide describes a deserialization flaw in Entra ID, Microsoft's identity service, with a CVSS score of 10.0. It says exploitation was confirmed before the patch. It adds that Microsoft fixed it on its own infrastructure, so customers had no patch to install.

The guide ties these two events together only by timing. It does not claim that the flaw was used in the Mirage2FA attacks.

How the attack works

This kind of attack is called adversary-in-the-middle. The attacker sits between the user and Microsoft. The user types a password and approves the MFA prompt, and both work as designed.

The proxy then keeps the session cookie that Microsoft issues. The guide says that cookie counts as valid proof of identity, whatever method was used to get it. The attacker never needs to break MFA. They collect what MFA produces.

The lesson here is that MFA guards the entrance, while the cookie is the key the attacker walks away with.

Why speed of response matters

The guide stresses a Microsoft feature called continuous access evaluation, or CAE. It lets Microsoft revoke a session within minutes. The guide says it is on by default for Entra ID P1, with no setting to turn on.

It also points out a trade-off. A CAE token lasts 20 to 28 hours, against 60 to 90 minutes for a standard one. The guide says that without active monitoring, CAE can help the attacker.

The author gives timings from tests on a Business Premium tenant. Revoking a session took about one minute on Microsoft's account page. On SharePoint Online through Edge, it took about three to four minutes. The author notes that Firefox and the Outlook web app showed no CAE token in those tests.

The guide's own estimate is that SIEM alerting takes about seven minutes. Without CAE, an attacker could keep a valid cookie for roughly 53 more minutes after revocation. With CAE, it says the window falls below ten minutes.

It also warns about a common mistake. Resetting the password first leaves the cookie valid. Sessions must be revoked first.

The structural fix, and its catch

The guide's stronger answer is Windows Hello for Business, or FIDO2 security keys. With Windows Hello for Business, each sign-in is signed by a key held in the device's TPM chip. FIDO2 keys do the same with a hardware key. The signature covers the site's origin as well as Microsoft's challenge.

A proxy has a different origin from login.microsoft.com. The signature then fails, and Entra ID rejects it. The guide says this protection does not rely on detection or revocation.

There are practical catches. The guide says a cloud-only account cannot sign in to a hybrid-joined Windows PC, which it confirmed in a lab on August 24. The fix it gives is a synced hybrid account on those PCs. It also notes that firmware TPMs hold only 7 to 8 Windows Hello keys. Shared PCs may need a discrete TPM with at least 32.

It also covers Cloud Kerberos Trust. This lets Windows Hello users reach on-premises resources without a password or a certificate authority.

Questions to put to your IT team

Start with logs. The guide says Business Premium keeps Entra ID logs for 30 days by default. Without forwarding to Log Analytics, events before July 22 were already gone when it was written.

Ask your team these questions:

Are Entra ID logs forwarded somewhere that keeps them longer? Can we revoke a user's sessions in minutes, and is that step written down before the password reset? Which licence do we hold? The guide says that without the Defender add-on, risk-based automatic revocation is not available.

Ask which staff, starting with administrators, can move to Windows Hello or FIDO2 keys. Ask which PCs are hybrid-joined and whether the staff who use them have synced (hybrid) accounts.

By the guide's estimates, the exposure after a theft is measured in minutes, if detection is in place. Your response plan should be measured the same way.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: doit4everyone.github.io.