GWS - Google Platforms Phishing

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

Generische Phishing-Methodik

Phishing Methodology - HackTricks

Google Groups Phishing

Anscheinend können in workspace Mitglieder standardmäßig Gruppen erstellen und Personen dazu einladen. Du kannst dann die E-Mail, die an den Nutzer gesendet wird, ändern und Links hinzufügen. Die E-Mail wird von einer google-Adresse gesendet, sodass sie legitim wirkt und Personen möglicherweise auf den Link klicken.

Es ist außerdem möglich, die FROM-Adresse als die Google group email zu setzen, um mehr E-Mails an die Nutzer innerhalb der Gruppe zu senden, wie im folgenden Bild, in dem die Gruppe google--support@googlegroups.com erstellt wurde und eine E-Mail an alle Mitglieder der Gruppe gesendet wurde (die ohne Zustimmung hinzugefügt wurden)

Google Chat Phishing

Du kannst vielleicht entweder einen Chat starten mit einer Person, wenn du nur ihre E-Mail-Adresse hast, oder eine Einladung zum Gespräch senden. Außerdem ist es möglich, einen Space zu erstellen, der beliebigen Namen haben kann (z. B. “Google Support”) und Mitglieder einzuladen. Wenn sie annehmen, könnten sie denken, dass sie mit Google Support sprechen:

Tip

Bei meinen Tests haben die eingeladenen Mitglieder jedoch nicht einmal eine Einladung erhalten.

Du kannst sehen, wie das früher funktionierte unter: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s

Google Doc Phishing

In der Vergangenheit war es möglich, ein scheinbar legitimes Dokument zu erstellen und dann in einem Kommentar eine E-Mail zu erwähnen (z. B. @user@gmail.com). Google sende eine E-Mail an diese Adresse und benachrichtigte, dass sie im Dokument erwähnt wurden.
Heutzutage funktioniert das nicht mehr, aber wenn du dem Opfer per E-Mail Zugriff auf das Dokument gewährst, sendet Google eine entsprechende E-Mail. Dies ist die Nachricht, die erscheint, wenn du jemanden erwähnst:

Tip

Opfer könnten Schutzmechanismen haben, die verhindern, dass E-Mails, die anzeigen, dass ein externes Dokument mit ihnen geteilt wurde, ihr Postfach erreichen.

Google Calendar Phishing

Du kannst ein Kalenderereignis erstellen und so viele E-Mail-Adressen der Firma, die du angreifst, hinzufügen, wie du hast. Plane dieses Kalenderereignis auf in 5 oder 15 min ab der aktuellen Zeit. Lass das Ereignis legitim aussehen und füge einen Kommentar und einen Titel hinzu, der anzeigt, dass sie etwas lesen müssen (mit dem phishing link).

Dies ist die Benachrichtigung, die im Browser mit einem Meeting-Titel “Firing People” erscheinen wird, daher könntest du einen eher phishing-ähnlichen Titel wählen (und sogar den Namen, der mit deiner E-Mail verknüpft ist, ändern).

Um es weniger verdächtig wirken zu lassen:

  • Konfiguriere es so, dass Empfänger die anderen eingeladenen Personen nicht sehen können
  • Sende KEINE E-Mails, die über das Ereignis informieren. Dann sehen die Personen nur die Erinnerung an ein Meeting in 5min und dass sie den Link lesen müssen.
  • Anscheinend kann man mit der API auf True setzen, dass Personen das Ereignis akzeptiert haben und sogar Kommentare in ihrem Namen erstellen.

App Scripts Redirect Phishing

Es ist möglich, ein Script auf https://script.google.com/ zu erstellen und es als eine für alle zugängliche Webanwendung freizugeben, die die legitime Domain script.google.com verwendet. Mit etwas Code wie dem folgenden könnte ein Angreifer das Script dazu bringen, beliebige Inhalte auf dieser Seite zu laden, ohne dabei die Domain zu verlassen:

function doGet() {
return HtmlService.createHtmlOutput(
'<meta http-equiv="refresh" content="0;url=https://cloud.hacktricks.wiki/en/pentesting-cloud/workspace-security/gws-google-platforms-phishing/index.html#app-scripts-redirect-phishing">'
).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL)
}

For example accessing https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec you will see:

Tip

Beachte, dass eine Warnmeldung erscheint, da der Inhalt innerhalb eines iframes geladen wird.

