Microsoft 365 AiTM Phishing: How Stolen Sessions Bypass MFA and What Tycoon2FA’s Takedown Means

How AiTM gets past your MFA​

The attack is simple, which is part of the problem:

1. The lure. A user clicks a link in a phishing email and lands on a reverse proxy that the attacker controls.
2. The relay. The proxy passes everything through to Microsoft's real sign-in service. The user sees the real page, including the organization's branding.
3. The MFA prompt. The user types a password and completes the MFA challenge. Every step is genuine, because it's all being forwarded.
4. The theft. Once authentication succeeds, the service issues a session cookie. The proxy grabs it, and the attacker loads it into their own browser.

The attacker now has a valid, active session and can go anywhere the user can. Schmitz says traditional methods such as SMS codes and number matching don't stop this. MFA protected the sign-in challenge, and the challenge was passed. What got stolen is the session created afterward.

Microsoft's threat intelligence describes a nasty follow-on effect. Tycoon2FA let attackers keep access to sensitive data even after passwords are reset, unless active sessions and tokens were explicitly revoked. For help desks, the lesson is that a password reset alone doesn't contain an AiTM compromise.

Section summary: AiTM steals the session that MFA produces, so you have to deal with the session as well as the password.

Tycoon 2FA: the PhaaS example, and what happened to it​

The GuidePoint post says phishing-as-a-service (PhaaS) platforms such as Tycoon2FA have "industrialized" AiTM. It also says a low-skilled attacker can rent a working proxy kit for as little as $120. The post gives no source or plan for that number. An independent research blog, RWP Ventures, says Microsoft's own March 2026 write-ups describe kits starting around $120/10 days or $350/month. So the figure looks plausible, but treat it as a historical price, not today's rate.

The post talks about Tycoon2FA in the present tense. It leaves out that the service was hit hard in March. Microsoft obtained a court order from the U.S. District Court from the Southern District of New York to seize 330 active domains used to back the core infrastructure of Tycoon 2FA. Cybersecurity News reported that Microsoft led the seizure of control panels and fake login pages, marking the first such cross-border public-private takedown under Europol's Cyber Intelligence Extension Programme.

The service was big:

• The platform accounted for 62% of phishing attempts Microsoft blocked by mid-2025, linking to 96,000 victims, including 55,000 Microsoft customers, with heavy impacts on healthcare and education sectors.
• Microsoft said the coordinated action targeted a service responsible for tens of millions of fraudulent emails reaching over 500,000 organizations each month worldwide.
• Microsoft's threat intelligence team found campaigns across nearly all sectors including education, healthcare, finance, non-profit, and government. It added that Tycoon2FA's rise likely stemmed from disruptions of other popular phishing services like Caffeine and RaccoonO365.

That last point is the real story. When one PhaaS platform goes down, its customers move to another one. RWP Ventures put it bluntly in its headline: the March disruption moved the volume, not the motive. The threat-tracking site Mallory also lists later reporting under the heading Researchers link Tycoon ecosystem to rising device code phishing campaigns, citing Barracuda and Proofpoint in April 2026. That matters because device code phishing is a different technique, and blocking session replay won't stop it. Microsoft's token-protection guidance separately advises blocking device code flow wherever possible.

So when GuidePoint asks whether your Microsoft environment is at risk, the takedown doesn't change the answer. The infrastructure was disrupted. The technique is still in use.

Section summary: Tycoon 2FA was disrupted in March 2026, but the PhaaS market adapts quickly. Plan defenses around the technique, not one kit.

Claims worth a skeptical eye​

A few points in the GuidePoint post need caveats:

• The "146% rise" figure. The post says Microsoft observed a 146% increase in AiTM attacks in 2024. It doesn't name the Microsoft report or define the measurement, so treat it as an unverified claim.
• AI-generated lures. The post says AI has nearly eliminated the typos and awkward wording users relied on to spot phishing. That's plausible, and Microsoft's own takedown post mentions cybercrime getting more scalable through automation and AI. But the post cites no specific study or numbers.
• "Only" and "cannot." The post calls phishing-resistant methods the only MFA that AiTM proxies can't relay. On the core cryptography that's broadly right. Its own FAQ admits attackers still get around these deployments through MFA downgrade attacks, authorization-layer phishing and post-authentication session theft. Phishing-resistant MFA protects the sign-in step very well. It doesn't make the whole tenant immune.

The controls that actually matter​

1. Phishing-resistant authentication​

The post lists FIDO2 security keys, passkeys, Windows Hello for Business and certificate-based authentication. These methods are cryptographically tied to the legitimate domain. A proxy on a lookalike domain can't complete the exchange, so nothing usable gets relayed.

Microsoft's deployment guidance for Entra ID enforces this with the Phishing-resistant MFA authentication strength in Conditional Access, rolled out in stages:

1. Start with Report-only. Create a Conditional Access policy in Report-only mode. Assign it to all users, exclude break-glass accounts, cover all resources, and require the Phishing-resistant MFA authentication strength.
2. Create it early. Microsoft recommends setting this up before enrollment campaigns start, so you build up a history of which sign-ins would have been blocked.
3. Enforce in waves. Use a security group per rollout wave, grouped by user and device platform, and add groups one at a time. Microsoft suggests slowing down if help desk tickets spike.
4. Look into the stragglers. Filter for sign-ins that wouldn't satisfy the policy. Check which OS, client app and resource they involve, then fix those before enforcing.
5. Register at least two methods per user. For example, a passkey plus Windows Hello for Business on the user's workstation, so a lost device doesn't lock anyone out.

This matches the GuidePoint post's advice: start with a pilot group, then expand by role sensitivity and app compatibility.

2. Conditional Access layers​

GuidePoint recommends requiring compliant devices, restricting access to trusted locations, and using risk-based policies through Entra ID Protection. The post says an attacker "would need to satisfy all of these conditions at once." That's only true when your policies actually cover every relevant app and user. One forgotten exclusion breaks the chain.

Microsoft's token-theft guidance adds two specific policies. One requires interactive phishing-resistant reauthentication, with sign-in frequency set to every time, for sign-ins at medium risk or higher. The other requires the same reauthentication for sensitive actions through authentication context. Someone holding a stolen session can't satisfy a fresh phishing-resistant prompt.

3. Token protection, within its limits​

Microsoft describes Conditional Access token protection as binding sign-in session tokens to the device they were issued on. A stolen token then won't work on an attacker's machine. The coverage is limited, though. Microsoft's token-protection article says that, at the time it was published, the feature covered Windows native applications connecting to Microsoft Teams, SharePoint and Exchange. Microsoft's Zero Trust guidance now mentions Windows and Apple platforms. Don't assume it covers browsers or every workload. Check Microsoft's current supported-apps list before planning around it.

For apps outside that scope, Microsoft points to network-based enforcement: Global Secure Access compliant-network checks, or location policies combined with Continuous Access Evaluation for apps that support it.

If a session gets stolen​

GuidePoint's response advice, with Microsoft's password-reset warning added:

• Revoke sessions right away and force the affected account to reauthenticate. A password reset alone isn't enough.
• Investigate what the attacker accessed during the session, including mailbox rules, file access and app consents.
• Reset any exposed credentials or permissions.
• Watch for unfamiliar device or location sign-ins right after a legitimate authentication, and review Entra ID Protection risk detections.

The bottom line​

The GuidePoint post is a solid primer, even with the sales pitch at the end. Its practical advice holds up, especially its warning about deploying a control, breaking something and rolling it back in the messy hybrid environments most organizations run. What it leaves out is that the best-known AiTM kit was taken down seven months ago, and attackers seem to have moved on to other kits and techniques. For Microsoft 365 admins, the to-do list is the same:

• Turn on a Report-only phishing-resistant policy this week.
• Treat SMS and push approvals as stopgaps.
• Make sure your incident playbook revokes sessions, not just passwords.