You changed the password and MFA is enabled, yet the attacker is still reading email. That is possible when the attacker did not steal the password. They stole the proof that the user had already logged in.

That proof is often a session cookie. A browser sends it with later requests so the user does not have to enter a password and MFA code on every page. If an attacker can replay the cookie, the application may see an authenticated session rather than a new login.

TL;DR

  • A session cookie is a temporary credential. Whoever can use it may inherit the session’s access.
  • MFA protects the creation of a session; it does not automatically protect every request made with that session.
  • Cookies can be stolen through infostealer malware, adversary-in-the-middle phishing, browser compromise, or application flaws.
  • Password reset alone may not terminate every session.
  • Respond by revoking sessions and tokens, cleaning the endpoint, removing persistence, and reviewing post-theft activity.

Why This Matters

Security advice often stops at “enable MFA.” That is good advice, but it can create the wrong mental model. MFA makes it harder to create a legitimate session. Once the service has issued that session, the browser usually presents a cookie or token instead of repeating the full authentication ceremony.

An attacker who steals the session may therefore never trigger an MFA prompt. The service sees a credential it created itself.

Microsoft’s guidance describes replayed session cookies as a token-theft risk and recommends controls such as token protection, risk-based reauthentication, and continuous access evaluation where the application supports them. These controls reduce risk, but response teams still need to understand the session lifecycle of each important application.

The terms are often mixed together, so keep the model simple:

  • A session cookie identifies a browser session to a web application.
  • An access token authorizes calls to an API for a limited time and scope.
  • A refresh token can request new access tokens without asking the user to sign in again.

The exact format is less important than the security property: each is a bearer credential unless it is cryptographically bound to a device or key. “Bearer” means possession can be enough. Copying the credential may copy the access.

The Secure, HttpOnly, and SameSite cookie attributes are important, but they solve specific problems. HttpOnly makes a cookie unavailable to normal page JavaScript; it does not stop malware running as the user from reading browser storage. Secure restricts transmission to HTTPS; it does not make a copied cookie unusable elsewhere.

How Sessions Are Stolen

Infostealer malware

Commodity stealers target browser profiles, saved credentials, cookies, and cryptocurrency wallets. The initial infection may be a fake installer, cracked software, malicious attachment, or paste-and-run lure. If the endpoint remains infected, changing credentials on that device can give the attacker the new credentials too.

Adversary-in-the-middle phishing

An AiTM proxy relays the real sign-in page to the victim. The user enters the password and completes MFA with the legitimate provider, while the proxy captures the session issued afterward. The login was real; the path to it was controlled by the attacker.

Browser or extension compromise

A malicious extension, remote debugging interface, or local process may access browser data or act inside the existing browser session. In this case, changing the source IP may not be necessary because the attacker can operate through the victim’s device.

Application vulnerabilities

Cross-site scripting, insecure session handling, leaked logs, exposed debugging data, and transport mistakes can expose session identifiers. These require application-specific investigation rather than assuming every theft came from malware.

How to Detect Token Replay

No single sign proves theft. Build detections around changes in context and impossible sequences:

  • one session appears from two distant networks within an implausible interval;
  • a known browser session suddenly changes autonomous system, user agent, device posture, or TLS characteristics;
  • the account accesses a new application without a corresponding interactive sign-in;
  • sensitive actions occur immediately after a suspicious download, phishing event, or endpoint malware alert;
  • activity continues after a password reset that should have required reauthentication;
  • a session performs mailbox export, OAuth consent, security-setting changes, or bulk downloads outside the user’s normal pattern.

IP address alone is weak evidence. Mobile networks, VPNs, corporate proxies, and privacy relays change addresses legitimately. Conversely, an attacker using a residential proxy near the victim may avoid a country-change alert. Combine network, device, identity, application, and endpoint signals.

For each session, log a non-secret correlation identifier, issuance time, authentication strength, device or key binding status, source context, refresh events, revocation, and sensitive actions. Never store raw cookies or tokens in analytics or incident tickets.

Containment: Do More Than Reset the Password

If session theft is plausible, use a sequence that closes both identity and endpoint access:

  1. Isolate the suspected endpoint when malware is possible. Preserve evidence according to your incident-response process.
  2. Revoke sign-in sessions, refresh tokens, and application sessions. The available controls and delay vary by platform.
  3. Reset the password from a known-clean device. Rotate other credentials exposed on the same endpoint.
  4. Remove persistence. Check new MFA methods, OAuth grants, app passwords, mailbox rules, API keys, recovery details, and devices.
  5. Review the activity window. Start before the first suspicious event and continue through confirmed revocation.
  6. Rebuild or clean the endpoint based on evidence. Do not return a credential-stealing host to service after only deleting the downloaded file.

Microsoft notes that its session-revocation operation can take several minutes and that external users may be governed by their home tenant. SaaS applications may also maintain their own sessions. Test the real behavior before an incident instead of assuming one identity-provider button logs the user out everywhere.

Reduce the Chance of Replay

Use phishing-resistant sign-in to prevent many AiTM paths. Where supported, bind tokens to a managed device or cryptographic key so a copied token is not sufficient. Require recent interactive authentication for high-risk actions such as changing MFA, creating keys, exporting data, or modifying payment details.

Keep sessions no longer than the business need requires. Use both inactivity and overall timeouts. Rotate identifiers after authentication and privilege changes, invalidate them on logout, and avoid putting session IDs in URLs or logs. Application owners should follow OWASP session-management guidance rather than inventing a custom token format.

Endpoint controls remain part of identity security. Browser and token data are reachable after local compromise, so patching, application control, extension governance, EDR telemetry, and limiting local privilege directly affect session risk.

What You Can Do Today

  • Pick one critical SaaS application and document exactly how administrators revoke its web and API sessions.
  • Run a controlled test: sign in, revoke the session, and measure when web, mobile, and API access actually stop.
  • Alert on a new authenticator, OAuth grant, or security-setting change after a risky session.
  • Ensure sensitive actions require recent authentication rather than trusting an old session indefinitely.
  • Teach responders that password reset and session revocation are separate actions.

MFA is still valuable. The correct lesson is more precise: protect the login, protect the endpoint, and treat the session created between them as a high-value credential.

Sources