Your MFA Worked. They Still Stole the Session: Mirage2FA and NYC Microsoft 365 Tenants

The bookkeeper on the Staten Island Railway opens an .htm attachment because the subject line says HR updated the 401(k). The page looks like Microsoft. She types the password. The Authenticator prompt on her phone is the same number-match she sees every morning. She approves it. Outlook loads.

Someone else is now in that mailbox. They did not break MFA. They sat in the middle, let Microsoft finish the login, and kept the session cookie Microsoft handed back. In a 15-user midtown or Victory Boulevard tenant, that cookie is the practice: mail, SharePoint, OneDrive, and every app that trusts the same sign-in.

This is not a new CVE. It is not the callback-before-wire problem. It is not Microsoft’s September 2026 passkey default. It is a session-theft kit sold as a service. The researchers who counted it call the toolkit Mirage2FA.

We already wrote about email and identity as the breach path. That post stops at the mailbox. This one is the layer after the second factor succeeds.

What ANY.RUN actually counted

The numbers below are from research by ANY.RUN analysts ShiFu and raptur3, as summarized on August 19, 2026 by Cyber Security News and by Cyber Accord. We did not invent a New York victim count, a law-firm loss, or a MicroSky client incident.

Mirage2FA is a phishing-as-a-service toolkit attributed to LinX Coders. ANY.RUN observed it from September 2024 through July 2026. Tempo rose in 2026; July was the loud month in the sandbox set they published.

They counted 9,426 targeted accounts, 4,532 potential compromises, 3,518 organizations, and activity in 94 countries. Of identified victims, 63.7 percent were in the United States. That share is not a Brooklyn count or a “NYC law firms got hit” claim. Anyone who turns it into one is padding the table.

Of 9,332 logged compromise events, 4,561 — 51 percent — were session-cookie theft, across 2,541 unique victims. Cookie theft is the plurality outcome, not a footnote. Technology accounts were 19.2 percent of victims, manufacturing 11.1 percent, education 9.9 percent. MSSPs show up among the affected. A managed-services login is useful because it already has a path into other tenants. We are not going to invent that your firm’s MSP was one of them.

Delivery is a file the user opens in a browser, not a dropped executable: .htm, .xhtml, and .svg attachments, often with HTML smuggling, a WebSocket relay to the real Microsoft login, and mail that sometimes rides Amazon SES. About 33.3 percent of the successful logins in the set came from a mobile device. A phone browser hides the URL. The railway commute is the screen the research says is common.

One fact matters more than the rest for a 15-user shop: a password reset alone does not evict a stolen session. The attacker is not waiting on the password. They are already holding the cookie.

How adversary-in-the-middle works in plain English

Think of a lookalike front desk. You walk up, show your ID, and the real building lets you in. The person behind the fake desk copies the badge the building just printed and keeps a spare.

Mirage2FA puts a reverse proxy between the victim and Microsoft. The page is a replica of the Microsoft 365 sign-in. The user types the email and password. The kit forwards both to the real service over a live WebSocket. Microsoft then asks for MFA. The user completes it on the fake portal — Authenticator, a one-time code, whatever they already use. Microsoft accepts the login and issues session cookies. The kit keeps those cookies, plus the credentials.

From that point the attacker does not need the password again and does not need another MFA prompt. They replay the cookie against Outlook on the web, SharePoint, OneDrive, and any SSO app that trusts the same Entra session. Inbox rules and forwarding can go in quietly. A partner’s mailbox can start writing the invoice that the callback post is about. The wire control is still the callback. The reason the email looks right is often a stolen session, not a guessed password.

Nothing in that chain requires a new Microsoft vulnerability. MFA proved the user approved a prompt. The prompt was on the wrong site.

Phishing-resistant sign-in is the long fix: a passkey or FIDO2 key is bound to the real origin, so a lookalike host does not get the assertion. That is why the passkeys rollout is not a fashion trend. Until those keys are on the people who can empty the tenant or release money, you still need a revoke path that actually kills cookies.

Microsoft documents that path. The Graph operation revokeSignInSessions invalidates refresh tokens and session cookies by resetting the user’s signInSessionsValidFromDateTime to now. A small delay of a few minutes is possible. An admin can run Revoke-MgUserSignInSession. Continuous Access Evaluation is how Exchange Online, Teams, and SharePoint Online hear that revoke instead of waiting for an access token to expire. CAE’s critical events include an administrator explicitly revoking all refresh tokens. The goal is near real time on those three services — CAE’s initial focus — with latency of up to 15 minutes possible.

