Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on behalf of users.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/03/21"
3integration = ["google_workspace"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects when an external (anonymous) user has viewed, copied or downloaded an encryption key file from a Google
11Workspace drive. Adversaries may gain access to encryption keys stored in private drives from rogue access links that do
12not have an expiration. Access to encryption keys may allow adversaries to access sensitive data or authenticate on
13behalf of users.
14"""
15false_positives = [
16 """
17 A user may generate a shared access link to encryption key files to share with others. It is unlikely that the
18 intended recipient is an external or anonymous user.
19 """,
20]
21from = "now-130m"
22index = ["filebeat-*", "logs-google_workspace*"]
23interval = "10m"
24language = "eql"
25license = "Elastic License v2"
26name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User"
27note = """## Triage and analysis
28
29> **Disclaimer**:
30> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
31
32### Investigating Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
33
34Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If shared improperly, these keys can be accessed by unauthorized users, potentially leading to data breaches. Adversaries exploit links with open access to obtain these keys. The detection rule identifies suspicious activities, such as anonymous access to key files, by monitoring file actions and link visibility settings.
35
36### Possible investigation steps
37
38- Review the file activity logs to identify the specific file(s) accessed by the anonymous user, focusing on actions such as "copy", "view", or "download" and the file extensions listed in the query.
39- Check the sharing settings of the accessed file(s) to confirm if they are set to "people_with_link" and assess whether this level of access is appropriate for the file's sensitivity.
40- Investigate the source of the rogue access link by examining any recent changes to the file's sharing settings or any unusual activity in the file's access history.
41- Identify and contact the file owner or relevant stakeholders to verify if the sharing of the file was intentional and authorized.
42- Assess the potential impact of the accessed encryption key(s) by determining what systems or data they protect and evaluate the risk of unauthorized access.
43- Consider revoking or changing the encryption keys if unauthorized access is confirmed to mitigate potential security risks.
44
45### False positive analysis
46
47- Shared project files with encryption keys may trigger alerts if accessed by external collaborators. To manage this, ensure that only trusted collaborators have access and consider using Google Workspace's sharing settings to restrict access to specific users.
48- Automated backup systems that access encryption keys for legitimate purposes might be flagged. Verify the source of access and, if legitimate, create an exception for the backup system's IP address or service account.
49- Internal users accessing encryption keys via shared links for routine tasks could be misidentified as anonymous users. Encourage users to access files through authenticated sessions and adjust monitoring rules to recognize internal IP ranges or user accounts.
50- Third-party integrations that require access to encryption keys might cause false positives. Review the integration's access patterns and whitelist known, secure integrations to prevent unnecessary alerts.
51- Temporary access links for external audits or compliance checks can be mistaken for unauthorized access. Use time-bound access links and document these activities to differentiate them from potential threats.
52
53### Response and remediation
54
55- Immediately revoke access to the specific Google Workspace Drive file by changing its sharing settings to restrict access to only authorized users.
56- Conduct a thorough review of the file's access history to identify any unauthorized access and determine the scope of potential data exposure.
57- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and any potential data compromise.
58- Rotate and replace any encryption keys that were accessed or potentially compromised to prevent unauthorized use.
59- Implement additional monitoring and alerting for similar file types and sharing settings to detect future unauthorized access attempts.
60- Escalate the incident to senior management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
61- Review and update access policies and sharing settings within Google Workspace to ensure that sensitive files are not shared with open access links.
62
63## Setup
64
65The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
66
67### Important Information Regarding Google Workspace Event Lag Times
68- 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.
69- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
70- 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.
71- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
72- See the following references for further information:
73 - https://support.google.com/a/answer/7061566
74 - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
75references = [
76 "https://support.google.com/drive/answer/2494822",
77 "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
78 "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
79]
80risk_score = 73
81rule_id = "980b70a0-c820-11ed-8799-f661ea17fbcc"
82severity = "high"
83tags = [
84 "Domain: Cloud",
85 "Data Source: Google Workspace",
86 "Use Case: Configuration Audit",
87 "Tactic: Credential Access",
88 "Resources: Investigation Guide",
89]
90timestamp_override = "event.ingested"
91type = "eql"
92
93query = '''
94file where event.dataset == "google_workspace.drive" and event.action : ("copy", "view", "download") and
95 google_workspace.drive.visibility: "people_with_link" and source.user.email == "" and
96 file.extension: (
97 "token","assig", "pssc", "keystore", "pub", "pgp.asc", "ps1xml", "pem", "gpg.sig", "der", "key",
98 "p7r", "p12", "asc", "jks", "p7b", "signature", "gpg", "pgp.sig", "sst", "pgp", "gpgz", "pfx", "crt",
99 "p8", "sig", "pkcs7", "jceks", "pkcs8", "psc1", "p7c", "csr", "cer", "spc", "ps2xml")
100'''
101
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105[[rule.threat.technique]]
106id = "T1552"
107name = "Unsecured Credentials"
108reference = "https://attack.mitre.org/techniques/T1552/"
109[[rule.threat.technique.subtechnique]]
110id = "T1552.004"
111name = "Private Keys"
112reference = "https://attack.mitre.org/techniques/T1552/004/"
113
114
115
116[rule.threat.tactic]
117id = "TA0006"
118name = "Credential Access"
119reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Google Workspace Drive Encryption Key(s) Accessed from Anonymous User
Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If shared improperly, these keys can be accessed by unauthorized users, potentially leading to data breaches. Adversaries exploit links with open access to obtain these keys. The detection rule identifies suspicious activities, such as anonymous access to key files, by monitoring file actions and link visibility settings.
Possible investigation steps
- Review the file activity logs to identify the specific file(s) accessed by the anonymous user, focusing on actions such as "copy", "view", or "download" and the file extensions listed in the query.
- Check the sharing settings of the accessed file(s) to confirm if they are set to "people_with_link" and assess whether this level of access is appropriate for the file's sensitivity.
- Investigate the source of the rogue access link by examining any recent changes to the file's sharing settings or any unusual activity in the file's access history.
- Identify and contact the file owner or relevant stakeholders to verify if the sharing of the file was intentional and authorized.
- Assess the potential impact of the accessed encryption key(s) by determining what systems or data they protect and evaluate the risk of unauthorized access.
- Consider revoking or changing the encryption keys if unauthorized access is confirmed to mitigate potential security risks.
False positive analysis
- Shared project files with encryption keys may trigger alerts if accessed by external collaborators. To manage this, ensure that only trusted collaborators have access and consider using Google Workspace's sharing settings to restrict access to specific users.
- Automated backup systems that access encryption keys for legitimate purposes might be flagged. Verify the source of access and, if legitimate, create an exception for the backup system's IP address or service account.
- Internal users accessing encryption keys via shared links for routine tasks could be misidentified as anonymous users. Encourage users to access files through authenticated sessions and adjust monitoring rules to recognize internal IP ranges or user accounts.
- Third-party integrations that require access to encryption keys might cause false positives. Review the integration's access patterns and whitelist known, secure integrations to prevent unnecessary alerts.
- Temporary access links for external audits or compliance checks can be mistaken for unauthorized access. Use time-bound access links and document these activities to differentiate them from potential threats.
Response and remediation
- Immediately revoke access to the specific Google Workspace Drive file by changing its sharing settings to restrict access to only authorized users.
- Conduct a thorough review of the file's access history to identify any unauthorized access and determine the scope of potential data exposure.
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and any potential data compromise.
- Rotate and replace any encryption keys that were accessed or potentially compromised to prevent unauthorized use.
- Implement additional monitoring and alerting for similar file types and sharing settings to detect future unauthorized access attempts.
- Escalate the incident to senior management and, if necessary, involve legal or compliance teams to assess any regulatory implications.
- Review and update access policies and sharing settings within Google Workspace to ensure that sensitive files are not shared with open access links.
Setup
The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
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:
References
Related rules
- Application Added to Google Workspace Domain
- Application Removed from Blocklist in Google Workspace
- Domain Added to Google Workspace Trusted Domains
- Google Workspace 2SV Policy Disabled
- Google Workspace Bitlocker Setting Disabled