OAuth Token Theft Incident Playbook Template

A stolen OAuth token gives an attacker the access of the user or integration it was issued to, with MFA already satisfied, and it keeps working until someone revokes the right grant at the right provider. This playbook template covers two branches: a user's refresh, access or session tokens stolen through phishing, malware or a device, and an OAuth application's tokens stolen from a third-party integration or granted to a malicious app. It sets out triggers, roles, triage decisions, evidence to preserve and revocation steps for Microsoft Entra ID, Google Workspace and GitHub, drawn from vendor documentation, RFC 7009 and published incidents. It is written for security operations, identity and SaaS platform teams, with decision points for incident managers and executives. Adapt the bracketed text before adoption.

How to use this template

Replace text in square brackets, such as [Organisation], [SIEM] and [Incident Manager], with your own names. "Must" is mandatory; "should" is recommended.
Decision points are marked D1 to D5; record each decision, who made it and when in the incident record.
Platform steps reflect the cited vendor documentation as of October 2026: re-check them yearly, and where this template says "follow the vendor's current documentation", write and test your own runbook step.
For personal access tokens and API keys found in code or logs, use the Leaked Credential Response Playbook; for wider account takeover, use the Identity Incident Response Playbook.

1. Scope and triggers

This playbook applies when [Organisation] suspects that an OAuth access token, refresh token, session token or an OAuth application credential issued for [Organisation] data has been obtained or used by an unauthorised party. Microsoft describes token theft as threat actors compromising and replaying tokens issued to a user even after MFA was satisfied, which is why a password reset alone does not end the incident.

Branch	Typical triggers	Main ATT&CK techniques
A. User token theft	Anomalous token or unfamiliar sign-in properties alert; non-interactive sign-ins from an unexpected location or device; AiTM phishing URL clicked; infostealer detection on a device; new MFA method or inbox rule on the account	T1528 Steal Application Access Token, T1550.001 Application Access Token, T1078.004 Cloud Accounts
B. Integration or app token theft	Vendor or provider advisory about a connected app; risky application alert; consent to an unfamiliar app, especially admin consent; tenant consent settings changed; bulk API queries from an integration's identity	T1528, T1550.001, T1098.003 Additional Cloud Roles, T1114.003 Email Forwarding Rule

Out of scope: lost devices with no evidence of token use ([Device Loss Procedure]).

2. Roles and contacts

Role	Responsibility	Named contact
[Incident Manager]	Owns the incident, decision points D1 to D5 and the timeline	[Name, phone]
[SOC Analyst]	Triage, log queries, scoping and evidence export. In Entra ID this needs sign-in and audit log access with a role such as Security Reader, Security Operator or Security Administrator	[Rota]
[Identity Administrator]	Disables accounts and revokes sessions. Microsoft lists User Administrator for non-admin users and Privileged Authentication Administrator for admin accounts; automation calling revokeSignInSessions needs the User.RevokeSessions.All permission	[Name]
[SaaS Platform Owner]	Revokes app grants and blocks apps in Google Workspace, GitHub, Salesforce and other affected platforms	[One per platform]
[Integration Owner]	Knows what each connected app can reach and which secrets it stores; rotates its credentials	[From the app inventory]
[Vendor Contact]	Security contact at the provider or integration vendor for coordinated revocation and indicators	[Contract or trust page]
[Legal and Privacy]	Notification decisions	[DPO, counsel]
[Executive Sponsor]	Approves business-disrupting containment and external communications	[Name]

On GitHub, only the person who authorised a GitHub App can revoke that authorisation, and organisation owners cannot revoke members' GitHub App authorisations (they can uninstall the app). Revoking an OAuth app's tokens through the API needs the app's own client ID and secret, so it sits with the app owner or vendor.

3. Detection and triage

Open the incident in [Ticketing system] with its branch (A, B or both).
Identify the token holder: user, service principal, OAuth client ID, integration and the platforms it can reach.
Review sign-ins and audit events: in Entra ID, check interactive and non-interactive sign-ins for unexpected locations or devices, audit logs for new devices, MFA methods and credential changes, and the "Consent to application" activity, noting admin consent and consent for all principals. Microsoft notes audit entries can take from 30 minutes to 24 hours to appear, and anomalous token alerts may not show in SigninLogs.
Check connected platforms: Google Workspace "Accessed apps" under Manage App Access (details usually appear 24 to 48 hours after authorisation), GitHub organisation audit log and authorised OAuth apps, and Salesforce Event Monitoring for connected app authentication and query activity.
Size what the token could reach as well as what it did reach, including secrets stored in the data it could read. In the Salesloft Drift campaign, Google Threat Intelligence Group reported that the actor searched exported Salesforce data for AWS keys, passwords and Snowflake tokens.
Set severity: [Critical] for admin or tenant-wide grants, or tokens reaching customer data; [High] for a single user with sensitive data access; [Medium] otherwise.

