« Google Workspace User Login with Unusual ASN Google Workspace Device Registration Burst for Single User »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.25

Google Workspace User Sign-in from Atypical Device Type

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

Google Workspace User Sign-in from Atypical Device Type

edit

Detects the first time a Google Workspace user is observed authenticating from a device of a given type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) within a historical window. Note that "DEVICE_REGISTER_UNREGISTER_EVENT" events do not represent one-time physical device enrollments; the Google Reports API emits a fresh "google_workspace.device.id" on each event, and the same physical device may produce multiple events per day as sessions/sync renewals occur. The rule therefore surfaces a user authenticating from a new device type, not a new physical device. This is still high-fidelity because adversaries who compromise a Workspace identity via AiTM kits or stolen OAuth refresh tokens frequently relay sessions from device types that diverge from the legitimate user’s baseline (e.g., a WINDOWS session appearing for a known macOS user, or simultaneous WINDOWS+MAC sessions within minutes), which is the canonical kit fingerprint. Because the underlying token retains access after password rotation, treat unexpected device-type divergence as a compromise indicator and revoke tokens, not just credentials.

Rule type: new_terms

Rule indices:

  • logs-google_workspace.device*

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
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Google Workspace User Sign-in from Atypical Device Type

This rule emits when a user authenticates from a device whose type (google_workspace.device.type) has not been observed for that user in the prior 14 days.

Important: this is not a true "device enrollment" event. Google’s Reports API emits DEVICE_REGISTER_UNREGISTER_EVENT from the mobile provider on every session/sync registration, with a fresh google_workspace.device.id each time. A single physical device can produce many such events per day. The rule therefore identifies a device-type-per-user anomaly: a session originating from a class of device the user has not been seen on in the prior 14 days, not a one-time physical device join.

The detection value remains high because adversaries who relay sessions via AiTM kits (Tycoon2FA Google variant, EvilGinx phishlets) or who replay stolen OAuth refresh tokens typically egress from device fingerprints that diverge from the victim’s baseline. Two patterns are especially diagnostic:

  • A device type appearing for a user that does not match the user’s known OS (e.g., WINDOWS sessions for a user whose corporate laptop is macOS).
  • Simultaneous WINDOWS+MAC (or similar cross-type) sessions for the same user within a short window, indicating the kit and the victim are active at the same time.

Because the underlying OAuth refresh token continues to grant access after a password reset, password rotation alone does not remediate this; only token revocation does.

Possible investigation steps

  • Identify the user (user.email), the device type (google_workspace.device.type), and the device model and OS (google_workspace.device.model, host.os.version).
  • Compare the registered device type to the user’s known device baseline. A WINDOWS device for a known macOS user, or an ANDROID device for a known iOS user, is a high-confidence adversary signal.
  • Pull all logs-google_workspace.login events for the same user.email in the 24 hours leading up to the device registration. Inspect source.geo.country_name, source.as.organization.name, and user_agent.original for each sign-in. A device registration immediately following a sign-in from a non-baseline ASN (hosting providers, cheap VPS, AiTM kit egress like Clouvider or Host Telecom) is the kit-driven persistence signature.
  • Cross-reference logs-google_workspace.token for event.action: "authorize" events from the same user near the same time. OAuth grants minted around the device registration window indicate the kit has minted additional tokens for the attacker-controlled device.
  • Inspect google_workspace.device.id and google_workspace.device.resource.id for the registered device. Capture both, since device.id is required for the device removal API call during remediation.
  • Confirm with the user whether the device registration is theirs (new hardware, BYOD enrollment) or unexpected.

False positive analysis

  • Legitimate first-time device enrollment for new hardware, BYOD onboarding, or device refresh cycles. Validate by checking IT hardware tickets, onboarding records, or HR.
  • Planned MDM rollouts that register many users' devices in a short window. Consider a temporary rule suppression during scheduled rollouts.
  • Users who legitimately use multiple device types and happened to first enroll a given type outside the lookback window (e.g., always had a personal Android but only just enrolled it in Workspace).

Response and remediation

  • If the device registration is unexpected: treat as compromise. Immediately suspend the user, revoke all OAuth tokens (DELETE /admin/directory/v1/users/<email>/tokens/<clientId>), reset the password, and clear recovery email/phone.
  • Remove the attacker-controlled device via the Admin SDK Directory API: POST /admin/directory/v1/customer/<customerId>/devices/chromeos/<deviceId>/action (or the mobile device variant) to wipe / remove the device.
  • Audit any post-registration mailbox, Drive, and Calendar activity for adversary data access or exfiltration.
  • Cross-check logs-gcp.audit-* if the tenant exposes GCP resources to the user: look for authenticationInfo.principalEmail matching the user from a non-baseline callerIp in the same window, since token theft frequently extends to cross-cloud access.

Rule query

edit
data_stream.dataset: "google_workspace.device" and
event.action: "DEVICE_REGISTER_UNREGISTER_EVENT" and
google_workspace.device.account_state: "REGISTERED" and
google_workspace.device.type: * and
user.email: *

Framework: MITRE ATT&CKTM

« Google Workspace User Login with Unusual ASN Google Workspace Device Registration Burst for Single User »