Wenn es einen google-site-verification-Eintrag gibt, ist es wahrscheinlich, dass es Workspace verwendet hat (oder verwendet):
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"
Wenn etwas wie include:_spf.google.com erscheint, bestätigt es dies (beachten Sie, dass es dies nicht verneint, da eine Domain in Workspace sein kann, ohne Gmail als E-Mail-Anbieter zu verwenden).
Versuchen Sie, ein Workspace mit dieser Domain einzurichten
Eine weitere Option ist, zu versuchen, einen Workspace mit der Domain einzurichten. Wenn es beschwert, dass die Domain bereits verwendet wird (wie im Bild), wissen Sie, dass sie bereits verwendet wird!
Versuchen Sie, das Passwort einer E-Mail mit dieser Domain wiederherzustellen
Wenn Sie eine gültige E-Mail-Adresse kennen, die in dieser Domain verwendet wird (z. B.: admin@email.com oder info@email.com), können Sie versuchen, das Konto unter https://accounts.google.com/signin/v2/recoveryidentifier wiederherzustellen. Wenn kein Fehler angezeigt wird, der darauf hinweist, dass Google keine Ahnung von diesem Konto hat, wird Workspace verwendet.
E-Mails und Dienstkonten auflisten
Es ist möglich, gültige E-Mails einer Workspace-Domain und SA-E-Mails zu auflisten, indem man versucht, ihnen Berechtigungen zuzuweisen und die Fehlermeldungen zu überprüfen. Dazu benötigen Sie lediglich Berechtigungen, um einem Projekt Berechtigungen zuzuweisen (das nur Ihnen gehören kann).
Beachten Sie, dass Sie sie überprüfen können, aber selbst wenn sie existieren, ihnen keine Berechtigung erteilen können. Verwenden Sie den Typ serviceAccount, wenn es sich um einen Benutzer handelt, und Benutzer, wenn es sich um ein SA handelt:
# 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.
Beachten Sie, dass bei einer gültigen Benutzer-E-Mail die Fehlermeldung darauf hinweist, dass der Typ nicht stimmt. So konnten wir feststellen, dass die E-Mail support@hacktricks.xyz existiert, ohne ihr Berechtigungen zu gewähren.
Sie können dasselbe mit Dienstkonten tun, indem Sie den Typ user: anstelle von serviceAccount: verwenden:
# 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.
