TL;DR: Starkiller uses headless Chrome and live reverse proxying to present real login pages, capture OTPs and session cookies, and bypass MFA while lowering the skill needed to run enterprise-style phishing, according to Abnormal AI. Static page fingerprinting and reputation filtering are no longer sufficient when defenders must detect anomalous logins, token reuse, and inbox behaviour instead.
NHIMG editorial — based on content published by Abnormal AI: Starkiller uses headless Chrome to proxy live login pages and bypass MFA
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
- 69% of organisations now have more machine identities than human ones.
- 57% of organisations lack a complete inventory of their machine identities.
Questions worth separating out
Q: How should security teams defend against phishing kits that proxy real login pages?
A: Treat the login page as the least reliable signal.
Q: Why do phishing kits that capture OTPs still bypass MFA?
A: Because the attacker is not defeating the factor, they are relaying it in real time and stealing the resulting authenticated session.
Q: What breaks when organisations only rely on static phishing detection?
A: They miss live proxy attacks that deliver the real website content through attacker infrastructure.
Practitioner guidance
- Instrument session replay detection Correlate login success with subsequent token reuse, location change, and device drift so a valid authentication does not become a blind spot.
- Harden inbox-to-login attack paths Treat email, identity, and browser telemetry as one chain.
- Reduce trust in bearer sessions Shorten the practical lifetime of sensitive sessions, require re-authentication for high-risk actions, and tie session validity to context changes that are difficult for a relay to preserve.
What's in the full article
Abnormal AI's full analysis covers the operational detail this post intentionally leaves for the source:
- The control-panel workflow that lets operators spin up live phishing infrastructure without reverse-proxy expertise.
- The URL masking logic, including the @-symbol trick and shortener chaining, that makes malicious links harder to classify.
- The session-monitoring and Telegram alert functions that show how operators track targets after credential capture.
- The community and update model behind the kit, which explains why it may evolve faster than static detection rules.
👉 Read Abnormal AI's analysis of Starkiller's live proxy phishing infrastructure →
Starkiller phishing kits: are your login and session controls keeping up?
Explore further
Static phishing detection is now a broken premise. Starkiller works because defenders have long assumed the malicious page is a static object that can be fingerprinted, compared, and blocklisted. Once the attacker proxies the real site live, that assumption fails because every victim sees current legitimate content rather than a template. The implication is that phishing defence must stop treating page appearance as the primary trust signal.
A few things that frame the scale:
- 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
- Another finding from the same research shows that 53% of organisations have experienced a security incident directly related to machine identity management failures.
A question worth separating out:
Q: Who is accountable when a stolen session is used for follow-on phishing?
A: Accountability sits across identity, messaging, and security operations. Identity teams own session controls and anomalous login detection, messaging teams own delivery-path abuse, and SOC teams own containment of reused tokens and mailbox compromise. A stolen session is not just a phishing issue, because it becomes an access and lateral-movement problem once it is reused.
👉 Read our full editorial: Starkiller phishing shifts the burden from page checks to session abuse