A new generation of attack tools no longer shows victims a fake copy of a login page. It shows them the real one, sitting invisibly between the victim and the legitimate site to capture everything, including the multi-factor code that was supposed to stop this exact attack.

 

What happened

Security researchers have documented a shift in how phishing kits operate, moving away from static fake copies of login pages toward tools that display the genuine website in real time while secretly routing the victim's activity through attacker-controlled infrastructure. According to The Hacker News, a platform called Starkiller, sold as a subscription product by a group calling itself Jinkusu, loads a brand's actual login page inside a hidden browser running on the attacker's own servers, then sits between the victim and the real site, relaying everything back and forth. Because the victim is genuinely interacting with the real service the entire time, any password, one-time code, or authentication token they enter passes directly through the attacker's infrastructure before continuing to the legitimate site. Multi-factor authentication completes exactly as it is supposed to. The attacker simply captures the resulting authenticated session and can use it to access the account independently, without the victim ever noticing anything unusual happened.

 

Going deeper

According to Infosecurity Magazine, Starkiller can impersonate a wide range of major services, including Google, Microsoft, Facebook, Apple, Amazon, Netflix, and various banks, and gives buyers a point-and-click control panel that requires no technical knowledge of how the underlying proxy or certificate systems actually work. The tool includes real-time session monitoring that lets an attacker watch a victim interact with the fake page live, a keylogger that records every keystroke, and automated alerts sent through Telegram whenever a new victim's credentials are captured. Because there is no fake page template involved at any point, security tools that work by identifying and blocking known malicious page designs have nothing consistent to detect. Every session looks different because every session is, in a technical sense, genuinely real. This same infrastructure-first approach has appeared in other campaigns as well. A columnist writing in SC World described a separate operation called GS7 that used sophisticated phishing kits to build login pages mimicking major brands with what researchers characterized as unprecedented accuracy, automating the registration of new lookalike domains in batches and producing more than 150 phishing sites targeting Fortune 500 financial services, technology, healthcare, and telecom companies.

 

What was said

Researchers who examined Starkiller's control panel, cited by Dark Reading, described the platform's significance in its packaging rather than any single new technique, "What is novel isn't a single feature. It's the architecture and packaging. Starkiller turns high-end reverse-proxy tradecraft into a turnkey, SaaS-style workflow that dramatically lowers the skill barrier and removes the usual weak points defenders rely on." Researchers added that organizations need to shift their detection approach entirely, "Organizations have to shift toward behavioral and identity-aware detection. This means monitoring for anomalous sign-ins, session token reuse, impossible travel patterns, and other signals of compromised sessions, even when MFA was technically completed, and the login page looked legitimate."

 

In the know

The technique Starkiller uses, known as adversary-in-the-middle proxying, has appeared across a growing number of competing phishing platforms rather than remaining unique to one operation. Tycoon2FA, one of the most widely used platforms using this same approach, was estimated to account for a large share of phishing attempts Microsoft blocked before facing partial law enforcement disruption in early 2026, with pricing as low as roughly $120 per month, according to Cyber Unit. Other active tools using the same underlying method include Evilginx, an originally legitimate security-testing framework that has been widely adopted by criminals, along with Sneaky2FA and FlowerStorm.

 

The big picture

Healthcare organizations that treat multi-factor authentication as sufficient protection against account compromise are working from an assumption that these tools were specifically built to defeat. A billing coordinator or clinical administrator who receives a convincing phishing email and clicks through has no visual signal that anything is wrong, because the page they see genuinely is the real Microsoft or Google login screen, rendered live. According to Paubox's 2026 Healthcare Email Security Report, 53% of breached healthcare organizations in 2025 used Microsoft 365, and the standard MFA methods most organizations rely on, authenticator app codes, SMS codes, and push notifications, are all captured in real time by this style of attack rather than defeated through any technical flaw in MFA itself.

 

FAQs

Why does multi-factor authentication fail to stop this kind of attack if it's working correctly?

MFA confirms that the person logging in controls the correct device or authentication method. In an adversary-in-the-middle attack, the victim genuinely does complete that verification because they are interacting with the real service the whole time. The attacker isn't defeating MFA technically. They are simply capturing the valid, fully authenticated session that MFA correctly produced, and using that session for themselves.

 

Why can't security tools just block the fake login page the way they used to?

Older phishing kits relied on a static, copied version of a login page that could be identified and blocked once security vendors recognized its unique design. A tool that loads the real page live through a hidden browser has no fixed design for a security tool to recognize, since the content is pulled directly from the legitimate site each time and simply passed through the attacker's infrastructure.

 

What is a headless browser, and why does it matter to how these attacks work?

A headless browser is a fully functional web browser that runs without any visible window on screen, controlled entirely by automated commands rather than a person clicking around. These phishing platforms use a headless browser running on the attacker's own server to load the real target website, which is what allows the tool to display genuine, up-to-date page content to the victim while secretly capturing everything they type.

 

Does phishing-resistant authentication actually stop this specific technique?

Authentication methods based on FIDO2 hardware keys or passkeys are cryptographically bound to the exact website domain they were set up for, which means the authentication process fails automatically if it is being relayed through an attacker's proxy rather than connecting directly to the real site. Standard authenticator app codes, SMS codes, and push notifications have no such binding and can be captured and reused by the attacker in real time.

 

What should security teams monitor if password resets and MFA no longer indicate a resolved compromise?

Since credentials themselves are never technically wrong in these attacks, teams need to watch for anomalous sign-in patterns such as logins from unexpected locations shortly after a suspicious email was received, session tokens being used from multiple different devices or locations in a short window, and unusual inbox rule changes or data access patterns following a login, rather than relying on password strength or MFA completion as an indicator that an account is secure.