Session Token Theft Response Playbook

A stolen session cookie or refresh token is a login that has already passed MFA, so a password reset on its own does not end the attacker's access. This playbook is the response procedure for one specific trigger: evidence that a user's live session material (browser cookies, refresh tokens, cloud role sessions) has been taken, usually from an infostealer log, and may be replayed. Its core is a revocation matrix that sets out, platform by platform, which action ends which token and how long already-issued tokens stay usable afterwards. It is written for SOC analysts, identity administrators and incident managers, and it is designed to be copied and adapted with your own platforms, owners and timings. For how the attack works and how to prevent it, see the Session Hijacking and Cookie Theft Guide and the Infostealer Logs and Session Token Abuse Guide; for stolen OAuth grants held by applications, use the OAuth Token Theft Incident Playbook.

How to use this template

Replace the placeholders: [Organisation], [IdP], [SOC lead] and the platform rows in section 5 should reflect the systems you actually run. Delete rows you do not use and add your own critical SaaS applications.
Confirm the timings: the revocation behaviour in section 5 comes from each vendor's public documentation as checked in November 2026. Product behaviour changes, so confirm the current values in each vendor's docs before you rely on them, and record the date you checked.
Pre-stage the tooling: the playbook assumes responders already hold the roles and API scopes listed in section 2. Granting them during an incident costs the minutes that matter.
Keep it narrow: if the investigation shows the attacker also changed MFA methods, created mail rules or registered applications, move to the Account Takeover Response Playbook or the Identity Incident Response Playbook and keep this one for the token work.

1. Purpose and triggers

1.1 This playbook defines how [Organisation] responds when session tokens belonging to a workforce user, administrator or service operator are suspected or confirmed stolen. Its aim is to end every live session the attacker may hold, across the identity provider and downstream applications, within [target: 60 minutes] of activation, and to establish what the sessions were used for.

1.2 Activate this playbook on any of the following:

Infostealer log hit: a threat intelligence feed, dark web monitoring service or law enforcement notice lists cookies or tokens for an [Organisation] domain or user.
Token replay alert: the IdP flags an anomalous token or session (for example, a session used from a new ASN or country minutes after a normal sign-in, without a fresh MFA event).
Endpoint detection: EDR reports a stealer family, browser credential store access (MITRE ATT&CK T1555.003) or cookie database access (T1539) on a device where the user is signed in.
Edge appliance memory leak: a vendor advisory states that session tokens could be read from an appliance the organisation runs, in which case every session that passed through it is in scope.

2. Roles and access

Role	Responsibility	Access needed before an incident
[Incident manager]	Declares the incident, owns the timeline, decides on notification	Ticketing, contact list
[SOC lead]	Triage, log queries, scoping of token use	Read access to IdP sign-in logs and SaaS audit logs
[Identity administrator]	Runs the revocation steps in section 5	Entra User Administrator (or Privileged Authentication Administrator for admin accounts), Okta `okta.users.manage` scope, Google Workspace user management privilege, IAM Identity Center administrator, Slack Enterprise admin token with `admin.users:write`
[Endpoint lead]	Isolates and images the affected device, removes the stealer	EDR isolation, MDM wipe rights
[Privacy or legal lead]	Assesses notification duties under section 8	Data inventory for affected systems

3. Triage: first 15 minutes

Identify the user and device. Record the account, the device name, and the source of the report. For a stealer log, record the log date: cookies harvested weeks ago may already have expired, but refresh tokens and "remember me" sessions often have not.
List the platforms in the log. Stealer logs usually contain cookies for many domains. Mark every [Organisation] IdP, SaaS and cloud console domain present. Each one is a row in section 5.
Check for live use. Query the IdP for sign-ins and token refreshes for the user in the last [7] days from IP addresses, ASNs or device IDs that do not match the user's managed device. A session used without a matching interactive MFA event is the strongest signal of replay.
Classify the account. Privileged, developer with cloud console or CI access, or standard user. Privileged and developer accounts go to priority 1 because their sessions can mint further credentials, as the CircleCI breach showed when malware on an engineer's laptop stole a session that had already passed two-factor authentication and the attacker used the engineer's role to generate production access tokens.
Decide containment order. Device first if the stealer may still be running (otherwise it will harvest the new sessions you are about to create), then the IdP, then downstream platforms.