D1: breach or not? Microsoft's rule is the right one: if the user activity can be confirmed as valid, there is no breach; if it cannot, assume a breach and proceed to containment.

Evidence to preserve

Exported sign-in logs (interactive and non-interactive), audit logs and consent records for the affected identities, from [earliest suspected date] to now, copied to [Evidence store] with hashes.
App details: client ID, publisher, consented scopes, consent type and who consented.
Token and session identifiers, IP addresses, user agents and device IDs seen in suspicious activity.
Provider API and query logs (Salesforce Event Monitoring, GitHub audit log, Google token and admin audit events).
Mailbox rules, forwarding settings, MFA methods and devices before removal: screenshot or export them, then remove.
Vendor advisories and correspondence, with times received.

Run exports in parallel with containment; revocation does not delete logs.

4. Containment

D2: business impact. Before disabling a service account, integration or executive account, the [Incident Manager] confirms with the [Integration Owner] what will break. Microsoft advises weighing the business effect of disabling accounts first, then putting containment before information gathering.

Platform	Containment step	Caveat
Entra ID user (cloud-only)	Disable the user (`Update-MgUser -AccountEnabled:$false`), run `Revoke-MgUserSignInSession`, disable registered devices; mark the user compromised in ID Protection	Revocation invalidates refresh tokens and browser session cookies after a delay of a few minutes. Access tokens last 1 hour by default unless the resource supports continuous access evaluation, which acts on revocation with latency of up to 15 minutes. Sessions issued by applications themselves are not revoked by Entra ID
Entra ID user (hybrid)	Disable in AD and reset the AD password twice, then revoke as above	The double reset mitigates pass-the-hash. Guest users are not covered: their sessions belong to their home tenant
Entra ID malicious or compromised app	Disable the application so it cannot obtain new tokens and no one can sign in to it or consent to it	Deleting it alone lets it return if another user consents. To remove existing consent grants, follow Microsoft's current documentation
Google Workspace	Set the app to Blocked in Security > Access and data control > API controls > Manage App Access; delete a user's tokens for the app with the Directory API `tokens.delete` (`DELETE https://admin.googleapis.com/admin/directory/v1/users/{userKey}/tokens/{clientId}`)	Access control changes can take up to 24 hours
GitHub	Organisation owners deny or remove the OAuth app under OAuth app access restrictions; users review Settings > Applications; the app owner revokes grants with `DELETE /applications/{client_id}/grant`, which deletes all the app's tokens for that user	Webhooks of a removed app are disabled, not deleted
Salesforce and other SaaS	Revoke the connected app's tokens and block the app: follow the vendor's current documentation	Confirm through the platform's logs that the tokens no longer work
Any RFC 7009 authorisation server	POST the token to the revocation endpoint with `token_type_hint` `refresh_token`; Google's endpoint is `https://oauth2.googleapis.com/revoke`	A 200 response is also returned for already-invalid tokens, and support for access-token revocation is only a SHOULD, so a 200 does not prove the access token is dead

Coordinate with the vendor in branch B: in the Salesloft Drift case, Salesloft and Salesforce revoked all active Drift access and refresh tokens on 20 August 2025. See the Salesloft Drift breach.
Iterate: repeat triage for each newly found account, app or device.

D3: containment confirmed? Confirm from provider logs, not revocation responses, when the token's activity stopped.

5. Eradication

Remove persistence: attacker-added MFA methods, devices, inbox and forwarding rules, app registrations, credentials added to service principals, roles and OAuth consents. Roll back changes made by compromised privileged accounts.
Rotate reachable secrets: search data the token could read for credentials. Google Threat Intelligence Group's Drift guidance is to revoke and rotate all discovered keys, credentials and tokens. In the GitHub OAuth token breach, GitHub reported that the attacker downloaded private repositories and reached an AWS key for npm. Run rotation through the Leaked Credential Response Playbook.
Rotate the integration's own credentials: client secrets, certificates and any API keys the integration held for [Organisation].
Treat every token stored in the affected platform as exposed: GTIG advised treating all authentication tokens stored in or connected to Drift as potentially compromised.
Clean the endpoint in branch A if infostealer malware or a compromised device was the source, before the user signs in again.

