Session Token Theft: Multi-Factor Authentication Without a Multi-Factor Prompt

The misconception this technique exploits#

Multi-factor authentication is widely described as something that stops phishing. It stops credential phishing. The distinction matters, because the artifact that grants access to a modern web application is not a password — it is a session cookie issued after authentication completes.

An adversary-in-the-middle kit does not attempt to guess, brute force or bypass the second factor. It positions itself between the user and the identity provider, lets the authentication succeed exactly as designed, and takes the resulting session token.

Mechanics#

The kit operates as a transparent reverse proxy:

1. The victim loads the phishing domain, which fetches and relays the genuine sign-in page in real time.
2. Submitted credentials are forwarded upstream to the real identity provider.
3. The provider issues its genuine MFA challenge, which is relayed back to the victim.
4. The victim approves. The provider issues a session cookie.
5. The proxy stores that cookie, then redirects the victim onward so the session appears to complete normally.

The attacker imports the cookie into their own browser. The application sees a valid, unexpired session that has already satisfied every authentication requirement.

Why conditional access often does not intervene#

Most policy engines evaluate conditions at authentication time. A replayed cookie arrives after that gate has closed.

Detection#

Cookie replay leaves narrow but real traces. Useful signals, in rough order of reliability:

• Sign-in without a corresponding authentication event. A session appearing in application logs with no matching interactive sign-in is the strongest indicator.
• User agent or TLS fingerprint drift within a single session lifetime.
• Autonomous system change between the authentication event and subsequent activity, particularly into hosting provider ranges.
• Mailbox rule creation shortly after sign-in — a reliable follow-on action rather than an access indicator.
• Newly registered look-alike domains resolving from corporate DNS.

# Illustrative detection intent, expressed as pseudo-query
sessions
| where authentication_event_id is null
| where source_asn in (hosting_provider_asns)
| join mailbox_rule_events on session_id within 30m

Controls that actually change the outcome#

Ranked by how much of the attack path each removes:

1. Origin-bound authentication (WebAuthn/FIDO2). The authenticator refuses to respond to a domain it was not registered against. The proxy never obtains a credential to relay, so the attack fails at step two rather than being detected at step five.
2. Token binding to device or client certificate. A stolen cookie replayed from different hardware is rejected.
3. Continuous access evaluation. Shortens the useful life of a stolen session from hours to minutes.
4. Restricting mailbox rule creation and alerting on it. Does not prevent access, but consistently catches the first post-access action.

Number-matching and push fatigue mitigations are worth deploying, but they address a different technique. Against this one they change nothing, because the user is approving an authentication they actually initiated.

Assessment#

Confidence is high. The pattern is consistent across widely available phishing kits and the mechanics are not in dispute.

The practical implication is uncomfortable for programmes that treat MFA rollout as a completed milestone: the control has to be specified by type, not by presence. "MFA enabled" and "phishing-resistant MFA enforced" describe very different security positions, and only the second one addresses what is described here.