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

to-top