GWS - Google Platforms Phishing
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Offensichtlich können Mitglieder in der Workspace standardmäßig Gruppen erstellen und Personen einladen. Du kannst dann die E-Mail, die an den Benutzer gesendet wird, mit einigen Links ändern. Die E-Mail wird von einer Google-Adresse kommen, sodass sie legitim aussieht und die Leute möglicherweise auf den Link klicken.
Es ist auch möglich, die FROM-Adresse als die Google-Gruppen-E-Mail festzulegen, um mehr E-Mails an die Benutzer innerhalb der Gruppe zu senden, wie im folgenden Bild, wo 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).
Du könntest entweder einen Chat mit einer Person beginnen, indem du nur ihre E-Mail-Adresse hast, oder eine Einladung zum Gespräch senden. Darüber hinaus ist es möglich, einen Space zu erstellen, der jeden Namen haben kann (z.B. "Google Support") und Mitglieder dazu einzuladen. Wenn sie akzeptieren, könnten sie denken, dass sie mit dem Google Support sprechen:
In meinen Tests haben die eingeladenen Mitglieder jedoch nicht einmal eine Einladung erhalten.
Du kannst überprüfen, wie das in der Vergangenheit funktioniert hat: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s
Früher war es möglich, ein anscheinend legitimes Dokument zu erstellen und in einem Kommentar eine E-Mail zu erwähnen (wie @user@gmail.com). Google sendete eine E-Mail an diese E-Mail-Adresse, um zu benachrichtigen, dass sie im Dokument erwähnt wurden. Heutzutage funktioniert das nicht mehr, aber wenn du dem Opfer E-Mail-Zugriff auf das Dokument gibst, wird Google eine E-Mail senden, die darauf hinweist. Dies ist die Nachricht, die erscheint, wenn du jemanden erwähnst:
Opfer könnten Schutzmechanismen haben, die verhindern, dass E-Mails, die darauf hinweisen, dass ein externes Dokument mit ihnen geteilt wurde, ihre E-Mail erreichen.
Du kannst ein Kalenderevent erstellen und so viele E-Mail-Adressen des Unternehmens, das du angreifst, hinzufügen, wie du hast. Plane dieses Kalenderevent in 5 oder 15 Minuten von der aktuellen Zeit. Lass das Event legitim aussehen und füge einen Kommentar und einen Titel hinzu, der darauf hinweist, dass sie etwas lesen müssen (mit dem Phishing-Link).
Dies ist die Warnung, die im Browser mit dem Meeting-Titel "Leute entlassen" erscheinen wird, sodass du einen phishinger Titel festlegen könntest (und sogar den Namen ändern, der mit deiner E-Mail verbunden ist).
Um es weniger verdächtig aussehen zu lassen:
Richte es so ein, dass Empfänger die anderen eingeladenen Personen nicht sehen können
Sende keine E-Mails, die über das Event benachrichtigen. Dann werden die Leute nur ihre Warnung über ein Meeting in 5 Minuten sehen und dass sie diesen Link lesen müssen.
Offensichtlich kannst du über die API einstellen, dass die Personen das Event akzeptiert haben und sogar Kommentare in ihrem Namen erstellen.
Es ist möglich, ein Skript in https://script.google.com/ zu erstellen und es als Webanwendung zu exponieren, die für jeden zugänglich ist, die die legitime Domain script.google.com verwendet.
Mit etwas Code wie dem folgenden könnte ein Angreifer das Skript dazu bringen, beliebige Inhalte auf dieser Seite zu laden, ohne die Domain zu stoppen:
Zum Beispiel, wenn Sie https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec aufrufen, sehen Sie:
Beachten Sie, dass eine Warnung erscheint, während der Inhalt in einem iframe geladen wird.
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 weitere Informationen siehe:
GWS - App ScriptsEine der vorherigen Techniken kann verwendet werden, um den Benutzer dazu zu bringen, auf eine Google OAuth-Anwendung zuzugreifen, die den Benutzer um Zugriff bittet. Wenn der Benutzer der Quelle vertraut, könnte er der Anwendung vertrauen (auch wenn sie nach hochprivilegierten Berechtigungen fragt).
Beachten Sie, dass Google in mehreren Fällen eine hässliche Aufforderung anzeigt, die warnt, dass die Anwendung nicht vertrauenswürdig ist, und Workspace-Administratoren können sogar verhindern, dass Personen OAuth-Anwendungen akzeptieren.
Google erlaubt es, Anwendungen zu erstellen, die im Namen von Benutzern mit mehreren Google-Diensten interagieren: Gmail, Drive, GCP...
Beim Erstellen einer Anwendung, die im Namen anderer Benutzer agiert, muss der Entwickler eine OAuth-Anwendung innerhalb von GCP erstellen und die Scopes (Berechtigungen) angeben, die die Anwendung benötigt, um auf die Benutzerdaten zuzugreifen. Wenn ein Benutzer diese Anwendung verwenden möchte, wird er aufgefordert, zu akzeptieren, dass die Anwendung Zugriff auf seine in den Scopes angegebenen Daten hat.
Dies ist eine sehr verlockende Möglichkeit, nicht-technische Benutzer dazu zu bringen, Anwendungen zu verwenden, die auf sensible Informationen zugreifen, da sie die Konsequenzen möglicherweise nicht verstehen. In Unternehmenskonten gibt es jedoch Möglichkeiten, dies zu verhindern.
Wie bereits erwähnt, wird Google dem Benutzer immer eine Aufforderung zur Annahme der Berechtigungen anzeigen, die sie der Anwendung in ihrem Namen gewähren. Wenn die Anwendung jedoch als gefährlich eingestuft wird, zeigt Google zuerst eine Aufforderung an, die darauf hinweist, dass sie gefährlich ist und es dem Benutzer schwieriger macht, die Berechtigungen für die App zu gewähren.
Diese Aufforderung erscheint in Apps, die:
Irgendeinen Scope verwenden, der auf private Daten zugreifen kann (Gmail, Drive, GCP, BigQuery...)
Apps mit weniger als 100 Benutzern (bei Apps > 100 ist ein Überprüfungsprozess erforderlich, um die unbestätigte Aufforderung nicht mehr anzuzeigen)
Hier finden Sie eine Liste aller Google OAuth-Scopes.
cloud-platform: Sehen und verwalten Sie Ihre Daten über Google Cloud Platform-Dienste. Sie können den Benutzer in GCP impersonifizieren.
admin.directory.user.readonly: Sehen und laden Sie das GSuite-Verzeichnis Ihrer Organisation herunter. Erhalten Sie Namen, Telefonnummern, Kalender-URLs aller Benutzer.
Beginnen Sie mit der Erstellung einer OAuth-Client-ID
Gehen Sie zu https://console.cloud.google.com/apis/credentials/oauthclient und klicken Sie auf die Konfiguration des Zustimmungsbildschirms.
Dann werden Sie gefragt, ob der Benutzertyp intern (nur für Personen in Ihrer Organisation) oder extern ist. Wählen Sie die Option, die Ihren Bedürfnissen entspricht.
Intern könnte interessant sein, wenn Sie bereits einen Benutzer der Organisation kompromittiert haben und diese App erstellen, um einen anderen zu phishen.
Geben Sie der App einen Namen, eine Support-E-Mail (beachten Sie, dass Sie eine Google-Gruppe-E-Mail festlegen können, um sich ein wenig mehr zu anonymisieren), ein Logo, autorisierte Domains und eine andere E-Mail für Updates.
Wählen Sie die OAuth-Scopes aus.
Diese Seite ist in nicht sensible Berechtigungen, sensible Berechtigungen und eingeschränkte Berechtigungen unterteilt. Jedes Mal, wenn Sie eine neue Berechtigung hinzufügen, wird sie in ihrer Kategorie hinzugefügt. Abhängig von den angeforderten Berechtigungen erscheinen unterschiedliche Aufforderungen für den Benutzer, die darauf hinweisen, wie sensibel diese Berechtigungen sind.
Sowohl admin.directory.user.readonly als auch cloud-platform sind sensible Berechtigungen.
Fügen Sie die Testbenutzer hinzu. Solange der Status der App auf Test steht, können nur diese Benutzer auf die App zugreifen, also stellen Sie sicher, dass Sie die E-Mail hinzufügen, die Sie phishen möchten.
Jetzt lassen Sie uns Anmeldeinformationen für eine Webanwendung mit der zuvor erstellten OAuth-Client-ID abrufen:
Gehen Sie zurück zu https://console.cloud.google.com/apis/credentials/oauthclient, diesmal wird eine andere Option angezeigt.
Wählen Sie Anmeldeinformationen für eine Webanwendung erstellen.
Legen Sie die benötigten JavaScript-Ursprünge und Umleitungs-URIs fest.
Sie können in beiden etwas wie http://localhost:8000/callback für Tests festlegen.
Holen Sie sich Ihre Anwendungs-Anmeldeinformationen.
Schließlich lassen Sie uns eine Webanwendung ausführen, die die Anmeldeinformationen der OAuth-Anwendung verwendet. Ein Beispiel finden Sie unter https://github.com/carlospolop/gcp_oauth_phishing_example.
Gehe zu http://localhost:8000, klicke auf die Schaltfläche "Mit Google anmelden", du wirst mit einer Nachricht wie dieser auffordert:
Die Anwendung zeigt das Zugriffs- und Aktualisierungstoken, die leicht verwendet werden können. Für weitere Informationen darüber, wie man diese Tokens verwendet, siehe:
GCP - Token PersistanceglcoudEs ist möglich, etwas mit gcloud anstelle der Webkonsole zu tun, siehe:
GCP - ClientAuthConfig Priveschttps://www.youtube-nocookie.com/embed/6AsVUS79gLw - Matthew Bryant - Hacking G Suite: Die Macht der dunklen Apps Script Magie
https://www.youtube.com/watch?v=KTVHLolz6cE - Mike Felch und Beau Bullock - OK Google, wie mache ich Red Team GSuite?
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
