Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting

src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md

@@ -9,7 +9,7 @@
 Die domänenweite Delegation von Google Workspace ermöglicht einem Identitätsobjekt, entweder einer **externen App** aus dem Google Workspace Marketplace oder einem internen **GCP-Dienstkonto**, **Daten im gesamten Workspace im Namen von Benutzern zuzugreifen**.
 
 > [!NOTE]
-> Das bedeutet im Grunde, dass **Dienstkonten** innerhalb von GCP-Projekten einer Organisation in der Lage sein könnten, **Workspace-Benutzer** derselben Organisation (oder sogar einer anderen) zu **imitieren**.
+> Das bedeutet im Grunde, dass **Dienstkonten** innerhalb von GCP-Projekten einer Organisation in der Lage sein könnten, **Workspace-Benutzer** derselben Organisation (oder sogar aus einer anderen) zu **imitieren**.
 
 Für weitere Informationen darüber, wie das genau funktioniert, siehe:
 
@@ -28,7 +28,7 @@ Mit einer **Liste aller Dienstkonten**, auf die er **Zugriff** hat, und der List
 
 #### [GCP Generiere Delegationstoken](https://github.com/carlospolop/gcp_gen_delegation_token)
 
-Dieses einfache Skript wird **ein OAuth-Token als delegierter Benutzer generieren**, das Sie dann verwenden können, um auf andere Google APIs mit oder ohne `gcloud` zuzugreifen:
+Dieses einfache Skript wird **ein OAuth-Token als der delegierte Benutzer generieren**, das Sie dann verwenden können, um auf andere Google APIs mit oder ohne `gcloud` zuzugreifen:
 ```bash
 # Impersonate indicated user
 python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>
@@ -41,15 +41,15 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
 Dies ist ein Tool, das den Angriff nach diesen Schritten durchführen kann:
 
 1. **GCP-Projekte auflisten** mit der Resource Manager API.
-2. Über jedes Projektressource iterieren und **GCP-Servicekonto-Ressourcen auflisten**, auf die der ursprüngliche IAM-Benutzer Zugriff hat, indem _GetIAMPolicy_ verwendet wird.
-3. Über **jede Servicekonto-Rolle iterieren** und integrierte, grundlegende und benutzerdefinierte Rollen mit der Berechtigung _**serviceAccountKeys.create**_ auf der Ziel-Servicekonto-Ressource finden. Es sollte beachtet werden, dass die Editor-Rolle diese Berechtigung von Natur aus besitzt.
-4. Einen **neuen `KEY_ALG_RSA_2048`** privaten Schlüssel für jede Servicekonto-Ressource erstellen, die mit der relevanten Berechtigung in der IAM-Richtlinie gefunden wurde.
-5. Über **jedes neue Servicekonto iterieren und ein `JWT`** **Objekt** dafür erstellen, das aus den SA-Privatschlüssel-Anmeldeinformationen und einem OAuth-Bereich besteht. Der Prozess zur Erstellung eines neuen _JWT_ Objekts wird **über alle bestehenden Kombinationen von OAuth-Bereichen** aus der **oauth_scopes.txt** Liste iterieren, um alle Delegationsmöglichkeiten zu finden. Die Liste **oauth_scopes.txt** wird mit allen OAuth-Bereichen aktualisiert, die wir als relevant für den Missbrauch von Workspace-Identitäten erachtet haben.
-6. Die Methode `_make_authorization_grant_assertion` zeigt die Notwendigkeit, einen **Ziel-Workspace-Benutzer** zu deklarieren, der als _subject_ bezeichnet wird, um JWTs unter DWD zu generieren. Auch wenn dies einen spezifischen Benutzer zu erfordern scheint, ist es wichtig zu erkennen, dass **DWD jede Identität innerhalb einer Domain beeinflusst**. Folglich hat die Erstellung eines JWT für **jeden Domainbenutzer** Auswirkungen auf alle Identitäten in dieser Domain, was mit unserer Kombinationen-Zählung übereinstimmt. Einfach ausgedrückt, ein gültiger Workspace-Benutzer reicht aus, um fortzufahren.\
-Dieser Benutzer kann in DeleFriend’s _config.yaml_ Datei definiert werden. Wenn ein Ziel-Workspace-Benutzer noch nicht bekannt ist, erleichtert das Tool die automatische Identifizierung gültiger Workspace-Benutzer, indem es Domainbenutzer mit Rollen auf GCP-Projekten scannt. Es ist wichtig zu beachten (nochmals), dass JWTs domainspezifisch sind und nicht für jeden Benutzer generiert werden; daher zielt der automatische Prozess auf eine einzige eindeutige Identität pro Domain ab.
-7. **Ein neues Bearer-Zugriffstoken auflisten und erstellen** für jedes JWT und das Token gegen die tokeninfo API validieren.
+2. Iterieren Sie über jede Projektressource und **listen Sie die GCP-Servicekontenressourcen** auf, auf die der ursprüngliche IAM-Benutzer Zugriff hat, indem Sie _GetIAMPolicy_ verwenden.
+3. Iterieren Sie über **jede Rolle des Dienstkontos** und finden Sie integrierte, grundlegende und benutzerdefinierte Rollen mit der Berechtigung _**serviceAccountKeys.create**_ auf der Ziel-Dienstkontoressource. Es sollte beachtet werden, dass die Editor-Rolle diese Berechtigung von Natur aus besitzt.
+4. Erstellen Sie einen **neuen `KEY_ALG_RSA_2048`** privaten Schlüssel für jede Dienstkontoressource, die mit der relevanten Berechtigung in der IAM-Richtlinie gefunden wurde.
+5. Iterieren Sie über **jedes neue Dienstkonto und erstellen Sie ein `JWT`** **Objekt** dafür, das aus den SA-Privatschlüssel-Anmeldeinformationen und einem OAuth-Bereich besteht. Der Prozess zur Erstellung eines neuen _JWT_-Objekts wird **alle bestehenden Kombinationen von OAuth-Bereichen** aus der **oauth_scopes.txt**-Liste durchlaufen, um alle Delegationsmöglichkeiten zu finden. Die Liste **oauth_scopes.txt** wird mit allen OAuth-Bereichen aktualisiert, die wir als relevant für den Missbrauch von Workspace-Identitäten erachtet haben.
+6. Die Methode `_make_authorization_grant_assertion` zeigt die Notwendigkeit an, einen **Ziel-Workspace-Benutzer** zu deklarieren, der als _subject_ bezeichnet wird, um JWTs unter DWD zu generieren. Auch wenn dies einen bestimmten Benutzer zu erfordern scheint, ist es wichtig zu erkennen, dass **DWD jede Identität innerhalb einer Domäne beeinflusst**. Folglich hat die Erstellung eines JWT für **jeden Domänenbenutzer** Auswirkungen auf alle Identitäten in dieser Domäne, was mit unserer Kombinationen-Zählung übereinstimmt. Einfach ausgedrückt, ein gültiger Workspace-Benutzer reicht aus, um fortzufahren.\
+Dieser Benutzer kann in DeleFriend’s _config.yaml_ Datei definiert werden. Wenn ein Ziel-Workspace-Benutzer noch nicht bekannt ist, erleichtert das Tool die automatische Identifizierung gültiger Workspace-Benutzer, indem es Domänenbenutzer mit Rollen in GCP-Projekten scannt. Es ist wichtig zu beachten (nochmals), dass JWTs domänenspezifisch sind und nicht für jeden Benutzer generiert werden; daher zielt der automatische Prozess auf eine einzige eindeutige Identität pro Domäne ab.
+7. **Auflisten und erstellen Sie ein neues Bearer-Zugriffstoken** für jedes JWT und validieren Sie das Token gegen die tokeninfo API.
 
-#### [Gitlab's Python-Skript](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
+#### [Gitlabs Python-Skript](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
 
 Gitlab hat [dieses Python-Skript](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp_misc/blob/master/gcp_delegation.py) erstellt, das zwei Dinge tun kann - das Benutzerverzeichnis auflisten und ein neues Administratorkonto erstellen, während es ein JSON mit SA-Anmeldeinformationen und dem Benutzer angibt, den man nachahmen möchte. So würden Sie es verwenden:
 ```bash
@@ -93,7 +93,7 @@ Die OAuth SA-ID ist global und kann für **Cross-Organizational Delegation** ver
 
 ### Erstellen eines Projekts zur Aufzählung von Workspace
 
-Standardmäßig haben Workspace-Benutzer die Berechtigung, **neue Projekte zu erstellen**, und wenn ein neues Projekt erstellt wird, erhält der **Ersteller die Rolle Owner** über dieses.
+Standardmäßig haben Workspace-Benutzer die Berechtigung, **neue Projekte zu erstellen**, und wenn ein neues Projekt erstellt wird, erhält der **Ersteller die Rolle Owner** über dieses Projekt.
 
 Daher kann ein Benutzer **ein Projekt erstellen**, die **APIs aktivieren**, um Workspace in seinem neuen Projekt aufzulisten, und versuchen, es zu **enumerieren**.
 
@@ -127,7 +127,7 @@ gcloud beta identity groups preview --customer <org-cust-id>
 Sie finden weitere Informationen zum `gcloud`-Anmeldefluss in:
 
 {{#ref}}
-../gcp-persistence/gcp-non-svc-persistance.md
+../gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
 Wie dort erklärt, kann gcloud den Scope **`https://www.googleapis.com/auth/drive`** anfordern, der es einem Benutzer ermöglichen würde, auf das Laufwerk des Benutzers zuzugreifen.\
@@ -135,7 +135,7 @@ Als Angreifer, wenn Sie den Computer eines Benutzers **physisch** kompromittiert
 ```bash
 gcloud auth login --enable-gdrive-access
 ```
-Wenn ein Angreifer den Computer eines Benutzers kompromittiert, könnte er auch die Datei `google-cloud-sdk/lib/googlecloudsdk/core/config.py` ändern und in die **`CLOUDSDK_SCOPES`** den Scope **`'https://www.googleapis.com/auth/drive'`** hinzufügen:
+Wenn ein Angreifer den Computer eines Benutzers kompromittiert, könnte er auch die Datei `google-cloud-sdk/lib/googlecloudsdk/core/config.py` ändern und im **`CLOUDSDK_SCOPES`** den Scope **`'https://www.googleapis.com/auth/drive'`** hinzufügen:
 
 <figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
 
@@ -152,7 +152,7 @@ Wenn ein Angreifer vollständigen Zugriff auf GWS hat, kann er auf Gruppen mit p
 
 ### Google Groups Privilegieneskalation
 
-Standardmäßig können Benutzer **frei in Workspace-Gruppen der Organisation beitreten**, und diese Gruppen **könnten GCP-Berechtigungen** zugewiesen haben (prüfen Sie Ihre Gruppen in [https://groups.google.com/](https://groups.google.com/)).
+Standardmäßig können Benutzer **frei in Workspace-Gruppen der Organisation beitreten**, und diese Gruppen **könnten GCP-Berechtigungen** zugewiesen haben (überprüfen Sie Ihre Gruppen in [https://groups.google.com/](https://groups.google.com/)).
 
 Durch den Missbrauch der **google groups privesc** könnten Sie in der Lage sein, zu einer Gruppe mit einer Art von privilegiertem Zugriff auf GCP zu eskalieren.
 

src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md

@@ -30,7 +30,7 @@ Sie können überprüfen, wie das in der Vergangenheit funktioniert hat: [https:
 ## Google Doc Phishing
 
 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 Sie **dem Opfer E-Mail-Zugriff auf das Dokument geben**, wird Google eine E-Mail senden, die darauf hinweist. Dies ist die Nachricht, die erscheint, wenn Sie jemanden erwähnen:
+Heutzutage funktioniert das nicht mehr, aber wenn Sie **dem Opfer E-Mail-Zugriff auf das Dokument geben**, wird Google eine E-Mail senden, die dies anzeigt. Dies ist die Nachricht, die erscheint, wenn Sie jemanden erwähnen:
 
 <figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
 
@@ -41,11 +41,11 @@ Heutzutage funktioniert das nicht mehr, aber wenn Sie **dem Opfer E-Mail-Zugriff
 
 Sie können **ein Kalenderereignis erstellen** und so viele E-Mail-Adressen des Unternehmens hinzufügen, das Sie angreifen, wie Sie haben. Planen Sie dieses Kalenderereignis in **5 oder 15 Minuten** von der aktuellen Zeit. Lassen Sie das Ereignis legitim aussehen und **setzen Sie einen Kommentar und einen Titel, der darauf hinweist, dass sie etwas lesen müssen** (mit dem **Phishing-Link**).
 
-Dies ist die Warnung, die im Browser mit dem Meeting-Titel "Firing People" erscheint, sodass Sie einen phishinger Titel festlegen könnten (und sogar den Namen ändern, der mit Ihrer E-Mail verbunden ist).
+Dies ist die Warnung, die im Browser mit dem Meeting-Titel "Leute entlassen" erscheint, sodass Sie einen phishinger Titel festlegen könnten (und sogar den Namen ändern, der mit Ihrer E-Mail verbunden ist).
 
 <figure><img src="../../../images/image (8).png" alt=""><figcaption></figcaption></figure>
 
-Um es weniger verdächtig erscheinen zu lassen:
+Um es weniger verdächtig aussehen zu lassen:
 
 - Richten Sie es so ein, dass **Empfänger die anderen eingeladenen Personen nicht sehen können**
 - Senden Sie **KEINE E-Mails, die über das Ereignis benachrichtigen**. Dann sehen die Leute nur ihre Warnung über ein Meeting in 5 Minuten und dass sie diesen Link lesen müssen.
@@ -53,7 +53,7 @@ Um es weniger verdächtig erscheinen zu lassen:
 
 ## App Scripts Redirect Phishing
 
-Es ist möglich, ein Skript in [https://script.google.com/](https://script.google.com/) zu erstellen und **es als Webanwendung bereitzustellen, die für jeden zugänglich ist**, die die legitime Domain **`script.google.com`** verwendet.\
+Es ist möglich, ein Skript in [https://script.google.com/](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:
 ```javascript
 function doGet() {
@@ -79,7 +79,7 @@ gws-app-scripts.md
 
 ## OAuth Apps Phishing
 
-Eine 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 auch der **Anwendung** **vertrauen** (auch wenn sie nach hochprivilegierten Berechtigungen fragt).
+Eine 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).
 
 > [!NOTE]
 > 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.
@@ -87,7 +87,7 @@ Eine der vorherigen Techniken kann verwendet werden, um den Benutzer dazu zu bri
 **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 in 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 Daten hat, die in den Scopes angegeben sind.
+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.
 
@@ -112,20 +112,20 @@ Diese Aufforderung erscheint in Apps, die:
 **Beginnen Sie mit der Erstellung einer OAuth-Client-ID**
 
 1. Gehen Sie zu [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) und klicken Sie auf "Zustimmungsbildschirm konfigurieren".
-2. Dann werden Sie gefragt, ob der **Benutzertyp** **intern** (nur für Personen in Ihrer Organisation) oder **extern** ist. Wählen Sie den aus, der Ihren Bedürfnissen entspricht.
+2. 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.
 3. 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**.
 4. **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. Je nach 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.
-5. **Fügen Sie die Testbenutzer hinzu.** Solange der Status der App "Test" ist, 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.
+5. **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** erhalten:
 
 1. Gehen Sie zurück zu [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), diesmal wird eine andere Option angezeigt.
 2. Wählen Sie **Anmeldeinformationen für eine Webanwendung erstellen**.
-3. Legen Sie die benötigten **JavaScript-Origins** und **Umleitungs-URIs** fest.
-- Sie können in beiden etwas wie **`http://localhost:8000/callback`** für Tests festlegen.
+3. Legen Sie die benötigten **JavaScript-Ursprünge** und **Umleitungs-URIs** fest.
+- Sie können in beiden etwas wie **`http://localhost:8000/callback`** zum Testen festlegen.
 4. Holen Sie sich Ihre Anwendungs-**Anmeldeinformationen**.
 
 Schließlich lassen Sie uns **eine Webanwendung ausführen, die die Anmeldeinformationen der OAuth-Anwendung verwendet**. Sie finden ein Beispiel unter [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
@@ -139,10 +139,10 @@ Gehe zu **`http://localhost:8000`**, klicke auf die Schaltfläche "Login with Go
 
 <figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
 
-Die Anwendung zeigt das **Zugriffs- und Aktualisierungstoken**, das leicht verwendet werden kann. Für weitere Informationen darüber, **wie man diese Tokens verwendet, siehe**:
+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**:
 
 {{#ref}}
-../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
+../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
 #### Verwendung von `glcoud`
@@ -156,6 +156,6 @@ Es ist möglich, etwas mit gcloud anstelle der Webkonsole zu tun, siehe:
 ## Referenzen
 
 - [https://www.youtube-nocookie.com/embed/6AsVUS79gLw](https://www.youtube-nocookie.com/embed/6AsVUS79gLw) - Matthew Bryant - Hacking G Suite: The Power of Dark Apps Script Magic
-- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch und Beau Bullock - OK Google, wie mache ich Red Team GSuite?
+- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch und Beau Bullock - OK Google, How do I Red Team GSuite?
 
 {{#include ../../../banners/hacktricks-training.md}}