Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The main difference between this way to synchronize users with GCDS is that GCDS is done manually with some binaries you need to download and run while Admin Directory Sync is serverless managed by Google in https://admin.google.com/ac/sync/externaldirectories.
At the moment of this writing this service is in beta and it supports 2 types of synchronization: From Active Directory and from Azure Entra ID:
Active Directory: In order to set this up you need to give access to Google to you Active Directory environment. And as Google only has access to GCP networks (via VPC connectors) you need to create a connector and then make your AD available from that connector by having it in VMs in the GCP network or using Cloud VPN or Cloud Interconnect. Then, you also need to provide credentials of an account with read access over the directory and certificate to contact via LDAPS.
Azure Entra ID: To configure this it's just needed to login in Azure with a user with read access over the Entra ID subscription in a pop-up showed by Google, and Google will keep the token with read access over Entra ID.
Once correctly configured, both options will allow to synchronize users and groups to Workspace, but it won't allow to configure users and groups from Workspace to AD or EntraID.
Other options that it will allow during this synchronization are:
Send an email to the new users to log-in
Automatically change their email address to the one used by Workspace. So if Workspace is using @hacktricks.xyz and EntraID users use @carloshacktricks.onmicrosoft.com, @hacktricks.xyz will be used for the users created in the account.
Select the groups containing the users that will be synced.
Select to groups to synchronize and create in Workspace (or indicate to synchronize all groups).
If you manage to compromise an AD or EntraID you will have total control of the users & groups that are going to be synchronized with Google Workspace. However, notice that the passwords the users might be using in Workspace could be the same ones or not.
When the synchronization happens it might synchronize all the users from AD or only the ones from a specific OU or only the users members of specific groups in EntraID. This means that to attack a synchronized user (or create a new one that gets synchronized) you will need first to figure out which users are being synchronized.
Users might be reusing the password or not from AD or EntraID, but this mean that you will need to compromise the passwords of the users to login.
If you have access to the mails of the users, you could change the Workspace password of an existing user, or create a new user, wait until it gets synchronized an setup the account.
Once you access the user inside Workspace it might be given some permissions by default.
You also need to figure out first which groups are being synchronized. Although there is the possibility that ALL the groups are being synchronized (as Workspace allows this).
Note that even if the groups and memberships are imported into Workspace, the users that aren't synchronized in the users sychronization won't be created during groups synchronization even if they are members of any of the groups synchronized.
If you know which groups from Azure are being assigned permissions in Workspace or GCP, you could just add a compromised user (or newly created) in that group and get those permissions.
There is another option to abuse existing privileged groups in Workspace. For example, the group gcp-organization-admins@<workspace.email> usually has high privileges over GCP.
If the synchronization from, for example EntraID, to Workspace is configured to replace the domain of the imported object with the email of Workspace, it will be possible for an attacker to create the group gcp-organization-admins@<entraid.email> in EntraID, add a user in this group, and wait until the synchronization of all the groups happen.
The user will be added in the group gcp-organization-admins@<workspace.email> escalating privileges in GCP.
Note that Workspace require credentials with read only access over AD or EntraID to synchronize users and groups. Therefore, it's not possible to abuse Google Workspace to perform any change in AD or EntraID. So this isn't possible at this moment.
I also don't know where does Google store the AD credentials or EntraID token and you can't recover them re-configuring the synchronizarion (they don't appear in the web form, you need to give them again). However, from the web it might be possible to abuse the current functionality to list users and groups.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