6. Recovery

D4: re-enable criteria. The [Incident Manager] re-enables accounts and integrations only when persistence is removed, the user's MFA methods and devices are verified, and the integration's credentials are rotated.

Users and apps re-authorise after refresh-token invalidation; confirm the new grants carry only the scopes needed.
Restore integrations with reduced scope: GTIG's Salesforce advice includes avoiding the full scope for connected apps, adding IP restrictions and Login IP Ranges, shortening session timeouts and granting API access through permission sets.
Where supported, enable Entra ID Token Protection, which binds sign-in session tokens to the device (available for native apps accessing Exchange Online, SharePoint Online and Teams on supported platforms; browser support is in preview).
Move high-value APIs to sender-constrained tokens (DPoP or mTLS), as RFC 9700 recommends, and ensure public-client refresh tokens are sender-constrained or rotated.

7. Communication and notification

Internal: [Incident Manager] updates [Executive Sponsor] at [interval]; affected users are told to expect re-authentication.
Providers and vendors: notify the platform and the integration vendor through [Vendor Contact], share indicators and request their log evidence. NIST IR 8587 (September 2026) places revocation as a shared duty between cloud providers and their customers and expects providers to notify the consuming agency promptly of suspected incidents.
Customers and partners: tier notices by impact. GitHub notified victims whose repository contents were downloaded on 18 April 2022 and those whose repository details were listed on 22 April, after disclosing to Heroku and Travis CI on 13 to 14 April.
Re-scope and re-notify: plan for scope to grow. GTIG extended the Drift advisory on 28 August 2025 to Drift Email, which had reached a very small number of Google Workspace accounts.
Regulators: D5: [Legal and Privacy] decides whether personal data was affected and which duties apply. Use the Data Breach Notification Checklist; record when D1 was made and by whom.

8. Post-incident review

Hold the review within [10] working days. Answer:

Why could the token be used from another device or location, and is device binding or sender-constraint now in place?
Were access and refresh token lifetimes appropriate? NIST IR 8587 recommends access and identity tokens be valid for no more than one hour; CISA notes short lifetimes only slow an attacker.
Was the app over-scoped, unused or unknown to the inventory? See the SaaS and OAuth App Governance Guide.
Did logs cover the full window, and how long did audit lag delay detection?
Which revocation step was slowest or unclear, and is it now scripted and tested?

Record these metrics per incident: time from first alert to D1; time from D1 to last successful use of the stolen token; number of grants and tokens revoked; number of secrets rotated; days the token was usable before detection.

Implementation guidance

Inventory first: list every OAuth app with tenant-wide or admin consent, its owner, scopes and the secrets it stores. The Gainsight Salesforce breach (long-lived OAuth tokens) and the Microsoft Midnight Blizzard breach (an OAuth app in a forgotten test tenant) show why.
Script revocation: keep tested runbook commands for each identity provider and SaaS platform, run under least-privilege roles, with output saved to the incident record.
Prove revocation end to end: in a test tenant, revoke a token and time how long the access token keeps working at each resource, including continuous access evaluation behaviour.
Retain logs: forward sign-in, audit, consent and SaaS API logs to [SIEM] with retention of at least [12] months.
Exercise: run a tabletop for each branch yearly, including a vendor-led revocation where you control nothing but your own grants.

Small organisations can run this playbook with an identity administrator, one SaaS owner and an incident response retainer. Larger organisations should automate D1 evidence collection and first-stage revocation from [SOAR], and pre-agree vendor contacts in contracts. Detection engineering for token misuse is covered in the ITDR Guide.

Playbook stage	NIST CSF 2.0	NIST SP 800-53 Rev. 5	OWASP ASVS 5.0 (preventive)
Plan and prepare	RS.MA-01	IR-8	V10.4.9 revocable refresh tokens
Detect and triage	DE.AE-02, RS.AN-03, RS.AN-06	SI-4, AU-6, IR-5	V10.7.3 users can review and revoke consents
Contain and eradicate	RS.MI-01, RS.MI-02	IR-4, AC-12	V10.4.5, V10.3.5 sender-constrained tokens
Notify	RS.CO-02	IR-6	n/a
Recover and improve	RC.RP-01, ID.IM-03	IR-4	V10.4.8 absolute refresh token expiry

Source references

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Identity Incident Response Playbook · Leaked Credential Response Playbook · ITDR Guide

OAuth Token Theft Incident Playbook: Contain, Revoke and Recover