Google Workspace Object Copied from External Drive with App Consent
Detects when a Workspace user copies a document, spreadsheet, form, or script from an external Drive into their My Drive
and, within minutes from the same IP, authorizes a custom web OAuth client that requests an Apps Script scope.
script.container is the container sidebar or dialog. The check also matches any other script.* scope, a
*.currentonly scope, or a scope containing scripts or container. Adversaries send spearphishing links with a /copy
URI parameter so the victim replicates a malicious object locally. Google names that replica with a "Copy of " prefix.
The copy is performed by a domain user rather than a collaborator account, and the consent is not a known Google
first-party client.
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:
- https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one
- https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two
- https://developers.google.com/apps-script/guides/bound
- https://developers.google.com/identity/protocols/oauth2
- https://support.google.com/a/users/answer/13004165#share_make_a_copy_links
Tags:
- Domain: Cloud
- Data Source: Google Workspace
- Data Source: Google Workspace Audit Logs
- Tactic: Initial Access
- Tactic: Execution
- Tactic: Persistence
- Resources: Investigation Guide
- Noise: Low
- Performance: Fast
- Profile: Recommended
- Threat: OAuth App Consent
- Rule Type: Event Correlation (EQL)
- Platform: Google Workspace
- Domain: SaaS
Version: 215
Rule authors:
- Elastic
Rule license: Elastic License v2
A /copy link replicates a document, spreadsheet, form, or script into the recipient's Drive with a Copy of title, and a container-bound Apps Script can then prompt for consent when the object is opened. This rule correlates that external My Drive copy (copy_type: external, actor_is_collaborator_account: false, owner_is_team_drive: false) with a custom web OAuth grant (client.type: WEB, client id ending in apps.googleusercontent.com) for the same source.user.email and source.ip within maxspan=3m. The grant must include an Apps Script scope: script.container (the container sidebar or dialog), any other script.* scope, a *.currentonly scope, or a scope containing scripts or container. Known Google first-party clients and Cloud project 857627895310 are excluded. Compare google_workspace.token.app_name with file.name and review google_workspace.token.scope.value. Broader scopes such as spreadsheets, drive, or gmail do not match on their own, and visibility is not filtered.
- Identify the affected user from
source.user.emailoruser.email. Notesource.ipand compare@timestamp(event time) on the copy and the authorize event. - Drive copy event (
google_workspace.drive):- Review
file.nameandgoogle_workspace.drive.file.typeto identify what was copied. Confirm the title containsCopy of. - For deeper review, pivot on
google_workspace.drive.file.idorfile.namein Drive audit logs and Admin console Drive investigation.
- Review
- OAuth authorize event (
google_workspace.token):- Review
google_workspace.token.app_nameandgoogle_workspace.token.client.idto identify the application. Check whether the app name appears in the copied title. - Review granted scopes in
google_workspace.token.scope.valueto determine which services the token can access (for example Drive, Gmail, or Calendar scopes beyond the current file). - Confirm
google_workspace.token.client.typeisWEBand that the client is not a known Google first-party client.
- Review
- 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.ipis 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>"
- Determine whether other users copied the same external object:
- 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 and consent to
a container-bound add-on within three minutes from the same IP. Compare
google_workspace.token.app_namewithfile.nameand reviewgoogle_workspace.token.scope.valuebefore closing the alert. Grants that do not include an Apps Script scope (script.containeror anotherscript.*scope,*.currentonly,scripts, orcontainer) do not match. - OAuth consent does not always follow the copy immediately. Opening the object later can separate the two actions beyond 180 seconds, which will not match even when the activity is related.
- Non-English Workspace locales translate the
Copy ofprefix, so those replicas will not match.
- 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.ingestedso delayed ingest does not drop events from the execution window. Sequence correlation andmaxspanstill use@timestampevent 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.intervalis set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
sequence by source.user.email, source.ip with maxspan=3m
[file where data_stream.dataset == "google_workspace.drive" and event.action == "copy" and
/* External My Drive replica by a domain user, not a collaborator account or shared drive */
google_workspace.drive.owner_is_team_drive == false and
google_workspace.drive.actor_is_collaborator_account == false and
google_workspace.drive.primary_event == true and
google_workspace.drive.copy_type == "external" and
/* Google Script, Forms, Sheets, and Documents can carry container-bound scripts */
google_workspace.drive.file.type : ("script", "form", "spreadsheet", "document") and
/* /copy links name the replica with this English prefix */
file.name : "Copy of*"]
[any where data_stream.dataset == "google_workspace.token" and event.action == "authorize" and
/* Custom web OAuth client, not a numeric GCP service-account client */
google_workspace.token.client.type == "WEB" and
google_workspace.token.client.id : "*apps.googleusercontent.com" and
/* Client IDs are {cloud_project_number}-{oauth_client}.apps.googleusercontent.com. */
not google_workspace.token.client.id : (
"77185425430*.apps.googleusercontent.com",
"32555940559*.apps.googleusercontent.com",
"764086051850*.apps.googleusercontent.com",
"407408718192*.apps.googleusercontent.com",
"857627895310*.apps.googleusercontent.com"
) and
/* script.container is the sidebar or dialog. Also match other script.* scopes,
container-bound *.currentonly, or a scope containing scripts or container */
google_workspace.token.scope.value : (
"*script.*",
"*.currentonly",
"*scripts*",
"*container*"
)]
Framework: MITRE ATT&CK
Tactic:
- Name: Initial Access
- Id: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Phishing
- Id: T1566
- Reference URL: https://attack.mitre.org/techniques/T1566/
Sub Technique:
- Name: Spearphishing Link
- Id: T1566.002
- Reference URL: https://attack.mitre.org/techniques/T1566/002/
Framework: MITRE ATT&CK
Tactic:
- Name: Execution
- Id: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: User Execution
- Id: T1204
- Reference URL: https://attack.mitre.org/techniques/T1204/
Sub Technique:
- Name: Malicious Link
- Id: T1204.001
- Reference URL: https://attack.mitre.org/techniques/T1204/001/
Framework: MITRE ATT&CK
Tactic:
- Name: Persistence
- Id: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
Technique:
- Name: Account Manipulation
- Id: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/
Sub Technique:
- Name: Additional Cloud Credentials
- Id: T1098.001
- Reference URL: https://attack.mitre.org/techniques/T1098/001/