Your employee approved the MFA prompt correctly, and the attacker was signed in anyway
Mirage2FA is a rented phishing service that sits between your staff and the real Microsoft 365 login page, passes their password and their MFA code through to Microsoft, and keeps the session cookie that comes back. ANY.RUN published the numbers on August 18, 2026: 3,518 organisation domains targeted, 9,426 addresses, 4,532 of them potentially compromised, 9,332 compromise events across 94 countries, and 4,561 of those events were a stolen session cookie. A password reset does not evict an attacker holding one. Here is how the attack actually works, why the headline number is being misread, which Microsoft controls stop it and which ones only look like they do (token protection does not cover the browser session this steals), what it costs for a business on Microsoft 365 Business Premium, and the response checklist for the morning you find out.
Every piece of security advice a small business has been given for a decade ends at the same place: turn on multi-factor authentication. It is good advice. Microsoft’s own figure, repeated in the product documentation for its managed Conditional Access policies, is that requiring MFA reduces the risk of compromise by more than 99 percent.
That number is true and it is also the reason this attack works so well. It has trained everyone, including the people running the business, to treat the MFA prompt as the finish line. So when an employee gets a login page, types the password, opens the authenticator app, approves the prompt and lands somewhere that looks slightly wrong, the mental model says I did the secure thing, so I am fine.
They are not fine. In the attack described below the approval is not bypassed, defeated, or brute forced. It is used. Your employee’s correctly performed MFA is what logs the attacker in.
The kit with the numbers attached
On August 18, 2026, researchers at ANY.RUN published an analysis of a phishing-as-a-service platform called Mirage2FA, attributed to an operator they track as LinX Coders. It is not new. Their sandbox data covers September 2024 through July 2026, and the volume climbs sharply through 2026: by July 2026 alone they recorded 445 Mirage2FA sandbox sessions in the month.
The figures, from ANY.RUN’s report:
| Measure | Figure |
|---|---|
| Unique organisation email domains targeted | 3,518 |
| Unique email addresses targeted | 9,426 |
| Addresses potentially compromised | 4,532 (about 48 percent) |
| Countries seen | 94 |
| Total compromise events | 9,332 |
| Events that were session cookie theft | 4,561, across 2,541 unique victims |
| Events that were password or 2FA capture | 3,044, across 1,589 victims |
| Events that were SSO logins | 1,339, across 616 victims |
| Successful logins from mobile devices | 33.3 percent |
Geographically, the United States accounts for 2,885 victims (63.7 percent), then India (229), Singapore (186), the United Kingdom (76) and Canada (75, 1.7 percent). By sector: technology 19.2 percent, manufacturing 11.1 percent, education 9.9 percent, consulting 8.3 percent, telecommunications 6.6 percent, healthcare 5.4 percent, finance 3.1 percent.
One correction worth making before you read anyone else’s coverage. Several outlets ran headlines saying roughly 4,500 companies were hit. The 4,532 figure is email addresses potentially compromised, not companies. The organisation count is 3,518 domains targeted. Those are different quantities measuring different things, and the difference matters if you are trying to reason about your own odds. Read the primary report, not the headline.
Note also what these numbers are: sandbox telemetry from one vendor’s users. They are a floor, not a census. Nobody has the real total.
What actually happens
Four steps, and the interesting part is that only the first one is what most people would call phishing.
One. The delivery. An email arrives with an attachment: a .htm, .xhtml or .svg file. Not a document, not an executable, nothing your mail filter is confident about. Some campaigns skip the attachment and use a QR code, which moves the click onto a personal phone where there is no corporate filtering at all. That is the likely explanation for the third of successful logins that came from mobile.
Two. The unpack. The attachment is an HTML smuggling stager: the malicious content is assembled inside the browser rather than transmitted as a file, which is why gateway scanning does not catch much. ANY.RUN documents layered obfuscation (XOR plus Base64 plus eval, hex decoders, obfuscator.io wrappers) and a fixed XOR key of 0xAD in the HTML. The stager fetches the real harvesting logic from a loader at a path matching /<3 chars>/xls/<token>.js.
Three. The relay. The victim is shown a Microsoft 365 login page. It is convincing because most of it is real: the kit is a reverse proxy. It takes the password the victim types, sends it to Microsoft, gets back Microsoft’s genuine MFA challenge, shows that to the victim, takes the code or the approval, and passes that to Microsoft too. Every check Microsoft performs, passes. It was a legitimate user, using a legitimate credential, completing a legitimate challenge. ANY.RUN describes the authentication data being relayed over a WebSocket channel.
Four. The theft. Microsoft, satisfied, issues a session cookie. The proxy is holding it. The victim is redirected somewhere harmless and usually notices nothing. The cookie is exfiltrated as a Base64-encoded .txt dump.
The attacker now has an authenticated session. Not a password that might be wrong, not a credential that will trigger a challenge. A session that Microsoft already agreed to.
The consequence people get wrong
Resetting the password does not throw the attacker out.
This is the single most expensive misunderstanding in small business incident response, and it is the reason a compromise that was detected on Monday is still live on Thursday. The stolen artefact is not the password. It is the proof that the password and the MFA were already accepted. Changing the password changes an input to a process that has already finished running.
What evicts them is revoking sessions, which invalidates refresh tokens and forces reauthentication. In the Entra admin center it is Users, select the user, Overview, Revoke sessions. In PowerShell it is Revoke-MgUserSignInSession -UserId <UPN>.
And be aware of a limit Microsoft states plainly in its own documentation: Entra can revoke the tokens it issued, but a browser-based application that has issued its own session token controls that separately, and Entra cannot directly revoke it. Access tokens last an hour by default. Continuous access evaluation shortens the real-world gap for the apps that support it (Exchange Online and SharePoint Online among them), but “revoke sessions” is not an instantaneous kill switch everywhere. It is still the step to run first, and the step most often skipped.
Why this market keeps refilling
On March 4, 2026, Microsoft published its account of Tycoon2FA, which had been the dominant AiTM platform since August 2023. At its peak Microsoft describes tens of millions of phishing messages reaching more than 500,000 organisations a month. Microsoft’s Digital Crimes Unit, with Europol and industry partners, disrupted it.
That was a genuinely good outcome, and five months later a different kit with the same capability is posting these numbers. Mirage2FA is not a successor built by the same people; it has been running since 2024. It simply had room to grow.
This is worth internalising because it shapes what you should spend money on. Takedowns remove operators. They do not remove the technique, because the technique is not a vulnerability that can be patched. Nothing is broken in Microsoft’s authentication. A reverse proxy relaying a real login is, to the identity provider, a user on a network path it cannot see. The fix has to be a credential that refuses to work through a proxy in the first place.
The controls, graded honestly
Works: phishing-resistant MFA
This is the one that actually breaks the attack, and it is worth understanding why, because it is not a matter of being stronger.
A passkey, a FIDO2 security key, or Windows Hello for Business signs a challenge that is bound to the origin, the actual domain in the browser. When the page is the attacker’s proxy domain rather than Microsoft’s, the credential does not produce a wrong answer, it produces nothing at all. There is no code for the victim to read out and no prompt for them to approve. The human is removed from the decision, which is the whole point, because the human is the component the kit is designed to defeat.
In Entra, enforce it with a Conditional Access policy using the Require authentication strength grant control and the built-in Phishing-resistant MFA strength, which covers Windows Hello for Business or platform credential, FIDO2 security key, and Entra certificate-based authentication (multifactor).
One documented limitation to plan around: Conditional Access is evaluated after initial authentication, so an authentication strength does not stop the user entering a password first. It stops the sign-in from completing without the phishing-resistant method. Your staff can still be tricked into typing a password on the wrong page. They just cannot finish the login for the attacker.
If you do nothing else after reading this: start privileged accounts on passkeys this month. Hardware keys are roughly $30 to $80 each, and passkeys in Microsoft Authenticator cost nothing.
Works, cheaply: cut the delivery
Block or quarantine .htm, .xhtml and .svg attachments at the mail gateway. Almost no legitimate business correspondence arrives as a raw HTML or SVG attachment, and these three are the kit’s front door. This is a ten-minute change with a genuinely low false-positive rate, and it is available on any Microsoft 365 or Google Workspace plan.
Add the QR-code brief for your team, because that path bypasses the gateway entirely by moving to a personal phone.
Partly works, and is widely oversold: token protection
Microsoft’s Conditional Access token protection binds sign-in session tokens to the device, so a stolen token cannot be replayed from the attacker’s machine. It is the right idea and it is frequently recommended in response to exactly this attack.
Read the availability table before you rely on it. Per Microsoft’s current documentation, token protection is generally available for native applications on Windows, iOS/iPadOS and macOS, covering Exchange Online, SharePoint Online and Microsoft Teams (plus Azure Virtual Desktop and Windows 365 on Windows). Support for browser-based applications is in preview and limited to selected web apps that access Azure Resource Manager.
The AiTM attack described in this post happens in a browser. So for the specific session this kit steals, token protection is not yet the control that saves you. Deploy it, because it closes the native-app replay path and the coverage is expanding, but deploy it knowing what it does not cover. Microsoft says the same thing in its own guidance, describing it as part of a defence-in-depth strategy rather than an answer. Also note it requires a registered device with a Primary Refresh Token, so it does nothing for unregistered machines.
Works as a backstop: network and device conditions
Because the attacker’s replay comes from somewhere else, conditions about where and what still bite even when who has been forged:
- Require a compliant or Entra-joined device for access to your resources. The attacker’s machine is neither.
- Location-based policies. For apps that support continuous access evaluation, strict location enforcement revokes session artefacts replayed outside your trusted network in near real time.
- Block legacy authentication, which does not support MFA at all and is a separate open door.
Detection, if you have the licence
Entra ID Protection carries risk detections named Anomalous Token, Attacker in the Middle, and Unfamiliar sign-in properties. Microsoft Defender XDR, using Defender for Cloud Apps connectors, raises alerts named Stolen session cookie was used and Possible AiTM phishing attempt.
Those are the alerts you want. Note the licensing, because it is the part vendors gloss over.
What this costs, in real licence terms
| Control | What you need |
|---|---|
| Security defaults (MFA on, legacy auth blocked) | Free, every tenant, no Conditional Access |
| Conditional Access, authentication strengths, device compliance | Entra ID P1, included in Microsoft 365 Business Premium |
| Risk-based policies, Entra ID Protection detections | Entra ID P2, which for a small business means the Defender Suite add-on for Business Premium |
| Passkeys and FIDO2 security keys | The method itself is free; enforcing it needs Conditional Access, so P1 |
If you are on Business Basic or Business Standard, you have security defaults and no Conditional Access. Turn on security defaults and register passkeys anyway. If you are on Business Premium and have never opened the Conditional Access blade, that is the gap worth closing this week: you are already paying for the control.
If you think it already happened
Order matters here. Most of the damage in these incidents happens in the days after detection, because the first move was the wrong one.
- Revoke sessions first, before the password reset. This is the step that ends the attacker’s access. Reversing the order gives them a warning and an intact session.
- Reset the password, and require MFA re-registration if you have any doubt about which methods are legitimate.
- Check the account’s registered MFA methods. Adding an authenticator is the standard way to keep access after a reset. An unfamiliar method is not a leftover, it is the attacker’s key.
- Check inbox rules. Rules that move messages containing “invoice”, “payment” or “wire” into an obscure folder are how the account gets used quietly for fraud rather than loudly for spam.
- Check mail forwarding, both the forwarding setting and rules that forward.
- Review OAuth app consent grants on the account. Consent given during a hijacked session survives password resets, MFA changes and session revocation, because it is a separate grant.
- Check for new devices registered to the account, and check whether the account added any delegated mailbox access.
- If the account touched banking or supplier payment details, treat it as a payment fraud incident too, not just an IT incident, and verify any changed banking details by phone on a number you already had.
Steps 3 through 6 are the ones small businesses miss, and each one is a way for the attacker to still be there next week after everybody agreed the incident was closed.
The bottom line
MFA is not failing. It is doing exactly what it was designed to do, which is prove that the person holding the credential can also produce a second factor. The attack does not argue with that proof, it stands next to the person while they produce it.
The upgrade that fixes it is a credential that is bound to the domain rather than to the person’s judgement, and it is available on plans small businesses already own. Everything else on the list, blocking HTML and SVG attachments, revoking sessions before resetting passwords, checking for an added authenticator, is cheap and unglamorous and worth doing this week.
Related reading from us: ClickFix, the attack that asks your staff to run it themselves, and the identity hardening we recommended after Microsoft’s August cloud CVEs.
If you want someone to look at your Microsoft 365 tenant and tell you plainly which of these are on, which are off, and what your plan actually entitles you to, get in touch.
Sources
- Mirage2FA: A Phishing Threat to US Companies with 4K Victims, ANY.RUN, published August 18, 2026, for all campaign figures
- Mirage2FA Surge Hits 4,500 US and EU Companies, Abusing Microsoft 365 Login Flows, The Hacker News, August 2026
- Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale, Microsoft Security Blog, March 4, 2026
- Token protection in Microsoft Entra Conditional Access, Microsoft Learn, for platform availability and supported resources
- Protecting tokens in Microsoft Entra, Microsoft Learn, for replay protection, network enforcement and detections
- Conditional Access authentication strengths, Microsoft Learn, for the built-in phishing-resistant MFA strength and its limitations
- Revoke user access in Microsoft Entra ID, Microsoft Learn, for what revoking sessions does and does not invalidate
- Respond to a compromised cloud email account, Microsoft Learn, for the response checklist
- What is Conditional Access? and Microsoft Entra licensing, Microsoft Learn, for licence requirements