Mirage2FA Phishing-as-a-Service Hit 4,500 US and EU Firms by Bypassing Microsoft 365 2FA
ANY.RUN says the commercial Mirage2FA toolkit hit roughly 4,500 US and EU companies from 2024 to 2026, letting Microsoft 365 users finish a normal login before stealing the authenticated session. It bypasses 2FA, and 48% of targeted addresses were potentially compromised.
A commercial phishing kit called Mirage2FA worked its way through roughly 4,500 US and European companies between 2024 and 2026, and the reason it mattered is not that it stole passwords. It is that it walked past two-factor authentication. In research published this week, the malware-analysis firm ANY.RUN tied Mirage2FA activity to 4,532 unique corporate email domains and found that 48% of the addresses it targeted were potentially compromised.
Mirage2FA is sold as phishing-as-a-service (PaaS), a subscription model that hands lower-skilled criminals a finished attack kit. What the buyer gets is a toolkit aimed at Microsoft 365 that abuses the legitimate login flow: the victim completes a real sign-in, two-factor prompt included, and the operator captures the resulting authenticated session on the other side. ANY.RUN describes the toolkit as "built to steal Microsoft 365 credentials and authenticated sessions through Adversary-in-the-Middle (AiTM) attacks." That single design choice is why standard defenses, including the 2FA that most organizations treat as their safety net, did not hold.
This piece is written for the person who has to answer the practical question the report raises: if a phishing campaign can satisfy a valid two-factor prompt and still take the account, what does a Microsoft 365 administrator actually change on Monday morning? The short version is that the fix is not another one-time-code factor. It is moving the highest-risk accounts to phishing-resistant sign-in and treating a stolen session as an identity incident rather than a password problem.
What the ANY.RUN Data Shows
The headline number is reach. ANY.RUN linked Mirage2FA to 4,532 unique organization email domains across the United States and Europe, which is where the "4,500 companies" figure comes from. The activity was not evenly spread. The United States accounted for 63.7% of the observed victims, with further activity in India, Singapore, the United Kingdom, Canada, Saudi Arabia, and South Africa, per the ANY.RUN writeup. Technology, manufacturing, and education were among the most targeted industries.
The compromise rate is the number that should worry a defender. ANY.RUN found that 48% of the email addresses Mirage2FA targeted were potentially compromised, and its research surfaced more than 9,000 potential compromise events involving cookie and password theft, single sign-on logins, and 2FA bypass. Those are ANY.RUN's counts, drawn from its own sandbox and threat-intelligence telemetry rather than from victim disclosures, and the firm frames the totals as potential rather than confirmed. Even read conservatively, a near-even split between "targeted" and "potentially compromised" is a poor showing for accounts that were supposed to be protected by a second factor.
The activity spans 2024 to 2026, so this is not a single burst. It is a product that sold, ran, and kept running for the better part of two years. ANY.RUN reported analyzing more than a thousand Mirage2FA sandbox sessions to build the picture, which is a useful reminder that the sample here is behavioral telemetry from a security vendor, not a law-enforcement seizure.
Why 2FA Did Not Stop It
The category matters, so name it plainly: Mirage2FA is an adversary-in-the-middle (AiTM) phishing operation, sometimes called session-token phishing. ANY.RUN attributes the toolkit to that pattern directly. The high-level idea is that the fake login page sits in front of the real Microsoft 365 service and relays the exchange in real time, so the user's genuine second factor is satisfied against the real service and the operator ends up holding a valid, authenticated session. The prize is the session, not the password. (The step-by-step relay mechanics are not something a defender needs, and they are not reproduced here.)
This is why the reflex of resetting the password falls short. As ANY.RUN puts it, "resetting a user's password does not automatically invalidate the attacker's active session," because the attacker is riding a stolen session cookie rather than a stored password. Kill the password and the live session can keep going until it is explicitly revoked. That gap is the whole reason this class of attack has become the default way to beat 2FA at scale.
The blast radius does not stop at one mailbox. Once an authenticated Microsoft 365 session is in hand, the attacker inherits whatever that identity can reach: corporate email, single-sign-on-connected apps, and trusted internal workflows, which is the setup for business email compromise and slow data theft. It is the same session-theft failure mode we covered when Microsoft traced an AiTM campaign across tens of thousands of users earlier this year, and it feeds the same persistent account takeover problem that outlives the initial break-in.
The diagram below lays out the response in the order a Microsoft 365 admin should work it, starting from the reason a password reset alone leaves the attacker in place.
|
● Microsoft 365 Admin Response
What to change after a session-theft phishing campaign that beats 2FA.
|
|
Why A Password Reset Is Not Enough
Mirage2FA steals the authenticated session, not just the password. A reset leaves the attacker signed in, so treat this as an identity incident.
|
|
↓
|
|
Audit Sign-Ins, Then Revoke And Rotate
Review Entra ID sign-in logs for AiTM signals. On suspicion, revoke active sessions and refresh tokens and reset credentials, not the password alone.
|
|
Migrate To Phishing-Resistant Passkeys
Move high-risk accounts to FIDO2 / WebAuthn security keys or passkeys, which an AiTM proxy cannot relay.
|
|
Tighten Conditional Access
Enforce device compliance and sign-in-risk policies, turn on Continuous Access Evaluation, and shorten session lifetimes to shrink the window of a stolen session.
|
|
Educate Users On The Lure
Train staff to distrust unexpected attachments and QR-code prompts that open a Microsoft 365 login page.
|
|
Source: ANY.RUN, Mirage2FA research (Aug. 2026). Diagram by The CyberSignal. Defender view; no exploitation detail.
|
What Microsoft 365 Admins Should Do Now
The defensive work splits into two jobs: shut down the sessions this campaign already has, and remove the conditions that let it win. Both are within reach of a standard Microsoft 365 and Entra ID tenant, and none of them requires a new product.
- Treat the session as the incident. When an account is suspected of a phishing hit, revoke its active sessions and refresh tokens in Entra ID and rotate the credential, rather than stopping at a password reset that a live session cookie will simply outlast.
- Audit sign-in and session logs. Pull Entra ID sign-in logs and look for the signals of a proxied login: unusual locations, mismatched device or client details, and session activity that continues after a reset. Correlate those with the reports that triggered the review.
- Move high-risk accounts to phishing-resistant authentication. Executives, administrators, and finance staff should sign in with FIDO2 / WebAuthn security keys or passkeys. ANY.RUN's own guidance is to "transition high-risk accounts to FIDO2/WebAuthn hardware keys or passkeys that cannot be proxied by AiTM tools." This is the one control that removes the relay attack rather than just narrowing it.
- Tighten conditional access. Device-compliance and sign-in-risk policies, Continuous Access Evaluation, token binding, and shorter session lifetimes all reduce how long a stolen session stays useful, which ANY.RUN flags as a meaningful containment lever.
- Educate users on the delivery. The kit reaches people through unexpected attachments and QR-code lures that open a convincing Microsoft 365 login. Teach staff to treat those as suspect, and give them a fast way to report one.
My read: passkeys are the real fix here, and 2FA alone is not enough anymore. Once an attacker can stand between a user and Microsoft 365 and relay a live login, every factor that can be typed, tapped, or approved in that moment can be relayed with it. A FIDO2 or WebAuthn credential breaks that because it is cryptographically bound to the real site and cannot be handed to a proxy. The catch, and it is a real one, is that moving the front door to passkeys shifts the pressure onto credential enrollment, which is exactly the soft spot the iAuthFlow V2 toolkit was built to abuse by registering an attacker-controlled passkey after a phishing hit. So the honest takeaway is not "turn on passkeys and relax." It is "turn on passkeys, and start auditing who registered them."
What Remains Unconfirmed
A few things are worth flagging rather than asserting. ANY.RUN has not named the affected organizations, so the "4,500 companies" figure is a count of unique email domains in its telemetry, not a published victim list. The compromise numbers, including the 48% figure and the 9,000-plus events, are ANY.RUN's own potential-compromise counts from its sandbox and intelligence data, not confirmed breaches independently verified by the targeted firms. The operator behind Mirage2FA is not identified. And while the bypass category is confirmed, ANY.RUN names the adversary-in-the-middle pattern explicitly, I have seen no statement from Microsoft that it has deployed detection specific to this toolkit. Treat the AiTM mechanism and the defensive gap as real, because they follow from how session authentication works, and treat the exact scale as vendor-reported until the affected organizations say more.
