In February 2026, cybersecurity researchers at Abnormal AI made a discovery that is already reshaping how the security industry thinks about phishing defense. The platform they uncovered, calling itself Starkiller, does not operate like any phishing kit that came before it. It does not serve a fake login page. It serves the real one — live, in real time, through an attacker-controlled proxy — and in doing so, it sidesteps every traditional detection method and renders multi-factor authentication (MFA) effectively useless.
Reported by Brian Krebs on February 20, 2026, and backed by detailed technical analysis from Abnormal AI researchers Callie Baron and Piotr Wojtyla, Starkiller represents what many in the security community are calling a watershed moment in the evolution of the phishing-as-a-service (PhaaS) ecosystem. This is not a marginal improvement on an old technique. It is a fundamental architectural shift that demands an equally fundamental rethink of how organizations defend their users, their accounts, and their data.
Why Traditional Phishing Has Always Had a Weakness
Traditional phishing operations work by cloning a target website, hosting that clone on a malicious server, and directing victims to it through deceptive emails or messages. The victim sees something that looks like a Microsoft, Google, or PayPal login page, enters their credentials, and the attacker captures what was typed.
This approach has a fundamental fragility: the cloned page is static. When Microsoft or Google updates the design of its login portal, the fake page immediately looks out of date. More importantly, security vendors have spent years building detection systems tuned exactly to this model — page fingerprinting, domain reputation systems, anti-phishing blocklists. Those tools work reasonably well, until a platform appears that makes the static clone completely obsolete.
What Starkiller Actually Does: The Transparent Proxy Architecture
Starkiller operates on an entirely different architectural principle from any conventional phishing kit. An attacker enters a brand’s real URL, and the platform spins up a Docker container running a headless Chrome instance that loads the real login page. The container then acts as a man-in-the-middle reverse proxy, forwarding the end user’s inputs to the legitimate site and returning the site’s responses.
In practical terms, when a victim clicks a Starkiller phishing link, they are not seeing a fake page. They are seeing the legitimate Microsoft login portal, the real Google sign-in screen, or the actual PayPal interface — loaded live through the attacker’s infrastructure. The HTML, CSS, and JavaScript served to the victim’s browser come directly from the real site, because the attacker’s server is fetching them in real time and relaying them forward.
Every input the victim types — their username, their password, their MFA one-time code — is captured in transit as it passes through the attacker’s reverse proxy. From the victim’s perspective, the authentication succeeds. They are logged in. Nothing went wrong. Meanwhile, the attacker has harvested their credentials and their authenticated session token.
How MFA Becomes the Attack Surface
The alarming capability of Starkiller is MFA bypass — and understanding why it works requires understanding the fundamental difference between time-delayed attacks and real-time relay attacks.
Conventional phishing steals credentials for later use. This is why MFA became so effective against it: even if an attacker stole a username and password, the MFA code had typically expired by the time they tried to use it. Time-based one-time passwords (TOTP) refresh every 30 seconds, creating a very narrow exploitation window.
Starkiller eliminates this problem entirely by collapsing the time gap to zero. The victim is not handing over credentials to be used later. The victim is, in real time, completing the authentication flow against the legitimate site — but doing so through the attacker’s infrastructure. When the victim enters their TOTP code, that code is forwarded to Microsoft or Google in the same moment. The legitimate session token issued in response is captured by the attacker before the victim even sees the confirmation screen.
“When attackers relay the entire authentication flow in real time, MFA protections can be effectively neutralized despite functioning exactly as designed.” — Abnormal AI, “Starkiller: New Phishing Framework Proxies Real Login Pages to Bypass MFA,” February 19, 2026
The researchers at Abnormal AI were precise in their framing: MFA is not broken. It is functioning correctly. The attack does not crack or circumvent MFA in any cryptographic sense. It exploits the timing model that MFA defenses depend on. Organizations that believe MFA is a sufficient terminal defense are operating with an outdated mental model of how these attacks work.
Cisco Talos documented the broader trend in their Q1 2024 Incident Response report, noting that MFA-related weaknesses were involved in nearly half of all security incidents their team responded to — including users accepting fraudulent push notifications and improper MFA implementation. Microsoft’s Threat Intelligence team has similarly tracked abuse of AiTM frameworks by multiple threat actors, including the Russian espionage group Star Blizzard and the cybercrime operator Storm-0485. What Starkiller adds is the radical democratization of the technique — packaging a previously expert-level attack into a point-and-click subscription service.
The Jinkusu Group: A Cybercrime Business
Starkiller is not a standalone tool created by a lone developer. It is one of several cybercrime services operated by a threat group calling itself Jinkusu. (Note: this platform is unrelated to the legitimate open-source red team penetration testing tool of the same name developed by BC Security.) The group sells Starkiller as a subscription-based SaaS product, complete with monthly fees, regular feature updates, customer support via Telegram, and an active user community forum where operators discuss techniques, request features, and troubleshoot deployments. In an ironic twist, the platform protects its own operators with time-based one-time password two-factor authentication on the login panel — the same category of protection it is specifically designed to bypass for victims.
The platform advertises a 99.7% success rate on its public landing page — a marketing claim that Dark Reading analysts have described as “almost certainly fictional,” but one that reflects both the brazenness of the operation and the commercial sophistication with which modern cybercrime platforms are built and promoted.
The Jinkusu forum shows an active user base. Members share operational tips, ask questions about mobile device support, and request new target brand additions. This community structure mirrors what legitimate SaaS companies build around their products: a user ecosystem that generates feedback, drives product improvement, and creates network effects.
The platform also includes an email harvesting capability that collects email addresses and contact information from compromised sessions. According to the kit’s own marketing materials, this data can be used to build target lists for follow-on phishing campaigns, creating a compounding effect in which a single successful compromise fuels the next wave of attacks and enables lateral expansion across an organization.
Additional modules include specialized capture templates for credit card numbers, cryptocurrency wallet seeds, bank credentials, and payment information. Fake browser update templates are available for tricking victims into downloading malicious payloads. The platform also promotes an “EvilEngine Core” module that claims to make phishing links entirely undetectable by security scanning tools.
URL Masking: Engineering the First Click
Starkiller includes a dedicated URL masking system designed to maximize the likelihood of that first click. An attacker selects a brand to impersonate from a menu that includes Google, Microsoft, Facebook, Apple, Amazon, Netflix, PayPal, and a range of banks. The tool generates a deceptive URL that visually mimics the legitimate domain while routing traffic through the attacker’s infrastructure.
The URL construction exploits a long-documented quirk of how web browsers parse addresses. Everything before the “@” symbol in a URL is treated as username data — legacy syntax from the early web — and the actual destination domain comes after the “@” symbol. Starkiller uses this to construct links like login.microsoft.com@[malicious-domain.ru] which display the trusted brand name prominently before the actual malicious destination.
The URL Masker integrates with popular URL shortening services including TinyURL, is.gd, and v.gd. Shortened URLs hide the full destination entirely, stripping away even the malicious domain. Email security filters that rely on URL reputation cannot effectively analyze what they cannot read.
The Operator Experience: Phishing as a SaaS Dashboard
One of the striking aspects of Starkiller is how comprehensively it has eliminated technical barriers for would-be attackers. Running an AiTM phishing campaign previously required configuring web servers, managing SSL/TLS certificates, standing up reverse proxy infrastructure, and handling DNS configuration. Starkiller automates all of it.
The control panel manages Docker container lifecycles, image builds, and active container status from a single interface. Attackers need not understand what a reverse proxy is, how certificate trust chains work, or how to configure a headless browser. They select a target brand, click a button, and the infrastructure assembles itself.
The monitoring capabilities include real-time session monitoring allowing the attacker to live-stream the victim’s interaction with the phishing page, a keylogger capturing every keystroke, cookie and session token theft for direct account takeover, geo-tracking of the victim’s location, automated Telegram alerts when new credentials arrive, and campaign analytics displaying visit counts, conversion rates, and performance graphs.
Why Traditional Defenses Fail
The security industry has built a large ecosystem of tools around the static phishing page model. Most of those tools fail against Starkiller — not because they are poorly designed, but because they are designed for a threat model that Starkiller’s architecture makes irrelevant.
Static page analysis works by fingerprinting the HTML, CSS, and JavaScript of known phishing pages. Starkiller renders this ineffective because there is no static phishing page to fingerprint. The page served to the victim is dynamically fetched from the real server in real time.
Domain blocklisting is similarly ineffective. Starkiller’s URL masking generates different domains for each campaign, and the domains have no established malicious reputation when the campaign begins. By the time a domain is identified and blocked, the campaign has often moved on.
Reputation-based URL filtering evaluates links based on the age and behavior of the destination domain. New domains have no reputation to evaluate negatively. A shortened URL hides the destination domain entirely.
“Because Starkiller proxies real login pages live rather than serving a cloned template, there often isn’t a stable phishing-page fingerprint to match, and the victim experience can look indistinguishable from a legitimate sign-in.” — Callie Baron, Senior Content Marketing Manager for Threat Intelligence, Abnormal AI, quoted in Dark Reading, February 2026
The AiTM Lineage: Where Starkiller Fits in History
The adversary-in-the-middle attack category has been developing for nearly a decade. The open-source tool Evilginx debuted in 2017 as a custom version of the nginx web server, repurposed as an AiTM phishing proxy; it was later redesigned and rewritten in Go as a standalone application with its own HTTP and DNS server. Modlishka and Muraena followed, each implementing variations of the transparent reverse-proxy concept. These tools lowered the barrier but still required meaningful technical knowledge to deploy.
Commercialized PhaaS platforms like EvilProxy and Tycoon 2FA made AiTM accessible to a broader criminal market but still left some technical seams visible to defenders — distinguishable domain patterns, certificate organization fields, URL path structures, and timing signals.
Starkiller’s innovation is the Docker-based headless browser architecture. Rather than operating a custom proxy engine that must be painstakingly tuned to each target website’s authentication flow, Starkiller simply runs the real browser against the real site and relays the result. This eliminates template drift — when Microsoft updates its login page, Starkiller users automatically serve the updated page because they are always fetching it live.
What Effective Defense Actually Looks Like
Against a platform like Starkiller, the most important defensive shift is conceptual before it is technical. Defenders must accept that a successful MFA completion no longer means a legitimate user completed it. The question is no longer “did MFA succeed?” but “does the session behavior after MFA success look like the legitimate user?”
Phishing-Resistant MFA (FIDO2)
FIDO2 hardware security keys and passkeys work against AiTM attacks for a cryptographic reason that conventional MFA cannot match. FIDO2 authentication is bound to the specific domain of the site the user is authenticating against. When the authentication flow passes through Starkiller’s proxy, the domain presented to the FIDO2 authenticator is the attacker’s domain, not Microsoft’s or Google’s, and authentication fails. Organizations that have fully deployed FIDO2 hardware keys or passkeys are genuinely protected against this class of attack in a way that TOTP and push-notification MFA are not.
Conditional Access and Continuous Session Evaluation
Conditional access policies should continuously evaluate session health rather than treating MFA completion as a one-time gate. Evaluating device compliance state, IP address reputation, geographic location, and user-agent consistency throughout a session — rather than only at login — dramatically reduces the value of a stolen session token.
Session Token Binding
Associating a token to the specific device fingerprint and IP address that completed authentication constrains the utility of stolen tokens. If a session token can only be used from the same device and network that generated it, replaying it from the attacker’s infrastructure fails even if the token was successfully captured.
Behavioral Email Analysis
Detection should focus on anomalies in sender behavior, email authentication signals (SPF, DKIM, DMARC alignment), and whether a given link request is consistent with the user’s normal workflow, rather than relying primarily on URL reputation.
Password Managers as a Passive Defense Layer
Browser-based password managers offer a practical, if partial, layer of defense. Because password managers autofill credentials only when the domain in the browser address bar matches the stored entry, they will not populate credentials on a Starkiller proxy domain. A user visiting login.microsoft.com@[malicious-domain] would find that their password manager does nothing — a strong behavioral signal that something is wrong. This is not a complete defense, since users can still manually enter credentials, but it provides a meaningful friction point that organizations should encourage.
Organizations should update incident response playbooks to account for the post-MFA compromise scenario. Traditional playbooks assume that MFA completion means a legitimate user is present. Starkiller requires playbooks that address what to do when a confirmed, legitimate MFA completion is followed by session behavior consistent with an attacker operating in a different location on an unrecognized device.
Key Takeaways
- MFA is not enough: Starkiller collapses the time gap between credential capture and use to zero, making TOTP and push-notification MFA ineffective. FIDO2/passkeys are the only phishing-resistant alternative.
- Static defenses are obsolete for this threat class: Page fingerprinting, domain blocklisting, and URL reputation filtering all fail against a platform that serves real login pages through a transparent proxy.
- Shift to behavioral detection: The question must move from “did MFA succeed?” to “does post-authentication behavior match the legitimate user?” Continuous session evaluation, device binding, and anomaly detection are essential.
- Cybercrime is industrializing: Starkiller is sold as a SaaS product with customer support, analytics dashboards, and community forums. The skill floor for executing advanced attacks has collapsed.
- Act now, not later: These are not aspirational long-term goals. Deploying FIDO2, implementing session token binding, and updating incident response playbooks are urgent operational priorities.
“The level of ongoing development means Starkiller is likely to become increasingly difficult to detect and defend against.” — Abnormal AI, “Starkiller: New Phishing Framework Proxies Real Login Pages to Bypass MFA,” February 19, 2026
The broader lesson is one the security community has encountered before: attackers iterate faster than defenders. The ecosystem has evolved from static phishing clones to open-source AiTM tools to commercial PhaaS platforms with analytics dashboards and customer support, in under a decade. The next iteration is already in development. The question for defenders is whether their architectures will be ready for it before it arrives at scale.