Why is a single SUPER_ADMIN_ADD treated as critical?

Because super admin in Google Workspace is the top of the tenant. A super admin can read any mailbox and Drive, reset any password, disable any user's 2SV, and create more super admins. Granting it is the action an attacker takes to convert a single compromised admin into durable, tenant-wide control. Legitimate super-admin appointments are rare, planned, and traceable to an existing owner — so alerting on every grant costs almost nothing and catches the one that matters.

What does 2SV_DISABLE tell you that a failed login wouldn't?

It tells you the attacker is thinking about persistence, not just access. Disabling a user's two-step verification means the next login for that account needs only a password — which the attacker, having compromised an admin, can reset at will. It converts a temporary foothold into a reusable backdoor account. Seeing 2SV_DISABLE for a victim followed by a super-admin grant to an external address, as in the validation sample, is a textbook takeover-then-persist sequence.

Should I correlate these three events or alert on each independently?

Both. Alert on each independently because each is individually rare and meaningful — you cannot afford to wait for a full chain before responding to a super-admin grant. But correlation by actor and source IP dramatically raises confidence: in the sample, the same compromised.admin@corp.com account disables a victim's 2SV and then grants Super Admin to attacker@external.com within two minutes. That temporal clustering from one actor is what separates an incident from three unrelated administrative events.

How do I get these events into a SIEM in the first place?

They come from the Google Workspace Admin SDK Reports API (the admin, login, and user_accounts applications), which most SIEMs pull on a schedule or receive via a Workspace-to-Chronicle/Pub-Sub export. The rule keys on the events[].name field — SUPER_ADMIN_ADD and SUSPICIOUS_LOGIN under the login/admin applications, 2SV_DISABLE under user account settings. Make sure your collector is subscribed to all three applications; a common gap is pulling login events but not admin USER_SETTINGS events, which hides the 2SV and role changes entirely.

Detect Super Admin Grants and 2SV Tampering in Google Workspace Audit Logs

Published September 18, 2026

Sigma Rule

title: Google Workspace Super Admin Grant and 2SV Tampering
id: 5898235a-abe3-4152-b4ee-26642696c381
status: experimental
description: >
  Detects admin-plane takeover in the Google Workspace Admin Reports API. Three
  independent high-signal events: a super-admin role being granted to an account
  (SUPER_ADMIN_ADD), two-step verification being disabled for a user
  (2SV_DISABLE), and Google's own risk engine flagging a login as suspicious
  (SUSPICIOUS_LOGIN). A super-admin grant is the highest-value action in a
  Workspace tenant; disabling 2SV removes a victim's last authentication control.
  Any one warrants an alert; seeing them in sequence from the same actor is an
  account-takeover chain in progress.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://attack.mitre.org/techniques/T1556/006/
author: LogTriage
date: 2026/09/18
logsource:
  product: gws
  service: admin
detection:
  grant_super_admin:
    eventName: 'SUPER_ADMIN_ADD'
  disable_2sv:
    eventName: '2SV_DISABLE'
  suspicious_login:
    eventName: 'SUSPICIOUS_LOGIN'
  condition: grant_super_admin or disable_2sv or suspicious_login
falsepositives:
  - Genuine new super-admin appointment (should be announced and ticketed)
  - Helpdesk-driven 2SV reset for a lost device (correlate with a ticket)
  - Single SUSPICIOUS_LOGIN for a traveling employee with no follow-on admin changes
level: critical
tags:
  - attack.persistence
  - attack.t1098
  - attack.defense_evasion
  - attack.t1556.006

What this rule detects

The Google Workspace Admin Reports API records every consequential action in a tenant. This rule fires on the three that signal admin-plane compromise:

SUPER_ADMIN_ADD — an account was granted the super-admin role, the highest privilege in the tenant.
2SV_DISABLE — two-step verification was turned off for a user, removing their last authentication control.
SUSPICIOUS_LOGIN — Google’s own risk engine flagged a sign-in as anomalous.

Each is an independent or branch. They are individually rare enough that a single occurrence justifies an alert, so there is no threshold.

Detection logic

