Session Cookie Theft: You Showed Your ID at the Door. But Someone Else Has Your Room Key

How session cookie theft bypasses MFA — and what you can do about it

When you check into a hotel, you show your ID at the front desk. The clerk verifies who you are, maybe checks a secondary piece of information, and hands you a key card. From that point on, that key card is what gets you into your room. It doesn't matter that you proved your identity at check-in. What matters is who has the key.

Your applications work the same way.

When a user logs into a web application — entering their password, completing an MFA challenge — the application issues them a session token, typically stored as a cookie in their browser. That token is their key card. Every subsequent request the user makes, the application checks for the token, not the credentials. If the token is valid, access is granted.

And if someone steals that token? They get in, too. No username required. No password required. No MFA prompt. They simply replay the token from their own browser. The application can't tell the difference.

What is a session cookie?

HTTP — the protocol that powers the web — is stateless. Every request is independent, which means that without some kind of token, users would have to log in again with every single click.

Session cookies solve that problem. After a successful login, the server issues a cookie that represents the authenticated session. As long as that cookie is valid, the user stays logged in.

The important takeaway: the session cookie is the credential after login. Even a perfectly secured login event doesn't guarantee that the session it creates is protected.

How do attackers steal session cookies?

The most common method is through a type of malware called infostealers. These tools are inexpensive and widely available — sold as a subscription service on underground markets - pricing for these subscriptions ranges from tens to hundreds of dollars a month. What makes them particularly effective is that they don't need administrator access to cause damage. They run as the current user and quietly harvest session tokens from the browser's local storage, pulling credentials for every application they can find — email, cloud file storage, corporate SaaS tools, identity security providers — all within minutes.

Those stolen tokens can then be sold on dark web marketplaces. Buyers browse available sessions the way they would browse any online product listing. They import the cookie into their own browser, and they're in. No login event fires. No alert is triggered. No MFA prompt appears because MFA already happened when the original session was created.

Confessions of a Cookie Thief

Session hijacking should be on your radar. It's emerging as one of the most insidious and overlooked threats in modern cybersecurity.

• Why it matters: Stolen tokens allow attackers to bypass MFA and impersonate users without needing a password.
• What you'll learn: How to use device binding and continuous evaluation to neutralize "infostealer" malware.

Watch the webinar: Confessions of a Cookie Thief

Why doesn't MFA prevent this?

MFA does exactly what it is designed to do: it protects the login event. Once login is complete and a session token is issued, MFA has done its job. But the session that was just created can remain active for hours or even days, depending on how the application is configured — and throughout that entire window, the session token is a valid, stealable asset.

Many organizations have never taken a close look at their session lifetime settings. If you dig into your SaaS applications, you will often find session durations configured for 8-hours, 12-hours, or even longer. Each of those is a window where a stolen token can be misused long after the original, MFA-verified login.

What can you do about it?

The good news is that practical, effective defenses exist. The strongest approach combines several layers working together:

Shorter session lifetimes reduce the value of a stolen token. A session that expires after 15 minutes of inactivity is far less useful to an attacker than one that is valid for several days. Pairing short lifetimes with automatic session rotation — where active sessions are quietly reissued new tokens — means stolen tokens go stale quickly.

Continuous context evaluation means your identity platform doesn't just verify who a user is at login — it keeps watching the session. If a session suddenly appears from an unfamiliar country, a new device, or a network that doesn't match any prior behavior, that's a signal to require re-authentication or terminate the session entirely, regardless of how it was originally established. OneLogin's adaptive authentication policies make it straightforward to configure exactly these kinds of rules.

Device binding ties sessions to the device and browser environment where they were created. When an identity provider can recognize the device associated with a session, it can reject attempts to replay that session from a different environment.

Anomaly detection at the session level gives visibility that most organizations don't have today. Most can tell you when a user logged in. Far fewer can tell you whether the same session was simultaneously active from two different locations, or whether a user's activity patterns shifted mid-session dramatically. Those are often the earliest indicators that something is wrong; however, this type of anomaly can also cause a false positive due to the use of VPNs, CDNs, or split-tunneling.

Endpoint security closes off the initial delivery mechanism. Managed devices with up-to-date endpoint security tools, combined with a policy restricting corporate application access to managed devices, make it significantly harder for infostealers to get a foothold in the first place.

Putting it all together

Session hijacking via infostealer malware is a real and growing threat — and it specifically targets the window that opens after a successful, MFA-verified login. The organizations best protected against it have taken some deliberate steps: reviewing their session lifetime settings, implementing step-up authentication for sensitive areas, enabling continuous context evaluation, and putting monitoring in place for unusual session behavior.

About the Author: Alicia Townsend fulfills the role of "Boots on the Ground" Product Manager for OneLogin. Key aspects of this role include developing and driving engineering efforts towards feature enhancements, security improvements and bug fixes as well as managing numerous other OneLogin product related areas: documentation, pricing, customer communications, etc. Alicia started at OneLogin in 2018 as the technical trainer and eventually became the director of all marketing content, documentation and training. Before OneLogin she spent the past 30 years as a technical trainer and consultant.