Google Workspace API Access Granted via Domain-Wide Delegation

Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/11/12"
  3integration = ["google_workspace"]
  4maturity = "production"
  5updated_date = "2026/07/08"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service
 11account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant.
 12Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based
 13persistence and access mail, drive, and directory data without relying on a single user's password alone.
 14"""
 15false_positives = [
 16    """
 17    Domain-wide delegation of authority may be granted to service accounts by system administrators. Verify that the
 18    configuration change was expected. Exceptions can be added to this rule to filter expected behavior.
 19    """,
 20]
 21from = "now-130m"
 22interval = "10m"
 23index = ["filebeat-*", "logs-google_workspace.admin-*"]
 24language = "kuery"
 25license = "Elastic License v2"
 26name = "Google Workspace API Access Granted via Domain-Wide Delegation"
 27note = """## Triage and analysis
 28
 29### Investigating Google Workspace API Access Granted via Domain-Wide Delegation
 30
 31Domain-wide delegation (DWD) allows a Google Cloud service account or OAuth client to access Workspace user data on
 32behalf of users across the domain. Only super administrators can authorize DWD, and each grant specifies API scopes
 33that define what the client can read or modify (for example Gmail, Drive, Directory, or Calendar APIs). Over-scoped DWD
 34grants create durable third-party access paths that survive individual user password resets.
 35
 36This rule matches `AUTHORIZE_API_CLIENT_ACCESS` events in the `google_workspace.admin` data stream.
 37
 38### Possible investigation steps
 39
 40- Identify the administrator who authorized access by reviewing `user.email` or `user.name`, and note `user.domain` and
 41  `event.ingested` if present in the alert.
 42- Identify the authorized client by reviewing `google_workspace.admin.api.client.name` and confirm the affected tenant
 43  with `google_workspace.admin.domain.name`.
 44- Review granted API scopes in `google_workspace.admin.api.scopes` against least-privilege expectations. Broad scopes
 45  (for example full mail or drive access) warrant higher urgency.
 46- Determine whether the change is expected and authorized:
 47  - Validate there is an approved change request or vendor onboarding record for the client and scopes.
 48  - If the actor account is unusual or the scopes exceed documented requirements, treat as higher priority until proven benign.
 49- Review DWD configuration in the Google Admin console:
 50  - Sign in to [admin.google.com](https://admin.google.com) with an authorized administrator account.
 51  - Navigate to Security > Access and data control > API controls > Domain-wide delegation.
 52  - Confirm the client ID, client name, and scopes match the alert fields.
 53- Search Kibana for related admin activity:
 54  - Find other DWD grants or revocations by the same administrator:
 55    ```
 56    data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("AUTHORIZE_API_CLIENT_ACCESS" or "REVOKE_API_CLIENT_ACCESS")
 57    ```
 58  - Scope for all grants to the same API client:
 59    ```
 60    data_stream.dataset: "google_workspace.admin" and event.action: "AUTHORIZE_API_CLIENT_ACCESS" and google_workspace.admin.api.client.name: "<CLIENT_NAME>"
 61    ```
 62  - Correlate with other high-risk admin actions from the same actor in the last 48 hours:
 63    ```
 64    data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("ASSIGN_ROLE" or "ADD_APPLICATION" or "CREATE_ROLE")
 65    ```
 66- If GCP audit logs are ingested, pivot on the service account or client:
 67  - Search for the client name in `gcp.audit.resource_name` and review `event.action` over the last 48 hours to determine
 68    how the service account is being used after authorization.
 69
 70### False positive analysis
 71
 72- Platform or security teams may authorize DWD for approved automation, backup, or migration tooling — validate against
 73  known service accounts and documented scope requirements.
 74- Vendor onboarding sometimes requires temporary broad scopes; confirm timing against change windows before closing as benign.
 75
 76### Response and remediation
 77
 78- Initiate the incident response process based on triage findings.
 79- If the grant is not clearly authorized, revoke domain-wide delegation for the client under Security > Access and data
 80  control > API controls > Domain-wide delegation while the investigation proceeds.
 81- Rotate or disable the associated GCP service account keys if the client is suspected malicious.
 82- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review
 83  delegated admin roles assigned to that account.
 84- Review activity performed with the authorized client based on scopes in `google_workspace.admin.api.scopes`.
 85- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
 86    - Identify the account role in the cloud environment.
 87    - Assess the criticality of affected services and servers.
 88    - Work with your IT team to identify and minimize the impact on users.
 89    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
 90    - Identify any regulatory or legal ramifications related to this activity.
 91- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
 92- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed.
 93- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
 94- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
 95- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
 96
 97## Setup
 98
 99The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
100
101### Important Information Regarding Google Workspace Event Lag Times
102- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
103- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
104- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
105- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
106- See the following references for further information:
107  - https://support.google.com/a/answer/7061566
108  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
109references = [
110    "https://developers.google.com/admin-sdk/directory/v1/guides/delegation",
111    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
112    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
113]
114risk_score = 73
115rule_id = "acbc8bb9-2486-49a8-8779-45fb5f9a93ee"
116severity = "high"
117tags = [
118    "Domain: Cloud",
119    "Data Source: Google Workspace",
120    "Use Case: Identity and Access Audit",
121    "Resources: Investigation Guide",
122    "Tactic: Persistence",
123    "Tactic: Privilege Escalation",
124]
125timestamp_override = "event.ingested"
126type = "query"
127
128query = '''
129data_stream.dataset:google_workspace.admin
130  and event.action:AUTHORIZE_API_CLIENT_ACCESS
131'''
132
133[rule.investigation_fields]
134field_names = [
135    "user.name",
136    "user.email",
137    "user.domain",
138    "event.action",
139    "google_workspace.admin.api.client.name",
140    "google_workspace.admin.api.scopes",
141    "google_workspace.admin.domain.name",
142]
143
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146
147[[rule.threat.technique]]
148id = "T1098"
149name = "Account Manipulation"
150reference = "https://attack.mitre.org/techniques/T1098/"
151
152[rule.threat.tactic]
153id = "TA0003"
154name = "Persistence"
155reference = "https://attack.mitre.org/tactics/TA0003/"
156
157[[rule.threat]]
158framework = "MITRE ATT&CK"
159
160[[rule.threat.technique]]
161id = "T1098"
162name = "Account Manipulation"
163reference = "https://attack.mitre.org/techniques/T1098/"
164
165[rule.threat.tactic]
166id = "TA0004"
167name = "Privilege Escalation"
168reference = "https://attack.mitre.org/tactics/TA0004/"

Triage and analysis

Investigating Google Workspace API Access Granted via Domain-Wide Delegation

Domain-wide delegation (DWD) allows a Google Cloud service account or OAuth client to access Workspace user data on behalf of users across the domain. Only super administrators can authorize DWD, and each grant specifies API scopes that define what the client can read or modify (for example Gmail, Drive, Directory, or Calendar APIs). Over-scoped DWD grants create durable third-party access paths that survive individual user password resets.

This rule matches AUTHORIZE_API_CLIENT_ACCESS events in the google_workspace.admin data stream.

Possible investigation steps

  • Identify the administrator who authorized access by reviewing user.email or user.name, and note user.domain and event.ingested if present in the alert.
  • Identify the authorized client by reviewing google_workspace.admin.api.client.name and confirm the affected tenant with google_workspace.admin.domain.name.
  • Review granted API scopes in google_workspace.admin.api.scopes against least-privilege expectations. Broad scopes (for example full mail or drive access) warrant higher urgency.
  • Determine whether the change is expected and authorized:
    • Validate there is an approved change request or vendor onboarding record for the client and scopes.
    • If the actor account is unusual or the scopes exceed documented requirements, treat as higher priority until proven benign.
  • Review DWD configuration in the Google Admin console:
    • Sign in to admin.google.com with an authorized administrator account.
    • Navigate to Security > Access and data control > API controls > Domain-wide delegation.
    • Confirm the client ID, client name, and scopes match the alert fields.
  • Search Kibana for related admin activity:
    • Find other DWD grants or revocations by the same administrator:
      1data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("AUTHORIZE_API_CLIENT_ACCESS" or "REVOKE_API_CLIENT_ACCESS")
      
    • Scope for all grants to the same API client:
      1data_stream.dataset: "google_workspace.admin" and event.action: "AUTHORIZE_API_CLIENT_ACCESS" and google_workspace.admin.api.client.name: "<CLIENT_NAME>"
      
    • Correlate with other high-risk admin actions from the same actor in the last 48 hours:
      1data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("ASSIGN_ROLE" or "ADD_APPLICATION" or "CREATE_ROLE")
      
  • If GCP audit logs are ingested, pivot on the service account or client:
    • Search for the client name in gcp.audit.resource_name and review event.action over the last 48 hours to determine how the service account is being used after authorization.

False positive analysis

  • Platform or security teams may authorize DWD for approved automation, backup, or migration tooling — validate against known service accounts and documented scope requirements.
  • Vendor onboarding sometimes requires temporary broad scopes; confirm timing against change windows before closing as benign.

Response and remediation

  • Initiate the incident response process based on triage findings.
  • If the grant is not clearly authorized, revoke domain-wide delegation for the client under Security > Access and data control > API controls > Domain-wide delegation while the investigation proceeds.
  • Rotate or disable the associated GCP service account keys if the client is suspected malicious.
  • If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account.
  • Review activity performed with the authorized client based on scopes in google_workspace.admin.api.scopes.
  • Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    • Identify the account role in the cloud environment.
    • Assess the criticality of affected services and servers.
    • Work with your IT team to identify and minimize the impact on users.
    • Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    • Identify any regulatory or legal ramifications related to this activity.
  • Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
  • Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed.
  • Implement security best practices outlined by Google.
  • Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
  • Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

Important Information Regarding Google Workspace Event Lag Times

  • As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
  • This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
  • To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
  • By default, var.interval is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
  • See the following references for further information:

References

Related rules

to-top