What a session cookie represents
HTTP is stateless. A server receiving a request has no inherent knowledge of prior requests, including the one in which a user authenticated.
Session tokens resolve this. On successful authentication a service issues a token — conventionally stored as a cookie — which the client presents with each subsequent request. The server validates the token against its session store, or in stateless designs verifies a cryptographic signature, and treats the request as authenticated.
The token is therefore not a credential. It is proof that a credential was accepted at some earlier point, and evidence of that kind is transferable in a way a password check is not.
Why the distinction determines the threat model
A password is an input to an authentication process. Presenting it initiates a verification sequence which may include additional factors, device checks, risk scoring, and logging of the attempt.
A session token is the output of that process. Presenting it initiates nothing. The verification already happened, under conditions the server no longer re-examines.
An attacker holding a valid token therefore does not authenticate. They resume a session that was legitimately established, and every control positioned at the authentication boundary is positioned behind them.
This is the substance of the claim that session theft "bypasses MFA." The control is not defeated in any technical sense. It was satisfied by the legitimate user, and the resulting session carries that satisfaction forward without re-verification.
Extraction methods
Infostealer malware. The dominant vector. Infostealers copy the browser's entire cookie store alongside saved credentials. In practice the cookies are frequently the more valuable component, since they require no password and trigger no login event.
Adversary-in-the-middle phishing. Rather than harvesting credentials, the phishing infrastructure proxies the genuine authentication flow. The victim authenticates against the real service, completes any MFA challenge, and the proxy captures the token as it is issued. Frameworks automating this are widely available, and the technique is effective against any factor that validates identity at login rather than binding the session to a device.
Malicious browser extensions. Extensions granted broad host permissions can read cookies for the origins they cover.
Cross-site scripting. Historically significant, now substantially mitigated by the HttpOnly attribute, which makes a cookie inaccessible to page scripts. The mitigation is effective where applied and absent where it is not.
Why password rotation is insufficient
On most platforms, changing a password does not invalidate existing sessions.
The reason is deliberate. Terminating every session on every password change would sign users out of every device each time they updated a credential, and vendors have generally judged that cost unacceptable. Sessions therefore persist across rotation unless explicitly terminated.
The standard incident response sequence inherits this. Exposure is detected, rotation is enforced, the incident is closed — and the attacker's session, established before the rotation, continues to function.
Revocation is a distinct operation from rotation, and it should precede it. If rotation happens first, a window exists in which the attacker retains access, can observe that a reset occurred, and can act on that knowledge — registering an additional authentication factor, altering recovery addresses, or establishing alternative persistence before the session is terminated.
The correct order is: revoke all sessions, rotate the credential, audit authentication factors for unrecognised enrolments, rotate any tokens or keys stored on the affected host, then remediate the host itself. Omitting the final step returns the environment to its starting condition, since the malware will harvest the replacement credential.
The stateless token problem
A structural limitation worth stating, because it determines whether revocation is possible at all.
Where sessions are recorded server-side — in a database, a cache, a session store — revocation consists of deleting the record. The next request presenting that token fails validation.
Where sessions are represented by self-contained signed tokens, commonly JSON Web Tokens, no server-side record exists. The token is valid because its signature verifies and its expiry has not passed. There is nothing to delete, and consequently no mechanism to terminate the session before expiry.
Architectures of this kind can implement revocation only by introducing state: a denylist consulted on each request, or short-lived access tokens paired with revocable refresh tokens. Both reintroduce the lookup that stateless design was intended to avoid.
For defenders, the practical question is specific: can your organisation actually terminate a session on demand, on each system that matters? Where the answer is no, the exposure window is fixed by token lifetime rather than by response time, and that should be understood before an incident rather than during one.
Session lifetime and persistence
Session duration varies from hours to months. Persistent-session options extend it substantially, and many implementations refresh the expiry on activity — meaning an attacker actively using a stolen token can sustain it indefinitely without ever re-authenticating.
This is why cookies extracted months earlier retain value, and why age is a poor proxy for relevance when assessing stealer log exposure.
Controls
Bind sessions to the device. The direction of travel in browser security is cryptographic binding, where the token is tied to a key held in device hardware and cannot be replayed from another machine. Where available, this addresses replay at its root rather than mitigating its consequences.
Reduce session lifetime on sensitive systems. Effective and genuinely costly in usability terms — a trade-off to be made deliberately, not assumed away.
Re-authenticate for consequential actions. Requiring a fresh factor before permission changes, data export, or financial operations limits what a resumed session can accomplish even where it cannot be prevented.
Evaluate session context. Abrupt changes in address, autonomous system, or device fingerprint mid-session are weak signals individually and useful in combination. Legitimate users change networks, so this cannot be applied absolutely.
Set HttpOnly, Secure and an appropriate SameSite value on cookies in applications you control. These do not address malware with filesystem access, but they close the script-based and cross-site paths.
Establish revocation capability before you need it. Know where the control lives on each critical platform, who is authorised to invoke it, and how to confirm it took effect. Where token architecture prevents revocation, know that in advance.
Monitor for exposure. Where extraction occurs on a host outside your administrative control — which is the common case — internal telemetry produces no signal, because a replayed session is indistinguishable from legitimate use. Detection is external by necessity, and the controlling variable is the interval between the token surfacing and the session being terminated.
For the distinction between malware that captures input over time and malware that extracts stored state in bulk, see infostealer vs keylogger.