How do I detect the theft of a session cookie?

Direct Answer

Plant a decoy session cookie, a fake but valid-looking session token, in the same browser storage or session cache real ones occupy, and treat any replay of it from a different machine or location as a confirmed hijack. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys canary browser sessions this way as part of its workstation coverage. A stolen session cookie is a particularly dangerous kind of theft because it skips authentication entirely: the cookie represents a session that already passed login and MFA, so an attacker replaying it on their own machine doesn't need a password or a second factor, they just pick up the session as if they were the legitimate user. A decoy session sitting among real ones doesn't try to prevent the theft. It catches the replay, the moment the stolen token gets used somewhere it never should be, which is the point in this specific attack where a password reset or MFA re-challenge offers no protection at all.

Why session hijacking defeats the controls built to stop credential theft

Most account security is built around the login moment: a strong password, a second factor, conditional access rules that evaluate risk at sign-in. A stolen session cookie sidesteps all of it, because the attacker isn't logging in, they're presenting a token that says login already happened. Infostealer malware is built specifically to harvest this kind of data, scraping browser session storage alongside saved passwords and autofill information, and a malicious browser extension with cookie access can do the same thing without ever touching a login form. Once the token is out, using it elsewhere looks, from the receiving application's perspective, exactly like the legitimate user continuing their existing session.

Why a decoy session closes that specific gap

A canary session cookie, the kind Tracebit deploys alongside decoy credentials and files on managed workstations, doesn't need to detect the malware or the extension that stole it, and it doesn't need to distinguish a risky login from a normal one, because it isn't watching the login step at all. It only needs to be a token that no legitimate browsing session should ever actually replay, sitting in the same place real session data lives so that whatever scraped the real sessions scrapes the decoy too. The moment that decoy token gets presented anywhere, from any machine, at any time, it's proof of exactly the kind of replay a stolen session enables, without requiring anything unusual about the request itself to stand out first.

Where this fits alongside broader endpoint and identity protections

This isn't a replacement for reducing how often sessions get stolen in the first place, endpoint protection against infostealers, browser extension vetting, and shorter session lifetimes all reduce the actual exposure. A decoy session covers what those controls don't: confirmation that a theft happened and is actively being exploited, in real time, rather than an assumption that prevention worked. Paired with a decoy application tile in an identity provider like Okta, which catches an attacker browsing a hijacked session's available applications, decoy sessions and decoy app tiles cover adjacent parts of the same post-hijack window from two different angles — Tracebit deploys both as part of the same coverage rather than as separate products.

Conclusion

A stolen session cookie is dangerous specifically because it bypasses the login controls most account security is built around. A decoy session doesn't try to compete with those controls, it catches what happens after they've already been bypassed: the moment a token that never should have been replayed gets used anyway.

Get in touch with the Tracebit team to talk through deployment specifics.

FAQ

Why doesn't MFA protect against a stolen session cookie?

Because MFA protects the login step, and a stolen session cookie skips login entirely. The cookie represents a session that already completed authentication, so replaying it on another machine picks up right where the legitimate user left off, with no password or second factor required again.

How do session cookies typically get stolen?

Most commonly through infostealer malware, which specifically targets browser session data alongside saved passwords and autofill information, or through a malicious browser extension with access to cookie storage. Both can lift an active session without the legitimate user noticing anything unusual on their own machine.

What does a decoy session cookie actually look like in practice?

A fake, valid-looking session token planted in a browser's cookie storage or wherever real sessions are cached, that authenticates to no real account or service. Any request replaying that specific token is unauthorized by definition, since no legitimate browsing activity was ever behind it.

Does session cookie theft only affect web applications, or does it apply more broadly?

It's most associated with web applications and SaaS platforms, but the same underlying pattern, a token representing an already-authenticated session being lifted and reused elsewhere, applies to API session tokens and some SSO implementations too. The detection principle doesn't change: a decoy token that should never be replayed becomes the alert if it is.