App Scripts OAuth Phishing

Es ist möglich, App Scripts zu erstellen, die an Dokumente angehängt sind, um zu versuchen, Zugriff auf das OAuth-Token eines Opfers zu erhalten, für mehr Informationen siehe:

GWS - App Scripts

OAuth Apps Phishing

Jede der vorherigen Techniken könnte verwendet werden, um den Benutzer dazu zu bringen, eine Google OAuth application aufzurufen, die beim Benutzer einige Zugriffsrechte anfordert. Wenn der Benutzer der Quelle vertraut, könnte er der Anwendung vertrauen (auch wenn sie hoch privilegierte Berechtigungen anfordert).

Note

Beachte, dass google in mehreren Fällen eine deutliche Warnung anzeigt, die darauf hinweist, dass die Anwendung untrusted ist, und Workspace-Admins können sogar verhindern, dass Benutzer OAuth-Anwendungen akzeptieren.

Google erlaubt das Erstellen von Anwendungen, die im Namen von Benutzern mit verschiedenen Google-Diensten interagieren können: Gmail, Drive, GCP…

Beim Erstellen einer Anwendung, die im Namen anderer Benutzer handeln soll, muss der Entwickler eine OAuth app innerhalb von GCP erstellen und die scopes (Berechtigungen) angeben, die die App benötigt, um auf die Daten der Benutzer zuzugreifen.
Wenn ein Benutzer diese Anwendung verwenden möchte, wird er dazu aufgefordert, die der Anwendung in den scopes angegebenen Zugriffsrechte zu akzeptieren.

Dies ist eine sehr ergiebige Methode, nicht-technische Benutzer dazu zu bringen, Anwendungen zu verwenden, die auf sensible Informationen zugreifen, da sie die Konsequenzen möglicherweise nicht verstehen. In Organisationen gibt es jedoch Möglichkeiten, dies zu verhindern.

Unverified App prompt

Wie bereits erwähnt, zeigt google dem Benutzer immer eine Aufforderung an, die Berechtigungen zu akzeptieren, die sie der Anwendung in ihrem Namen gewähren. Wenn die Anwendung jedoch als gefährlich eingestuft wird, zeigt google zunächst einen Prompt an, der darauf hinweist, dass sie gefährlich ist und es dem Benutzer erschwert, der Anwendung die Berechtigungen zu gewähren.

Dieser Prompt erscheint bei Apps, die:

  • Any scope verwenden, das auf private Daten zugreifen kann (Gmail, Drive, GCP, BigQuery…)
  • Apps mit weniger als 100 Nutzern (bei Apps > 100 ist außerdem ein Review-Prozess nötig, um das unverified prompt nicht mehr anzuzeigen)

Interesting Scopes

Hier findest du eine Liste aller Google OAuth scopes.

  • cloud-platform: View and manage your data across Google Cloud Platform services. You can impersonate the user in GCP.
  • admin.directory.user.readonly: See and download your organization’s GSuite directory. Get names, phones, calendar URLs of all the users.

Create an OAuth App

Start creating an OAuth Client ID

  1. Go to https://console.cloud.google.com/apis/credentials/oauthclient and click on configure the consent screen.
  2. Then, you will be asked if the user type is internal (only for people in your org) or external. Select the one that suits your needs
  • Internal might be interesting you have already compromised a user of the organization and you are creating this App to phish another one.
  1. Give a name to the app, a support email (note that you can set a googlegroup email to try to anonymize yourself a bit more), a logo, authorized domains and another email for updates.
  2. Select the OAuth scopes.
  • This page is divided in non sensitive permissions, sensitive permissions and restricted permissions. Eveytime you add a new permisison it’s added on its category. Depending on the requested permissions different prompt will appear to the user indicating how sensitive these permissions are.
  • Both admin.directory.user.readonly and cloud-platform are sensitive permissions.
  1. Add the test users. As long as the status of the app is testing, only these users are going to be able to access the app so make sure to add the email you are going to be phishing.

Now let’s get credentials for a web application using the previously created OAuth Client ID:

  1. Go back to https://console.cloud.google.com/apis/credentials/oauthclient, a different option will appear this time.
  2. Select to create credentials for a Web application
  3. Set needed Javascript origins and redirect URIs
  • You can set in both something like http://localhost:8000/callback for testing
  1. Get your application credentials

Finally, lets run a web application that will use the OAuth application credentials. You can find an example in https://github.com/carlospolop/gcp_oauth_phishing_example.