The rule keys on events[].name from the Admin Reports API — no counting, no windows, just three event names that should never appear unexpectedly:

SUPER_ADMIN_ADD is the escalation. It is what an attacker does after compromising one admin to gain durable tenant-wide control. Legitimate grants are planned and attributable to an existing owner; anything else is the pivot point of a takeover.
2SV_DISABLE is the persistence. Turning off a victim’s second factor turns a password-reset (which a compromised admin can do freely) into reusable access to that account.
SUSPICIOUS_LOGIN is the early warning. On its own it is often benign travel; clustered with the other two from the same actor, it is the first link in the chain.

The real power is correlation. Alert on each independently, but group by actor email and source IP — the same principal producing two or three of these within minutes is an incident, not coincidence.

Validated against a real sample

Validated against google_workspace_attack.json (shipped with LogTriage), a three-event chain:

A SUSPICIOUS_LOGIN for attacker@external.com from 185.220.101.42, with the is_suspicious parameter set true
A 2SV_DISABLE performed by compromised.admin@corp.com (same source IP) targeting victim@corp.com
A SUPER_ADMIN_ADD by compromised.admin@corp.com — this time from 45.142.212.100 — granting the Super Admin role to attacker@external.com

Read together: a suspicious external login, then a compromised internal admin stripping a victim’s 2SV, then that same admin handing super-admin rights to the external attacker. Complete takeover in three log lines.

The rule fires on that sample and stays silent on the matching benign log, which contains only a login_success (with is_suspicious set false) and a document view — no SUPER_ADMIN_ADD, 2SV_DISABLE, or SUSPICIOUS_LOGIN events at all.

False positives

Legitimate versions of these events exist, but they share a property the attack does not: they are expected. A planned super-admin appointment is announced and ticketed. A helpdesk 2SV reset correlates with a support case and a known, uncompromised admin as the actor. A SUSPICIOUS_LOGIN for a genuinely traveling employee stands alone, with no admin changes following it.

The tuning move is therefore correlation, not suppression: enrich each event with the actor’s recent history and any linked change ticket. A super-admin grant by an admin who themselves just produced a SUSPICIOUS_LOGIN from a Tor exit is not a false positive under any tuning.

Frequently Asked Questions

Why is a single SUPER_ADMIN_ADD treated as critical?: Because super admin in Google Workspace is the top of the tenant. A super admin can read any mailbox and Drive, reset any password, disable any user's 2SV, and create more super admins. Granting it is the action an attacker takes to convert a single compromised admin into durable, tenant-wide control. Legitimate super-admin appointments are rare, planned, and traceable to an existing owner — so alerting on every grant costs almost nothing and catches the one that matters.
What does 2SV_DISABLE tell you that a failed login wouldn't?: It tells you the attacker is thinking about persistence, not just access. Disabling a user's two-step verification means the next login for that account needs only a password — which the attacker, having compromised an admin, can reset at will. It converts a temporary foothold into a reusable backdoor account. Seeing 2SV_DISABLE for a victim followed by a super-admin grant to an external address, as in the validation sample, is a textbook takeover-then-persist sequence.
Should I correlate these three events or alert on each independently?: Both. Alert on each independently because each is individually rare and meaningful — you cannot afford to wait for a full chain before responding to a super-admin grant. But correlation by actor and source IP dramatically raises confidence: in the sample, the same compromised.admin@corp.com account disables a victim's 2SV and then grants Super Admin to attacker@external.com within two minutes. That temporal clustering from one actor is what separates an incident from three unrelated administrative events.
How do I get these events into a SIEM in the first place?: They come from the Google Workspace Admin SDK Reports API (the admin, login, and user_accounts applications), which most SIEMs pull on a schedule or receive via a Workspace-to-Chronicle/Pub-Sub export. The rule keys on the events[].name field — SUPER_ADMIN_ADD and SUSPICIOUS_LOGIN under the login/admin applications, 2SV_DISABLE under user account settings. Make sure your collector is subscribed to all three applications; a common gap is pulling login events but not admin USER_SETTINGS events, which hides the 2SV and role changes entirely.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs