I need a minute. Because this is genuinely good news, and I don’t get to write those very often, and I want to savour it for approximately thirty seconds before I spend the next fifteen hundred words explaining why it doesn’t actually fix the underlying problem and you still need to sort your shit out.
330 domains. Seized. Gone. The Tycoon 2FA phishing-as-a-service platform — the thing responsible for somewhere around 60% of all blocked phishing attempts by mid-2025, per Microsoft’s own numbers — is dead. Europol coordinated the action, Microsoft did the heavy technical lifting, and law enforcement across Latvia, Lithuania, Portugal, Poland, Spain, and the United Kingdom executed the physical seizures. That is, genuinely, a big deal.
But here’s the thing. I was just writing about how ShinyHunters keeps burning SSO victims alive and the session-hijacking epidemic that nobody’s actually fixing at the architecture level — and Tycoon 2FA is the industrial infrastructure behind exactly that wave of attacks. So yes, celebrate. Then keep reading.
What Tycoon 2FA Actually Was
Per Bleeping Computer, Europol’s press release, and The Hacker News, Tycoon 2FA has been operating since at least August 2023. Two and a half years of open, advertised, Telegram-listed criminal business. It was an adversary-in-the-middle (AiTM) phishing platform, sold for the completely accessible price of $120 for 10 days of access. That is less than a single enterprise SaaS seat for a month. For $120, any moderately motivated criminal got a full reverse-proxy phishing infrastructure capable of bypassing Microsoft 365, Outlook, OneDrive, SharePoint, and Gmail MFA.
Here is how it worked, and I need you to understand the mechanism properly because it’s the part that makes every “just enable MFA” recommendation completely useless against this class of attack.
The victim lands on a fake login page that looks exactly like the real Microsoft or Google login. They enter their password. The Tycoon 2FA reverse proxy relays that credential to the real Microsoft or Google server in real time. Then the victim gets an MFA prompt — their authenticator app, their SMS code, whatever they have set up. They enter it. The proxy relays that too. The real login completes successfully. The victim sees their inbox. Everything appears normal.
What the proxy also captured, in that same transaction, was the session cookie that resulted from the completed authentication. That cookie is what Microsoft and Google use to say “this browser already authenticated, don’t challenge it again.” An attacker with that cookie opens a browser, injects it, and is inside your Microsoft 365 environment. No password. No MFA prompt. Nothing. Just a valid authenticated session that your identity platform has no reason to question.
According to Microsoft, the platform was generating tens of millions of phishing emails per month by mid-2025 and had touched more than 500,000 organisations in attempted attacks. Confirmed compromises — meaning actual successful session hijacking — sit at around 100,000 organisations worldwide, including government institutions, schools, and healthcare providers. A hundred thousand confirmed pops. Not a rounding error.
The detail that should make you genuinely angry: access persisted even after password resets. Because the stolen asset is a session cookie, not a password, resetting the compromised account’s password does precisely nothing unless you also explicitly revoke all active sessions and tokens. Most incident response playbooks say “reset the password and monitor.” That playbook is wrong for this attack. The attacker still has a live authenticated session. The account is still owned.
The Takedown: What Actually Happened
The operation was coordinated by Europol’s European Cybercrime Centre (EC3) with Eurojust support. Technical disruption was led by Microsoft. The intelligence that built the case originated with Trend Micro, who shared research with Europol, who disseminated it through EC3 advisory channels to build the law enforcement coalition.
Supporting organisations included Cloudflare, Coinbase (handling cryptocurrency infrastructure tracing), Intel471, Proofpoint, Shadowserver Foundation, SpyCloud, eSentire, Crowell, Resecurity, and Health-ISAC. That last one — Health-ISAC — tells you exactly who was getting beaten hardest with this tool. Healthcare. Because healthcare always has underpatched identity infrastructure, always has staff clicking links under time pressure, and always has the kind of PII and operational data that makes successful compromises extremely monetisable. As I documented with Lazarus going RaaS against US hospitals, the sector has been a recurring victim for years and apparently has not taken the collective hint.
The 330 seized domains covered the full infrastructure stack: control panels, customer-facing administration interfaces, the reverse-proxy phishing pages themselves, and payment processing endpoints. The Telegram channel used to sell Tycoon 2FA subscriptions has been disrupted. Note I said disrupted, not destroyed. That is a meaningful word choice.
Why This Will Happen Again
I’ve been tracking criminal service market evolution since dark web and Bitcoin first enabled ransomware economies at scale, and the pattern is completely consistent. Law enforcement scores a significant takedown. The ecosystem fragments for a few weeks. The same operators, or their associates who weren’t arrested, or completely unrelated criminals who watched the playbook and built their own version — they reconstitute. Eighteen months later, the successor platform is bigger than the original.
The reason the cycle persists is structural. Tycoon 2FA worked because password-plus-TOTP authentication is fundamentally vulnerable to AiTM proxying. That underlying vulnerability hasn’t been patched. The infrastructure that exploited it is gone. The attack category that the infrastructure enabled is alive, well, and almost certainly already served by competing platforms that weren’t disrupted in this operation.
The $120 price point is what made Tycoon 2FA an industry problem rather than a targeted-attack problem. Sophisticated AiTM attacks used to require custom tooling, reverse-proxy configuration skills, and a genuine understanding of the authentication flows being intercepted. Tycoon 2FA commoditised all of that. Any Telegram user with a prepaid card could run a professional-grade MFA-bypass phishing campaign against Microsoft 365 tenants. That democratisation of attack capability is the actual story. The IBM X-Force 2026 Threat Intelligence Index documented exactly this trend: the skills gap between nation-state-level capability and generic criminal operators is collapsing, and PhaaS platforms like this are a primary mechanism driving that collapse.
Why Your MFA Still Isn’t Enough
I know you’ve been told MFA is the answer. Your auditor told you. Your compliance checklist demands it. Your vendor’s webinar promised that enabling MFA would make attackers go away and cry. That advice is accurate against password spraying and basic credential stuffing. Against AiTM phishing, it is completely false, and the 100,000 confirmed Tycoon 2FA victims are the data that proves it.
The reason is fundamental: MFA adds a second factor to the authentication step. AiTM attacks don’t attack the authentication step — they let it complete successfully, on the real platform, with real credentials and real MFA codes, and then steal the session that results from it. It’s putting a quality lock on your front door and leaving the house key on the mat. The lock worked exactly as designed. That didn’t help.
What actually matters against AiTM:
Phishing-resistant MFA. FIDO2 security keys and passkeys are the gold standard. They bind authentication to the origin domain — meaning a fake Microsoft login page cannot successfully relay a FIDO2 challenge to the real Microsoft servers because the origin won’t match. Tycoon 2FA’s proxy mechanism breaks completely against FIDO2. If your privileged accounts are still on TOTP codes or SMS OTP, you have accounts that are fully vulnerable to the next Tycoon 2FA, which is coming. Plan the migration now.
Token binding and Conditional Access. Microsoft Entra Conditional Access policies with device compliance requirements mean a session cookie stolen from a victim machine cannot be used from an unmanaged attacker device. The policy says this session is only valid from a compliant, enrolled device. A stolen cookie imported into an attacker’s browser fails the compliance check. Combine this with Continuous Access Evaluation for near-real-time session revocation when anomalies surface.
Session TTLs. How long does an authenticated session persist in your environment? If the answer is “I don’t know,” that is a problem you need to fix today. Default Microsoft 365 token lifetimes can persist for weeks. An attacker with a cookie from a Tycoon 2FA hit in January could, depending on your configuration, still have an active session right now. Your incident response procedure should list “revoke all active sessions and tokens” as step one on suspected account compromise — before password reset, not after it.
Impossible travel and concurrent session alerting. A user authenticating from Germany at 9am and from an IP in Singapore at 10am is either running a VPN for legitimate reasons or is compromised. Your SIEM should have this rule. If it doesn’t, write it today. AiTM session hijacking often manifests exactly here: one legitimate session, and suddenly a second active session from an unexpected geography or device. This is not sophisticated detection — it’s a basic conditional rule that catches a large percentage of active session hijacks. The Odido breach showed what happens when nobody is watching these signals across 8 million customer accounts.
Email gateway detection. Tycoon 2FA lures had documented behavioural signatures — specific redirect patterns, HTML structure, hosting infrastructure tells. Proofpoint, Microsoft Defender for Office 365, and Intel471 have all published IOC lists and detection guidance. If you run your own email gateway, apply those. Run retrospective analysis against your historical email logs for the past 30 months — the entire operational lifespan of this platform. Find out if any of your users were targeted. Find out if any of them clicked.
As I’ve warned writing about Booking.com getting phished, repeatedly, because the human element never gets fixed, the core issue is that MFA marketing created a generation of IT leaders who think they solved the authentication problem. They didn’t. They solved one specific attack vector. PhaaS platforms like Tycoon 2FA exist precisely because “solved authentication” was proclaimed too early, and too loudly, and too incorrectly.
What You Need To Do Right Now
If any user in your organisation could plausibly have clicked a phishing link in the past two and a half years — which is to say, if you employ humans who read email — you should treat potentially any Microsoft 365 or Google Workspace account as possibly having had its session hijacked at some point. That is not paranoia. That is what 100,000 confirmed victims in two and a half years of operation implies.
Pull your Microsoft Entra sign-in logs. Look for sessions from unexpected geolocations, unexpected IP ranges, unusual device registrations, or unexpected application access patterns — particularly any application being accessed that the account doesn’t normally touch. Cross-reference against the IOC lists. Anything suspicious: revoke the session, revoke all tokens for that account, reset the credentials, and then investigate.
Review your MFA configuration. TOTP and SMS OTP should be considered temporary mitigations at this point, not solved security. Prioritise FIDO2 migration for admin accounts, privileged service accounts, and executive-level mailboxes — the highest-value targets first. Then roll it out to the rest of your user population on a scheduled timeline with actual enforcement dates, not “we’re planning to look at this.”
Set explicit short-duration token TTLs for privileged access. If your cloud admins have session tokens that persist for eight hours, twelve hours, or God forbid longer, shorten them. Privileged sessions should require re-authentication frequently. Inconvenience is not a security argument. Incident response is inconvenient. Pick your inconvenience.
And for the love of everything, do not announce internally that you’ve “handled” the Tycoon 2FA risk because the platform was taken down. You haven’t. The attack category is alive. The session cookies that platform harvested over 30 months of operation may still be valid in some environments. And the successor platform is already taking orders somewhere on Telegram, almost certainly at a lower price point and with better customer support. That is how this industry works.
