« Google Workspace Custom Admin Role Created Google Workspace Role Modified »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.26

Google Workspace Password Policy Modified

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Google Workspace Password Policy Modified

edit

Detects when a Google Workspace administrator modifies organization password policy settings. Adversaries with administrative access may weaken password requirements, such as disabling strong password enforcement, allowing password reuse, or reducing minimum length, to increase the success of password spraying and credential stuffing against tenant accounts and to sustain access after initial compromise.

Rule type: query

Rule indices:

  • filebeat-*
  • logs-google_workspace.admin-*

Severity: medium

Risk score: 47

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: Identity and Access Audit
  • Tactic: Persistence
  • Tactic: Defense Evasion
  • Resources: Investigation Guide

Version: 211

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Google Workspace Password Policy Modified

Threat actors with Google Workspace administrative access may modify tenant password policies to weaken authentication controls across an organizational unit or domain. Relaxing password complexity, reuse, or rotation requirements increases the likelihood of successful password spraying, credential stuffing, and reuse of passwords exposed in third-party breaches. Because policy changes apply to all users in scope, a single modification can materially expand the attack surface for the entire unit.

Saving changes in the Admin console can update multiple password settings at once. Google logs each setting change as a separate CHANGE_APPLICATION_SETTING or CREATE_APPLICATION_SETTING event (for example, minimum length, maximum length, reset frequency, strong password enforcement, and password reuse). Alert suppression groups by user.email, google_workspace.admin.org_unit.name, and source.ip within the rule lookback so analysts receive one alert per password policy modification session instead of one alert per setting.

Possible investigation steps

  • Identify the initiating (actor) administrator by reviewing user.email or user.name, and note the source.ip and event.ingested timestamps.
  • Identify the setting changed in the alert by reviewing google_workspace.admin.setting.name.
  • Review google_workspace.admin.old_value and google_workspace.admin.new_value to determine whether the change weakened policy. Examples of high-risk changes include:
  • Password Management - Enforce strong password set to disabled
  • Password Management - Enable password reuse set to enabled
  • Password Management - Minimum password length reduced
  • Password Management - Password reset frequency increased (less frequent rotation)
  • Identify the scope of impact by reviewing google_workspace.admin.org_unit.name and determining which users inherit the updated policy.
  • Determine whether the modification is expected and authorized:
  • If the actor account or source.ip is unusual, treat the alert as higher priority until proven benign.
  • Search Kibana for all password settings changed in the session:
  • In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes).
  • Use the following KQL example, replacing <ACTOR_EMAIL> and <ORG_UNIT> as needed: ``` data_stream.dataset: "google_workspace.admin" and event.action: ("CHANGE_APPLICATION_SETTING" or "CREATE_APPLICATION_SETTING") and user.email: "<ACTOR_EMAIL>" and google_workspace.admin.setting.name: Password Management - * ```
  • Optionally filter on google_workspace.admin.org_unit.name: "<ORG_UNIT>" to isolate changes for the same organizational unit.
  • Review all google_workspace.admin.setting.name, google_workspace.admin.old_value, and google_workspace.admin.new_value fields returned to understand the full scope of the modification.
  • Scope for related activity by searching for the same user.email performing other security-weakening admin actions within the last 48 hours, such as MFA enforcement changes, SSO/SAML modifications, or role assignments.

False positive analysis

  • Verify the password policy change aligns with an approved change window, compliance exception, or migration activity.
  • Policy hardening can also generate alerts for this rule — use old_value and new_value to distinguish benign hardening from weakening changes.

Response and remediation

  • Initiate the incident response process based on triage findings.
  • If the modification is not clearly authorized, restore password policy settings to their prior values for the affected organizational unit while the investigation proceeds.
  • If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account.
  • 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.
  • Review the permissions assigned to the implicated administrator 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).

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:
  • https://support.google.com/a/answer/7061566
  • https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html

Setup

edit

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

Rule query

edit
data_stream.dataset:google_workspace.admin and
  event.action:(CHANGE_APPLICATION_SETTING or CREATE_APPLICATION_SETTING) and
  google_workspace.admin.setting.name:(
    "Password Management - Enforce strong password" or
    "Password Management - Password reset frequency" or
    "Password Management - Enable password reuse" or
    "Password Management - Enforce password policy at next login" or
    "Password Management - Minimum password length" or
    "Password Management - Maximum password length"
  )

Framework: MITRE ATT&CKTM

« Google Workspace Custom Admin Role Created Google Workspace Role Modified »