Starkiller falls into a category of phishing that no longer tries to “imitate” an access page: it places itself in the middle and proxies the legitimate page in real time. The user sees a “normal” login, enters credentials, and completes MFA, yet the attacker can maintain the authenticated state (cookies/tokens) and reuse it. The result is an intrusion that, from the point of view of many traditional controls, looks far too much like a valid sign-in.
In corporate operations, this shifts the focus: it’s not enough to “have MFA” or to train people to spot poorly placed logos. Useful defense involves understanding what the proxy is intercepting (the session), how that session travels to the attacker, and how to instrument signals that let you detect it and cut access before the attacker turns that session into persistence.
What went wrong: MFA completed, and the session was stolen anyway
The typical failure is not that the user “typed the password anywhere” without thinking; it’s that the flow looks legitimate because the phishing service loads the real page through a proxy. In many cases, the fraudulent domain serves the provider’s content (IdP/SSO), and the user completes the process without friction. What the attacker wants is not only the password, but the artifact that proves “I’m already authenticated”: the session cookie or the token issued after MFA.
In terms of impact, this translates into access to email, collaboration tools, or cloud consoles without needing to type credentials again. In practice, the first move is often to change email forwarding rules, register a new factor, create a “legitimate” OAuth app, or download data. The security team receives alerts that look like “a user logging in successfully,” and reaction time shrinks.
How Starkiller works when it acts as a real-time proxy
The operational idea is simple: the attacker controls a domain and a server that behaves as an intermediary. The user’s browser does not talk directly to the IdP, but to the proxy; the proxy, in turn, talks to the real IdP. The user sees authentic screens because, to a large extent, they are: they are rendered through the intermediary.
In that transit, the proxy can capture credentials and, most critically, capture/inject cookies and tokens. If the provider issues a session cookie after MFA, that cookie can be exposed to the intermediary and reused from another machine. In an enterprise, this is noticeable because the attacker doesn’t “break” MFA: they reuse it within the time window in which the session is valid.
- Session interception (cookie/token)
When the target is the cookie, the most painful indicator is that changing the password afterward does not immediately cut the stolen session if there is no global invalidation or if there are persistent sessions. In environments with legacy applications or integrations, this is common: the password is rotated, but the session stays alive long enough for the attacker to create persistence.
- Reuse from another host/ASN
Operationally, it is observed as a “jump”: the same user goes from an interactive login to activity from another location/network without a new MFA challenge. If the IdP does not bind the session to the device or does not force reauthentication on context changes, the attacker can operate until the session expires or someone revokes it.
Early signals in logs: what really gives away a phishing proxy
Effective detection rarely comes from a “suspicious URL” in an email (though it helps). What usually gives away a real-time proxy are flow anomalies: sequences of events, abrupt IP/UA changes, or access patterns that don’t fit the usual device. In a corporate SOC, what’s valuable is correlating telemetry from the IdP, the endpoint, and the destination SaaS.
Realistic example: a user completes MFA in the IdP from their corporate laptop (EDR telemetry present), and a few minutes later, activity appears in email from a different user-agent and without a managed-device footprint. If the attacker also creates inbox rules or authorizes an OAuth app, that “second step” is often more deterministic than the login itself.
- Context change without reauthentication
Look for sessions that change IP/ASN or user-agent in a short window, especially if there is no new MFA or “step-up” event. In providers that log “token refresh” or “session issued,” correlate it with the first access to sensitive resources (email, drive, console).
- Persistence actions in SaaS
Forwarding rules, delegations, registered devices, app passwords, or new OAuth apps are often the next move. It’s more useful to alert on “forwarding rule creation” or “consent granted” after an anomalous sign-in than to try to block every phishing email.
How to do it in practice: guardrails that actually stop session theft
Defense against proxy phishing is not a single piece; it is a combination of session controls and conditional access policies. The goal is that, even if the user completes MFA in an intermediated flow, the session is not reusable from the attacker’s environment or is quickly invalidated when context changes.
In an enterprise, what’s most effective is usually hardening the identity plane: requiring phishing-resistant authentication where possible (methods based on origin/key, not codes), and forcing “step-up” or blocking when the device is not managed or when the network origin doesn’t comply. If your organization relies on BYOD or external access, it has to be implemented with well-governed exceptions; otherwise, the operational bypass is done by the company itself.
- Configure conditional access by device and risk
Concrete action: define policies that require a managed/compliant device for critical applications (email, storage, admin panels). Verification: validate in the IdP that a login from an unmanaged browser forces a stronger method, limits the session, or outright blocks. In internal testing, simulate access from a device without posture and confirm that you do not obtain a reusable session.
- Reduce session lifetime and scope
Concrete action: tune session timeouts and revocation. At an operational level, make sure the response procedure (password reset) includes revoking active sessions and revoking tokens in the IdP/SaaS. Verification: after revoking, check that a previously active session stops accessing (not only that the next login fails).
- Block typical post-phishing persistence
Concrete action: create alerts and, if your platform supports it, auto-remediation rules for: creation of forwarding rules, granting of OAuth consents, enrollment of new factors, and changes to recovery methods. Verification: run a controlled exercise (decoy account) and confirm that the event triggers an alert and that the playbook revokes the session and reverts the change.
Recommendations for corporate environments
Starkiller represents phishing where the real target is the session, not the form. In that scenario, completing MFA does not guarantee security if the attacker can intermediate the flow and reuse cookies/tokens issued after the challenge.
In operations, what works best is combining: detection by sequences (context changes without reauthentication and persistence actions), conditional access policies that bind sessions to device/risk, and response procedures that include effective revocation of sessions and tokens. If your controls do not force a “step-up” when context changes, a real-time proxy will continue to look like a normal login.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.