4. Containment: device and identity provider

4.1 Isolate the device through EDR before revoking anything. If the user signs in again on an infected device, the new cookies are stolen too. Preserve a memory image if your forensic process requires it (section 7).

4.2 Disable or block the account for priority 1 accounts while revocation runs. For standard users, revocation plus a credential reset is usually enough.

4.3 Revoke IdP sessions and refresh tokens using the platform row in section 5, then reset the password from a clean device. Do not reset the password first: on several platforms a reset does not by itself end sessions that already exist.

4.4 Review persistence: new MFA methods, new devices registered to the user, OAuth consents granted during the exposure window and mailbox forwarding rules. Remove anything the user cannot account for.

5. Revocation matrix by platform

Platforms are listed alphabetically. Each row states what the documented action ends and what continues until expiry, so responders know what still needs doing. These are customer-side actions under the shared responsibility model; confirm current behaviour in each vendor's documentation.

Platform	Action	What it ends	What runs to expiry, and the follow-up
AWS IAM Identity Center	End the user's active sessions in the IAM Identity Center console; disable the user for priority 1	The AWS access portal sign-in session; new sessions need a fresh sign-in immediately; application sessions within 30 minutes	IAM role sessions already issued to the console or CLI continue until they expire, up to the permission set's session duration (maximum 12 hours). Shorten that duration for sensitive permission sets ahead of time
AWS IAM roles (assumed directly)	On the role, choose Revoke sessions, then Revoke active sessions	All temporary credentials the role issued before the revocation time: IAM attaches the inline policy `AWSRevokeOlderSessions`, a deny on `aws:TokenIssueTime`	Affects every user of the role, so expect legitimate users to re-authenticate. Roles created from Identity Center permission sets and service-linked roles are handled in Identity Center instead
Google Workspace	Admin console: Directory > Users > user > Security > Sign-in cookies > Reset. Suspending the user also resets cookies	Web and mobile browser sessions	Desktop apps such as Google Drive for desktop need a separate sign-out, and third-party app access is revoked separately under the user's security settings. Managed computers can be signed out from Devices > Endpoints > Sign Out User
Microsoft Entra ID	User Overview > Revoke sessions, or `Revoke-MgUserSignInSession`, or Graph `POST /users/{id}/revokeSignInSessions` (permission `User.RevokeSessions.All`)	Refresh tokens and browser session cookies issued by Entra ID; Microsoft notes a delay of a few minutes	Access tokens stay valid until expiry (one hour by default) except in apps that support Continuous Access Evaluation. Application session cookies are ended by the application itself. External users are revoked in their home tenant. Disable registered devices with `Update-MgDevice` where the device is suspect
Okta	Clear user sessions in the Admin Console, or `DELETE /api/v1/users/{userId}/sessions?oauthTokens=true`	All Okta IdP sessions; with `oauthTokens=true`, OIDC and OAuth refresh and access tokens; `forgetDevices` clears remembered factors (check its default for your engine)	Sessions that downstream web and native apps created themselves are ended in those apps
Slack (Enterprise)	API method `admin.users.session.reset` with an admin user token holding `admin.users:write`	All valid sessions on all devices for the user; `mobile_only` or `web_only` narrow the reset	Review bot and user tokens the account created during the exposure window. See the Slack Tokens Security Guide
[Critical SaaS application]	[Admin action or API call]	[Session types ended]	[What runs to expiry; owner]

5.1 Federated applications: SAML and OIDC applications keep their own session after the IdP session ends. For each application in the stealer log, end the application session or deprovision the user. Microsoft documents app provisioning cycles of roughly 20 to 40 minutes, so for priority 1 accounts trigger the application step manually rather than waiting.

5.2 Our recommendation: record, for every critical application, the admin action that ends a user's sessions and the maximum lifetime of anything it does not end. That residual lifetime is your real exposure window; if it is longer than [4 hours] for an administrative application, shorten the application's session or token lifetime in advance.

Platform hardening references: AWS IAM Identity Center Guide, Google Workspace Security Guide, Entra ID Security Guide, Okta Security Hardening Guide and Slack Enterprise Security Guide.

