Responding to a Gmail BitM compromise — the OAuth-revoke step every other playbook skips

When to use this runbook

You suspect a Gmail or Workspace account was compromised via BitM. Triggers that should land you here:

User reports clicking a Google-themed link (Drive share, Docs invitation, Calendar invite) that opened what looked like a Google sign-in page on a non-Google domain
BitM Shield extension fired DANGER on a page the user visited
Workspace audit log shows a new OAuth grant for mail.google.com from a non-allowlisted Desktop-app client
Gmail batch-API access from a python-requests-style user-agent for a user who does not use any custom Gmail integration
User reports unfamiliar messages in their Sent folder
User reports new email-forwarding or filter rules they did not create
A connected service (CRM, helpdesk) reports receiving auto-responses from the user that the user did not write

The crucial point — read this before anything else

Password rotation does not revoke the OAuth refresh token. Signing out all sessions does not revoke the OAuth refresh token. The Google "secure your account" flow does not revoke the OAuth refresh token.

The refresh token survives every standard credential-remediation step. It is independent of the user's password, independent of the user's session state, independent of the user's IP, and independent of the user's device. It silently re-issues access tokens for as long as it lives. From the user's perspective, there is no sign-in event after the initial capture — no notification, no security alert, no log entry visible from the user-facing security dashboard.

The only thing that revokes a refresh token is an explicit visit to myaccount.google.com/permissions (consumer Gmail) or admin.google.com/ac/owl/list (Workspace admin) and a manual click on Remove Access for the offending grant.

We tested this on our own account. We rotated the password. We signed out all sessions. We watched the attacker's container in our lab keep reading mail using the refresh token until we manually visited the permissions page and revoked it. Most IR runbooks for phishing do not include this step. That is the gap this runbook closes.

The four containment moves, in order

Run these from a different device than the suspect one. The suspect device may have malware or browser extensions installed by the attacker that would compromise the remediation.

Move 1 — Change the password

Even though the password alone is no longer the attacker's primary access, change it. The attacker has it, they will use it elsewhere if you do not, and credential-stuffing reuse is the most common downstream attack after a phishing compromise.

Consumer Gmail: myaccount.google.com/security → Password
Workspace admin: have the user change their password via the Workspace login page, or force a password change from the admin console

Use a password that is not used anywhere else. The old password is now in the attacker's hands and is being run against every other service the user might have.

Move 2 — Sign out all sessions

Invalidates the session cookie jar the attacker captured.

Consumer Gmail: myaccount.google.com/security → Your devices → Sign out of unfamiliar devices, or use the "Sign out all" option
Workspace admin: revoke the user's sessions from the admin console (admin.google.com → Users → [user] → Security → Sign out from all sessions)

This kills the cookie-replay path. Combined with Move 1, it makes the attacker's session-cookie capture worthless. It does not touch the OAuth refresh token.

Move 3 — Revoke OAuth grants (the move that matters)

This is the step most playbooks skip. Without it, the attacker keeps reading mail.

Consumer Gmail:

Open myaccount.google.com/permissions
Review every third-party app listed
For each app the user does not recognize, click on it and click Remove Access
Pay particular attention to apps with broad scopes — anything with Read, compose, send, and permanently delete all your email from Gmail is the canonical attacker grant
Check apps authorized within the compromise window (use the audit-log timestamps from Move 5 if you have them)

Workspace admin:

Open admin.google.com/ac/owl/list
Filter for the affected user
Review every authorized app
Block any app that does not have a known legitimate purpose
For tenant-wide blocking, use the Workspace API access dashboard to deny the offending app's client_id for all users — prevents recurrence if the attacker tries to re-grant after Move 1 and 2

After Move 3 completes, the attacker's persistent access is terminated. Subsequent token-refresh attempts from the attacker's container will fail with invalid_grant.

Move 4 — Audit and remove forwarding rules / filters

The attacker often sets up an inbox rule that auto-forwards mail matching specific keywords (financial, contract, customer name, security alert) to an external mailbox, then auto-deletes the original so the user never sees the forwarded message. This survives all three previous moves because it is a mailbox-level configuration, not an OAuth grant.

Consumer Gmail: Settings → See all settings → Forwarding and POP/IMAP, then Settings → Filters and Blocked Addresses
Workspace: same UI as consumer Gmail, plus the admin can audit forwarding via the admin console

Remove any rule or forwarding configuration the user does not recognize. Particular attention to:

Rules that auto-forward to an external address
Rules that auto-delete or auto-archive incoming mail
Rules that auto-mark as read
Filters that look for specific keywords (often financial, security, password reset terms)

Move 5 — Scoping (next 1–2 hours)

Now figure out what the attacker did during their access window.

Pull the access window from audit logs

For consumer Gmail: visit myaccount.google.com/notifications and myaccount.google.com/security → Recent security events. Note any unfamiliar sign-in event with timestamp, IP, and device.

For Workspace: pull the relevant audit logs from the admin console:

Source: Workspace Admin Reports APIchr(10)Event types:chr(10)- login (filter on the affected user)chr(10)- token (filter on authorize, revoke, request)chr(10)- access_transparency (if you have BeyondCorp / VPC-SC)chr(10)- drive (if Drive scopes were granted)chr(10)- gmail (mailbox audit if available — Workspace Enterprise+)

Note the timestamps of:

