This rule detects when a Google Workspace user authenticates from a device type that has not been observed for that user in the prior 14 days. It relies on google_workspace.device fields in the logs-google_workspace.device* stream to identify a new device-type per user, not a one-time physical device enrollment. The distinction matters because the Google Reports API emits a fresh google_workspace.device.id on each event, so a single physical device can generate multiple entries. A divergence in device type is a high-fidelity signal of potential compromise, since adversaries who use tactics like AiTM kits or stolen OAuth tokens may relay sessions from device types that differ from the user’s baseline (e.g., a Windows session for a macOS user, or simultaneous Windows and macOS sessions). Because OAuth tokens can remain valid after password rotation, token revocation is the appropriate remediation beyond credential reset. The rule is triggered by a term-based condition that flags events where the user’s email and a new device.type appear, with a lookback/history window of 14 days. The detection looks at the device type, and surfaces fields such as google_workspace.device.type, google_workspace.device.model, google_workspace.device.id, and google_workspace.device.resource.id along with user.email to enable rapid triage. ### Investigation goals - Identify the affected user and the device type that triggered the alert. - Compare the registered device type against the user’s known baseline (and, if available, device model and OS). - Review sign-in activity for the same user in the 24 hours prior to the device registration, including geo, ASN, user_agent, and any anomalies in authentication flow. - Check for nearby token events (e.g., authorize actions) and any cross-cloud access indicators in logs-gcp.audit or similar sources. - Confirm whether the device registration is expected (new hardware, BYOD, or an IT rollout) or unexpected. ### False positives - Legitimate first-time device enrollment (new corporate or personal device). - Planned MDM or fleet rollout campaigns that register many devices of the same type within a short window. - Users who legitimately use multiple device types and only recently enrolled a specific type outside prior lookback. ### Response and remediation - If unexpected: treat as compromise. Immediately suspend the user, revoke OAuth tokens for the affected client IDs, reset the password, and clear recovery methods. - Remove attacker-controlled device via Admin SDK (device removal) and ensure the device cannot reauthenticate. - Audit mailbox, Drive, and Calendar activity for unauthorized access or exfiltration. - Cross-check logs-gcp.audit or other cloud audit trails for corroborating evidence of token theft or cross-cloud access. ### MITRE ATT&CK alignment - T1098.005 Device Registration under T1098 (Account Manipulation) and related persistence signals. - T1078 Cloud Accounts under Initial Access, reflecting use of cloud-stored credentials to gain access from alternate device types. ### Data and scope - Data sources: primarily Google Workspace Cloud Service data (google_workspace.device logs) with supporting signals from login/token activities. - Lookback: 14 days for device-type baselining; immediate look at the current event window for correlating signs of credential abuse. - Name: Google Workspace User Sign-in from Atypical Device Type.