« Application Removed from Blocklist in Google Workspace Google Workspace Bitlocker Setting Disabled »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.26

Domain Added to Google Workspace Trusted Domains

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Domain Added to Google Workspace Trusted Domains

edit

Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary.

Rule type: query

Rule indices:

  • filebeat-*
  • logs-google_workspace.admin-*

Severity: high

Risk score: 73

Runs every: 10m

Searches indices from: now-130m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: Google Workspace
  • Use Case: Configuration Audit
  • Tactic: Defense Evasion
  • Resources: Investigation Guide

Version: 211

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Domain Added to Google Workspace Trusted Domains

Google Workspace allowlisted domains define which external organizations users may collaborate with across services such as Drive, Chat, and Classroom. Adding a domain to this list expands who can receive shared content under the tenant’s trust policies. Threat actors with administrative access may add a domain they operate to bypass out-of-domain sharing controls and establish a durable path for collection or exfiltration.

This rule identifies when an administrator adds a domain via the ADD_TRUSTED_DOMAINS event in the google_workspace.admin data stream.

Possible investigation steps

  • Identify the initiating (actor) administrator by reviewing user.email or user.name, and note source.ip and event.ingested if present in the alert.
  • Identify the domain added by reviewing google_workspace.admin.domain.name.
  • Determine whether the change is expected and authorized:
  • Validate there is an approved change request or partner onboarding record for the new domain.
  • If the actor account or source.ip is unusual, treat the alert as higher priority until proven benign.
  • Review allowlisted domains in the Google Admin console:
  • Navigate to Account > Domains > Allowlisted domains.
  • Confirm the domain from google_workspace.admin.domain.name appears on the list and whether it is appropriate for your organization’s sharing model.
  • Assess domain reputation and ownership using external intelligence (for example, VirusTotal or WHOIS) to determine whether the domain is associated with your organization or a known partner.
  • Search Kibana for related admin and sharing activity:
  • Find other trust or sharing policy changes by the same actor: ``` data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("ADD_TRUSTED_DOMAINS" or "REMOVE_TRUSTED_DOMAINS") ```
  • After the add, review Drive events for files shared to users outside your domain: ``` data_stream.dataset: "google_workspace.drive" and event.action: ("change_user_access" or "change_document_visibility") ```
  • Scope for other security-weakening admin actions from the same user.email within the last 48 hours.

False positive analysis

  • Verify the domain belongs to an approved partner or subsidiary with a documented business need for cross-organization collaboration.
  • Adding test or lab domains during migrations is possible — validate timing against change windows.

Response and remediation

  • Initiate the incident response process based on triage findings.
  • If the add is not clearly authorized, remove the domain from Allowlisted domains while the investigation proceeds.
  • If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account.
  • Review recent Drive and Chat sharing to external users for sensitive data exposure tied to the newly trusted domain.
  • 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).

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:
  • https://support.google.com/a/answer/7061566
  • https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html

Setup

edit

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

Rule query

edit
data_stream.dataset:google_workspace.admin and event.action:ADD_TRUSTED_DOMAINS

Framework: MITRE ATT&CKTM

« Application Removed from Blocklist in Google Workspace Google Workspace Bitlocker Setting Disabled »