Google Workspace Super Admin Compromised: Admin Log Checks
If a Google Workspace super admin is compromised: Admin log events for new admins, role grants, SSO changes, delegation, mail routing and compliance rules.
TL;DR. A compromised admin account turns a mailbox incident into a tenant incident. In the Admin log, review everything the account did in the window. The priorities: new super admins and role grants (GRANT_ADMIN_PRIVILEGE, ASSIGN_ROLE), SSO / SAML changes (CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED), domain-wide delegation (AUTHORIZE_API_CLIENT_ACCESS), mail routing, email monitors and content compliance rules, 2SV turned off for users, password resets and new accounts. Each one is a persistence mechanism that user-level clean-up won't touch.
Most Workspace compromises stay at the mailbox level. When they don't, the reason is usually an admin who was phished like everyone else, or a reused credential. The June 2026 Google Threat Intelligence report on UNC6508 describes an actor who reused credentials harvested elsewhere to reach a Workspace administrator account, then created a content compliance rule that BCC'd matching mail to an outside Gmail address. No user's mailbox settings showed anything.
The Admin log, briefly
Every Admin console and Admin SDK change is recorded in the Admin log (Admin log events; API names in the admin event appendix). Each record has the acting admin, the IP, the event name and parameters (target user, setting name, old and new values). Google documents it as near real time, with the usual six-month retention.
What to look for, and why
| Change | Admin log events | Why an attacker does it | Analyzer severity |
|---|---|---|---|
| New super admin | GRANT_ADMIN_PRIVILEGE | Backup admin that survives the original account's reset | High |
| Admin role / delegated admin | ASSIGN_ROLE, GRANT_DELEGATED_ADMIN_PRIVILEGES, ADD_PRIVILEGE | Quieter than super admin, still powerful | Medium |
| SSO | CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED, UPLOAD_OAUTH_CERTIFICATE | Send sign-ins to an IdP they control, or trust their certificate | High |
| Domain-wide delegation | AUTHORIZE_API_CLIENT_ACCESS | API impersonation of every user | High |
| App controls | ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS, … | Let their OAuth app through | Medium |
| Mail routing / monitoring | MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR, Gmail setting changes about routing, forwarding or compliance | Copy mail for users or the whole domain | High |
| 2SV turned off for a user | TURN_OFF_2_STEP_VERIFICATION, UNENROLL_USER_FROM_STRONG_AUTH | Weaken a target account | High |
| Password reset | CHANGE_PASSWORD | Take over another user | Low |
| New or restored user | CREATE_USER, UNSUSPEND_USER, UNDELETE_USER | Backdoor account | Low |
MITRE mappings: T1098.003 Additional Cloud Roles, T1484.002 Trust Modification, T1556 Modify Authentication Process, T1136.003 Create Cloud Account.
The low-severity rows are normal helpdesk work. They matter only in context: the same admin, the same day, after a risky sign-in. The analyzer's chain rule captures exactly that. A risky sign-in followed within 14 days by an admin, SSO, delegation, routing or 2SV change on the same account is critical.
SSO: the quiet backdoor
Workspace can hand authentication to a third-party identity provider through SSO profiles (Security → Authentication → SSO with third-party IdP; see Google's SSO setup guide). An attacker who changes the sign-in URL or uploads their own verification certificate can mint sign-ins for users without knowing any password. Password resets and 2SV don't help.
Checks:
- Compare the sign-in page URL, entity ID and certificates of each profile with your IdP's actual values.
- Check which organizational units or groups each profile is assigned to.
- Correlate with the SAML log: sign-ins through a profile nobody expected.
A limit worth stating: the analyzer matches the SSO event names above. Newer SSO profile operations may be logged under other names. Search the Admin log for "SSO" manually during an incident. If your IdP is Okta, look at the IdP side too. oktaforensics.com covers Okta's System Log.
Mail routing and compliance rules
Admin-level mail rules apply to many mailboxes at once and are invisible in any user's Gmail settings:
- Routing can add recipients or change the destination server.
- Content compliance can match expressions and add recipients. That is the UNC6508 technique.
- Email monitors (older API feature) copy a user's mail to another address.
The analyzer flags MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR, and Gmail setting creations or changes whose setting name mentions routing, forwarding, compliance or bypass. Also review the rules themselves in Apps → Google Workspace → Gmail → Compliance and Routing. The log tells you when, the console tells you what is active now.
Response for an admin compromise
- Contain the admin account: reset sign-in cookies, revoke tokens, reset the password, enforce security keys. Google's 2SV enforcement for admins page is relevant here.
- Enumerate changes: filter the Admin log on that actor for the whole window and export it.
- Revert each unexplained change: remove admins and roles, restore SSO profiles, remove delegations, delete routing and compliance rules, restore 2SV.
- Hunt for second-order accounts: users created or passwords reset by the attacker are attacker-controlled. Repeat the investigation for each.
- Harden: few super admins, not used for daily work, security keys only, and multi-party approval where available. CISA's SCuBA baselines for Google Workspace give a reviewed configuration reference.
This closes the attack-techniques series. For the user-level counterpart, see Gmail forwarding rules. For the full method, see the investigation guide. To triage an Admin log export quickly, use the analyzer.
FAQ
How do I see what a Google Workspace admin changed?
Open Reporting → Audit and investigation → Admin log events in the Admin console and filter on the admin's email as actor and the incident period, or query the Reports API with applicationName=admin. Every setting change, role grant and user change is recorded there.
Why would an attacker change SSO settings in Google Workspace?
Pointing SSO to an identity provider they control, or adding their own signing certificate, lets them sign in as users without passwords or 2SV, and survives password resets. Treat any unplanned SSO change as an incident.