Loading

Google Workspace Object Copied from External Drive with App Consent

Detects when a user copies a Google document, spreadsheet, form, or script from an external Drive into their Workspace Drive and shortly after authorizes a custom Google OAuth application. Adversaries may send spearphishing links with a /copy URI parameter so the victim replicates a malicious object locally. Container-bound Apps Script can then execute on open and prompt the user for OAuth consent, granting the attacker's application access to Workspace data.

Rule type: eql
Rule indices:

  • logs-google_workspace.*

Rule Severity: high
Risk Score: 73
Runs every: 10m
Searches indices from: now-130m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Cloud
  • Data Source: Google Workspace
  • Tactic: Initial Access
  • Tactic: Execution
  • Tactic: Persistence
  • Resources: Investigation Guide

Version: 213
Rule authors:

  • Elastic

Rule license: Elastic License v2

Google Workspace users can receive Drive links with URI parameters such as view, edit, or copy. A copy link lets the recipient replicate the object into their own Drive. Documents, spreadsheets, forms, and Apps Script projects can include container-bound scripts that run when the object is opened. Copying alone does not produce an OAuth event; the user must open the copied object (or trigger an installable onOpen handler) before Apps Script can prompt for consent.

This rule correlates two events for the same source.user.email within maxspan=3m using @timestamp (Google event time). When a user copies a Google document, spreadsheet, form, or script from an external Drive into their Workspace Drive and shortly after authorizes a custom Google OAuth application.

  • Identify the affected user from source.user.email or user.email in the alert. Note source.ip and compare @timestamp (event time).
  • Drive copy event (google_workspace.drive):
    • Review file.name, file.id, and google_workspace.drive.file.type to identify what was copied.
    • For deeper review, pivot on file.id or file.name in Drive audit logs and Admin console Drive investigation.
  • OAuth authorize event (google_workspace.token):
    • Review google_workspace.token.app_name and google_workspace.token.client.id to identify the application.
    • Review granted scopes in google_workspace.token.scope.value to determine which services the token can access (for example Drive, Gmail, or Calendar scopes beyond identity).
    • Review google_workspace.token.client.type and any user.domain context if present.
  • Determine whether the activity is expected:
    • Contact the user to confirm they intentionally copied an external template and authorized the application.
    • If timing or source.ip is unusual for the user, treat as higher priority until validated.
  • Search Kibana for related activity:
    • Determine whether other users copied the same external object:
      data_stream.dataset: "google_workspace.drive" and event.action: "copy" and google_workspace.drive.copy_type: "external" and file.name: "<FILE_NAME>"
    • Correlate with sign-in activity around the same window:
      data_stream.dataset: "google_workspace.login" and user.email: "<USER_EMAIL>"
    • Scope for other OAuth grants to the same client across the tenant:
      data_stream.dataset: "google_workspace.token" and event.action: "authorize" and google_workspace.token.client.id: "<CLIENT_ID>"
  • If a container-bound script is suspected, locate the copied object in the user's Drive and review Apps Script code for exfiltration, token harvesting, or persistence logic. Remove the object from affected users' Drives.
  • Users may legitimately copy public templates (spreadsheets, forms, or documents) from external drives for personal or business use; OAuth consent afterward may still be benign if the embedded script is intentional (for example a known add-on or vendor workflow).
  • OAuth consent does not always follow copy immediately; opening the object later can separate the two actions beyond maxspan=3m, which would prevent a match even when activity is related.
  • Initiate the incident response process based on triage findings.
  • If the copy or OAuth grant is not clearly authorized, revoke the application's access for the affected user under Security > Access and data control > API controls (or remove the user token via admin OAuth reports).
  • Remove malicious copied objects from affected users' Drives and report abusive OAuth clients to Google if appropriate.
  • If the user account is suspected compromised, reset credentials, revoke active sessions, and review all OAuth grants for that user.
  • Review activity performed with the authorized token based on scopes in google_workspace.token.scope.value.
  • 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 user 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).

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

  • 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 and uses timestamp_override: event.ingested so delayed ingest does not drop events from the execution window. Sequence correlation and maxspan still use @timestamp event time.
  • Drive and token audit events may arrive on different schedules; the token integration polls Google's API on a longer default interval. To reduce false negatives, consider reducing the poll interval for both Drive and token data sources.
  • By default, var.interval is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
sequence by source.user.email with maxspan=3m
[file where data_stream.dataset == "google_workspace.drive" and event.action == "copy" and

    /* Should only match if the object lives in a Drive that is external to the user's GWS organization */
    google_workspace.drive.owner_is_team_drive == false and google_workspace.drive.copy_type == "external" and

    /* Google Script, Forms, Sheets and Document can have container-bound scripts */
    google_workspace.drive.file.type: ("script", "form", "spreadsheet", "document")]

[any where data_stream.dataset == "google_workspace.token" and event.action == "authorize" and

    /* Ensures application ID references custom app in Google Workspace and not GCP */
    google_workspace.token.client.id : "*apps.googleusercontent.com"]

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK