Google Workspace Login Flagged Suspicious

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

Google Workspace Login Flagged Suspicious

Surfaces Google Workspace sign-in events that Google’s identity risk engine has flagged as suspicious via the is_suspicious field on the login activity record. This is Google’s own ML-driven sign-in risk signal. The field is set by Google server-side based on signals like sign-ins from anonymizer infrastructure, known-malicious IP ranges, atypical user characteristics, or anomalous device fingerprints. Use this signal as enrichment alongside the other Workspace sign-in rules rather than as a standalone alert. This rule is a building block. It does not generate user-facing alerts by default but populates signal.rule.building_block_type for correlation rules or analyst pivots.

Rule type: query

Rule indices:

filebeat-*
logs-google_workspace.login*

Severity: low

Risk score: 21

Runs every: 60m

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

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Domain: Identity
Data Source: Google Workspace
Data Source: Google Workspace Audit Logs
Data Source: Google Workspace User Log Events
Use Case: Threat Detection
Use Case: Identity and Access Audit
Tactic: Initial Access
Tactic: Credential Access
Rule Type: BBR
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Google Workspace Login Flagged Suspicious

Google sets google_workspace.login.is_suspicious: true when its server-side risk engine identifies a sign-in event as anomalous for the user. Triggers commonly include:

Sign-in from an anonymizer (Tor exit, public VPN, etc.)
Sign-in from a known-malicious IP range
Atypical device fingerprint for the user
Sign-in from a geography or ASN inconsistent with the user’s history

As a building block, this signal is intended for use alongside other detection rules. On its own it is medium-confidence.

Possible investigation steps

Inspect source.ip, source.as.organization.name, source.geo.country_name. Classify the network: residential ISP, corporate VPN, hosting provider (high concern), anonymizer (high concern).
Inspect google_workspace.login.type. google_password is an interactive sign-in (highest concern). reauth is a silent token refresh (lower concern unless paired with other signals).
Inspect google_workspace.login.challenge_method. Whether 2FA was relayed or skipped factors into the kit-vs-traveler determination.
Pull the user’s recent sign-in history. Is this a one-off flag or a sustained pattern from a new network?
Cross-reference logs-google_workspace.token for event.action: "authorize" events from the same user.email immediately following the suspicious sign-in. An OAuth grant minted seconds after a Google-flagged sign-in is the AiTM kit signature.
Cross-reference logs-google_workspace.device for DEVICE_REGISTER_UNREGISTER_EVENT with account_state: "REGISTERED" near the same time. New device registration paired with is_suspicious is high-fidelity compromise.
Confirm with the user whether the sign-in was theirs.

False positive analysis

Travelers, VPN users, new-device sign-ins, and users returning from leave will all trip Google’s risk engine occasionally.
Building-block signals are not tuned for false-positive minimization at the source; they trade noise for coverage. Combine with other signals before treating as actionable.

Response and remediation

This rule does not generate user-facing alerts by default. Use it as enrichment for higher-level correlation rules.
If a correlation surfaces this signal alongside other indicators (atypical ASN, atypical country, OAuth grant, device registration), follow the response steps in those rules.

Setup

edit

Setup

Important Information Regarding Google Workspace Event Lag Times

Google Workspace Reports API ingestion lag commonly runs in the 30-minute to 3-hour range. This rule’s 130-minute lookback gives partial coverage but will miss events delayed beyond that envelope.
See https://support.google.com/a/answer/7061566 for Google’s published guidance on event availability.
Check your integration’s Login lag time to ensure it is configured to meet the needs of this rule.

Rule query

edit

data_stream.dataset: "google_workspace.login" and
    event.provider: "login" and
    google_workspace.login.is_suspicious: true

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Initial Access
- ID: TA0001
- Reference URL: https://attack.mitre.org/tactics/TA0001/
Technique:
- Name: Valid Accounts
- ID: T1078
- Reference URL: https://attack.mitre.org/techniques/T1078/
Sub-technique:
- Name: Cloud Accounts
- ID: T1078.004
- Reference URL: https://attack.mitre.org/techniques/T1078/004/
Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Steal Application Access Token
- ID: T1528
- Reference URL: https://attack.mitre.org/techniques/T1528/
Technique:
- Name: Adversary-in-the-Middle
- ID: T1557
- Reference URL: https://attack.mitre.org/techniques/T1557/

« Google Workspace Drive Encryption Key(s) Accessed from Anonymous User Google Workspace MFA Enforcement Disabled »