MFA Is Working Fine. That's the Problem.

Tycoon 2FA got taken down today. Coinbase, Microsoft, and Europol coordinated a disruption: domain seizures, civil action, operator identified. Good news. Except Starkiller is still running. And the one after Starkiller is already being built. The takedown is not the story. The architecture is.

Nobody explains this clearly in the coverage: these tools don't break MFA. They don't need to. MFA is working exactly as designed when your session gets stolen. That's the actual problem.

What Starkiller Actually Does

Most write-ups describe it as a "phishing kit" and leave it there. That framing is wrong in a way that matters.

A traditional phishing kit serves a static clone of a login page. It collects credentials. Done. That's a solved problem: browser warnings, visual inspection, password managers that won't autofill on the wrong domain.

Starkiller is different. It spins up a Docker container running headless Chrome, loads the real login page, and proxies your entire session through it in real time. You're not looking at a fake Microsoft login. You're looking at the actual Microsoft login, rendered live, with your keystrokes forwarded to Microsoft's servers and the responses piped back to you. Everything works. MFA challenge arrives. You approve it. Login succeeds.

Meanwhile, the session token (the cookie Microsoft issued to prove you just authenticated) gets captured before it reaches you. The attacker's Telegram gets a notification. Their dashboard logs a conversion.

The URL trick is old: [e-mail]. The @ sign means everything before it is treated as username data by the URL parser. The actual destination is attacker-proxy.ru. Browsers have gotten better at flagging this, but it still works often enough to be worth shipping.

Abnormal AI's writeup has the best line: "When attackers relay the entire authentication flow in real time, MFA protections can be effectively neutralized despite functioning exactly as designed."

Exactly as designed. Sit with that.

Why Your MFA Doesn't Help

TOTP codes, push notifications, SMS: all of these answer the same question: is this the right user? They authenticate the user to the server. What they don't do is authenticate the channel between the user and the server.

That distinction is everything.

When you approve a push notification, you're telling Microsoft: yes, this login attempt is mine. You're not telling Microsoft: yes, this login attempt is coming directly from my browser to you. The proxy forwards your approval in real time. Microsoft sees a valid MFA response from your registered device. It issues a session token. The token goes to the proxy. The proxy keeps it.

Session tokens are actually better to steal than passwords. A password proves identity once and you still have to do MFA. A session token proves identity for hours or days, with no MFA challenge on reuse. The attacker doesn't need your password after this. They have your authenticated session.

The enterprise policy gap is what keeps me up at night. Your Conditional Access policy says MFA required: checked. Your SIEM shows authentication succeeded from a compliant device: checked. No anomalous login flags: checked. The session token is already in Telegram.

Your policy is satisfied. Your audit log is clean. You're compromised.

The One Thing That Actually Works

FIDO2 / WebAuthn / passkeys. This is the exception, and the reason is specific.

When you authenticate with a hardware key or a passkey, the authenticator signs a challenge that includes the origin: the domain your browser is actually connected to. If you're on attacker-proxy.ru, your browser reports attacker-proxy.ru as the origin. The authenticator signs that. The legitimate server receives a signature over the wrong domain and rejects it.

The proxy cannot fix this. It doesn't have your private key. It can't forge a valid signature over login.microsoft.com. The origin is cryptographically bound to the authentication response. Proxying breaks it.

This is why I keep pushing back when people say "just use any MFA." The choice of factor matters. TOTP and push MFA are meaningfully weaker than FIDO2 against this attack class, not because they're badly implemented, but because they were designed to solve a different problem.

A few things that help but don't prevent: compliant device policies reduce how useful a stolen token is on an attacker's unmanaged device. Short session lifetimes shrink the window. Continuous access evaluation can revoke tokens mid-session on anomaly signals. These are worth doing. They're defense-in-depth. They don't close the architectural gap.

What To Actually Do

If you're running an org:

1. Enforce FIDO2 where you can. Hardware keys for privileged accounts, at minimum. Microsoft Authenticator passkeys for the rest. Platform authenticators (Touch ID, Windows Hello) are better than TOTP. This is not optional if you're in a high-value-target industry.

2. Compliant device + CAE as defense-in-depth. Won't stop token theft, but limits what an attacker can do with a stolen token. Pair with short session lifetimes.

3. Train people on the URL trick. [e-mail] means the domain is anything.ru. It's detectable if you know to look. Most people don't.

4. Don't treat "MFA required" as a complete control. It isn't. It's a necessary condition, not a sufficient one. Your policy needs to distinguish between MFA-required and MFA-resistant.

If you're an individual: passkeys everywhere you can get them. Not because TOTP is useless (it stops credential stuffing and basic phishing) but because it doesn't stop this.

---

Tycoon 2FA is down. Starkiller is up. The lineage goes back to Evilginx in 2017: nine years of the same technique, getting progressively easier to operate. Docker containers, SaaS dashboards, Telegram bots, reseller programs. The skill floor is near zero now.

The technique isn't new. The operationalization is. And "MFA required" policies that don't specify which MFA are going to keep getting exploited until the industry stops treating all second factors as equivalent.

They're not.