Stolen Session Cookie Replay: Detecting Token Theft at Login

An infostealer on your customer’s machine does not bother with their password. It exfiltrates the session cookies your app already issued, and those cookies represent a session that has already cleared MFA.

Cookie theft is the quiet workhorse of modern account takeover. There is no failed-login spike, no impossible-travel alert on the auth endpoint, because the attacker never logs in — they resume a session you already trusted. Catching it means asking a question the cookie alone cannot answer: is this the device the session was born on?

Why a valid cookie is not a valid user

Your session token proves that someone, at some point, authenticated successfully. It says nothing about who holds it now. When it is replayed from an attacker’s machine, every server-side check passes: the signature is valid, the expiry is fine, the user record is real.

The one thing that does not travel with a stolen cookie is the device it was issued to. Bind the session to a device identity at login, and replay becomes visible: the token arrives, but the fingerprint underneath it has changed.

Binding sessions to a device identity

The pattern is simple and durable. At the moment you issue a session, record the device that received it. On subsequent requests — especially sensitive ones — re-resolve the device and compare.

Prynt provides a stable visitorId resolved server-side, so you can implement device-bound sessions without trusting anything the client sends:

1. At login, resolve the visitorId and store it alongside the session record.
2. On each sensitive request (payments, settings, exports), resolve the visitorId again.
3. If it does not match the one bound at issue, treat the session as hijacked and force re-authentication.
4. Because the identifier is server-side, an attacker replaying the cookie cannot forge the matching device.

Unlike a cookie, the visitorId survives cookie clearing and private mode — but it does not survive being on a different machine, which is exactly the property you want for replay detection.

Signals that distinguish theft from normal roaming

Legitimate users move between networks and locations constantly. Binding to IP would generate endless false positives. Device binding is tighter, and you can layer supporting signals to be sure:

• Device mismatch between session issue and session use — the primary signal
• A sudden shift into a datacenter or residential-proxy ASN mid-session
• Concurrent use of one session from two devices in different geographies
• Impossible sequence: the same session active in two places faster than travel allows

A returning customer switching from home Wi-Fi to mobile data keeps the same visitorId; only a genuinely different machine trips the check. That is how you catch replay without paging your users every time they change networks.

Responding without nuking every session

Blunt responses — killing every session on any anomaly — train users to ignore your security. Grade the response to the risk:

• On a device mismatch alone, silently step up: require MFA or a passkey re-challenge before the sensitive action completes.
• On mismatch plus a proxy network, revoke the session and notify the enrolled device.
• On concurrent multi-geo use, revoke the newer session and preserve the older, trusted one.

Reason codes make each of these defensible. When your fraud team reviews a blocked session, “session bound to device A, replayed from device B on a datacenter IP” is an explanation, not a hunch.

Make replay worthless

You cannot keep every infostealer off every customer machine, but you can make a stolen cookie useless on any machine but the one it came from. Device-bound sessions turn silent replay into a detectable, blockable event without adding friction for real users.

Prynt is free to start. Try switching devices against a live session in the playground to watch the visitorId change, then bind your sessions to it and close the replay window.