Tycoon2FA is Down - What Happens Next?

On March 4th 2026, a Europol-led coalition took down Tycoon2FA - a major adversary-in-the-middle (AiTM) phishing-as-a-service platform in operation. At its peak, Tycoon2FA was behind campaigns targeting over 500,000 organisations per month, with tens of millions of phishing messages sent. Microsoft's technical analysis of the platform is thorough and worth reading: Inside Tycoon2FA.

It's good work. Genuinely. But if the takedown feels like the end of the story, read on.

We've been here before

Tycoon2FA didn't appear out of nowhere. It rose to dominance because its predecessors were taken down. Microsoft themselves note that Tycoon2FA's growth was fuelled by the disruption of Caffeine and RaccoonO365 - two other phishing-as-a-service platforms that were dismantled before it.

So the pattern is clear: a platform is built, it grows, law enforcement and industry partners coordinate a takedown, and within months the customer base migrates to whatever fills the gap. Caffeine was taken down, and its users moved to RaccoonO365 and Tycoon2FA. RaccoonO365 was taken down, and Tycoon2FA absorbed more of the market. Now Tycoon2FA is down.

Something will replace it. Probably multiple things. The demand hasn't gone anywhere - account takeover via AiTM is too effective and too profitable for the criminal ecosystem to simply stop because one platform was disrupted.

What we saw

Tycoon2FA infrastructure has been in our feed for a long time. We were detecting and blocking their backend proxy infrastructure in the environments we protect well before the takedown.

Microsoft's analysis describes the platform's infrastructure patterns in detail: the short-lived domains on cheap TLDs (.space, .email, .solutions, .live), the shift from high-entropy subdomains to readable ones mimicking legitimate services, the 24-72 hour lifespan of campaign-specific domains. All of this is accurate, and all of it describes the frontend - the disposable, throwaway layer of the attack.

What we track is the other end. The backend proxy engines that those thousands of throwaway frontends all funnel through. The infrastructure that actually proxies authentication to your identity provider and captures session tokens. The stuff that persists for weeks or months, gets reused across campaigns, and costs real money and effort to maintain.

This is the infrastructure that matters.

The frontend problem

Tycoon2FA was generating thousands of new frontend domains daily. Microsoft's report shows them rotating across TLDs, using recognisable subdomains (cloud, desktop, azure, sharepoint, microsoft) to reduce suspicion, and burning through domains faster than any blocklist could keep up.

If your defence strategy depends on cataloguing these frontends after they've been used, you're playing a game you cannot win. By the time a URL is reported, analysed, and pushed to a blocklist, the campaign has moved on. The domain is dead and a new one has taken its place. This was true of Tycoon2FA and it's equally true of what's already taken its place.

Go chasing frontends all you like. We'll carry on finding the backend infrastructure that matters.

Here is what it looks like in practice. These are two Tycoon2FA login pages, both presented on different domains from our data back in May 2025 - ten months before Europol's takedown:

The domains are:

etsinqshan[.]com
qenzsoln[.]com

Both of these domains were being fronted by cloudflare (like the majority of AiTM frontends around that time). Fortunately we have a few techniques for delving further, and in doing so we pull out the backend infrastructure, an IPv6 address highlighted in bold below:

[
  {
    "hostname": "etsinqshan.com",
    "ip": "2a0b:7140:8:1:5054:ff:fe10:9356"
  },
  {
    "hostname": "etsinqshan.com",
    "ip": "104.21.10.196"
  },
  {
    "hostname": "etsinqshan.com",
    "ip": "172.67.190.211"
  }
]

[
  {
    "hostname": "qenzsoln.com",
    "ip": "2a0b:7140:8:1:5054:ff:fe10:9356"
  },
  {
    "hostname": "qenzsoln.com",
    "ip": "172.67.181.196"
  },
  {
    "hostname": "qenzsoln.com",
    "ip": "104.21.35.250"
  }
]

This IPv6 address is the IP address that victims of this campaign will have observed in their authentication logs. It was the same IP address for these two frontends, and many others. The backend supporting both of these frontends, and many others, was a single VPS sat in a cloud hosting provider in the US. Multiple frontends, one backend.

{
  "ip": "2a0b:7140:8:1:5054:ff:fe10:9356",
  "region": "Texas",
  "country": "US",
  "org": "AS62904 Eonix Corporation",
  "timezone": "America/Chicago"
}

This is not an anomaly, back in 2024 when we ran an analysis on some of our data this theme was very much there, one backend, multiple frontends:

What doesn't change

Platforms come and go. Tycoon2FA replaced Caffeine. Tycoon2FA was already on the decline and has been replaced by other kits. The names change, the admin panels get redesigned, the evasion techniques evolve. But one thing remains constant: every AiTM attack requires backend infrastructure that logs into your identity provider on behalf of the attacker.

That backend infrastructure has to exist. It has to be online. It has to be configured to proxy authentication flows. And it has to be detectable - because no matter how cleverly the frontend is disguised, the backend still needs to talk to Microsoft Entra, Okta, Google Workspace, or whatever identity provider is being targeted.

This is why we focus on backend detection. It's platform-agnostic. It doesn't matter whether the attacker is using Tycoon2FA, Whisper2FA, Evilginx, Starkiller, or the next toolkit that hasn't been named yet. The backend infrastructure pattern is fundamentally the same, and it's what we hunt.

What should you be doing right now?

The Tycoon2FA takedown is not a reason to relax. If anything, the next few weeks are higher risk - displaced operators will be migrating to new platforms, testing new infrastructure, and spinning up fresh campaigns. Here's what's worth doing now:

Audit your current threat intel coverage. Would your existing feeds have caught Tycoon2FA infrastructure before the takedown? If your feeds are reactive - based on URLs observed in attacks - the answer is probably no, or at best only partially and after victims had already been hit. If your conditional access policies only block infrastructure after it's been reported, you have a gap.

Review your conditional access policies. If you haven't already, read our post on where conditional access risk policies fail against AiTM. The default Microsoft recommendations can actually weaken your defences. A "risky sign-in" policy that grants access after an MFA challenge is a regression if your organisation already enforces MFA - you're giving an AiTM proxy exactly what it needs to succeed.

Think about what your defences depend on. Do they depend on knowing the name of the platform? Knowing the specific URL? Or do they work at the infrastructure level, regardless of which toolkit generated the phishing page? If your defence model requires identifying the specific platform, it will break every time a new one appears. If it works at the infrastructure level — blocking backend proxies from authenticating to your IdP - it survives platform changes by design.

Don't assume FIDO2 alone is the answer. It's the strongest single control against AiTM, and every organisation should be working toward phishing-resistant MFA. But full FIDO2 deployment takes time, fallback methods often remain enabled during rollout, and not every user or scenario can be covered. You need layers, not a single control you haven't finished deploying yet.

Challenge traditional thinking. We try hard to avoid talking about phishing when talking about AiTM. Phishing is unquestionably the primary delivery mechanism for AiTM lures, but it doesn't have to be - it's used because it works, and it works because it's easy to evade email security. But AiTM isn't an email problem, it's an authentication problem. It might start with an email, but it ends with someone logging into your identity provider through an attacker's proxy. That's the point to kill it.

What comes next

We're already tracking the infrastructure that will power whatever follows Tycoon2FA. We don't need to wait for a new platform to be named, for Europol to issue a press release, for Microsoft to publish an analysis or even for there to be victims. The backend infrastructure is visible now, during the preparation phase, and it's already in our feed.

If you're not sure whether your current defences would have protected you from Tycoon2FA - or from whatever comes next - start a free 30-day trial or find us in the Azure Marketplace.