What is session-token theft?¶
Session-token theft is the unauthorised acquisition and reuse of a credential that represents an already authenticated session. The service may accept the reused token without asking for the password or repeating the original MFA challenge.
One authentication can lead to activity from another client¶
Dave signs in to Google Workspace in Chrome on his Northstar laptop at 08:52. The service creates a browser session. At 10:17, a request using that session authority appears from a client Dave does not recognise and accesses Drive object OBJ-7721.
The absence of a second password event is part of the mechanism. The later client is presenting continuing authority created by the earlier authentication.
Join creation, use and termination¶
Preserve the original authentication, session or token identifiers, account, application, device/browser, network, issue and expiry times, later resource requests, security alerts, refresh events and the response that ended or rejected access. Cloud sessions explains the continuing exchange; refresh tokens explains how some authority can obtain replacement tokens.
A sudden client or network change, overlapping activity or an anomalous-token alert can support a replay hypothesis. None is conclusive alone: mobile routing, corporate gateways, synchronisation and incomplete logging can also change the visible context. The next useful comparison is the known device state, browser artefacts, relevant messages or malware findings and the exact actions performed by each client.
Current provider examples - checked 2 September 2026
Google Workspace currently documents the login-audit event user_signed_out_due_to_suspicious_session_cookie, whose console message identifies a suspicious session cookie for the affected user. Microsoft Entra describes its anomalous token risk as abnormal session- or refresh-token characteristics that may indicate replay, while warning that low and medium risk detections can produce false positives.
Detection coverage, token binding, event names and revocation behaviour vary by service and configuration. A provider alert should be preserved as an assessment alongside the underlying session and resource records.
The durable principle¶
The session identifies accepted technical authority, not the later operator. Evidence of the original client, the unauthorised acquisition route and the replaying client is what advances personal attribution.
The point to remember
A reused session can produce authenticated cloud activity without a new login. Follow one session from creation through each client context, resource event and termination.
