Google Workspace Password Policy Modified

ELASTIC detection rule by Elastic · Elastic License v2

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.

[metadata]
creation_date = "2020/11/17"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/06/01"

[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
    """
    Password policies may be modified by system administrators. Verify that the configuration change was expected.
    Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Password Policy Modified"
note = """## 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](https://support.google.com/a/answer/7587183) 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:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/7061566",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
]
risk_score = 47
rule_id = "a99f82f5-8e77-4f8b-b3ce-10c0f6afbc73"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
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"
  )
'''

[rule.alert_suppression]
group_by = ["user.email", "google_workspace.admin.org_unit.name", "source.ip"]
duration = {value = 130, unit = "m"}
missing_fields_strategy = "suppress"

[rule.investigation_fields]
field_names = [
    "user.name",
    "user.email",
    "source.ip",
    "event.action",
    "google_workspace.admin.setting.name",
    "google_workspace.admin.org_unit.name",
    "google_workspace.admin.old_value",
    "google_workspace.admin.new_value",
]

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

6f5a7734-56cc-411d-8ce5-8e24a1d6d11f

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion