Google Workspace Password Policy Modified

Detects when a Google Workspace password policy is modified. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/11/17"
  3integration = ["google_workspace"]
  4maturity = "production"
  5updated_date = "2024/05/21"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when a Google Workspace password policy is modified. An adversary may attempt to modify a password policy in
 11order to weaken an organization’s security controls.
 12"""
 13false_positives = [
 14    """
 15    Password policies may be modified by system administrators. Verify that the configuration change was expected.
 16    Exceptions can be added to this rule to filter expected behavior.
 17    """,
 18]
 19from = "now-130m"
 20index = ["filebeat-*", "logs-google_workspace*"]
 21interval = "10m"
 22language = "kuery"
 23license = "Elastic License v2"
 24name = "Google Workspace Password Policy Modified"
 25note = """## Triage and analysis
 26
 27### Investigating Google Workspace Password Policy Modified
 28
 29Google Workspace administrators manage password policies to enforce password requirements for an organization's compliance needs. Administrators have the capability to set restrictions on password length, reset frequency, reuse capability, expiration, and much more. Google Workspace also allows multi-factor authentication (MFA) and 2-step verification (2SV) for authentication.
 30
 31Threat actors might rely on weak password policies or restrictions to attempt credential access by using password stuffing or spraying techniques for cloud-based user accounts. Administrators might introduce increased risk to credential access from a third-party by weakening the password restrictions for an organization.
 32
 33This rule detects when a Google Workspace password policy is modified to decrease password complexity or to adjust the reuse and reset frequency.
 34
 35#### Possible investigation steps
 36
 37- Identify associated user account(s) by reviewing the `user.name` or `source.user.email` fields in the alert.
 38- Identify the password setting that was created or adjusted by reviewing `google_workspace.admin.setting.name` field.
 39- Check if a password setting was enabled or disabled by reviewing the `google_workspace.admin.new_value` and `google_workspace.admin.old_value` fields.
 40- After identifying the involved user, verify administrative privileges are scoped properly to change.
 41- Filter `event.dataset` for `google_workspace.login` and aggregate by `user.name`, `event.action`.
 42  - The `google_workspace.login.challenge_method` field can be used to identify the challenge method used for failed and successful logins.
 43
 44### False positive analysis
 45
 46- After identifying the user account that updated the password policy, verify whether the action was intentional.
 47- Verify whether the user should have administrative privileges in Google Workspace to modify password policies.
 48- Review organizational units or groups the role may have been added to and ensure the new privileges align properly.
 49
 50### Response and remediation
 51
 52- Initiate the incident response process based on the outcome of the triage.
 53- Consider resetting passwords for potentially affected users.
 54- Disable or limit the account during the investigation and response.
 55- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
 56    - Identify the account role in the cloud environment.
 57    - Assess the criticality of affected services and servers.
 58    - Work with your IT team to identify and minimize the impact on users.
 59    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
 60    - Identify any regulatory or legal ramifications related to this activity.
 61- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
 62- Reactivate multi-factor authentication for the user.
 63- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
 64- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
 65- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
 66- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
 67
 68## Setup
 69
 70The Google Workspace Fleet integration, the Filebeat module, or data that's similarly structured is required for this rule.
 71
 72### Important Information Regarding Google Workspace Event Lag Times
 73- As per Google's documentation, Google Workspace administrators might observe lag times ranging from several minutes to 3 days between the event occurrence time and the event being visible in the Google Workspace admin/audit logs.
 74- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
 75- 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.
 76- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
 77- See the following references for further information:
 78  - https://support.google.com/a/answer/7061566
 79  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
 80risk_score = 47
 81rule_id = "a99f82f5-8e77-4f8b-b3ce-10c0f6afbc73"
 82severity = "medium"
 83tags = [
 84    "Domain: Cloud",
 85    "Data Source: Google Workspace",
 86    "Use Case: Identity and Access Audit",
 87    "Tactic: Persistence",
 88    "Resources: Investigation Guide",
 89]
 90timestamp_override = "event.ingested"
 91type = "query"
 92
 93query = '''
 94event.dataset:google_workspace.admin and event.provider:admin and event.category:iam and
 95  event.action:(CHANGE_APPLICATION_SETTING or CREATE_APPLICATION_SETTING) and
 96  google_workspace.admin.setting.name:(
 97    "Password Management - Enforce strong password" or
 98    "Password Management - Password reset frequency" or
 99    "Password Management - Enable password reuse" or
100    "Password Management - Enforce password policy at next login" or
101    "Password Management - Minimum password length" or
102    "Password Management - Maximum password length"
103  )
104'''
105
106
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1098"
111name = "Account Manipulation"
112reference = "https://attack.mitre.org/techniques/T1098/"
113
114
115[rule.threat.tactic]
116id = "TA0003"
117name = "Persistence"
118reference = "https://attack.mitre.org/tactics/TA0003/"

Triage and analysis

Investigating Google Workspace Password Policy Modified

Google Workspace administrators manage password policies to enforce password requirements for an organization's compliance needs. Administrators have the capability to set restrictions on password length, reset frequency, reuse capability, expiration, and much more. Google Workspace also allows multi-factor authentication (MFA) and 2-step verification (2SV) for authentication.

Threat actors might rely on weak password policies or restrictions to attempt credential access by using password stuffing or spraying techniques for cloud-based user accounts. Administrators might introduce increased risk to credential access from a third-party by weakening the password restrictions for an organization.

This rule detects when a Google Workspace password policy is modified to decrease password complexity or to adjust the reuse and reset frequency.

Possible investigation steps

  • Identify associated user account(s) by reviewing the user.name or source.user.email fields in the alert.
  • Identify the password setting that was created or adjusted by reviewing google_workspace.admin.setting.name field.
  • Check if a password setting was enabled or disabled by reviewing the google_workspace.admin.new_value and google_workspace.admin.old_value fields.
  • After identifying the involved user, verify administrative privileges are scoped properly to change.
  • Filter event.dataset for google_workspace.login and aggregate by user.name, event.action.
    • The google_workspace.login.challenge_method field can be used to identify the challenge method used for failed and successful logins.

False positive analysis

  • After identifying the user account that updated the password policy, verify whether the action was intentional.
  • Verify whether the user should have administrative privileges in Google Workspace to modify password policies.
  • Review organizational units or groups the role may have been added to and ensure the new privileges align properly.

Response and remediation

  • Initiate the incident response process based on the outcome of the triage.
  • Consider resetting passwords for potentially affected users.
  • Disable or limit the account during the investigation and response.
  • Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    • Identify the account role in the cloud environment.
    • Assess the criticality of affected services and servers.
    • Work with your IT team to identify and minimize the impact on users.
    • Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    • Identify any regulatory or legal ramifications related to this activity.
  • Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
  • Reactivate multi-factor authentication for the user.
  • Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
  • Implement security best practices outlined by Google.
  • Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
  • Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

Setup

The Google Workspace Fleet integration, the Filebeat module, or data that's similarly structured is required for this rule.

Important Information Regarding Google Workspace Event Lag Times

  • As per Google's documentation, Google Workspace administrators might observe lag times ranging from several minutes to 3 days between the event occurrence time 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:

Related rules

to-top