git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example
cd gcp_oauth_phishing_example
pip install flask requests google-auth-oauthlib
python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"

Rufen Sie http://localhost:8000 auf, klicken Sie auf den Login with Google Button, Sie werden mit einer Meldung wie dieser aufgefordert:

Die Anwendung zeigt das access and refresh token, das leicht verwendet werden kann. Für weitere Informationen darüber, wie man diese tokens verwendet, siehe:

GCP - Token Persistence

Verwendung von glcoud

Es ist möglich, Dinge mit gcloud statt über die Webkonsole zu erledigen, siehe:

GCP - ClientAuthConfig Privesc

OAuth-App-Schutz

Standardmäßig ist es so konfiguriert, dass jeder Benutzer innerhalb einer Workspace-Organisation jede OAuth-App mit beliebigen Berechtigungen akzeptieren kann, aber es ist möglich, dies einzuschränken, sodass nur Apps zugelassen werden, die lediglich die für Sign in with Google benötigten Basisinformationen anfordern, oder dass keine Drittanbieter-Apps erlaubt werden.

Außerdem ist es, selbst wenn das Vertrauen in externe Drittanbieter-Apps nicht erlaubt ist, möglich, allen internen Apps (Apps, die innerhalb der Organisation erstellt wurden) zu vertrauen. Dieses Vertrauen ist standardmäßig aktiviert.

OAuth Consent Grant Abuse: Erkennung & Reaktion (Admin Reports)

Wenn ein Benutzer einer OAuth-App die Autorisierung erteilt, zeichnet Google Workspace dies in der Admin Reports OAuth Token Audit Activity (application name token) auf, wobei events.name auf authorize gesetzt ist. Diese Events sind die beste Telemetrie, um consent phishing zu erkennen und die client ID sowie die scopes zu verfolgen, die gewährt wurden.

Wichtige Felder, die aus dem Audit-Event extrahiert werden sollten:

  • id.time, id.customerId
  • actor.email, actor.profileId
  • ipAddress, networkInfo.regionCode, networkInfo.subdivisionCode
  • events[0]['parameters'] values for client_id, app_name, scope, scope_data

Zuerst Baseline (Rauschen reduzieren): Legen Sie ein Inventar der bestehenden client IDs und scopes an und alarmieren Sie bei neuen/seltenen Zustimmungen.

gam all users print tokens todrive

Erkennungs‑ideen (neue/seltene App + riskante Scopes):

  • Alarm auslösen, wenn eine client_id nicht in einer genehmigten allowlist ist und in den letzten X Tagen nicht gesehen wurde (z. B. 90).
  • Alarm auslösen, wenn das gewährte scope hochriskante oder seltene Scopes enthält, insbesondere solche, die Zugriff auf Massendaten oder Auswirkungen auf die Lieferkette ermöglichen, wie:
  • https://mail.google.com/
  • https://www.googleapis.com/auth/gmail.readonly
  • https://www.googleapis.com/auth/drive
  • https://www.googleapis.com/auth/drive.readonly
  • https://www.googleapis.com/auth/chat.messages
  • https://www.googleapis.com/auth/chromewebstore
client_id NOT IN approved_client_ids
AND client_id NOT IN last_seen_90d
AND scope CONTAINS any(high_risk_scopes OR rare_scopes)

Reaktion / Eindämmung:

  • Widerrufe tokens für die bösartige OAuth client ID:
gam all users delete tokens clientId <client_id>
  • Blockiere die OAuth client ID in der Admin Console, indem du der Anwendung den Zugriff auf Google-Daten entziehst.

Threat hunting pivots:

  • Liste externe Apps auf, denen weniger als N Benutzer zugestimmt haben (geringe Verbreitung).
  • Überprüfe App-Namen, Herausgeber, Berechtigungen/Scopes und eindeutige Anwendungs-ID.
  • Achte auf ruhende Apps, die plötzlich riskante Berechtigungen nutzen (mögliche Folgeaktionen wie interne Phishing-Angriffe oder Datendiebstahl).

Gegenmaßnahmen:

  • Beschränke den Zugriff aller Drittanbieter-Apps (nur vom Admin genehmigt).
  • Erlaube eingeschränkten Zugriff, sodass Nutzer nur der grundlegenden “Sign in with Google”-Profilinfo zustimmen können.

Referenzen

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks