Mirage2FA is a commercial phishing-as-a-service toolkit that sits between your users and Microsoft's real login page. Rather than harvesting a password and stopping there, it proxies the legitimate Microsoft 365 authentication flow, so the victim sees a genuine-looking sign-in prompt, completes the two-factor step, and hands over both credentials and the session cookie that Microsoft issues afterward. Original reporting for this article comes from The Hacker News.
That cookie is the part that matters. With a valid session token, attackers access an already-authenticated Microsoft 365 session and anything connected through single sign-on, without ever needing to satisfy your 2FA policy again. This is an adversary-in-the-middle (AiTM) technique, and ANY.RUN's research shows it works against accounts where two-factor authentication is fully enabled.
The scale is the second half of the story. ANY.RUN links Mirage2FA activity from 2024 through 2026 to 4,532 unique organization email domains, with the United States accounting for 63.7% of victims and further activity observed in India, Singapore, the United Kingdom, Canada, Saudi Arabia, and South Africa. Technology, manufacturing, and education were among the most targeted industries.
ANY.RUN recorded more than 9,000 potential compromise events involving cookie and password theft, SSO logins, and 2FA bypass, with 48% of targeted email addresses potentially compromised.
For an IT team, the practical consequence is that your usual signal of compromise disappears. There is no failed-login spike and no password anomaly, because the authentication succeeded exactly as designed and the attacker arrives holding a token your identity provider already trusts.
For executives, the exposure is a trusted corporate identity: business email, files, and any SSO-connected application that identity can reach. ANY.RUN notes that follow-on access through SSO-connected apps and internal workflows widens the affected area beyond the first account, which raises containment costs. Because the intrusion runs on a hijacked session instead of a stolen password, resetting that password does not end the attacker's access.
Attack Chain: From Phishing to Credential Theft Despite 2FA
The delivery stage relies on ordinary email content: attachments and links that a user opens without hesitation. ANY.RUN's analysis of the campaign shows the payload chain running through redirects, embedded scripts, and encoded data before the victim ever sees a login prompt, which maps to T1566.002 (Phishing: Spearphishing Link) in MITRE ATT&CK. The redirect hops matter for one reason: each one strips context, so the URL a user finally lands on shares no obvious relationship with the message they clicked.
The landing page renders a Microsoft 365 sign-in screen and maintains a live channel back to the operator's infrastructure. Sandbox execution surfaces WebSocket activity during this phase, meaning the fake page holds a persistent two-way connection rather than posting a form once and finishing. That connection is what lets the relay pass the second-factor challenge and the resulting token in near real time, corresponding to T1557 (Adversary-in-the-Middle) and T1539 (Steal Web Session Cookie).
ANY.RUN recorded more than 9,000 potential compromise events across the campaign, covering cookie theft, password theft, SSO logins, and 2FA bypass. That count sits against 4,532 unique organizational email domains touched between 2024 and 2026, with technology, manufacturing, and education appearing most often among targeted industries.
Post-authentication activity is where cost accumulates. With a stolen session cookie replayed into a browser, the operator inherits the account's existing entitlements, which ATT&CK tracks as T1550.004 (Use Alternate Authentication Material: Web Session Cookie) and T1078 (Valid Accounts). No password prompt fires, no second-factor push arrives, and the sign-in carries the trust level of the legitimate user.
From there the research describes expansion through the identity itself:
- SSO-connected applications reached through the same hijacked session, extending access to systems that never saw the phishing email
- Corporate mailbox access supporting impersonation and fraud against colleagues, suppliers, and customers
- Internal business workflows that widen the attack radius beyond the first account and drive up containment effort
- Follow-on compromise of additional accounts using the credibility of the trusted identity
For a finance or operations team, that translates into invoice and payment redirection attempts arriving from a genuine internal address, with genuine message history behind them.
Detection difficulty comes from the fact that nothing in the authentication path is counterfeit at the protocol level. The victim's credentials go to Microsoft. Microsoft validates them, issues a real token, and logs a successful sign-in. Signature-based email and web controls looking for spoofed domains or malformed login forms have little to bite on, because the login flow itself is legitimate and the phishing page is a transparent conduit.
The research does not publish fixed C2 domains or file hashes for this campaign, and infrastructure rotation is treated as expected behavior. The durable indicators are behavioral: recurring loader patterns, encoded data blobs, WebSocket traffic tied to credential entry, and clusters of infrastructure that resolve to the same operator across separate lures. Pivoting from a single suspicious URL, domain, IP, or file to that surrounding infrastructure is how analysts establish whether one alert belongs to the wider campaign.
When you review a phishing cluster with these characteristics, the working assumption should be that roughly half the recipients completed the flow, not a small fraction.
Key Insight: One operational note on the numbers: 48% of targeted email addresses were assessed as potentially compromised.
Business and Compliance Impact of Compromised Microsoft 365 Accounts
ANY.RUN's research ties Mirage2FA activity to 4,532 unique organization email domains between 2024 and 2026, with 48% of targeted email addresses potentially compromised. That ratio is the number to bring to your leadership team. It means roughly half the mailboxes this toolkit touched produced a usable authentication artifact for the operator.
When an attacker holds a live session for one of your Microsoft 365 accounts, they inherit that user's permissions across the tenant. Exchange Online mailbox contents, files in OneDrive, document libraries in SharePoint, and Teams chat history are all reachable through the same authenticated identity. If the account belongs to someone in finance, HR, or legal, the exposed material is contract data, payroll records, and privileged correspondence.
The industries hit hardest in this campaign were technology, manufacturing, and education. Each carries a different flavor of consequence. A technology firm loses source code and customer configuration data. A manufacturer loses production schedules, supplier pricing, and design files. An education institution holds student records that fall under statutory protection.
Geographic spread also shapes your regulatory exposure. The United States accounted for 63.7% of victims, with additional activity in India, Singapore, the United Kingdom, Canada, Saudi Arabia, and South Africa. If your tenant serves users across those regions, a single hijacked mailbox can trigger notification duties under multiple regimes at once, including GDPR for EU data subjects and state statutes such as the CCPA.
The 2FA bypass is what makes this expensive on the compliance side. Multi-factor authentication is a named control in HIPAA security assessments, SOC 2 Type II access-control criteria, and cyber insurance underwriting questionnaires. Your attestation says MFA is enforced, and it is. The attacker did not defeat the control so much as walk around it by taking the token issued after it succeeded. Explaining that distinction to an auditor, a regulator, or an insurer is a documentation exercise you pay for in professional-services hours.
Response costs run higher than a standard credential-theft case for a specific reason: a password reset alone does not end the intrusion. Your team has to determine which sessions and tokens were valid, what SSO-connected applications the identity could reach, and which actions in the audit log were the real user versus the operator. That scoping work is where the hours accumulate, and it extends across every downstream service tied to the same identity.
Then there is the outward-facing damage. A compromised account inside your tenant sends mail that passes SPF, DKIM, and DMARC because it originates from your legitimate infrastructure. Attackers use that trust to reach your customers, suppliers, and channel partners, which turns your incident into their incident. Vendor risk questionnaires and contractual breach-notification clauses mean your partners will hear about it either way, and some will require evidence of remediation before normal business resumes.
- Data exposure: mailbox contents, cloud file stores, collaboration history, and anything reachable through single sign-on.
- Regulatory: notification obligations and control-effectiveness questions under GDPR, CCPA, HIPAA, and SOC 2.
- Financial: forensic scoping across every SSO-connected application, plus legal review of exposed records.
- Third-party: fraud and follow-on phishing sent from your authenticated domain to partners and customers.
Follow-on access through connected apps and internal workflows widens the affected radius, and containment costs rise with it. Treat the scope question, not the password, as the center of the financial exposure.
Detection and Immediate Response Actions
Revoke the session tokens before you reset a single password. A stolen cookie stays valid until you explicitly kill it, so a password change on its own leaves the operator logged in. Treat every confirmed phish as an identity incident: revoke refresh tokens and active sessions for the affected account, then reset the credential, then check what that identity did while the session was live.
Start by establishing which identities and consented applications actually exist in your tenant, the inventory step the NIST Cybersecurity Framework asks for. Pull an inventory of app registrations and OAuth grants, and flag anything a standard user consented to in the past 90 days. Attackers who hold a live session frequently register or approve an application so their access survives the credential reset you just performed.
On the preventive side, the controls that matter are the ones that stop a proxied login from producing a usable token in the first place:
- Block legacy authentication protocols in Conditional Access, since they bypass modern authentication and interactive prompts entirely.
- Require compliant or hybrid-joined devices for Exchange Online, SharePoint, and Teams access, which invalidates a token replayed from attacker infrastructure.
- Restrict user consent so only administrators can approve applications requesting mail, file, or directory permissions.
- Audit Global Administrator and other privileged role assignments, remove standing access, and require phishing-resistant authentication for every one that remains.
For detection, your Microsoft 365 unified audit log and sign-in logs hold the evidence. Hunt for impossible travel, sign-ins where the token was issued in one geography and used in another, authentication from hosting-provider IP space, and successful logins that record no interactive MFA challenge because the token was already minted. Off-hours mailbox access and new inbox rules that forward or delete messages containing words like "invoice" or "wire" are common follow-on actions once an operator settles into an account.
In environments Capstone manages, Adlumin ITDR correlates these authentication signals across managed environments and surfaces the anomalous session reuse that a password-focused alert never catches. That distinction matters operationally: the alert you need fires on how an identity is behaving after sign-in, not on whether the credential was typed correctly.
Turn on Microsoft Defender for Office 365 Safe Links and Safe Attachments with real-time URL detonation, and pair that with sandbox detonation of suspicious attachments and links in isolation before a user reaches a login prompt. Analysts should pivot outward from what detonation reveals, using recurring loaders, encoded data, and suspicious WebSocket activity to map related infrastructure rather than blocking a single URL and closing the ticket.
Your response playbook needs a session-theft path that differs from your password-reset path. Scope the investigation to the identity: mailbox rules, delegate permissions, MFA method changes, device registrations, and every application that identity touched through single sign-on. Follow-on access through connected apps expands what you have to contain, and each additional connected workload adds review time.
Longer term, move to phishing-resistant authentication. FIDO2 security keys and Windows Hello for Business bind the credential to the device and origin, so a proxied login page cannot complete the ceremony. Shorten sign-in session lifetimes for high-risk roles, enforce continuous access evaluation so revocation takes effect in minutes, and train users on what a consent prompt requesting mailbox access actually grants. Record which detections fired and which did not after each incident, and adjust your Conditional Access rules accordingly.
Hardening Microsoft 365 Against Credential Interception
Deploy FIDO2 security keys or Windows Hello for Business to every account holding a privileged role, and configure authentication strength policies so those accounts cannot sign in any other way. Phishing-resistant methods cryptographically bind the credential to the real Microsoft sign-in origin, which means a proxy page cannot relay the handshake to Microsoft on the victim's behalf. Everything else on this list makes credential interception harder, while this one removes the mechanism.
Before you roll it out, list who actually needs that treatment. Pull the membership of Global Administrator, Exchange Administrator, Application Administrator, and Privileged Role Administrator, plus any service account with mail.send or full mailbox access. That population is usually small enough to issue hardware keys within a single procurement cycle.
For the general workforce, move MFA off SMS and email one-time codes and onto authenticator push with number matching. SMS and email codes sit in channels an attacker can reach through SIM swap or an already-compromised mailbox, and a relayed six-digit string works just as well for the operator as for your user.
Conditional Access is what limits the value of a stolen session cookie. Require a compliant or Entra-joined device for Exchange Online, SharePoint, and Teams, so a token replayed from an unmanaged host outside your fleet fails the device check even when the token itself is valid. Layer these controls on top:
- Token protection (sign-in session binding) for desktop clients, which ties the refresh token to the device it was issued on.
- Sign-in risk and user risk policies set to block or force reauthentication on high risk, which is where Entra ID Protection surfaces impossible-travel and anomalous-IP detections.
- Named location policies that block or challenge sign-ins from countries where you have no staff, contractors, or customers.
- Shorter sign-in frequency plus continuous access evaluation for administrative sessions, so a hijacked session has a defined expiry rather than an open-ended one.
Disable legacy authentication next, because it routes around all of the above. IMAP, POP3, SMTP AUTH, and Exchange ActiveSync basic auth accept a username and password directly without evaluating Conditional Access, which turns a stolen password into direct mailbox access with no MFA prompt involved. Check your sign-in logs for legacy client activity first so you know which line-of-business applications and multifunction printers will break, then block the protocols tenant-wide.
On the application side, change the consent policy itself. Set user consent to "Do not allow user consent" with an admin consent request workflow, and permit pre-approval only for applications from verified publishers with low-impact permissions. This closes off the path where an attacker with a live session grants a malicious OAuth application standing access to mail and files.
For detection, correlate identity signals with endpoint data in Microsoft Sentinel or your existing SIEM instead of reviewing them in separate consoles. The pattern worth alerting on is a successful sign-in with a session that has no matching interactive authentication event on the user's known device, especially when it is followed within minutes by an inbox rule creation, a mail-forwarding change, or a burst of file downloads. Correlating the sign-in against endpoint telemetry tells you whether the session originated on hardware you manage.
Sequence the work by population size. Hardware keys for administrators, then device-compliance enforcement for the rest of the tenant, then legacy protocol shutdown once you have inventoried what still depends on it.
Key Takeaway: Assume 2FA Alone Is Insufficient
Two-factor authentication does its work at the moment of sign-in. It confirms that someone presented the correct factor at the prompt, and that is the boundary of what it tells you. Who holds the resulting session is a separate question, and it is the question this campaign is built around.
The victim spread suggests broad, opportunistic targeting rather than a focused operation. The United States accounts for 63.7% of the total victims, with activity also observed in India, Singapore, the United Kingdom, Canada, Saudi Arabia, and South Africa. Technology, manufacturing, and education were among the most targeted industries, which tells you the selection criteria was a Microsoft 365 tenant with a mailbox, not a specific sector or revenue band.
Because this capability is sold as a service, the operator running the phishing page against your users does not need the skill to build the proxy. That changes your threat model in a practical way. You are not sizing your risk against a handful of capable groups, you are sizing it against anyone willing to rent the tooling.
The useful shift is in how you evaluate your own identity controls. Ask what each one does after the authentication event completes, because the authentication event is the part this toolkit passes through cleanly. Controls that only inspect the login moment, including 2FA, verify a fact that has already stopped being useful by the time the session token is in an attacker's hands.
Treat the authentication and the session as two distinct things when you assess coverage, and you will find the specific gaps worth closing in your tenant.
