Google_workspace — CraftedSignal Threat Feed

Google Workspace Drive Data Transfer or Takeout Export Initiated

hello@craftedsignal.io — Thu, 28 May 2026 15:40:55 +0000

The Google Workspace environment allows administrators to perform bulk data transfers of user Drive files to other in-domain accounts, as well as create Customer Takeout exports that package user or organizational data for download or transfer to external destinations. An adversary with compromised administrator credentials may abuse these features to collect sensitive files without needing to modify per-file sharing permissions. This activity is often conducted during the collection and exfiltration phases of an attack. The rule detects CREATE_DATA_TRANSFER_REQUEST events with Drive application scope and CUSTOMER_TAKEOUT_CREATED events within Google Workspace admin logs, providing visibility into potential data theft by malicious insiders or external attackers who have gained administrative privileges. Defenders should investigate any unexpected data transfer or takeout export activities to determine their legitimacy and potential impact.

Attack Chain

An attacker gains unauthorized access to a Google Workspace administrator account, potentially through credential compromise or phishing.
The attacker authenticates to the Google Workspace Admin console using the compromised credentials.
The attacker initiates a data transfer request to reassign a user’s Drive files to another account within the same Google Workspace domain using CREATE_DATA_TRANSFER_REQUEST.
Alternatively, the attacker initiates a Customer Takeout export job (CUSTOMER_TAKEOUT_CREATED) to package organizational data for download. This may involve specifying a Google-provided bucket or a customer-owned Cloud Storage location.
The Google Workspace system processes the data transfer or export request.
For data transfer requests, the designated target account receives ownership or access to the transferred files.
For Customer Takeout exports, the data is packaged into an archive.
The attacker downloads the archive from the designated storage location or accesses the data through the target account, achieving exfiltration or staging of sensitive data.

Impact

A successful attack could result in the exfiltration of sensitive company data, intellectual property, or personal information stored within Google Drive. The number of affected users depends on the scope of the data transfer or takeout export. Targeted sectors could vary depending on the nature of the compromised administrator account and the data it has access to. The damage could include financial loss, reputational damage, legal liabilities, and compromise of competitive advantages.

Recommendation

Deploy the Sigma rule “Google Workspace Drive Data Transfer or Takeout Export Initiated” to your SIEM to detect suspicious data transfer or takeout export activities.
Review admin logs for involved user accounts as described in the rule’s “Possible investigation steps” section.
For Customer Takeout events, pivot on google_workspace.admin.OBFUSCATED_CUSTOMER_TAKEOUT_REQUEST_ID in Elasticsearch to find related admin events for the same export job.
Implement security best practices outlined by Google to prevent credential compromise and unauthorized access to administrator accounts as referenced in the Google security best practices reference.
Monitor the user.email, user.target.email, and google_workspace.admin.new_value fields in the logs to track the initiator, source, and destination users involved in data transfer requests.
Reduce the interval that the Google Workspace Filebeat module polls Google’s reporting API for new events to mitigate event lag times as mentioned in the Setup section.

Google Workspace Device Registration Burst for Single User

hello@craftedsignal.io — Thu, 28 May 2026 14:10:07 +0000

This detection identifies anomalous Google Workspace device registration activity indicative of adversary-in-the-middle (AiTM) phishing or stolen OAuth token replay attacks. The rule focuses on bursts of DEVICE_REGISTER_UNREGISTER_EVENT logs where a single user registers three or more distinct device IDs within a one-minute window. While legitimate session/sync registrations can trigger this event, a high-cardinality burst is rare and suggests malicious activity, such as a phishing kit relaying user sign-ins or token-replay tooling driving multiple sessions against a stolen OAuth refresh token. This activity can lead to account compromise, data exfiltration, and unauthorized access to Google Workspace resources. The rule leverages Google Workspace device logs.

Attack Chain

The attacker initiates a phishing campaign targeting Google Workspace users (T1566).
The victim clicks a malicious link, leading to an AiTM phishing kit or a credential harvesting page (T1566.001).
The attacker relays the victim’s credentials to Google, successfully authenticating and bypassing multi-factor authentication (MFA) if present (T1557).
The attacker’s relay or stolen OAuth token replay tooling registers multiple device contexts in rapid succession, generating multiple DEVICE_REGISTER_UNREGISTER_EVENT logs with distinct google_workspace.device.id values (T1098.005).
The attacker leverages the newly registered devices or replayed tokens to gain persistent access to the victim’s Google Workspace account (T1078.004).
The attacker performs unauthorized actions, such as accessing sensitive data, modifying account settings, or sending malicious emails (T1530).

Impact

Successful exploitation can lead to account compromise, unauthorized access to sensitive data within Google Workspace, and potential business email compromise (BEC). The attacker could exfiltrate data, modify account settings, or use the compromised account to further propagate attacks within the organization. The impact is magnified if the compromised user has elevated privileges or access to critical resources.

Recommendation

Deploy the provided Sigma rule Detect Google Workspace Device Registration Burst for Single User to detect suspicious bursts of device registrations (Log Source: Google Workspace Device Logs).
Investigate users triggering the rule, focusing on device fingerprint consistency and preceding login events, as described in the rule’s note section.
Cross-reference logs-google_workspace.login events for successful logins preceding the burst, examining source.geo.country_name, source.as.organization.name, and user_agent.original for anomalies.
Revoke OAuth tokens for affected users (DELETE /admin/directory/v1/users//tokens/) if compromise is suspected, as mentioned in the rule’s note section.

Google Workspace User Sign-in from Atypical Device Type

hello@craftedsignal.io — Thu, 28 May 2026 14:09:50 +0000

This detection rule identifies anomalous Google Workspace device registrations, specifically focusing on deviations from a user’s typical device type. It leverages Google Workspace device logs to detect when a user authenticates from a device type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) that has not been associated with them within a 14-day historical window. The rule does not flag new physical device enrollments, as the Google Reports API generates fresh device IDs on each event. Instead, it highlights situations where an attacker, using compromised credentials obtained through AiTM kits or stolen OAuth tokens, accesses a Workspace account from a device type different from the user’s established pattern. This is a strong indicator of compromise, as these kits often relay sessions through unusual device fingerprints, such as a Windows session for a macOS user, or concurrent sessions from different OS types. Because refresh tokens persist across password resets, focus on token revocation for remediation.

Attack Chain

Attacker compromises a user’s Google Workspace credentials through AiTM phishing or steals an OAuth refresh token.
Attacker uses the stolen credentials or token to authenticate to Google Workspace.
Google Workspace logs a DEVICE_REGISTER_UNREGISTER_EVENT with a new google_workspace.device.id associated with the session.
The attacker accesses Google Workspace resources like Gmail, Drive, or Calendar.
The attacker may create new OAuth tokens for persistence.
The attacker exfiltrates sensitive data.
The attacker may attempt to move laterally to other cloud resources accessible via the compromised account.
The attacker persists by maintaining access through the stolen credentials and newly created OAuth tokens.

Impact

A successful attack can result in unauthorized access to sensitive data within Google Workspace, including emails, documents, and calendar information. Attackers can exfiltrate data, escalate privileges, and potentially move laterally to other cloud resources. The compromise can persist even after a password reset due to the nature of OAuth refresh tokens. Affected sectors depend on the victim organization but may include any industry using Google Workspace.

Recommendation

Deploy the Sigma rule “Google Workspace User Sign-in from Atypical Device Type” to detect anomalous device registrations (rule).
When an atypical device registration is detected, immediately suspend the user, revoke all OAuth tokens, reset the password, and clear recovery email/phone, as detailed in the rule’s “Response and remediation” section.
Investigate logs-google_workspace.login events for the same user in the 24 hours leading up to the device registration, looking for suspicious ASN, country, and user agent patterns, as described in the rule’s “Possible investigation steps” section.
Monitor logs-google_workspace.token events for event.action: "authorize" events around the device registration time to identify newly minted OAuth tokens (rule’s “Possible investigation steps”).