Google Workspace Device Registration Burst for Single User

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

Google Workspace Device Registration Burst for Single User

edit

Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt.

Rule type: esql

Rule indices: None

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (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 Device Logs
  • Use Case: Threat Detection
  • Use Case: Identity and Access Audit
  • Tactic: Persistence
  • Tactic: Initial Access
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 2

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Google Workspace Device Registration Burst for Single User

DEVICE_REGISTER_UNREGISTER_EVENT from the Google Workspace mobile provider does not represent a one-time physical device enrollment. The Reports API emits a fresh google_workspace.device.id on every session/sync registration, and a single physical device can produce multiple events per day as Workspace-aware apps independently attest. Legitimate activity, however, very rarely concentrates three or more distinct device IDs into a one-minute window for a single user. A burst of that shape is the fingerprint of either:

  • An AiTM phishing-kit relay session: the kit completes the victim’s sign-in against Google, then attests one or more device contexts of its own, all from the same kit infrastructure within seconds.
  • Token-replay tooling driving multiple sessions in quick succession against a stolen OAuth refresh token.

In both cases the device fingerprint (OS, model) typically converges on a single value distinct from the victim’s baseline (e.g., all "Windows" attestations for a known macOS user), and the burst events fire within a few seconds of each other rather than spread across minutes.

Possible investigation steps

  • Identify the user (user.email, user.id) and inspect Esql.host_os_version_values, Esql.device_type_values, Esql.device_model_values. A homogeneous fingerprint (single OS, single model) across multiple device IDs in the burst window is highly suspicious.
  • Cross-reference logs-google_workspace.login for event.action: "login_success" events from the same user.email in the 30 minutes preceding the burst. The kit-relay sign-ins should appear there. Inspect each sign-in’s source.geo.country_name, source.as.organization.name, and user_agent.original for divergence from the user’s baseline. Hosting-provider ASNs (Clouvider, Host Telecom, OVH, Alibaba, Vultr, DigitalOcean, M247) for interactive sign-ins are high-fidelity suspicious.
  • Cross-reference logs-google_workspace.token for event.action: "authorize" events for the same user near the burst window. Each kit relay normally fires a corresponding OAuth grant within seconds, often to Google Chrome (77185425430.apps.googleusercontent.com) or another long-lived first-party client.
  • Pull all logs-google_workspace.device events for the user across the 24 hours preceding the burst to characterize the user’s normal device-event rate. A user who typically produces less than 1 event per hour suddenly emitting 3+ in a minute is a strong anomaly even before considering device fingerprints.
  • Confirm with the user whether they were performing a new device setup, OS upgrade, or onboarding activity during the burst window.

False positive analysis

  • New device setup where a user simultaneously enrolls multiple Workspace-aware apps (Gmail, Drive, Calendar, Meet) on first boot can produce a burst. Validate by checking whether the burst coincides with a known device refresh or onboarding event.
  • Major OS upgrades that re-attest several apps concurrently can also produce a burst. The host OS version values will reflect the upgrade transition.
  • Bulk MDM rollouts or fleet refreshes may produce bursts across many users at the same time. Consider rule suppression during planned rollouts.

Response and remediation

  • Treat as likely AiTM compromise or token-replay activity until proven otherwise. Suspend the user, revoke all OAuth tokens (DELETE /admin/directory/v1/users/<email>/tokens/<clientId>), reset the password, clear recovery email/phone, sign out all sessions.
  • Audit logs-google_workspace.token: authorize events for kit-issued or replay-issued OAuth grants. Each grant maps to an independently replayable refresh token; revoking via the consent removes them all at once.
  • Audit the device IDs surfaced in the burst via the Admin SDK Directory API and remove any that are confirmed adversary-controlled.
  • If the tenant exposes GCP resources to the user, cross-check logs-gcp.audit-* for authenticationInfo.principalEmail matching the user from a non-baseline callerIp in the same window; token theft frequently extends to cross-cloud access.

Rule query

edit
from logs-google_workspace.device-*
| where event.dataset == "google_workspace.device"
    and event.action == "DEVICE_REGISTER_UNREGISTER_EVENT"
    and google_workspace.device.account_state == "REGISTERED"
    and user.email is not null
    and google_workspace.device.id is not null

| eval Esql.bucket_minute = date_trunc(1 minute, @timestamp)

| stats
        Esql.count_distinct_device_id = count_distinct(google_workspace.device.id),
        Esql.device_id_values = values(google_workspace.device.id),
        Esql.device_resource_id_values = values(google_workspace.device.resource.id),
        Esql.device_type_values = values(google_workspace.device.type),
        Esql.device_model_values = values(google_workspace.device.model),
        Esql.device_account_state_values = values(google_workspace.device.account_state),
        Esql.host_os_version_values = values(host.os.version),
        Esql.event_provider_values = values(event.provider),
        Esql.event_id_values = values(event.id),
        Esql.google_workspace_actor_type_values = values(google_workspace.actor.type),
        Esql.google_workspace_event_type_values = values(google_workspace.event.type),
        Esql.organization_id_values = values(organization.id),
        Esql.user_domain_values = values(user.domain),
        Esql.timestamp_first_seen = min(@timestamp),
        Esql.timestamp_last_seen = max(@timestamp),
        Esql.event_count = count(*)
    by user.id, user.email, user.name, Esql.bucket_minute

| where Esql.count_distinct_device_id >= 3

| keep user.id,
        user.email,
        user.name,
        Esql.bucket_minute,
        Esql.timestamp_first_seen,
        Esql.timestamp_last_seen,
        Esql.count_distinct_device_id,
        Esql.event_count,
        Esql.device_id_values,
        Esql.device_resource_id_values,
        Esql.device_type_values,
        Esql.device_model_values,
        Esql.device_account_state_values,
        Esql.host_os_version_values,
        Esql.event_provider_values,
        Esql.event_id_values,
        Esql.google_workspace_actor_type_values,
        Esql.google_workspace_event_type_values,
        Esql.organization_id_values,
        Esql.user_domain_values

Framework: MITRE ATT&CKTM