Google Workspace Device Registration Burst for Single User

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/05/15"
  3integration = ["google_workspace"]
  4maturity = "production"
  5updated_date = "2026/05/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects bursts of Google Workspace device registration events for the same user, where three or more distinct
 11"google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT"
 12fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity
 13typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint
 14behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay
 15tooling, both of which mint a new session attestation per relay or replay attempt.
 16"""
 17false_positives = [
 18    """
 19    A user simultaneously enrolling multiple Workspace-aware apps on a new device (e.g., first-time setup of Gmail,
 20    Drive, Calendar, and Meet on a new laptop in a short window) may produce three or more distinct device IDs in a
 21    minute. Validate by checking whether the burst is tied to a fresh device or onboarding event.
 22    """,
 23    """
 24    Major OS upgrades or Workspace client refreshes that re-attest several apps concurrently may also produce a burst.
 25    Cross-reference against the user's known device OS transitions.
 26    """,
 27]
 28from = "now-9m"
 29language = "esql"
 30license = "Elastic License v2"
 31name = "Google Workspace Device Registration Burst for Single User"
 32note = """## Triage and analysis
 33
 34### Investigating Google Workspace Device Registration Burst for Single User
 35
 36`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:
 37
 38- 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.
 39- Token-replay tooling driving multiple sessions in quick succession against a stolen OAuth refresh token.
 40
 41In 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.
 42
 43### Possible investigation steps
 44
 45- 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.
 46- 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.
 47- 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.
 48- 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.
 49- Confirm with the user whether they were performing a new device setup, OS upgrade, or onboarding activity during the burst window.
 50
 51### False positive analysis
 52
 53- 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.
 54- Major OS upgrades that re-attest several apps concurrently can also produce a burst. The host OS version values will reflect the upgrade transition.
 55- Bulk MDM rollouts or fleet refreshes may produce bursts across many users at the same time. Consider rule suppression during planned rollouts.
 56
 57### Response and remediation
 58
 59- 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.
 60- 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.
 61- Audit the device IDs surfaced in the burst via the Admin SDK Directory API and remove any that are confirmed adversary-controlled.
 62- 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.
 63"""
 64references = [
 65    "https://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile",
 66    "https://any.run/malware-trends/tycoon/",
 67    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
 68]
 69risk_score = 47
 70rule_id = "bea0589d-c7a4-4dc6-a931-9fecaa8689fb"
 71severity = "medium"
 72tags = [
 73    "Domain: Cloud",
 74    "Domain: Identity",
 75    "Data Source: Google Workspace",
 76    "Data Source: Google Workspace Device Logs",
 77    "Use Case: Threat Detection",
 78    "Use Case: Identity and Access Audit",
 79    "Tactic: Persistence",
 80    "Tactic: Initial Access",
 81    "Tactic: Credential Access",
 82    "Resources: Investigation Guide",
 83]
 84timestamp_override = "event.ingested"
 85type = "esql"
 86
 87query = '''
 88from logs-google_workspace.device-*
 89| where event.dataset == "google_workspace.device"
 90    and event.action == "DEVICE_REGISTER_UNREGISTER_EVENT"
 91    and google_workspace.device.account_state == "REGISTERED"
 92    and user.email is not null
 93    and google_workspace.device.id is not null
 94
 95| eval Esql.bucket_minute = date_trunc(1 minute, @timestamp)
 96
 97| stats
 98        Esql.count_distinct_device_id = count_distinct(google_workspace.device.id),
 99        Esql.device_id_values = values(google_workspace.device.id),
100        Esql.device_resource_id_values = values(google_workspace.device.resource.id),
101        Esql.device_type_values = values(google_workspace.device.type),
102        Esql.device_model_values = values(google_workspace.device.model),
103        Esql.device_account_state_values = values(google_workspace.device.account_state),
104        Esql.host_os_version_values = values(host.os.version),
105        Esql.event_provider_values = values(event.provider),
106        Esql.event_id_values = values(event.id),
107        Esql.google_workspace_actor_type_values = values(google_workspace.actor.type),
108        Esql.google_workspace_event_type_values = values(google_workspace.event.type),
109        Esql.organization_id_values = values(organization.id),
110        Esql.user_domain_values = values(user.domain),
111        Esql.timestamp_first_seen = min(@timestamp),
112        Esql.timestamp_last_seen = max(@timestamp),
113        Esql.event_count = count(*)
114    by user.id, user.email, user.name, Esql.bucket_minute
115
116| where Esql.count_distinct_device_id >= 3
117
118| keep user.id,
119        user.email,
120        user.name,
121        Esql.bucket_minute,
122        Esql.timestamp_first_seen,
123        Esql.timestamp_last_seen,
124        Esql.count_distinct_device_id,
125        Esql.event_count,
126        Esql.device_id_values,
127        Esql.device_resource_id_values,
128        Esql.device_type_values,
129        Esql.device_model_values,
130        Esql.device_account_state_values,
131        Esql.host_os_version_values,
132        Esql.event_provider_values,
133        Esql.event_id_values,
134        Esql.google_workspace_actor_type_values,
135        Esql.google_workspace_event_type_values,
136        Esql.organization_id_values,
137        Esql.user_domain_values
138'''
139
140
141[[rule.threat]]
142framework = "MITRE ATT&CK"
143[[rule.threat.technique]]
144id = "T1098"
145name = "Account Manipulation"
146reference = "https://attack.mitre.org/techniques/T1098/"
147[[rule.threat.technique.subtechnique]]
148id = "T1098.005"
149name = "Device Registration"
150reference = "https://attack.mitre.org/techniques/T1098/005/"
151
152
153
154[rule.threat.tactic]
155id = "TA0003"
156name = "Persistence"
157reference = "https://attack.mitre.org/tactics/TA0003/"
158[[rule.threat]]
159framework = "MITRE ATT&CK"
160[[rule.threat.technique]]
161id = "T1078"
162name = "Valid Accounts"
163reference = "https://attack.mitre.org/techniques/T1078/"
164[[rule.threat.technique.subtechnique]]
165id = "T1078.004"
166name = "Cloud Accounts"
167reference = "https://attack.mitre.org/techniques/T1078/004/"
168
169
170
171[rule.threat.tactic]
172id = "TA0001"
173name = "Initial Access"
174reference = "https://attack.mitre.org/tactics/TA0001/"
175[[rule.threat]]
176framework = "MITRE ATT&CK"
177[[rule.threat.technique]]
178id = "T1557"
179name = "Adversary-in-the-Middle"
180reference = "https://attack.mitre.org/techniques/T1557/"
181
182
183[rule.threat.tactic]
184id = "TA0006"
185name = "Credential Access"
186reference = "https://attack.mitre.org/tactics/TA0006/"
187
188[rule.investigation_fields]
189field_names = ["@timestamp", "user.email", "user.id", "user.name"]

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.

References

Related rules

to-top