Se tiver um registro google-site-verification, é provável que esteja (ou tenha estado) usando o Workspace:
dig txt hacktricks.xyz
[...]
hacktricks.xyz. 3600 IN TXT "google-site-verification=2mWyPXMPXEEy6QqWbCfWkxFTcQhyYdwHrOxee1Yeo-0"
hacktricks.xyz. 3600 IN TXT "google-site-verification=C19PtLcZ1EGyzUYYJTX1Tp6bOGessxzN9gqE-SVKhRA"
hacktricks.xyz. 300 IN TXT "v=spf1 include:usb._netblocks.mimecast.com include:_spf.google.com include:_spf.psm.knowbe4.com include:_spf.salesforce.com include:spf.mandrillapp.com ~all"
Se algo como include:_spf.google.com também aparecer, confirma isso (observe que se não aparecer, não nega, pois um domínio pode estar no Workspace sem usar o gmail como provedor de e-mail).
Tente configurar um Workspace com esse domínio
Outra opção é tentar configurar um Workspace usando o domínio, se reclamar que o domínio já está em uso (como na imagem), você sabe que já está em uso!
Tente recuperar a senha de um e-mail usando esse domínio
Se você souber de qualquer endereço de e-mail válido sendo usado nesse domínio (como: admin@email.com ou info@email.com), você pode tentar recuperar a conta em https://accounts.google.com/signin/v2/recoveryidentifier, e se não mostrar um erro indicando que o Google não tem ideia sobre essa conta, então está usando o Workspace.
Enumerar e-mails e contas de serviço
É possível enumerar e-mails válidos de um domínio do Workspace e e-mails de contas de serviço tentando atribuir permissões a eles e verificando as mensagens de erro. Para isso, você só precisa ter permissões para atribuir permissões a um projeto (que pode ser de sua propriedade).
Observe que para verificá-los, mesmo que existam, sem conceder permissão, você pode usar o tipo serviceAccount quando for um usuário e usuário quando for um SA:
# Try to assign permissions to user 'unvalid-email-34r434f@hacktricks.xyz'# but indicating it's a service accountgcloudprojectsadd-iam-policy-binding<project-controlled-by-you> \--member='serviceAccount:unvalid-email-34r434f@hacktricks.xyz' \--role='roles/viewer'## Response:ERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: User unvalid-email-34r434f@hacktricks.xyz does not exist.
# Now try with a valid emailgcloudprojectsadd-iam-policy-binding<project-controlled-by-you> \--member='serviceAccount:support@hacktricks.xyz' \--role='roles/viewer'# Response:ERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: Principal support@hacktricks.xyz is of type "user". The principal should appear as "user:support@hacktricks.xyz". See https://cloud.google.com/iam/help/members/types for additional documentation.
Observe como, quando o e-mail do usuário era válido, a mensagem de erro indicava que o tipo não é, então conseguimos descobrir que o e-mail support@hacktricks.xyz existe sem conceder a ele nenhum privilégio.
Você pode fazer o mesmo com Contas de Serviço usando o tipo user: em vez de serviceAccount::
# Non existentgcloudprojectsadd-iam-policy-binding<project-controlled-by-you> \--member='serviceAccount:<invalid-sa-name>@<proj-uniq-name>.iam.gserviceaccount.com' \--role='roles/viewer'# ResponseERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: User <invalid-sa-name>@<proj-uniq-name>.iam.gserviceaccount.com does not exist.
# Existentgcloudprojectsadd-iam-policy-binding<project-controlled-by-you> \--member='serviceAccount:<sa-name>@<proj-uniq-name>.iam.gserviceaccount.com' \--role='roles/viewer'# ResponseERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: Principal testing@digital-bonfire-410512.iam.gserviceaccount.com is of type "serviceAccount". The principal should appear as "serviceAccount:testing@digital-bonfire-410512.iam.gserviceaccount.com". See https://cloud.google.com/iam/help/members/types for additional documentation.
