After a successful login, a website usually issues a session cookie so the browser does not repeat authentication on every page. If an attacker steals that active session, the account may appear already authenticated, even when MFA protected the original login.
How sessions are stolen
Infostealer malware can copy browser data from a compromised device. An adversary-in-the-middle phishing page can relay a real sign-in and capture the resulting session token. Unsafe extensions and exposed debugging logs can also leak session material.
Warning signs
- Account activity continues after a password change.
- New forwarding rules, API tokens or connected applications appear.
- Security logs show a recognized session from an unfamiliar location.
- Messages are marked read or settings change without explanation.
Containment requires more than a password reset
- Use a clean device and the service's “sign out everywhere” control.
- Change the password and remove unknown recovery methods.
- Revoke application passwords, OAuth grants and API tokens.
- Scan the original device and remove suspicious extensions.
- Recreate sessions only after the device is trusted again.
Reduce the risk
Keep browsers updated, install extensions sparingly and never paste commands from a surprise “verification” page. Use phishing-resistant authentication, but remember that device compromise occurs after authentication. Services should use short-lived sessions for sensitive actions, rotate tokens, set secure cookie attributes and ask for reauthentication before changing recovery or payment details.
MFA remains valuable; session theft does not make it pointless. It means security must protect the login, the browser and the session lifecycle rather than treating authentication as the finish line.
Why changing a password may not end the incident
A stolen session cookie can remain valid until it expires or the server revokes it. After suspected infostealer activity, use the account's “sign out everywhere” control, remove unfamiliar devices and connected applications, and then change credentials from a clean system. Email deserves priority because it can reset many other accounts.
Developer-side protections
Session cookies should use Secure and HttpOnly attributes, an appropriate SameSite policy, short lifetimes for sensitive roles and rotation after authentication changes. Bind high-risk actions to fresh authentication rather than trusting an old session indefinitely. Logging should support revocation without storing raw session secrets.
No cookie flag repairs a compromised computer. Endpoint updates, extension review and malware response remain necessary, while session design limits how long a stolen token stays useful.
Understand the session lifecycle
A session token is valuable because the server accepts it as evidence that authentication already happened. Theft can occur through malware, a malicious extension, cross-site scripting, an exposed log or an insecure device backup. MFA may have protected the original login perfectly and still be bypassed once the authenticated session is copied.
Containment must invalidate the server-side session. Changing the password is important, but some services deliberately preserve existing sessions. Use the account's session-management controls, revoke connected applications and rotate high-value credentials from a clean device.
What developers should verify
Use cookies with Secure, HttpOnly and an appropriate SameSite value. Rotate the session identifier after login and privilege changes, expire inactive high-risk sessions, and require fresh authentication for payments, recovery changes and administrator actions. Store only a verifier or hashed token when the design allows it, never raw bearer tokens in ordinary logs.
Test revocation explicitly. Sign in on two devices, revoke one session and confirm that its next request fails. Then change the password and document which sessions survive. Security documentation should describe observed behavior, not assume every framework or identity provider makes the same choice.