First Time Seen Google Workspace OAuth Login from Third-Party Application
Detects the first time a third-party application logs in and authenticated with OAuth. OAuth is used to grant permissions to specific resources and services in Google Workspace. Compromised credentials or service accounts could allow an adversary to authenticate to Google Workspace as a valid user and inherit their privileges.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/03/30"
3integration = ["google_workspace"]
4maturity = "production"
5updated_date = "2025/02/19"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects the first time a third-party application logs in and authenticated with OAuth. OAuth is used to grant
11permissions to specific resources and services in Google Workspace. Compromised credentials or service accounts could
12allow an adversary to authenticate to Google Workspace as a valid user and inherit their privileges.
13"""
14false_positives = [
15 """
16 Developers may leverage third-party applications for legitimate purposes in Google Workspace such as for
17 administrative tasks.
18 """,
19]
20from = "now-130m"
21index = ["filebeat-*", "logs-google_workspace*"]
22interval = "10m"
23language = "kuery"
24license = "Elastic License v2"
25name = "First Time Seen Google Workspace OAuth Login from Third-Party Application"
26note = """## Triage and analysis
27
28> **Disclaimer**:
29> 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.
30
31### Investigating First Time Seen Google Workspace OAuth Login from Third-Party Application
32
33OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access, mimicking legitimate users. The detection rule identifies unusual OAuth logins by monitoring authorization events linked to new third-party applications, flagging potential misuse for further investigation.
34
35### Possible investigation steps
36
37- Review the event details to identify the specific third-party application involved by examining the google_workspace.token.client.id field.
38- Check the google_workspace.token.scope.data field to understand the scope of permissions granted to the third-party application and assess if they align with expected usage.
39- Investigate the user account associated with the OAuth authorization event to determine if there are any signs of compromise or unusual activity.
40- Correlate the timestamp of the OAuth login event with other security logs to identify any concurrent suspicious activities or anomalies.
41- Verify if the third-party application is known and authorized within the organization by consulting with relevant stakeholders or reviewing application whitelists.
42- Assess the risk and impact of the OAuth login by considering the privileges of the user account and the sensitivity of the accessed resources.
43
44### False positive analysis
45
46- New legitimate third-party applications: Users may frequently integrate new third-party applications for productivity or collaboration. To manage this, maintain a whitelist of known and trusted applications and exclude them from triggering alerts.
47- Regular updates to existing applications: Some applications may update their OAuth client IDs during version upgrades. Monitor application update logs and adjust the detection rule to exclude these known updates.
48- Internal development and testing: Organizations developing their own applications may trigger this rule during testing phases. Coordinate with development teams to identify and exclude these internal applications from alerts.
49- Frequent use of service accounts: Service accounts used for automation or integration purposes might appear as new logins. Document and exclude these service accounts from the detection rule to prevent false positives.
50
51### Response and remediation
52
53- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access.
54- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred.
55- Reset the credentials of the affected user and any other users who may have been compromised, ensuring that strong, unique passwords are used.
56- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
57- Implement additional monitoring for the affected user and similar OAuth authorization events to detect any further suspicious activity.
58- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or data exfiltration.
59- Review and update OAuth application permissions and policies to ensure that only trusted applications have access to sensitive data and services.
60
61## Setup
62
63The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
64### Important Information Regarding Google Workspace Event Lag Times
65- 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.
66- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
67- 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.
68- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
69- See the following references for further information:
70 - https://support.google.com/a/answer/7061566
71 - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
72references = [
73 "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
74 "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
75 "https://developers.google.com/apps-script/guides/bound",
76 "https://developers.google.com/identity/protocols/oauth2",
77]
78risk_score = 47
79rule_id = "21bafdf0-cf17-11ed-bd57-f661ea17fbcc"
80severity = "medium"
81tags = ["Domain: Cloud", "Data Source: Google Workspace", "Tactic: Defense Evasion", "Tactic: Initial Access", "Resources: Investigation Guide"]
82timestamp_override = "event.ingested"
83type = "new_terms"
84
85query = '''
86event.dataset: "google_workspace.token" and event.action: "authorize" and
87google_workspace.token.scope.data: *Login and google_workspace.token.client.id: *apps.googleusercontent.com
88'''
89
90
91[[rule.threat]]
92framework = "MITRE ATT&CK"
93[[rule.threat.technique]]
94id = "T1550"
95name = "Use Alternate Authentication Material"
96reference = "https://attack.mitre.org/techniques/T1550/"
97[[rule.threat.technique.subtechnique]]
98id = "T1550.001"
99name = "Application Access Token"
100reference = "https://attack.mitre.org/techniques/T1550/001/"
101
102
103
104[rule.threat.tactic]
105id = "TA0005"
106name = "Defense Evasion"
107reference = "https://attack.mitre.org/tactics/TA0005/"
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110[[rule.threat.technique]]
111id = "T1078"
112name = "Valid Accounts"
113reference = "https://attack.mitre.org/techniques/T1078/"
114[[rule.threat.technique.subtechnique]]
115id = "T1078.004"
116name = "Cloud Accounts"
117reference = "https://attack.mitre.org/techniques/T1078/004/"
118
119
120
121[rule.threat.tactic]
122id = "TA0001"
123name = "Initial Access"
124reference = "https://attack.mitre.org/tactics/TA0001/"
125
126[rule.new_terms]
127field = "new_terms_fields"
128value = ["google_workspace.token.client.id"]
129[[rule.new_terms.history_window_start]]
130field = "history_window_start"
131value = "now-15d"
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 First Time Seen Google Workspace OAuth Login from Third-Party Application
OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access, mimicking legitimate users. The detection rule identifies unusual OAuth logins by monitoring authorization events linked to new third-party applications, flagging potential misuse for further investigation.
Possible investigation steps
- Review the event details to identify the specific third-party application involved by examining the google_workspace.token.client.id field.
- Check the google_workspace.token.scope.data field to understand the scope of permissions granted to the third-party application and assess if they align with expected usage.
- Investigate the user account associated with the OAuth authorization event to determine if there are any signs of compromise or unusual activity.
- Correlate the timestamp of the OAuth login event with other security logs to identify any concurrent suspicious activities or anomalies.
- Verify if the third-party application is known and authorized within the organization by consulting with relevant stakeholders or reviewing application whitelists.
- Assess the risk and impact of the OAuth login by considering the privileges of the user account and the sensitivity of the accessed resources.
False positive analysis
- New legitimate third-party applications: Users may frequently integrate new third-party applications for productivity or collaboration. To manage this, maintain a whitelist of known and trusted applications and exclude them from triggering alerts.
- Regular updates to existing applications: Some applications may update their OAuth client IDs during version upgrades. Monitor application update logs and adjust the detection rule to exclude these known updates.
- Internal development and testing: Organizations developing their own applications may trigger this rule during testing phases. Coordinate with development teams to identify and exclude these internal applications from alerts.
- Frequent use of service accounts: Service accounts used for automation or integration purposes might appear as new logins. Document and exclude these service accounts from the detection rule to prevent false positives.
Response and remediation
- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access.
- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred.
- Reset the credentials of the affected user and any other users who may have been compromised, ensuring that strong, unique passwords are used.
- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
- Implement additional monitoring for the affected user and similar OAuth authorization events to detect any further suspicious activity.
- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or data exfiltration.
- Review and update OAuth application permissions and policies to ensure that only trusted applications have access to sensitive data and services.
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
- Google Workspace Object Copied to External Drive with App Consent
- Google Workspace Suspended User Account Renewed
- O365 Mailbox Audit Logging Bypass
- Application Removed from Blocklist in Google Workspace
- Domain Added to Google Workspace Trusted Domains