Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
editGoogle Workspace Drive Encryption Key(s) Accessed from Anonymous User
editDetects 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
editTriage 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.nameandgoogle_workspace.drive.file.type, and noteevent.action(view,copy, ordownload) andevent.ingested. -
Identify the file owner by reviewing
google_workspace.drive.file.owner.emailand determine whether that user should store key material in Drive. -
Review
source.user.idand 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, orrenameevents that may indicate when the link was opened. -
Search for other key-like files owned by the same user with
people_with_linkvisibility. - 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.intervalis 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
editThe Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
Rule query
editfile 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
-
Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
-
Technique:
- Name: Unsecured Credentials
- ID: T1552
- Reference URL: https://attack.mitre.org/techniques/T1552/
-
Sub-technique:
- Name: Private Keys
- ID: T1552.004
- Reference URL: https://attack.mitre.org/techniques/T1552/004/
-
Tactic:
- Name: Collection
- ID: TA0009
- Reference URL: https://attack.mitre.org/tactics/TA0009/
-
Technique:
- Name: Data from Cloud Storage
- ID: T1530
- Reference URL: https://attack.mitre.org/techniques/T1530/