Google Workspace 2SV Policy Disabled By User

[metadata]
creation_date = "2022/08/26"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a
compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and
making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges.
"""
false_positives = [
    """
    Administrators may remove 2-step verification (2SV) temporarily for testing or during maintenance. If 2SV was
    previously enabled, it is not common to disable this policy for extended periods of time.
    """,
]
from = "now-190m"
index = ["filebeat-*", "logs-google_workspace.login-*", "logs-google_workspace.user_accounts-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace 2SV Policy Disabled By User"
note = """## Triage and analysis

### Investigating Google Workspace 2SV Policy Disabled By User

Threat actors who compromise a Google Workspace account may disable 2-step verification (2SV) on that account to remove
the second authentication factor. With 2SV turned off, the account falls back to password-only authentication, which can
support session abuse, AiTM credential relay, and sustained access without MFA challenges on future sign-ins. This is
especially concerning for administrators, executives, and users with access to sensitive mail, data, or admin functions.

In AiTM and session-hijacking scenarios, an attacker with an active session may disable 2SV before the legitimate user
notices, making it easier to re-enter the account later using stolen credentials alone.

This rule identifies when a user disables 2SV on their account via the `2sv_disable` event. The event appears in
both the `google_workspace.login` and `google_workspace.user_accounts` data streams; alert suppression groups by
`user.email` and `source.ip` within the rule lookback to avoid duplicate alerts when both streams are ingested.

### Possible investigation steps

- Identify the user account that disabled 2SV by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps.
- Determine the account's privilege and data access — prioritize triage if the user is an administrator, holds delegated admin roles, or has access to sensitive resources.
- Determine whether the disable is expected or unauthorized:
  - Validate with the user or their manager whether they intentionally turned off 2SV (for example, device replacement).
  - If the `source.ip`, geolocation, or timing is unusual for the user, treat the alert as higher priority until proven benign.
- Search Kibana for precursor and follow-on account changes for the same `user.email` in the hours before and after the alert:
  - `password_edit`, `recovery_email_edit`, `recovery_phone_edit` in `google_workspace.login` or `google_workspace.user_accounts`
  - `login_success`, `login_failure`, `suspicious_login`, and `login_challenge` in `google_workspace.login`
  - OAuth activity in `google_workspace.token` if token abuse is suspected
- Review `google_workspace.login.challenge_method` on recent sign-ins to determine whether MFA was used, bypassed, or relayed before 2SV was disabled.

### False positive analysis

- Legitimate users may disable 2SV temporarily, but this weakens the account — confirm the change was authorized even when the actor appears benign.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the disable is not clearly authorized, re-enable 2SV on the affected account, reset the password, and revoke active sessions while the investigation proceeds.
- 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 user 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, 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 190 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.
- 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) for Filebeat and 3 hours for the Fleet Integration `login` datastream. 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/9176657?hl=en",
    "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 = 73
rule_id = "5e161522-2545-11ed-ac47-f661ea17fbce"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:("google_workspace.login" or "google_workspace.user_accounts") and event.action:"2sv_disable"
'''

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

[rule.investigation_fields]
field_names = [
    "user.name",
    "user.email",
    "source.ip",
    "event.action",
]

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

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

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

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