A compromised Google Workspace super admin can read any mailbox, copy mail to an outside address, grant OAuth apps tenant-wide access and lock every other administrator out, all with legitimate console actions. The response is different from a single-user account takeover because the attacker controls the tools you would use to investigate and contain, and because Google's own recovery path runs through DNS ownership and Google Support. This playbook covers how a Workspace tenant compromise shows up, the triage questions to answer first, containment in priority order, super admin recovery, eradication of mail routing, delegation and OAuth persistence, Drive sharing sweeps, evidence to preserve and notification rules. It is for Workspace administrators, security operations teams and incident responders. For incidents centred on a third-party identity provider, use the Identity Provider Tenant Compromise Playbook; for the log and event reference behind the detections here, see the Google Workspace Audit Log Detection Guide.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
Key takeaways
- Know your recovery path before you need it. A locked-out super admin recovers through a recovery email or phone, another super admin, or DNS verification with a CNAME or TXT record, so the DNS team is part of incident response.
- Resetting a password is not containment. Reset sign-in cookies, revoke application-specific passwords and remove connected applications as well, because OAuth tokens and app passwords outlive a password change.
- Mail persistence hides in three places. User forwarding, admin routing and email monitors, and mailbox delegation each send copies of mail to the attacker and each needs its own sweep.
- Removing an app from a user is temporary. Google says the user can restore access by signing in again; block the app in API controls to stop it permanently.
- The investigation tool is edition-dependent. Confirm now whether your edition includes the security investigation tool; if not, plan to use audit log exports and the Reports API.
How the incident shows up
| Signal | Source | What it suggests |
|---|---|---|
suspicious_login, account_disabled_hijacked, gov_attack_warning | Login audit log, alert centre | Google has assessed the account as at risk |
user_signed_out_due_to_suspicious_session_cookie | Login audit log | Possible session cookie theft |
GRANT_ADMIN_PRIVILEGE or GRANT_DELEGATED_ADMIN_PRIVILEGES nobody requested | Admin audit log | Attacker creating backup admin access (ATT&CK T1098.003) |
2sv_disable, recovery_email_edit, recovery_phone_edit | Login audit log | Attacker taking over the account's recovery path |
CHANGE_RECOVERY_EMAIL, GENERATE_2SV_SCRATCH_CODES by an admin | Admin audit log | Admin actions that hand an attacker another account |
email_forwarding_out_of_domain | Login audit log | User-level forwarding to an external address (T1114.003) |
CREATE_EMAIL_MONITOR, MAIL_ROUTING_DESTINATION_ADDED | Admin audit log | Admin-level copying of a user's mail |
| Large external sharing or download spikes | Drive log events | Data theft from Drive (T1530) |
| Admins cannot sign in; password or 2SV changed | Users report it | Account access removal (T1531) |
Triage questions
- How many super admins do we have, and how many can still sign in? Google recommends more than one super admin, each held by a different person, precisely so one can act while another is recovered.
- Which accounts are confirmed or suspected compromised, and are any of them super admins or holders of delegated roles?
- Do we control DNS for the primary domain? Super admin recovery depends on adding a CNAME or TXT record.
- Is sign-in federated? If a third-party identity provider signs users in, its compromise may be the root cause; check SAML log events and SSO profile changes.
- What did the attacker change in the Admin console? Pull admin log events for the window, including new admins, app access control changes, routing and email monitors, and domain-wide delegation grants.
- Which OAuth apps and service accounts were authorised in the window? Check OAuth log events (token activity) for new client IDs with broad scopes.
- What data left? Gmail forwarding, Drive external shares and downloads, and Takeout log events.
- Which edition do we hold? The security investigation tool is in Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium.
Containment priorities
- Secure a clean super admin. If any super admin is still trusted, sign in from a known-clean device and use that account for everything that follows. If none is, start recovery: the recovery page offers Try another way for a code to the recovery email or phone; without recovery details the wizard asks for a CNAME record and fails if the record is not found within 48 hours; Contact support gives a reference number and requires a CNAME or TXT record, and DNS changes can take up to 24 hours. Google may ask for further verification, and its admin best practices note the wizard uses account history and billing information.
- Suspend or lock compromised accounts. Suspending a user resets their sign-in cookies. For accounts you must keep active, open the user's Security panel and use Reset Password with Ask for a password change at the next sign-in, then Sign-in cookies > Reset. Google notes Gmail sessions can take up to an hour to end.
- Remove every non-password credential. In the same panel, revoke Application-specific passwords, remove unknown security keys and passkeys (removal is allowed when a key is lost), check Recovery information, and if backup codes may be exposed, use Get backup verification codes to generate a new set, which invalidates the old one.
- Strip attacker admin access. Revoke admin roles granted during the window and remove any super admin you did not create.
- Cut off OAuth access. Remove suspicious apps under the user's Connected applications, then block them tenant-wide in Security > Access and data control > API controls > Manage Third-Party App Access by setting access to Blocked. Google says user-level removal is temporary. For tenant-wide grants, review domain-wide delegation; see the Google Workspace Domain-Wide Delegation Security Guide.
- Stop mail leaving. Restrict Automatic forwarding under Apps > Google Workspace > Gmail > End User Access to internal addresses for the affected organisational units. Google's page does not say whether existing user rules stop when the setting is turned off, so remove each rule found in the sweep as well.
- Freeze external sharing temporarily for affected organisational units if Drive exfiltration is suspected, accepting the business impact for a short window.
| Credential or access path | Survives a password reset? | Containment action |
|---|---|---|
| Browser and mobile sessions | Possibly until cookies reset | Sign-in cookies Reset, or suspend |
| Application-specific passwords | Yes | Revoke in user Security panel |
| OAuth tokens for third-party apps | Yes | Remove under Connected applications, then Block in API controls |
| Domain-wide delegation grants | Yes, tenant-wide | Remove the client ID in API controls |
| Backup verification codes | Yes | Generate new codes to invalidate old set |
| Forwarding, routing, email monitors, delegates | Yes | Remove each one; restrict automatic forwarding |
Eradication
- Admin changes: walk admin log events from the earliest suspicious time and reverse every unapproved change: roles (
GRANT_ADMIN_PRIVILEGE), recovery details (ADD_RECOVERY_EMAIL,CHANGE_RECOVERY_PHONE), password changes (CHANGE_PASSWORD), app access control loosening, SSO profile changes. - Mail persistence: remove email monitors (
CREATE_EMAIL_MONITOR), routing destinations (MAIL_ROUTING_DESTINATION_ADDED), user forwarding addresses and filters, and mailbox delegates. Use Email Log Search to confirm forwarding has stopped. Attackers also hide replies with filters (ATT&CK T1564.008 Email Hiding Rules). - Malicious mail: use the security investigation tool to find and erase phishing sent from compromised accounts to internal users, where your edition includes it.
- OAuth and service accounts: compare authorised apps and domain-wide delegation client IDs with an approved list; remove and block anything unexplained. Check the matching Google Cloud projects for new service account keys. See the OAuth Token Theft Incident Playbook.
- Drive: list files shared externally or made public during the window, using Drive log events filtered to sharing and visibility changes, and revert them. Record what was shared before reverting.
- Devices: where endpoint management is in place, sign the user out of managed computers from Devices > Endpoints > Sign Out User and wipe lost mobile devices.
Recovery
- Rebuild the admin model: at least two super admins held by different people, each a dedicated account used only for super admin tasks, with routine work delegated to limited roles, as Google recommends.
- Phishing-resistant sign-in for admins: security keys for 2-Step Verification, with a spare key enrolled and stored safely, and printed backup codes kept securely.
- Decide on self-recovery: Google turns super admin self-recovery off by default for most current and all new customers; keep it off unless the recovery email and phone are themselves well protected.
- Lock down apps: set unconfigured third-party apps to restricted access and move to an allowlist of Trusted or Limited apps.
- Return users gradually: unsuspend accounts only after their recovery details, 2SV methods, delegates and filters are confirmed clean.
- Raise detection: alert on new admin grants, recovery detail changes and external forwarding for 30 days at a higher priority.
Small and large tenants
A small business with one super admin and no second administrator has no in-console fallback, so DNS-based recovery through Google Support is the main route; the most valuable preparation is a second super admin held by a different person and a written note of who controls the domain's DNS. A large tenant usually has the opposite problem: many delegated admin roles, dozens of authorised OAuth apps and federated sign-in, so scoping takes longer than recovery. Large tenants should pre-build saved queries for the admin, OAuth and Drive log events above and agree in advance who may suspend executives' accounts during an incident. See Google Workspace for Small Business for the smaller case.
Measuring readiness
- Super admin resilience: number of super admins held by different people with security keys enrolled (target two or more).
- Time to clean admin: minutes from declaration to a trusted super admin session in a tabletop exercise.
- Unowned apps: count of authorised OAuth apps and domain-wide delegation clients with no named owner (target zero).
- External forwarding: number of accounts permitted to forward externally, tracked monthly.
- Containment completeness: percentage of compromised accounts where cookies, app passwords and connected apps were all cleared within the first hour.
Evidence to preserve
| Evidence | Why | How |
|---|---|---|
| Admin, Login, OAuth, SAML, Drive, Gmail and Takeout log events | Timeline of attacker actions and data access | Export via the Reports API or BigQuery export before retention expires |
| Security investigation tool queries and results | Admin actions taken during response are themselves logged | Save queries and results; note Admin log records them |
| Forwarding addresses, filters, delegates, routing rules | Shows where mail went | Screenshot or export before removal |
| OAuth client IDs, scopes and grant dates | Scope of third-party access | Export from API controls and token events |
| Drive sharing state of affected files | Data exposure assessment | Export file lists with sharing settings before reverting |
| Google Support case and DNS change records | Recovery sequence and proof of ownership | Keep case number and DNS change tickets |
| Vault holds on affected mailboxes | Preserve mail an attacker might delete | Place holds where Vault is licensed |
| Phase | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | MITRE ATT&CK v20 |
|---|---|---|---|
| Triage | RS.AN-03 | IR-4, AU-6 | T1078.004 Cloud Accounts |
| Containment | RS.MI-01 | AC-2, IA-5 | T1531, T1098.003, T1528 |
| Eradication | RS.MI-02 | IR-4 | T1114.003, T1564.008, T1530 |
| Recovery | RC.RP-01 | CP-10, AC-6, IA-2 | Hardening against repeat takeover |
| Notification | RS.CO-02 | IR-6 | Not applicable |
Notification triggers
- Personal data in mail and Drive: GDPR Article 33 requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals; a processor must tell the controller without undue delay. See the Breach Notification Laws by Country Guide.
- US listed companies: a material incident triggers a Form 8-K Item 1.05 filing, generally due four business days after the materiality determination.
- Downstream fraud: if the attacker used compromised mailboxes to send payment instructions, warn affected customers and suppliers quickly and follow the Business Email Compromise Response Playbook.
Lessons from incidents
- Third-party OAuth tokens reach Workspace too. When an integration provider's tokens are stolen, they can be used to read Workspace mail until revoked. An inventory of authorised apps, with owners, is what lets you answer "were we affected" in hours rather than days.
- Personal Google profiles leak corporate secrets. Service account and admin credentials saved in a personal Google profile in Chrome on a managed laptop sit outside corporate control. Restrict which Google accounts can sign in to managed browsers and devices, and treat saved admin credentials in personal profiles as a finding.
Practitioner checklist
- Keep at least two super admins, each a dedicated account held by a different person, with security keys and printed backup codes.
- Document who can change DNS for the primary domain and how fast, for super admin recovery.
- Confirm whether your edition includes the security investigation tool; if not, set up audit log export now.
- Alert on
GRANT_ADMIN_PRIVILEGE, recovery detail changes,email_forwarding_out_of_domainandCREATE_EMAIL_MONITOR. - Restrict automatic forwarding to internal addresses by default.
- Set unconfigured third-party apps to restricted and maintain a Trusted and Limited allowlist with owners.
- Review domain-wide delegation grants quarterly.
- Practise the containment sequence: cookies, app passwords, connected apps, API control block.
Standards and references
- Google Workspace Admin Help: Recovering administrator access to your account
- Google Workspace Admin Help: Manage a user's security settings
- Google Workspace Admin Help: Security best practices for administrator accounts
- Google Workspace Admin Help: About the security investigation tool
- Google Workspace Admin Help: Control which third-party and internal apps access Google Workspace data
- Google Workspace Admin SDK: Admin audit activity events, user settings
- Google Workspace Admin SDK: Login audit activity events
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
Related NHI Mgmt Group resources: Google Workspace Security Guide · Google Workspace Audit Log Detection Guide · Google Workspace Domain-Wide Delegation Security Guide · Identity Provider Tenant Compromise Playbook · OAuth Token Theft Incident Playbook