New Starkiller Phishing Framework Uses Real Login Pages to Bypass MFA Security
A new phishing framework called Starkiller is raising the bar for “phishing-as-a-service” by serving victims the real login pages of major brands through attacker infrastructure, making pages look authentic and stay up to date.
By acting as a live reverse proxy, it can capture credentials and, more importantly, steal session cookies/tokens after the victim completes multi-factor authentication (MFA), enabling account takeover even when MFA is working as designed.
How Starkiller works
Unlike traditional kits that host static HTML clones, Starkiller spins up a headless Chrome browser inside a Docker container, loads the target brand’s real site, and proxies traffic between the victim and the legitimate service.
This approach delivers genuine HTML/CSS/JavaScript to the victim while keeping the attacker “in the middle,” so user input and authentication artifacts pass through and can be logged.
Operationally, the platform is presented as a polished control panel where an operator pastes a brand URL and deploys the phishing flow with minimal technical effort.
Abnormal’s write-up notes capabilities beyond basic credential theft, including real-time session monitoring (live viewing of the victim session), keystroke logging, geo-tracking, automated Telegram alerts, and campaign-style analytics like visits and conversion rates.
It also highlights “MFA bypass” as a core selling point because the victim is genuinely authenticating to the real site through the proxy, allowing the attacker to capture the resulting session cookies and tokens after MFA is completed.
Starkiller also tries to remove the most common user warning sign, the suspicious link, by providing a URL masking tool.
The platform supports brand impersonation choices (e.g., major consumer and enterprise providers), keyword modifiers, and built-in URL shorteners to obscure the true destination.
One technique described is the “@” (userinfo) URL trick, where content before “@” is treated as user info and the real destination comes after it, helping the link look trustworthy at a glance.
This aligns with widely documented URL disguise behavior: the browser ultimately navigates to the domain after the “@”, even if the earlier text appears to reference a legitimate brand.
The same marketing materials described in the report position Starkiller for broader fraud, with modules for payment/financial data theft (including crypto wallet seed phrases) and “fake update” templates intended to push malware via bogus browser update prompts.
The framework is presented as an evolving service, with a community forum, ongoing updates, and even TOTP-based 2FA to protect operator access to the panel.
What defenders can do now
The core defensive shift is to treat this as session hijacking at scale, not “just” password phishing. Practical steps that materially reduce impact include:
- Prioritize phishing-resistant authentication (FIDO/WebAuthn or PKI) for high-value users and apps, since standards bodies explicitly recommend phishing-resistant options due to phishing risk. Federal guidance also describes how FIDO2’s challenge-response signing binds authentication to the legitimate service, improving resistance to verifier impersonation.
- Hunt for identity signals that survive perfect-looking pages: anomalous sign-ins, session token reuse from unexpected locations, and other behavioral patterns highlighted as necessary when page fingerprinting and simple blocklists fail.
- Tighten email and URL controls: expand short links, flag “@” userinfo patterns, and train users to verify the real domain (the part after “@” if present), since attackers use that structure to misdirect attention.
- Assume rapid follow-on: if a user reports a suspicious “real” login experience, revoke active sessions, reset credentials, and review sign-in logs for token replay and new device registrations (because the attacker may already have a valid session cookie).