Phishing kits like Starkiller use real-time reverse proxies to bypass MFA by capturing session cookies post-authentication. This technical analysis explores why traditional MFA fails and details concrete solutions like TLS fingerprinting, FIDO2, and strict Conditional Access Policies to defeat these Man-in-the-Middle attacks.

That 3 AM Page: When MFA Isn’t Enough

I remember the alert like it was yesterday. 3:17 AM. A high-privilege account login from an unrecognized IP. Standard procedure: check logs, rotate creds, call the user. The user swore up and down they were asleep. But the logs were clear: successful username, password, and a successful MFA push notification approval. We were staring at a ghost in the machine. For a few panicked hours, we thought our whole identity provider was compromised. The truth was simpler, and way more insidious: a real-time phishing proxy had just made our multi-million dollar security stack look like a picket fence. This isn’t theoretical anymore; it’s happening, and if you’re not prepared, you’re next.

So, What’s Actually Happening Here? The Ugly Truth About AiTM.

We drill it into our users: “Use MFA! It’ll protect you!” And we’re not wrong, but we’re not entirely right, either. We’ve trained people to defend against credential theft, but the game has changed. These new attacks aren’t just after your password; they’re after the keys to the kingdom: your session cookie.

Think of it like this: an Attacker-in-the-Middle (AiTM) phishing kit is just a malicious reverse proxy. It’s a web server that sits between your user and the real login page (like login.microsoftonline.com).

1. The user clicks a phishing link (`login.microsftonline.com` instead of `login.microsoftonline.com` – spot the typo?).
2. The proxy presents a perfect pixel-for-pixel copy of the real login page to the user.
3. The user enters their username and password. The proxy forwards this to Microsoft.
4. Microsoft challenges for MFA. The proxy forwards the MFA prompt to the user.
5. The user approves the MFA push or enters their TOTP code. The proxy forwards this to Microsoft.
6. Microsoft says, “Great, you’re legit!” and sends back a session cookie to the proxy.
7. Here’s the rub: The proxy now has the valid, MFA-blessed session cookie. It passes it to the attacker and maybe redirects the user to a “login failed” page. The attacker now logs in as the user, from their own machine, completely bypassing the MFA challenge because they have the post-authentication session token.

Your MFA did its job—it proved the user was who they said they were at that exact moment. But it did nothing to prove the user was talking directly to your server.

Pro Tip: Stop thinking about just protecting credentials. Start thinking about protecting the session. The session token is the real prize for attackers in a post-MFA world.

The Fixes: From Duct Tape to Fort Knox

Alright, enough doom and gloom. We’re engineers; we build things and we fix things. Here are three ways to fight back, ranging from a clever trick to a fundamental architectural shift.

1. The Quick Fix: TLS Fingerprinting (JA3/S)

This is my favorite “hacky-but-it-works” solution. Every time a browser initiates a TLS connection (HTTPS), it sends a “Client Hello” message. The combination of ciphers, extensions, and curves in that message creates a unique signature, almost like a fingerprint. A user’s Chrome on Windows has a different fingerprint than the phishing kit’s Go or Python HTTP client on Linux.

The phishing proxy has to make two separate TLS connections: User <–> Proxy and Proxy <–> Your Server. The fingerprint your server sees is from the proxy, not the user’s browser. If you know what your users’ browsers should look like, you can spot the imposter.

The Reddit thread’s Rust PoC is a perfect example of how to grab this. On your end, you could implement a check in your load balancer or authentication gateway (like F5, NGINX, or a custom service). The logic is simple: “Does the TLS fingerprint for this session match the User-Agent header?” If a request comes in with a User-Agent for Chrome on Windows but a TLS fingerprint for a common Linux cURL library, you can flag it or block it outright.

// Pseudo-code for an auth gateway check
function is_valid_fingerprint(request) {
    let user_agent = request.headers.get("User-Agent");
    let tls_fingerprint = request.get_tls_fingerprint(); // e.g., JA3 Hash

    // A pre-compiled map of known-good User-Agent -> Fingerprint mappings
    let known_good_prints = get_known_good_fingerprints(user_agent);

    if (known_good_prints.contains(tls_fingerprint)) {
        return true; // Looks legit
    } else {
        log_suspicious_activity(request.ip, user_agent, tls_fingerprint);
        return false; // Mismatch! Likely a proxy.
    }
}

Is it foolproof? No. Attackers can try to spoof their fingerprints. But it raises the bar significantly and stops the low-effort kits dead in their tracks.

2. The Permanent Fix: Phishing-Resistant MFA (FIDO2/WebAuthn)

This is the real solution. FIDO2 and WebAuthn (using hardware keys like YubiKeys, or platform authenticators like Windows Hello) fundamentally change the game. They create a cryptographic binding between the user, their authenticator, and the specific website they are trying to log into (the “origin”).

When a user registers their YubiKey with `login.realcorp.com`, the key stores that origin. During login, the server sends a challenge, and the user’s browser tells the YubiKey, “Hey, `login.realcorp.com` is asking you to sign this.” The key signs it and sends it back. The server verifies the signature and lets them in.

When the phishing site (`login.phishingcorp.com`) tries to proxy this, the browser tells the YubiKey, “Hey, `login.phishingcorp.com` is asking you to sign this challenge from `login.realcorp.com`.” The YubiKey’s internal security logic says, “Absolutely not. I’ve never heard of `login.phishingcorp.com`,” and the authentication fails. The MitM attack is broken at a cryptographic level.

Warning: The rollout is the hard part. It requires user education, hardware distribution, and a fallback plan for lost keys. It’s a project, not a flick of a switch, but it’s the only way to truly solve this problem for good. Start with your privileged users and expand from there.

3. The ‘Nuclear’ Option: Strict Conditional Access Policies

Sometimes you’re under active attack and you just need to stop the bleeding, now. This is where you use your Identity Provider’s muscle. In Azure AD, this is called Conditional Access. In Okta, it’s Sign-on Policies. The principle is the same: add more context to the authentication decision beyond just the credential and MFA.

You build a wall with rules like this:

This is “nuclear” because it can be disruptive. A salesperson on hotel Wi-Fi might get blocked because their device falls out of compliance. But when `prod-db-01` is on the line, you sometimes have to accept a few false positives to stop a catastrophic breach. You can apply these policies in a “report-only” mode first to see the impact before you flip the big red switch.

Ultimately, security is about layers. None of these is a silver bullet, but by combining them, you can build a system that is resilient, intelligent, and strong enough to make attackers decide to go after easier targets. Now, go check your logs.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions