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 inspectEsql.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.loginforevent.action: "login_success"events from the sameuser.emailin the 30 minutes preceding the burst. The kit-relay sign-ins should appear there. Inspect each sign-in'ssource.geo.country_name,source.as.organization.name, anduser_agent.originalfor 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.tokenforevent.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.deviceevents 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: authorizeevents 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-*forauthenticationInfo.principalEmailmatching the user from a non-baselinecallerIpin the same window; token theft frequently extends to cross-cloud access.
References
Related rules
- Google Workspace Impossible Travel Login
- Google Workspace User Sign-in from Atypical Device Type
- Google Workspace Device Registration After OAuth from Suspicious ASN
- Google Workspace User Login with Unusual ASN
- Azure Key Vault Excessive Secret or Key Retrieved