Google Workspace Drive Encryption Key(s) Accessed from Anonymous User

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

Google Workspace Drive Encryption Key(s) Accessed from Anonymous User

edit

Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise.

Rule type: eql

Rule indices:

  • filebeat-*
  • logs-google_workspace.drive-*

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: Credential Access
  • Tactic: Collection
  • Resources: Investigation Guide

Version: 10

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Google Workspace Drive Encryption Key(s) Accessed from Anonymous User

Threat actors and opportunistic scanners frequently abuse Google Drive links set to "Anyone with the link" to access sensitive files without authenticating. Private keys, keystores, and token files stored in user drives are high-value targets. Possession of these files can enable decryption of protected data, signing or impersonation, and lateral movement into systems that trust the exposed material.

This rule uses EQL to detect view, copy, or download activity in google_workspace.drive where google_workspace.drive.visibility is people_with_link, source.user.email is empty (anonymous access), and file.extension matches common key or credential file types.

Possible investigation steps

  • Identify the file accessed by reviewing file.name and google_workspace.drive.file.type, and note event.action (view, copy, or download) and event.ingested.
  • Identify the file owner by reviewing google_workspace.drive.file.owner.email and determine whether that user should store key material in Drive.
  • Review source.user.id and any available IP or user-agent context in the raw event to characterize the anonymous accessor.
  • Confirm sharing posture in Google Drive:
  • Open the file in Drive as an administrator or the owner and review Share settings.
  • Verify whether access is "Anyone with the link" and whether the link was intentionally published or may have been exposed after account compromise.
  • Search Kibana for related Drive activity for the same file or owner: ``` data_stream.dataset: "google_workspace.drive" and google_workspace.drive.file.owner.email: "<OWNER_EMAIL>" and file.name: "<FILE_NAME>" ```
  • Look for earlier change_user_access, change_document_visibility, or rename events that may indicate when the link was opened.
  • Search for other key-like files owned by the same user with people_with_link visibility.
  • Determine blast radius — identify which systems, applications, or cloud resources the key protects (VPN, TLS, code signing, service accounts, encrypted archives).
  • Contact the file owner and security stakeholders to confirm whether anonymous access was expected (for example, a documented external audit). Treat unexpected access as high priority.

False positive analysis

  • Legitimate use of link-based sharing for key files is rare; validate business justification before closing as benign.
  • Automated scanners or DLP tools may touch public links — correlate with known security tooling and owner intent.

Response and remediation

  • Initiate the incident response process based on triage findings.
  • Revoke the open link or restrict sharing to specific users; move key material out of broadly link-shared locations.
  • If access is unauthorized, rotate or replace the exposed keys and review dependent systems for abuse.
  • Review the file owner’s account for signs of compromise (unusual logins, OAuth grants, or mass sharing changes).

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
file where data_stream.dataset == "google_workspace.drive" and event.action : ("copy", "view", "download") and
    google_workspace.drive.visibility: "people_with_link" and source.user.email == "" and
    file.extension: (
        "token","assig", "pssc", "keystore", "pub", "pgp.asc", "ps1xml", "pem", "gpg.sig", "der", "key",
        "p7r", "p12", "asc", "jks", "p7b", "signature", "gpg", "pgp.sig", "sst", "pgp", "gpgz", "pfx", "crt",
        "p8", "sig", "pkcs7", "jceks", "pkcs8", "psc1", "p7c", "csr", "cer", "spc", "ps2xml")

Framework: MITRE ATT&CKTM