« Application Added to Google Workspace Domain Google Workspace Admin Role Assigned to a User or Group »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.26

Google Workspace 2SV Policy Disabled By User

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

Google Workspace 2SV Policy Disabled By User

edit

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.

Rule type: query

Rule indices:

  • filebeat-*
  • logs-google_workspace.login-*
  • logs-google_workspace.user_accounts-*

Severity: medium

Risk score: 47

Runs every: 10m

Searches indices from: now-190m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: Google Workspace
  • Use Case: Configuration Audit
  • Tactic: Persistence
  • Resources: Investigation Guide

Version: 112

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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 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 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

Setup

edit

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

Rule query

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

Framework: MITRE ATT&CKTM

« Application Added to Google Workspace Domain Google Workspace Admin Role Assigned to a User or Group »