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/09/18"
  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    "Noise: Low",
 84    "Performance: Fast",
 85    "Rule Type: ES|QL",
 86    "Platform: Google Workspace",
 87    "Domain: SaaS",
 88]
 89timestamp_override = "event.ingested"
 90type = "esql"
 91
 92query = '''
 93from logs-google_workspace.device-*
 94| where event.dataset == "google_workspace.device"
 95    and event.action == "DEVICE_REGISTER_UNREGISTER_EVENT"
 96    and google_workspace.device.account_state == "REGISTERED"
 97    and user.email is not null
 98    and google_workspace.device.id is not null
 99
100| eval Esql.bucket_minute = date_trunc(1 minute, @timestamp)
101
102| stats
103        Esql.count_distinct_device_id = count_distinct(google_workspace.device.id),
104        Esql.device_id_values = values(google_workspace.device.id),
105        Esql.device_resource_id_values = values(google_workspace.device.resource.id),
106        Esql.device_type_values = values(google_workspace.device.type),
107        Esql.device_model_values = values(google_workspace.device.model),
108        Esql.device_account_state_values = values(google_workspace.device.account_state),
109        Esql.host_os_version_values = values(host.os.version),
110        Esql.event_provider_values = values(event.provider),
111        Esql.event_id_values = values(event.id),
112        Esql.google_workspace_actor_type_values = values(google_workspace.actor.type),
113        Esql.google_workspace_event_type_values = values(google_workspace.event.type),
114        Esql.organization_id_values = values(organization.id),
115        Esql.user_domain_values = values(user.domain),
116        Esql.timestamp_first_seen = min(@timestamp),
117        Esql.timestamp_last_seen = max(@timestamp),
118        Esql.event_count = count(*)
119    by user.id, user.email, user.name, Esql.bucket_minute
120
121| where Esql.count_distinct_device_id >= 3
122
123| keep user.id,
124        user.email,
125        user.name,
126        Esql.bucket_minute,
127        Esql.timestamp_first_seen,
128        Esql.timestamp_last_seen,
129        Esql.count_distinct_device_id,
130        Esql.event_count,
131        Esql.device_id_values,
132        Esql.device_resource_id_values,
133        Esql.device_type_values,
134        Esql.device_model_values,
135        Esql.device_account_state_values,
136        Esql.host_os_version_values,
137        Esql.event_provider_values,
138        Esql.event_id_values,
139        Esql.google_workspace_actor_type_values,
140        Esql.google_workspace_event_type_values,
141        Esql.organization_id_values,
142        Esql.user_domain_values
143'''
144
145
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148[[rule.threat.technique]]
149id = "T1098"
150name = "Account Manipulation"
151reference = "https://attack.mitre.org/techniques/T1098/"
152[[rule.threat.technique.subtechnique]]
153id = "T1098.005"
154name = "Device Registration"
155reference = "https://attack.mitre.org/techniques/T1098/005/"
156
157
158
159[rule.threat.tactic]
160id = "TA0003"
161name = "Persistence"
162reference = "https://attack.mitre.org/tactics/TA0003/"
163[[rule.threat]]
164framework = "MITRE ATT&CK"
165[[rule.threat.technique]]
166id = "T1078"
167name = "Valid Accounts"
168reference = "https://attack.mitre.org/techniques/T1078/"
169[[rule.threat.technique.subtechnique]]
170id = "T1078.004"
171name = "Cloud Accounts"
172reference = "https://attack.mitre.org/techniques/T1078/004/"
173
174
175
176[rule.threat.tactic]
177id = "TA0001"
178name = "Initial Access"
179reference = "https://attack.mitre.org/tactics/TA0001/"
180[[rule.threat]]
181framework = "MITRE ATT&CK"
182[[rule.threat.technique]]
183id = "T1557"
184name = "Adversary-in-the-Middle"
185reference = "https://attack.mitre.org/techniques/T1557/"
186
187
188[rule.threat.tactic]
189id = "TA0006"
190name = "Credential Access"
191reference = "https://attack.mitre.org/tactics/TA0006/"
192
193[rule.investigation_fields]
194field_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