Researchers at Abnormal Security disclosed the Starkiller platform in February 2026 after uncovering its control panel and analyzing its infrastructure. The platform is operated by a cybercriminal group calling itself Jinkusu and sold openly as a commercial-grade phishing toolkit — complete with a dashboard, Telegram support, monthly updates, and documented features. It is not related to the legitimate red team tool of the same name from BC Security.
What separates Starkiller from phishing kits that have come before it is the architectural approach. Rather than hosting a static HTML replica of a target login page — an approach that breaks whenever the real site updates its layout — Starkiller loads the actual, live login page through attacker-controlled infrastructure and positions itself between the victim and the legitimate service in real time. This is the definition of an adversary-in-the-middle (AiTM) attack, and Starkiller packages that capability into a point-and-click workflow that requires no technical expertise to operate.
How the Platform Works
The core mechanism is straightforward to describe even if the infrastructure behind it is not. When an attacker selects a target brand from Starkiller's control panel, the platform spins up a Docker container running a headless Chrome browser instance. That container loads the real login page for the selected brand — Microsoft 365, Google, PayPal, Apple, banking portals, or virtually any other service — and then acts as a reverse proxy between that site and the victim.
When a victim clicks the phishing link and arrives at the page, they are not looking at a clone. They are looking at the actual login interface for the real service, rendered live through the attacker's infrastructure. Every element — the fonts, the layout, the placeholder text, any recent UI changes — is current because the content is being pulled from the real site in real time. There is nothing static to fingerprint.
Because Starkiller proxies the real site live rather than serving a cloned template, there are no static phishing page files for security vendors to fingerprint or blocklist. The phishing page itself is indistinguishable from the legitimate login portal because it is the legitimate login portal.
As the victim types their credentials and submits any MFA codes, those inputs are forwarded to the real service through the proxy. The login succeeds — the victim is authenticated. From the victim's perspective, nothing went wrong. But every keystroke, form submission, and session token passed through attacker-controlled infrastructure on the way through, and all of it was logged.
Why MFA Fails Against This Attack
This is the part that matters for organizations that have deployed MFA and believe it provides sufficient protection. Against AiTM attacks like Starkiller, most common forms of MFA offer no meaningful protection at all.
The reason is timing. MFA codes — whether delivered by SMS, generated by an authenticator app, or sent via email — are valid for a short window and are designed to be entered into a browser. In a traditional phishing scenario where the attacker collects a code on a fake page, they would need to race to use it before it expires. Starkiller eliminates that race entirely. Because the victim is actually authenticating with the real service through the proxy, any one-time code they submit is forwarded to the legitimate site in real time. The site issues a valid session token. The victim is logged in. Starkiller captures that session token alongside the credentials, and the attacker now has everything needed to authenticate as the victim independently — without needing the code again and without the victim being aware anything went wrong.
SMS codes, TOTP authenticator app codes, email OTPs, and push notification approvals are all vulnerable to AiTM session theft. The code is valid and the login succeeds — Starkiller captures the resulting session token. Completing MFA correctly does not protect a user if the session is stolen immediately after authentication.
Push-based MFA — where the user approves a login notification on their phone — removes the need to type a code but introduces MFA fatigue as a separate vulnerability. It does not address the session theft problem. If the victim approves the push notification because they believe they are logging in legitimately, Starkiller receives the authenticated session token just the same.
The only form of MFA that is structurally resistant to this attack is phishing-resistant authentication: FIDO2/WebAuthn hardware security keys and passkeys. These methods use a cryptographic challenge-response mechanism that is bound to the legitimate domain. Because the session is being proxied through a different domain, the cryptographic binding fails and the authentication cannot be relayed. An attacker with a FIDO2-protected target has no path forward through a proxy attack.
The Full Feature Set
Starkiller markets itself as an end-to-end phishing platform, not just a proxy tool. The feature list described in Abnormal's research covers the full attack lifecycle from initial lure delivery to post-compromise data collection.
On the credential capture side, the platform includes real-time keylogging, cookie and session token theft, and automated Telegram notifications when new credentials arrive. Operators can monitor active sessions live, effectively watching the victim's screen as they interact with the proxied page. Campaign analytics provide visit counts, conversion rates, and performance graphs — the same dashboard metrics a legitimate SaaS product would offer.
For URL delivery, Starkiller includes a dedicated URL masking tool that supports keyword customization (selecting terms like "login," "verify," "security," or "account" to include in the link), integrates URL shorteners like TinyURL, and uses the @ userinfo URL trick — where content before the @ character appears to reference a legitimate brand but the browser navigates to the domain that follows it. A crafted link might visually suggest it points to a trusted service while routing to attacker infrastructure.
The @ URL trick works by exploiting how browsers parse URLs. In a URL like https://microsoft.com@attacker.io/login, everything before the @ is treated as credential information and ignored by the browser. The actual destination is attacker.io. Hovering over the link in an email client may display the full string, but a casual glance at the visible text can be misleading.
Beyond credential theft, the platform's marketing materials describe financial fraud modules for capturing credit card numbers, bank credentials, crypto wallet seed phrases, and payment data. Fake software update templates — mimicking Chrome and Firefox update prompts — are included to deliver malware payloads. An advertised module called EvilEngine Core claims to make phishing links undetectable to reputation-based filters.
The operator experience is designed to be frictionless. Docker engine management, container lifecycle, image builds, and active session monitoring are all consolidated in a single panel. Operators do not need to understand reverse proxy configuration, TLS certificate management, or Docker networking. They select a brand, configure a link, and monitor results from the dashboard. Jinkusu maintains a community forum where customers discuss techniques and request features, and provides dedicated Telegram support alongside monthly framework updates.
Context: The Broader PhaaS Ecosystem
Starkiller is the latest entrant in a rapidly expanding phishing-as-a-service (PhaaS) ecosystem. The underlying technique — reverse proxy AiTM session theft — is not new. Evilginx, an open-source framework originally built for red team engagements, has been widely adopted by attackers for several years. Modlishka, Muraena, and others use similar approaches. What Starkiller adds is commercial packaging that removes the operational friction previously associated with running proxy-based infrastructure.
The scale of the problem extends well beyond Starkiller. Tycoon 2FA, another PhaaS platform using AiTM techniques, was partially disrupted by Microsoft and Europol in early 2026 after it had been linked to an estimated 96,000 victims and was responsible for a significant share of the phishing attempts Microsoft blocked in 2025. Its entry price was reported at roughly $120 per month. Sneaky2FA, Flowerstorm, and the 1Phish kit targeting 1Password users represent additional active platforms using variations of the same core technique.
The common thread across all of these platforms is the shift from credential harvesting to session hijacking. Stealing a username and password used to be the goal. Now the goal is the authenticated session token — the cookie that the browser holds after a successful login. With that token, an attacker can access the account directly without ever needing the password or MFA code again, for as long as the session remains valid.
Detection and Defense
Traditional phishing detection methods do not work against Starkiller. Domain blocklisting requires a known bad domain to be identified and added to a list — Starkiller's proxy infrastructure changes per campaign and the phishing page content is pulled live from a legitimate domain, not hosted statically. Static page analysis has nothing to analyze. Reputation-based URL filtering may flag suspicious links, but cannot identify a proxied legitimate page as malicious based on page content alone.
The defensive shift that security teams need to make is from page-level detection to session and identity-level detection. The question is no longer "does this page look like a phishing page?" — it looked exactly like the real thing because it was the real thing. The question becomes "does this authenticated session look like it belongs to this user?"
Behavioral signals that become relevant in this model include anomalous login patterns, session token reuse from unexpected geographic locations, impossible travel events (authentication from one country followed immediately by activity from another), device fingerprint mismatches between the authentication event and subsequent session activity, and access patterns that diverge from the user's normal behavior immediately after login. These signals are detectable through identity threat detection systems, SIEM correlation rules, and the anomaly detection features available in enterprise identity platforms like Microsoft Entra ID and Okta.
- Deploy phishing-resistant MFA: FIDO2/WebAuthn hardware security keys and passkeys are structurally resistant to AiTM proxy attacks because the cryptographic challenge is bound to the legitimate domain. Prioritize this for high-value accounts, administrative access, and financial systems.
- Enable conditional access policies: Enforce device compliance checks, require managed devices for sensitive applications, and configure sign-in risk policies that challenge or block sessions flagged as anomalous. Session token theft from an unmanaged device accessing corporate resources should generate an alert.
- Monitor for session anomalies, not just login failures: Successful MFA completion is not the end of the detection opportunity. Monitor for session token reuse from new IP ranges, impossible travel, and activity spikes immediately following authentication events — particularly for accounts accessing email, file storage, or financial systems.
- Train users on URL inspection: The
@trick and shortened URL patterns are identifiable with trained attention. Users should hover over links before clicking, be suspicious of unsolicited login prompts regardless of how legitimate the destination page appears, and report unexpected authentication requests even when they successfully log in. - Limit session token longevity: Shorter session lifetimes reduce the window an attacker has to use a stolen token. Pair this with re-authentication requirements for sensitive operations — accessing financial data, modifying account settings, or downloading large volumes of files should require step-up authentication.
The detection shift also has implications for incident response. When a compromised account is identified, the investigation should not start with the login page — it should start with the session. Was this token issued from a location consistent with the user's history? Was the authenticating device recognized? Did account activity change immediately after authentication? Those questions are more likely to surface evidence of AiTM compromise than reviewing which login page was visited.
Key Takeaways
- Starkiller proxies real login pages through attacker infrastructure. Victims see the actual legitimate site. There is no visual indicator of compromise, and most users have no reason to suspect anything is wrong. This is not a limitation of user awareness — it is a limitation of the authentication model itself.
- SMS codes, TOTP apps, and push notifications do not protect against AiTM session theft. All three methods can be bypassed in real time by a reverse proxy. Only FIDO2/WebAuthn and passkeys provide structural resistance because their cryptographic binding cannot be relayed across domains.
- The PhaaS ecosystem has made high-capability AiTM attacks accessible to low-skill operators. Infrastructure management, session monitoring, URL masking, and multi-brand impersonation are packaged into a polished dashboard. The technical barrier that previously limited these attacks to sophisticated adversaries no longer exists.
- Detection requires a shift from page analysis to session behavior monitoring. Blocklists and static analysis cannot catch what Starkiller does. The detection surface moves to anomalous session signals after a successful authentication event.
- The goal of modern phishing has shifted from credential theft to session hijacking. Passwords are no longer the primary target — authenticated sessions are. Security architecture and monitoring strategies need to account for this shift explicitly.
Starkiller represents a direction the threat landscape has been moving toward for some time. The technique is well-understood; what is new is the packaging. As the operational cost of running proxy-based phishing infrastructure continues to fall, these attacks will become more common across a wider range of threat actors. Organizations relying on authenticator apps and push notifications as their primary MFA controls should treat that as an incomplete defense and plan accordingly.