Reset the password and leave the sessions up, and you have changed a secret the attacker is no longer using.

Why a 15-user NYC firm is the target, not the exception

A 15-person law or accounting shop in this city does not have a security operations queue. It has a bookkeeper who also answers the partner, a Global Admin that is often the managing partner’s mailbox, and a Thursday when someone needs the binder out of SharePoint before a closing or a filing. The attachment does not have to encrypt the tenant. It has to look like HR on a phone.

Attackers do not need a New York-only campaign. They need English-language Microsoft 365 tenants, mail that lands, and users who complete MFA without reading the URL bar. ANY.RUN’s United States share is the closest geography they published. We will not manufacture a Staten Island infection number to make the map feel local.

What is local is the blast radius. In a 15-user tenant the partner’s mailbox is the client file. Shared mailboxes for AP or closings sit next to it. One replayed cookie can read last night’s engagement email, drop a forwarding rule, and still leave the user looking signed in.

SHIELD still applies. New York asks for reasonable safeguards, not a named product. Being able to revoke sessions — and knowing a password change is not that revoke — is a safeguard you can write down. We already laid out the SHIELD checklist. This post is the session step that checklist does not write for you.

Seven things a 15-user shop can finish this week

1. Quarantine .htm, .xhtml, and .svg attachments at the mail gateway. Not “tell people to be careful.” Block or quarantine those extensions for everyone. A real vendor invoice is a PDF, a portal, or a thread you already have. Mirage2FA’s published delivery is a browser file, sometimes smuggled, sometimes sent through Amazon SES.
2. Write the incident sentence and put it where the bookkeeper works. “If anyone completed a Microsoft login from an attachment or from a link we did not type ourselves, we revoke sign-in sessions first. We do not stop at a password reset.” If that sentence lives only in a handbook nobody opens, you do not have a rule.
3. Practice the revoke on a test account before you need it. In the Entra admin center, revoke the user’s sessions. Or run Revoke-MgUserSignInSession for that user. Graph’s revokeSignInSessions is the same action: it resets signInSessionsValidFromDateTime so refresh tokens and browser session cookies stop being accepted. Microsoft says a small delay of a few minutes is possible. Time it once so Thursday’s panic is not the first run.
4. Turn Continuous Access Evaluation on and leave it on. CAE is how Exchange, Teams, and SharePoint Online — the services Microsoft first focused on — subscribe to the revoke. Critical events include an admin explicitly revoking all refresh tokens. Near real time is the goal; up to 15 minutes of latency is documented. If CAE is off, the cookie can keep reading mail after you think you kicked it out.
5. Treat a suspected open as an identity incident, not a password ticket. After the revoke: mailbox audit, inbox rules, forwarding, and OAuth grants. Look at sign-in logs for the hour around the click. ANY.RUN, as restated by Cyber Accord, says revoke sessions and tokens, then review forwarding and OAuth. A password ticket that never does that work leaves the attacker’s rule in place.
6. Move the people who can empty the tenant or release money to phishing-resistant MFA. Global Admin, partners, and the bookkeeper. A passkey or FIDO2 key will not assert to a lookalike host. Authenticator push still will, because the user is the one approving the prompt. The passkeys post is the rollout calendar. This step is why that calendar is not optional for the three accounts that matter.
7. Treat the phone as the likely screen. About one in three successful logins in the ANY.RUN set were mobile. On a phone, open the URL bar before you type. If the host is not the Microsoft sign-in host you already know, close it. Do not complete MFA to “see if it works.” The kit wants that approval. If the attachment already opened and the prompt already went through, go back to step 3. Do not reset the password and call it contained.

How MicroSky helps — on this session, not a generic stack

We will tell you, in writing:

• Whether .htm, .xhtml, and .svg attachments are blocked or quarantined, or whether they still land in the bookkeeper’s inbox.
• Who can revoke sign-in sessions today, whether they have run Revoke-MgUserSignInSession on a test account, and whether CAE is on for Exchange, Teams, and SharePoint Online.
• Which accounts are Global Admin, partner, or AP — and which of those still complete MFA with a prompt a fake portal can relay.
• Whether mailbox audit, forwarding, and OAuth grants are something you can actually read after a suspected click.

We will not replace a session revoke with a slide about phishing.

Call MicroSky at (718) 672-2177 or visit microskyms.com for a free, no-obligation look at how your firm kills a stolen Microsoft 365 session. We serve NYC, Staten Island, New Jersey, and the tri-state.

Ask who can revoke sessions, whether CAE is on, and what happens if the bookkeeper already approved the prompt. If nobody can answer in one minute, that is the finding.