A fake sign-in page passes the one-time code straight to Microsoft

On 18 August 2026 ANY.RUN described the phishing toolkit Mirage2FA, sold as a service and built to steal Microsoft 365 sign-ins. The toolkit places itself between the victim and the real sign-in page, and collects the password, the one-time code and the finished session cookie. Multi-factor authentication does not stop the attack. ANY.RUN records activity in 94 countries, with observations running from September 2024 to July 2026 and a clear escalation during 2026.

What happens technically

An adversary in the middle attack does not behave like an ordinary fake sign-in page. The fake page is a reverse proxy: everything the victim types is passed on to the real service in real time, and everything the real service answers is passed back to the victim. The victim therefore sees the correct sign-in flow, with the correct error messages and the correct prompt for a one-time code, because it really is Microsoft answering. ANY.RUN describes the chain in nine steps, and states that the relaying happens over a WebSocket connection. Once the victim completes the sign-in, the attacker is left holding the authenticated session cookie. That is the real prize, because a valid session grants access without asking for a password or a code again.

Delivery arrives through email attachments, links and QR codes, and ANY.RUN states that large volumes were distributed through Amazon SES using payroll and pension themes as bait. The attachments fall into three file types, with htm files clearly the most common, and obfuscated JavaScript most common in exactly those. ANY.RUN describes six loader variants, each with its own way of hiding the code, and uses the loader pattern as a hunting signature. The figures the company reports are 3518 unique organisation domains and 9426 unique target addresses, of which 4532 are listed as potentially compromised, and 9332 events across four outcomes where session cookie theft is the most common. ANY.RUN explicitly marks all of these as estimates rather than confirmed compromises, and states caveats about the quality of its geographic data. The company ties the toolkit to an operator brand it calls LinX Coders, but frames the attribution as likely rather than established. The United States dominates the victim distribution, and Norway and the Nordics do not appear in the material.

What this means for you if you rely on one-time codes

If you rolled out multi-factor authentication with one-time codes and ticked the box marked sign-in secured, this is the case that shows why the tick mark is not enough. The code you type is valid for a few seconds, and the attacker needs only those seconds. Our assessment is that the important distinction here runs between factors that can be relayed and factors that cannot. A one-time code can be typed into a place where it does not belong. A passkey or a hardware security key is bound to the address it was created for, and therefore cannot be relayed to a fake page.

The second thing to take away concerns what happens after the attack is over. Changing the password of a user caught this way does nothing about the problem, because the attacker holds a valid session rather than the password. The session has to be revoked deliberately. If you are responsible for Microsoft 365, it is worth knowing that a third of the successful sign-ins ANY.RUN observed came from mobile devices, meaning the surface where the user sees least of the address in the browser. If your organisation is covered by NIS2, this belongs in the assessment of whether your sign-in solution actually withstands known attack techniques, and not merely whether multi-factor is switched on.

Berigo recommends

• Move the users with the broadest access to passkeys or hardware security keys. Those cannot be relayed to a fake page the way a one-time code can.
• Set sign-in conditions that look at more than password and code, for example that the device is known and managed.
• Practise revoking active sessions, not just changing passwords. A stolen session survives a password change.
• Watch for sign-ins where the session starts somewhere other than where the user is, and for new mail forwarding rules created right after a sign-in.
• Tell your users that an attachment which opens a sign-in page in the browser is a warning in itself, however correct that page looks.