The phishing click (from email logs or user recall)
The first attacker sign-in
The OAuth grant issuance
The first batch-API access (the attacker's first mailbox sweep)
The last attacker activity before containment

This timeline is the spine of the post-mortem and the basis for any external notification decision.

What the attacker likely did during access

From our lab observations of BitM attacker capabilities, the attacker most likely:

Pulled mailbox metadata via the Gmail batch endpoint — typically a sweep of Inbox, Sent, Drafts, Starred, and any folder labeled with high-value keywords
Read the full MIME body of any message they considered interesting (financial, contractual, customer-related, security-related)
Sent mail as the user to collect responses or to phish further targets
Modified profile settings to redirect future security alerts (e.g., changing the recovery email)
Set up forwarding rules or filters for ongoing exfiltration
Authorized additional OAuth applications for redundant persistence

Audit each of these. The data download from takeout.google.com is the most complete record — request it as part of the IR; it arrives within 24 hours.

Move 6 — External notification (next 2–4 hours)

If the attacker sent messages from the user's account, those recipients now think they got a message from the user. They are at elevated phishing risk for the next several days.

Identify recipients

From the audit logs in Move 5 (or from the takeout archive), pull the list of recipients of messages sent during the compromise window.

Out-of-band notification

Notify each affected recipient through a channel other than email (phone, Slack, Teams, in-person). Suggested message:

t; "My email account was compromised between [start time] and [end time]. Any messages from me during that window should be treated as suspicious. Do not click any links in those messages or act on any requests they contain. If you already did, let me know so I can advise."

For high-value recipients (executives, finance contacts, customers), call rather than message. The personal touch matters and the urgency is real.

Internal notification (organizations)

Notify the security team if not already involved
Notify the user's manager so they understand the operational impact
If the user had access to sensitive data (HR, legal, financial), notify the relevant business owners
If regulated data (PII, PHI, financial) was potentially in scope, notify privacy/legal — they decide on regulator notification

Report the lure

Submit the lure URL to:

Google Safe Browsing: safebrowsing.google.com/safebrowsing/report_phish/
Your email gateway provider (helps protect other organizations on the same provider)
Internal blocklist for your organization's email gateway

Move 7 — Forensic preservation (next 4 hours)

Collect evidence before audit logs roll over and before the user accidentally overwrites screenshots.

Required collection:chr(10)1. Screenshot of the Recent security events page BEFORE any remediationchr(10)2. Screenshot of the OAuth permissions page BEFORE Move 3 — proves which apps were authorizedchr(10)3. Screenshot of forwarding/filter settings BEFORE Move 4chr(10)4. Request a full Google Takeout archive — most complete record of activitychr(10)5. Note exact timestamps:chr(10)- Phishing clickchr(10)- First attacker sign-inchr(10)- OAuth grant issuancechr(10)- Containment Move 1 through 4 completionchr(10)6. Save the phishing URL itself (do not click again — record from the original email)chr(10)7. If you have CASB / proxy / EDR logs, export the full Google traffic historychr(10)for the user from 30 minutes before the click to 4 hours after

Key data points for the post-mortem:

IP addresses of attacker activity → ASN lookup to confirm hosting provider
User-agent strings → most BitM containers ship with a stable Chrome version, useful for clustering against other compromises
Timestamps → correlate with the phishing click to confirm causation
The OAuth client_id of the attacker's grant → useful for hunting other users in your tenant who may have authorized the same client

Move 8 — Recovery and prevention (next week)

The incident is contained. Now prevent recurrence.

For the individual user

Install BitM Shield in their primary browser (covered in the mitigations post)
Bookmark accounts.google.com directly — never click Google links from email or chat
Enable a passkey for Google (does not stop BitM but stops the much-more-common AiTM attacks)
Brief them on the BitM pattern so they recognize it next time

For the organization

Deploy BitM Shield as a managed Chrome extension across the fleet
Add the attacker's lure domain and OAuth client_id to your blocklists
Brief the broader team on the BitM pattern with anonymized details from this incident
Review whether other users in the same role or business unit clicked the same link — campaigns are often multi-victim
Update the IR runbook with any new IOCs from the incident

Update detections

Whatever the attacker did during this incident — specific ASN, specific OAuth client_id, specific batch-API access pattern — update your detections to catch the same pattern faster next time. The TTPs are now known to you. Do not waste them.

What end users should look for in real time

This is the user-awareness section. Print as a one-pager and circulate to the team.

Five signs you might be looking at a BitM page:

The browser feels off. Cursor lags. Keystrokes appear with a delay. The page resizes oddly when you maximize the window. Real Google does not have these symptoms.
The address bar is wrong. Look at the actual host. A real Google login is at accounts.google.com. BitM pages live on a different domain even though the content looks identical to Google.
Right-click View Page Source looks empty or weird. A real Google page has thousands of lines of HTML. A BitM stream page has a few dozen lines of <canvas> and JavaScript wrapper.
Bookmarks do not work. If the page asks you to "click this email link to sign in" instead of letting you go directly via your bookmark — stop.
Password manager refuses to autofill. Your password manager checks the actual domain. If it will not fill, trust your password manager over the page.

If any of these happen, stop. Close the tab. Go to your bookmarks. Sign in via the bookmark. If you already typed the password, run the four containment moves above immediately.

Quick reference card

SIGN-IN HISTORY:    myaccount.google.com/security → Recent security eventschr(10)SIGN OUT ALL:       myaccount.google.com/security → Your deviceschr(10)PASSWORD CHANGE:    myaccount.google.com/security → Passwordchr(10)OAUTH PERMISSIONS:  myaccount.google.com/permissions  ← THE STEP MOST PLAYBOOKS SKIPchr(10)FORWARDING/FILTERS: mail.google.com → Settings → See all settings → Forwarding/Filterschr(10)TAKEOUT (DOWNLOAD): takeout.google.comchr(10)WORKSPACE OAUTH:    admin.google.com/ac/owl/list  (admin only)chr(10)WORKSPACE SIGN-OUT: admin.google.com → Users → [user] → Security → Sign out from all sessionschr(10)chr(10)ORDER OF OPERATIONS: Password → Sessions → OAuth → Forwarding → Audit → Notify → Preserve

Print and tape next to the SOC monitor. The OAuth revoke step is the one that matters most and the one most defenders skip on the first incident.