6. Scoping what the sessions were used for

Question	Where to look	Evidence of misuse
Was the token replayed?	IdP sign-in and token refresh logs, non-interactive sign-ins	Same session or device ID from an unfamiliar IP or ASN; refreshes with no interactive MFA
What data was touched?	SaaS audit logs (file downloads, mailbox access, exports)	Bulk downloads, search queries for credentials or finance terms
Did the attacker create persistence?	Directory audit log, OAuth consent log, mailbox rules	New MFA method, new app consent, forwarding rule, new API token (T1098.001 for cloud credentials)
Did they reach cloud consoles?	AWS CloudTrail, Azure Activity Log, Google Cloud audit logs	Role sessions from unfamiliar sources, new access keys, policy changes
Did they mint other tokens?	Developer platforms, CI systems, secrets managers	New personal access tokens or deploy keys; treat these as separate credentials to revoke

The Bybit hack is the reference case for the last two rows: attackers reused a developer's active AWS session tokens rather than defeating MFA, and used that access to alter web application code in an S3 bucket. Scoping must therefore follow the session into every system the user could change, not only the data they could read.

7. Evidence to preserve

Stealer log extract: the entries for [Organisation] domains, with the source, retrieval date and hash. Store it as sensitive evidence: it contains live secrets.
IdP logs: export sign-in, token and audit logs for the exposure window before retention expires. Default retention on some tiers is short.
Device image or EDR triage package: including browser profile paths, so the stealer family and harvest time can be confirmed.
Revocation record: the time each action in section 5 ran, by whom, and the response returned. This proves containment to auditors and regulators.

8. Notification and closure

8.1 The privacy lead assesses whether personal data was accessed. Under UK GDPR and EU GDPR Article 33, a personal data breach likely to result in a risk to individuals is notified to the supervisory authority within 72 hours of the organisation becoming aware of it. Entities in scope of NIS2 follow their national transposition, which includes an early warning within 24 hours of becoming aware of a significant incident. See the Breach Notification Laws by Country Guide for other regimes.

8.2 Close the incident only when: the device is clean or reimaged; every row in section 5 that applies has been actioned and verified with a failed replay test or log evidence; residual role sessions have passed their maximum lifetime; and persistence found in section 6 is removed.

8.3 In the review, record the time from detection to complete revocation per platform, and which platforms forced the team to wait for token expiry.

Implementation guidance

Rollout

Build the matrix: complete section 5 for your IdP and your ten most critical applications, testing each action against a test account and timing how long a replayed cookie keeps working.
Script the IdP step: wrap the IdP revocation, device disable and password reset into one runbook action in your SOAR or automation platform, with a dry-run mode that only lists what it would do.
Exercise: run a tabletop using a mock stealer log, then a live test against a test user. Roll back by re-enabling the test account and devices.
Shorten residual windows: use the exercise results to cut session and role durations, and to enable binding controls such as Conditional Access token protection (generally available for native apps on Windows, iOS and iPadOS, and macOS; browser support is in preview as of November 2026) and Device-Bound Session Credentials. Our recommendation: pilot in report-only mode first.

Metrics

Metric	Target (ours)
Time from stealer log alert to IdP revocation	Under 30 minutes for priority 1
Time to revoke across all platforms in the log	Under 4 hours
Critical applications with a documented, tested revocation action	100%
Maximum residual token lifetime for admin applications	4 hours or less
Re-infection rate (same user in a new stealer log within 90 days)	Zero

Framework mapping

Framework	Reference	Where it applies
MITRE ATT&CK	T1539 Steal Web Session Cookie; T1550.004 Web Session Cookie; T1528 Steal Application Access Token; T1555.003 Credentials from Web Browsers	Triggers and scoping (sections 1, 3, 6)
NIST SP 800-53 Rev 5	IR-4 Incident Handling; AC-12 Session Termination; SC-23 Session Authenticity; IA-11 Re-authentication	Sections 4, 5 and the rollout
NIST CSF 2.0	DE.CM-03; RS.AN-03; RS.MI-01	Detection, scoping, containment

Session Token Theft Response Playbook: Infostealer Cookies, Token Replay and Revocation