MFA protects the login, not the session.

Fastpotify’s session token survives multi-factor authentication. That is the finding. The login completes, the MFA challenge passes, and the platform issues a session cookie that carries full authenticated state - bound to nothing. No device. No network. No client. Steal the cookie, replay it, and the session belongs to whoever holds it. No password. No second factor. This maps cleanly to MITRE T1539, steal web session cookie, chained to T1550.004, use of a web session cookie as alternate authentication material. There is no memory-corruption CVE here. This is a design-level weakness - CWE-613, insufficient session expiration, layered with CWE-539, persistent cookies carrying sensitive session state.

Start with what the token is. A bearer token. Possession equals authority. After the identity provider returns a successful assertion, Fastpotify mints the cookie, and from that point the cookie is the only artifact the server validates per request. It does not re-check the MFA result. It does not re-validate the IdP assertion. It verifies the cookie signature and the expiry timestamp. Both hold, the request is authenticated. The second factor was a one-time gate at the front door. The cookie is a key that copies.

The break is in binding. There is none. Whether the token is an opaque session ID or a signed JWT is irrelevant - neither variant seals in a device fingerprint hash, a TLS channel binding per RFC 8471, a source-IP pin, or a token-binding key. The cookie is portable by construction, and a portable bearer token is a credential that can be lifted and used elsewhere. Move it to another host, another browser build, another ASN, and the server accepts it - because the server never encoded where the token was permitted to be used. The trust decision was made once, at issuance, and never re-evaluated.

Lifetime compounds the exposure. Long idle timeout. Long absolute lifetime. Sliding renewal that extends the cookie on every request. A cookie captured at hour zero stays valid across the full window, and refresh-on-use means an attacker who keeps the session warm - one request every few minutes - never lets it lapse. HttpOnly limits JavaScript read access, but HttpOnly does nothing against theft at the network edge or theft of the browser’s cookie store on disk.

The primary exploit path is adversary-in-the-middle. T1557. An attacker stands up a reverse-proxy phishing kit - Evilginx-class. The victim lands on a lookalike domain. The proxy relays traffic to the real Fastpotify login in real time. The victim enters credentials. The proxy forwards them upstream. The real server issues the MFA challenge. The victim completes it - a push approval, a TOTP code, an SMS. The real server returns the authenticated session cookie back through the proxy, and the proxy captures it in transit. MFA passed. It passed for the attacker’s benefit. The cookie now sits in the attacker’s possession as a fully authenticated session. This is the exact mechanism that neutralised push and TOTP MFA across 2022 through 2024 in campaigns Microsoft and Okta both documented.

The second path is client-side theft. An infostealer on the endpoint - RedLine, Lumma, Raccoon. The stealer reads the browser cookie store. On Windows the values are DPAPI-protected, but DPAPI decrypts in the user’s own context, so a process running as the user recovers the plaintext. The stealer exfiltrates the Fastpotify cookie inside a bulk log and sells it on a marketplace. A buyer imports the cookie into a browser and resumes the session. T1555.003, credentials from web browsers. The cookie does not care that it was minted on a different machine.

This is the dominant MFA-bypass class in current intrusions. Scattered Spider - UNC3944 - and the broader initial-access-broker economy run on stolen session cookies, not cracked passwords. Cloudflare and Okta have both published incident analysis naming session-token replay as the operative step. The password stopped being the target once MFA became common. The session cookie replaced it, because the cookie is the authenticated artifact that sits behind MFA - the thing MFA was protecting, now portable.

Telemetry is where this gets uncomfortable. The authentication log records one successful MFA login from the victim. Clean. It does not fire a second time on replay, because replay is not authentication - it is the presentation of an existing session. The SIEM sees a legitimate login, then activity that inherits that login’s trust with no corresponding auth event. Detections keyed on failed logins, impossible MFA prompts, or brute force see nothing. Nothing failed.

The signal lives in session correlation. One session ID, two source ASNs, two geographies, minutes apart. Victim in Sydney on a residential ISP, replay from a hosting provider’s IP range. Impossible travel - but computed against the session, not the account. Fastpotify’s server logs, if they record source IP and user-agent per session, carry the discrepancy. The failure is rarely missing data. It is un-correlated data. The fields exist in separate log lines that no rule joins.

User-agent drift is the second tell. The stolen cookie is replayed from a different browser build than the one that minted it. The platform binds nothing, so it accepts the mismatch silently - but the access log still records two distinct user-agent strings against a single session lineage. That delta is queryable. A correlation rule that groups by session ID and alerts on a change in ASN or user-agent mid-session catches both the AiTM and the infostealer replay.

Endpoint telemetry only helps on the client-theft path. The infostealer stage is visible. Sysmon Event ID 11 on writes near the browser profile directory. Event ID 10 on process access to the browser process, or direct reads of the Login Data and Cookies SQLite files by a process that is not the browser. EDR flags the unusual handle to the cookie store. That is the on-host tell. The AiTM path leaves nothing on the endpoint - the theft happens inside the proxy, off-host, and the victim’s machine only ever talked to what looked like a normal login.

Network telemetry carries the AiTM indicators. The phishing domain is newly registered, lookalike, with a TLS certificate issued hours before use, proxying to the real origin. DNS logs and proxy logs hold it. Post-compromise, replay traffic to Fastpotify originates from datacenter IP space rather than residential - an ASN-reputation signal that a session-aware rule can weight.

The durable detection is a stateful join. Key events by session identifier, not by account. Emit an alert when a single session shows a change in source ASN, a shift in user-agent family, or concurrent activity from two IPs inside a short interval. That requires the platform to log IP and client per request, not per login, and it requires the SIEM to hold session state rather than evaluate events in isolation. Most environments log the login and discard the session context. That is the gap the replay walks through - not a missing sensor, a missing correlation.

The patch boundary is the point that matters. Binding the token kills the class. Device-bound session credentials - the cookie bound to a private key held in the endpoint’s TPM or secure enclave, along the lines of the Device Bound Session Credentials work Google is shipping in Chrome - make the cookie non-replayable. Proving possession requires a key that never leaves the device, so a cookie copied to another host is inert. Short absolute lifetimes and forced re-authentication on sensitive actions shrink the usable window. Server-side revocation that actually invalidates the session - not a client-side cookie clear - closes the door on a session already stolen.

Residual exposure after a partial fix is the trap. If Fastpotify shortens the lifetime but leaves the token unbound, the window narrows and the class survives. AiTM captures a fresh cookie regardless of how short its life is, because the attacker replays it immediately, inside the valid window, while the victim is still logged in. Lifetime reduction only defeats stale-cookie replay from old infostealer dumps. It does nothing against real-time proxy capture. The single control that breaks cookie replay is cryptographic binding of the session to the device it was issued on. Everything short of that is window management, and window management does not stop an attacker who is already inside the window.