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 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 User Sign-in from Atypical Device Type
- Google Workspace User Login with Unusual ASN
- Entra ID Kali365 Default User-Agent Detected
- Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource
- Entra ID OAuth User Impersonation to Microsoft Graph