Starkiller Phishing Kit: Why MFA Fails Against Real-Time Reverse Proxies

Sorry, no Hardening macOS this week.

I actually wanted to, but my attention was caught on something else, somehow more urgent. Originally I wanted to limit this blog to Apple and BSD-related contents, but this attack deserves all my attention for a simple reason:

IT IS BEAUTIFUL

*As much as I despise cybercriminals, I think that these mofos are really what pushes the Internet forward.

And when an attack is well crafted, chapeau!, let’s admit it!

Don’t worry, Hardening (and also Reversing 101) will come back next week!

Introduction

This week, Dark Reading reported on a phishing-as-a-service platform called Starkiller, disclosed by researchers at Abnormal AI. Krebs picked it up too.

If you haven’t read the article, go read it. I’ll wait.

Done? Good. Now let me tell you why this thing kept me up past my usual 3:30 AM. If you haven’t, fear not - I’ll fill you in.

The new kid in town is actually a new generation of phishing-as-a-service (PaaS) platforms. This new kid has radically changed the phishing threat model (finally, I’d say. It was sooo 90ish using “Employee security training” as the panacea for everything… but they won’t learn): these platforms do not create fake login pages - they actually proxy the real ones in real time. Aim’s capturing credentials, MFA tokens, session cookies - the whole landscape of boring things. What makes this different is the flow: the user authenticates for real, and credentials are stolen in transit, contextually, as the session happens.

Traditional defences such as domain blacklisting, static page analysis, and obviously MFA pathetically fail to AitM (which, by the way, means Adversary in the Middle. Because the Man in the Middle was not an adversary, clearly…).

Let’s not panic, anyway. We know there’s no perfect defence… but there’s no perfect attack either.

Technical Analysis

The old-phashioned phishing

The usual way to mount a phishing attack was kind of boring: the attacker created a static HTML page, a clone of the actual login page. The user then enters credentials, which are captured. Later on, the credentials get replayed.

It goes without saying that here MFA constitutes a great defence.

These cloned pages go stale quickly, look imperfect, and are easily fingerprinted by security vendors.

The New Way

The attacker runs a reverse proxy, often a headless Chrome instance in a docker container. This reverse proxy:

1. loads the actual login page from the legitimate service
2. serves the page to the victim - although through the attacker infrastructure
3. intercepts everything while in transit:
   1. keystrokes
   2. MFA codes
   3. session cookies
4. this easily leads to obtaining an authenticated session, not distinguishable from the real user’s

The victims: they see the real website, with real content, real functionalities, and real MFA prompts. Everything is real, because everything is real. It’s just taking a detour through someone else’s server. The only anomaly being the URI - and modern kits easily disguise the URIs!

So, dear “Solve everything with MFA”-consultant, now it’s time you find another mantra. But let me explain you why your old mantra is not enough anymore.

MFA does not protect against session hijacking through a real-time proxy. The user completes the MFA challenge legitimately. The token is valid. The session is real. The attacker just happens to be forwarding everything through their own pipe.

The question is not “was MFA completed?” The question is: does the authenticated session behave like the legitimate user?

Key capabilities of Starkiller

Who’s Behind It

Starkiller is one of several services offered by a threat group called Jinkusu. It’s sold as a subscription service with community support, feature requests, and regular updates — mirroring legitimate SaaS business models.

A subscription service. With a dashboard. With campaign analytics. With customer support on Telegram. If this wasn’t scary, it would have been ph-ashinating.

Why Traditional Defences Fail

Ok, now we have a grasp of the severity of the situation. It’s not nice, at all, but again, there are many things you can do. The first one, being getting rid of mantras.

Detection

Detection must shift from “is this page fake?” to “is this session behaving normally?”

Easier said than done.

TLS Fingerprinting

Every TLS client — browser, automation tool, or proxy — produces a distinctive handshake pattern called a JA3 fingerprint. This fingerprint is derived from the cipher suites, extensions, and elliptic curves offered in the TLS ClientHello message.

Detection signal:

• ClientHello with fewer extensions than expected for the claimed User-Agent
• Cipher suite ordering inconsistent with the browser version
• Missing GREASE values (real browsers inject these; some headless configurations don’t)
• JA3 hash matching known automation/proxy fingerprints

Operational note: I have developed a proof-of-concept tool (ja3-probe) that demonstrates this detection capability. The PoC parses TLS ClientHello messages, extracts JA3 components, and classifies the client against a database of known fingerprints.

Post-Authentication Behaviour Analysis (Identity Layer)

This is the most critical detection layer. Even if the attacker captures a valid session, the replayed session will exhibit anomalies:

• Proxemics: (AKA “you’re not Superman, you’re not the Flash. You’re not even Sideshow Bob) A legitimate user authenticates from London, then the session is used from an Eastern European IP like 30 seconds later. Something phishy, there.
• Session token reuse: The same token appears from multiple IP addresses or device fingerprints. Obviously this requires some infrastructure.
• Device mismatch: Authentication completed on a known corporate device, but the session is replayed from an unknown device
• Behavioural deviation: Post-login actions don’t match the user’s established patterns (e.g., immediately creating mail forwarding rules)

Recommended actions:

• Enable Continuous Access Evaluation (CAE) where available (Microsoft Entra supports this, and so does Okta Identity Threat Protection)
• Implement session binding to IP address and device fingerprint at the identity provider level
• Alert on inbox rule creation within 60 minutes of authentication from a new location
• Monitor for OAuth app consent grants from unexpected sessions

DNS & Certificate Intelligence (Infrastructure Layer)

AitM infrastructure leaves traces in the DNS and certificate ecosystem:

• Certificate Transparency (CT) logs: Simultaneous issuance of multiple certificates for subdomains mimicking SSO portals is a strong indicator
• Domain age: Phishing domains are typically registered within 72 hours of use
• DNS patterns: Research by Infoblox has shown that Evilginx campaigns produce consistent DNS patterns even when hiding behind Cloudflare, enabling signature-based tracking
• Dedicated feeds: Lab539 has developed methods to identify AitM infrastructure before it’s used in campaigns

But this is redundant for you, because you read First hardening of the network layer and you learned how to harden your DNS settings so that new domains are not resolved. Yes, you can say that it’s your DNS, not your customers, but there you go: the solution is as easy as recommending your customers to read that article! Better yet, to become avid readers of this blog.

Anti-Evasion Awareness

Modern AitM kits actively detect and evade security scanners:

• They serve benign redirects to non-browser User-Agents
• They use bot detection (JA4 fingerprinting) to filter scanner traffic
• They employ short-lived URLs that expire after a single use

This means passive scanning and crawling are unreliable. Active detection must focus on signals visible during real user sessions, not on probing the phishing infrastructure from outside.

Before some vendor or LinkedIn compliance bard weaponises a sentence in this post, it is worth reiterating that:

• JA3/JA4 are correlation signals, not verdicts.
• FIDO2/passkeys are highly effective when properly deployed, but weak fallback flows can reintroduce risk.
• DNS hardening reduces exposure; it does not “solve phishing” in isolation.
• IP/device/session binding must be implemented with risk-based logic, not cargo-cult rigidity.

  Actions

  Technicalities

  Deploy FIDO2 / Passkeys for high-value accounts. This is the single most effective countermeasure. FIDO2 authentication is cryptographically bound to the legitimate domain. Properly deployed FIDO2/passkeys are phishing-resistant because the authentication ceremony is bound to the legitimate origin (RP ID). An AiTM proxy on a different domain cannot simply relay that like it relays passwords or TOTP codes.. This is not a workaround — it’s a fundamental property of the protocol. If you do one thing after reading this post, do this.

Implement session binding. Tie your session tokens to the IP address and device fingerprint that created them. If a session token suddenly appears from a different IP in a different country, that’s not your user. Kill the session.

Enable Continuous Access Evaluation (CAE) if you’re on Microsoft 365 / Entra. CAE allows near-real-time revocation of sessions when risk signals are detected. It’s not enabled by default. Enable it.

Monitor post-authentication behaviour. The classic AitM-to-BEC escalation path is: steal session → create inbox forwarding rules → send fraudulent payment requests. Alert on inbox rule creation within the first hour after authentication from a new location. Alert on MFA method changes. Alert on OAuth app consent grants.

Inspect TLS fingerprints. Feed JA3/JA4 hashes from your reverse proxy or WAF into your SIEM. Flag connections where the TLS fingerprint doesn’t match the claimed User-Agent.

Subscribe to AitM-specific threat intelligence. Lab539 and Infoblox both publish feeds that identify AitM infrastructure, sometimes before it’s used in campaigns. Integrate these into your DNS-layer blocking.

La touche de l’Architecte

Password managers are your canary. A password manager will only auto-fill credentials on the domain where they were saved. If your password manager doesn’t offer to fill in your Microsoft credentials, you’re not on Microsoft’s domain. Train your users to notice this.

Plan for passwordless. The long-term answer to credential-based attacks is eliminating credentials. Passkeys, certificate-based authentication, hardware tokens. The credential that doesn’t exist can’t be stolen.

What You Should NOT Do

Do not panic-buy a vendor solution without understanding the problem first.

I mean it. Every time a new attack technique gets media coverage, the vendor machine spins up. By next week you’ll have twelve companies telling you their product “stops Starkiller” or “prevents AitM attacks” with some proprietary AI-powered-blockchain-quantum-something.

Before you buy anything, ask yourself:

1. Do I understand how AitM actually works? (If you’ve read this far, you do.)
2. What layer does this vendor’s solution operate at? If it’s just email filtering, it won’t help once the user clicks the link. If it’s just domain blocklisting, it won’t help against freshly spun-up infrastructure.
3. Does this solution address session hijacking, or just credential theft? Because AitM is a session hijacking attack. Stopping the credential theft is nice, but if the session token is already gone, you’re still compromised.
4. Have I done the basics first? FIDO2, session binding, CAE, post-auth monitoring — these are free or near-free and more effective than most paid solutions.

The security industry has a vendorisation problem. Every threat becomes a sales opportunity before it becomes a learning opportunity. Don’t let that happen to you. Understand the attack. Implement the fundamentals. Then evaluate whether you need additional tooling.

And for the love of all that is holy, stop treating MFA as the end of the conversation. It’s the beginning.

Some self promotion

Yeah, I don’t like pushy vendors, therefore I hate selling myself as well. However: remember that in my last posts i randomly ranted about rotten scrapers and revolting script kiddies messing with my resources? Well, if not, you don’t miss much - but I had these issues. Nastier than caries, more insistent than the aforementioned salesman.

What did I do? My response was deliberately nasty. Aradia. There you go: https://www.aradia.zone. Have a look there. Aradia does all the tech-stuff you’ve seen before. And more, because its reason to be is to torture mofos wasting your resources.

Or get in touch with me. I am quite often on https://infosec.exchange - my handle is @gbiondo.

Curious what this looks like in production? aradia.zone/stats

Conclusions

I am a man of my word. You will see a new article in a week for the Hardening macOS series. Perhaps also for the Reversing 101.

In the meantime, be ruthless, be smart, be paranoid, and be also iron man, for fairies wear boots.

And have fun!

References

• Abnormal AI, “Starkiller Phishing Kit” (February 2026) — https://abnormal.ai/blog/starkiller-phishing-kit
• Krebs on Security, “‘Starkiller’ Phishing Service Proxies Real Login Pages, MFA” (February 2026)
• Infoblox, “DNS Uncovers Infrastructure Used in SSO Attacks” (December 2025)
• Kulkan Security, “See no Evil(ginx) / Detecting and Stopping AitM Phishing Threats” (February 2026)
• Microsoft Security Blog, “Detecting and mitigating a multi-stage AiTM phishing and BEC campaign” (June 2023)
• Push Security, “Phishing 2.0: How Phishing Toolkits Are Evolving with AitM” (April 2025)
• Salesforce, JA3 — https://github.com/salesforce/ja3
• FoxIO, JA4+ — https://github.com/FoxIO-LLC/ja4