Attack technique
Technique name: Google Workspace Domain-Wide-Delegation on GCP Service Account
MITRE ATT&CK:
- Tactic: Persistence
- Technique: Modify Authentication Process (T1556)
Technique description:
Domain-Wide Delegation in Google Workspace is a feature that allows OAuth application or GCP service account to act on behalf of users to access data across the GCP & Google Workspace ecosystem. The feature is designed for applications that need to interact with Google APIs or any service that requires user impersonation.
The feature can potentially be abused as a persistence backdoor with the creation of a delegation config to a custom GCP service account key. With its ability to impersonate any user, a malicious service account can access sensitive data or execute unauthorized actions across the Google Workspace domain. In essence, this means that, with adequate access to key SaaS APIs like Gmail and Google Drive, an attacker could gain access to almost any data within the Google Workspace environment. Notably, this could occur almost undetected as the service account takes on the guise of the user without needing the user's login details. This makes the actions taken by the account appear in logs and records under the identity of the targeted user.
Threat hunting theses breakdown
Delegate domain-wide configuration authority to GCP Service accounts
Relevant data sources:
Google Workspace Audit Logs
Optional: GCP Audit Logs (threat hunting enrichment)
Thesis explanation:
The thesis looks for a creation and update of domain delegation event AUTHORIZE_API_CLIENT_ACCESS in Google Workspace admin logs and focuses on GCP service account identities by identifying the target application as an integer. Given that the AUTHORIZE_API_CLIENT_ACCESS event in Google Workspace doesn't contain details on the target service account rather than the OAuth client ID, the thesis performs a cross-correlation with the related GCP events to gather information on the relevant GCP Service Account details, such the attached GCP Project and key creation events.
Blind spots:
Backdoored Google Workspace application from the Google Marketplace (less likely to happen as Google has an in-depth approval process review for Marketplace applications).
Recommended investigation flow:
- Look into the creation time of the GCP Service Account private key (for instance, older keys are less suspicious).
- Investigate the actor email who created the delegation configuration.
- Investigate the service account by correlating the OAuth ID to the GCP service logs.
- Investigate the IP which created the GCP Service Account key (this is crucial as the delegating IP isn't recorded in Google Workspace logs).
- Investigate the user who created the GCP Service Account key.
- Examine the IP address linked to the authentication session of the Google Workspace super admin who created the delegation rule.
- Investigate the API calls made by the Service Account delegation.
- What API calls is it making, and to which Rest API applications?
- Investigate the target user identity which the API call made on his behalfInvestigate the target Google
- Workspace user associated with these API requests
- Do the API calls happen repetitively on the same identities? Is the target identity an employee or a generic user account?
- Review the OAuth scopes attached to the identity object (eg: read-only, edit, administration)
Hunting queries
https://gist.github.com/axon-git/29e0c7e014b9ea1068b6eadbb7a74037
Hunters content
Detection: Google Workspace Delegation Configuration Created or Updated on GCP Service Account
Automatic investigation: GCP Service Account Key Creations Events
Scoring model: Google Workspace Delegation Configuration Scoring Model