diff --git a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md b/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
index b768ad09f..8b79c67cc 100644
--- a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
+++ b/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
@@ -6,12 +6,12 @@
 
 ### **ドメイン全体の委任の基本**
 
-Google Workspace のドメイン全体の委任は、**外部アプリ**（Google Workspace Marketplace から）または内部の **GCP サービスアカウント** のいずれかのアイデンティティオブジェクトが、**ユーザーに代わって Workspace 全体のデータにアクセスする**ことを可能にします。
+Google Workspace のドメイン全体の委任は、**外部アプリ**（Google Workspace Marketplace から）または内部の **GCP サービスアカウント** のいずれかのアイデンティティオブジェクトが、**ユーザーを代表して Workspace 全体のデータにアクセスする**ことを可能にします。
 
 > [!NOTE]
-> これは基本的に、**GCP プロジェクト内のサービスアカウント**が、同じ組織の **Workspace ユーザー**（または異なる組織のユーザー）を**なりすます**ことができる可能性があることを意味します。
+> これは基本的に、**GCP プロジェクト内のサービスアカウント**が、同じ組織の **Workspace ユーザー**（または異なる組織のユーザー）を **なりすます**ことができる可能性があることを意味します。
 
-これがどのように機能するかの詳細については、次を確認してください：
+これがどのように機能するかについての詳細は、以下を確認してください：
 
 {{#ref}}
 gcp-understanding-domain-wide-delegation.md
@@ -19,12 +19,12 @@ gcp-understanding-domain-wide-delegation.md
 
 ### 既存の委任の侵害
 
-攻撃者が **GCP 上のアクセスを侵害し**、会社の **有効な Workspace ユーザーのメール**（できれば **スーパ管理者**）を知っている場合、彼は **アクセスできるすべてのプロジェクトを列挙し**、**プロジェクトのすべての SA を列挙し**、**アクセスできるサービスアカウントを確認し**、**なりすますことができる各 SA でこれらの手順を繰り返す**ことができます。\
+攻撃者が **GCP 上のアクセスを侵害し**、会社の **有効な Workspace ユーザーのメールアドレス**（できれば **スーパ管理者**）を知っている場合、彼は **アクセスできるすべてのプロジェクトを列挙し**、**プロジェクトのすべての SA を列挙し**、**アクセスできるサービスアカウントを確認し**、**なりすますことができる各 SA でこれらの手順を繰り返す**ことができます。\
 **アクセスできるすべてのサービスアカウントのリスト**と **Workspace** **メールのリスト**を持っている攻撃者は、**各サービスアカウントでユーザーをなりすます**ことを試みることができます。
 
 > [!CAUTION]
-> ドメイン全体の委任を構成する際には、Workspace ユーザーは必要ないため、**有効なユーザーが1人いれば十分で、なりすますために必要です**。\
-> ただし、**なりすまされたユーザーの権限が使用される**ため、スーパ管理者であればすべてにアクセスできるようになります。アクセス権がない場合は無意味です。
+> ドメイン全体の委任を構成する際には、Workspace ユーザーは必要ないため、**有効なユーザーが1人いれば十分で、なりすましに必要です**。\
+> ただし、**なりすましたユーザーの権限が使用される**ため、スーパ管理者であればすべてにアクセスできるようになります。アクセス権がない場合は無意味です。
 
 #### [GCP 生成委任トークン](https://github.com/carlospolop/gcp_gen_delegation_token)
 
@@ -44,9 +44,9 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
 2. 各プロジェクトリソースを反復処理し、初期IAMユーザーがアクセスできる**GCPサービスアカウントリソース**を_**GetIAMPolicy**_を使用して列挙します。
 3. **各サービスアカウントロール**を反復処理し、ターゲットサービスアカウントリソースに対して_**serviceAccountKeys.create**_権限を持つ組み込み、基本、およびカスタムロールを見つけます。Editorロールは本質的にこの権限を持っていることに注意する必要があります。
 4. IAMポリシーで関連する権限が見つかった各サービスアカウントリソースに対して**新しい`KEY_ALG_RSA_2048`**プライベートキーを作成します。
-5. **各新しいサービスアカウントを反復処理し、`JWT`** **オブジェクト**を作成します。このオブジェクトはSAプライベートキーの資格情報とOAuthスコープで構成されています。新しい_**JWT**_オブジェクトを作成するプロセスは、**oauth_scopes.txt**リストからのすべての既存のOAuthスコープの組み合わせを反復処理し、すべての委任の可能性を見つけるために行われます。リスト**oauth_scopes.txt**は、Workspaceアイデンティティを悪用するために関連性があると見なされたすべてのOAuthスコープで更新されます。
-6. `_make_authorization_grant_assertion`メソッドは、DWDの下でJWTを生成するために、_subject_と呼ばれる**ターゲットワークスペースユーザー**を宣言する必要性を明らかにします。これは特定のユーザーを必要とするように見えるかもしれませんが、**DWDはドメイン内のすべてのアイデンティティに影響を与える**ことを理解することが重要です。したがって、**任意のドメインユーザー**のためにJWTを作成することは、そのドメイン内のすべてのアイデンティティに影響を与え、組み合わせ列挙チェックと一致します。簡単に言えば、有効なWorkspaceユーザーが1人いれば十分です。\
-このユーザーはDeleFriendの_config.yaml_ファイルで定義できます。ターゲットワークスペースユーザーが既に知られていない場合、ツールはGCPプロジェクトで役割を持つドメインユーザーをスキャンすることによって有効なワークスペースユーザーの自動識別を促進します。再度重要な点は、JWTはドメイン固有であり、すべてのユーザーのために生成されるわけではないため、自動プロセスはドメインごとに1つのユニークなアイデンティティをターゲットにします。
+5. **各新しいサービスアカウントを反復処理し、`JWT`** **オブジェクト**を作成します。このオブジェクトは、SAプライベートキーの資格情報とOAuthスコープで構成されています。新しい_**JWT**_オブジェクトを作成するプロセスは、**oauth_scopes.txt**リストからのすべての既存のOAuthスコープの組み合わせを反復処理し、すべての委任の可能性を見つけるために行われます。リスト**oauth_scopes.txt**は、Workspaceアイデンティティを悪用するために関連性があると見なされたすべてのOAuthスコープで更新されます。
+6. `_make_authorization_grant_assertion`メソッドは、DWDの下でJWTを生成するために、_subject_と呼ばれる**ターゲットワークスペースユーザー**を宣言する必要性を明らかにします。これは特定のユーザーを必要とするように思えるかもしれませんが、**DWDはドメイン内のすべてのアイデンティティに影響を与える**ことを理解することが重要です。したがって、**任意のドメインユーザー**のためにJWTを作成することは、そのドメイン内のすべてのアイデンティティに影響を与え、組み合わせ列挙チェックと一致します。要するに、有効なWorkspaceユーザーが1人いれば十分です。\
+このユーザーはDeleFriendの_config.yaml_ファイルで定義できます。ターゲットワークスペースユーザーが既に知られていない場合、このツールはGCPプロジェクト上の役割を持つドメインユーザーをスキャンすることによって有効なワークスペースユーザーの自動識別を促進します。再度重要な点は、JWTはドメイン固有であり、すべてのユーザーのために生成されるわけではないため、自動プロセスはドメインごとに1つのユニークなアイデンティティを対象とします。
 7. **各JWTのために新しいベアラートークンを列挙して作成し、tokeninfo APIに対してトークンを検証します。**
 
 #### [GitlabのPythonスクリプト](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
@@ -79,17 +79,17 @@ pip install --upgrade --user oauth2client
 
 **GCPプロジェクトでサービスアカウントを作成する能力**と**GWSに対するスーパー管理者権限を持つ攻撃者は、SAsがいくつかのGWSユーザーを偽装できる新しい委任を作成することができます:**
 
-1. **新しいサービスアカウントと対応するキー ペアの生成:** GCPでは、新しいサービスアカウントリソースは、コンソールを介して対話的に、または直接API呼び出しやCLIツールを使用してプログラム的に生成できます。これには、**役割 `iam.serviceAccountAdmin`** または **`iam.serviceAccounts.create`** **権限**を持つカスタムロールが必要です。サービスアカウントが作成されると、**関連するキー ペア**を生成します (**`iam.serviceAccountKeys.create`** 権限)。
+1. **新しいサービスアカウントと対応するキー ペアの生成:** GCPでは、新しいサービスアカウントリソースは、コンソールを介して対話的に、または直接API呼び出しやCLIツールを使用してプログラム的に生成できます。これには、**役割 `iam.serviceAccountAdmin`** または **`iam.serviceAccounts.create`** **権限**を備えたカスタムロールが必要です。サービスアカウントが作成されると、**関連するキー ペア**を生成します (**`iam.serviceAccountKeys.create`** 権限)。
 2. **新しい委任の作成:** **Google Workspaceでグローバルなドメイン全体の委任を設定できるのはスーパー管理者ロールのみであることを理解することが重要です**。ドメイン全体の委任は**プログラム的に設定できず、**Google Workspaceの**コンソール**を通じて**手動で**作成および調整できます。
 - ルールの作成は、**APIコントロール → Google Workspace管理コンソールでのドメイン全体の委任の管理**のページにあります。
-3. **OAuthスコープ権限の添付:** 新しい委任を構成する際、GoogleはクライアントID（**GCPサービスアカウント**リソースの**OAuth ID**）と、委任が必要とするAPI呼び出しを定義する**OAuthスコープ**の2つのパラメータのみを要求します。
+3. **OAuthスコープ権限の添付:** 新しい委任を構成する際、Googleは**クライアントID**（GCPサービスアカウントリソースの**OAuth ID**）と、委任が必要とするAPI呼び出しを定義する**OAuthスコープ**の2つのパラメータのみを要求します。
 - **OAuthスコープの完全なリスト**は[**こちら**](https://developers.google.com/identity/protocols/oauth2/scopes)で確認できますが、以下の推奨があります: `https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid`
-4. **ターゲットアイデンティティの代理として行動する:** この時点で、GWSに機能する委任オブジェクトがあります。今、**GCPサービスアカウントの秘密鍵を使用してAPI呼び出しを行うことができ**（OAuthスコープパラメータで定義されたスコープ内で）、**Google Workspaceに存在する任意のアイデンティティの代理として行動します**。サービスアカウントは、必要に応じて、REST APIアプリケーションに対する権限に応じてアクセストークンを生成します。
+4. **ターゲットアイデンティティの代理として行動する:** この時点で、GWSに機能する委任オブジェクトがあります。今、**GCPサービスアカウントの秘密鍵を使用してAPI呼び出しを行うことができ**（OAuthスコープパラメータで定義されたスコープ内で）、**Google Workspaceに存在する任意のアイデンティティの代理として行動します**。サービスアカウントは、そのニーズに応じてアクセス トークンを生成し、REST APIアプリケーションに対する権限に従います。
 - この委任を使用するための**ツール**については、**前のセクション**を確認してください。
 
 #### 組織間委任
 
-OAuth SA IDはグローバルであり、**組織間委任**に使用できます。組織間のグローバル委任を防ぐための制限は実装されていません。簡単に言えば、**異なるGCP組織のサービスアカウントを使用して、他のWorkspace組織でドメイン全体の委任を構成できます**。これにより、**Workspaceへのスーパー管理者アクセスのみが必要であり、同じGCPアカウントへのアクセスは不要です**。攻撃者は、自身が管理するGCPアカウントでサービスアカウントと秘密鍵を作成できます。
+OAuth SA IDはグローバルであり、**組織間委任**に使用できます。組織間のグローバル委任を防ぐ制限は実装されていません。簡単に言えば、**異なるGCP組織のサービスアカウントを使用して、他のWorkspace組織でドメイン全体の委任を構成できます**。これにより、**Workspaceへのスーパー管理者アクセスのみが必要となり、同じGCPアカウントへのアクセスは不要です**。攻撃者は、自身が管理するGCPアカウントでサービスアカウントと秘密鍵を作成できます。
 
 ### Workspaceを列挙するためのプロジェクトの作成
 
@@ -116,7 +116,7 @@ gcloud identity groups memberships list --group-email=g<group-email>
 # FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
 gcloud beta identity groups preview --customer <org-cust-id>
 ```
-チェック **さらなる列挙は**:
+チェック **さらに列挙する**:
 
 {{#ref}}
 ../gcp-services/gcp-iam-and-org-policies-enum.md
@@ -124,23 +124,23 @@ gcloud beta identity groups preview --customer <org-cust-id>
 
 ### Gcloud資格情報の悪用
 
-`gcloud`のログインフローに関する詳細情報は以下で確認できます:
+`gcloud`のログインフローに関する詳細情報は次のリンクで確認できます:
 
 {{#ref}}
-../gcp-persistence/gcp-non-svc-persistance.md
+../gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
-そこで説明されているように、gcloudは**`https://www.googleapis.com/auth/drive`**のスコープを要求することができ、これによりユーザーは自分のドライブにアクセスできます。\
-攻撃者として、もしあなたがユーザーのコンピュータを**物理的に**侵害し、**ユーザーがまだログインしている**場合、次のコマンドを使用してドライブへのアクセスを持つトークンを生成してログインすることができます:
+そこで説明されているように、gcloudは**`https://www.googleapis.com/auth/drive`**のスコープを要求でき、これによりユーザーが自分のドライブにアクセスできるようになります。\
+攻撃者として、もしあなたがユーザーのコンピュータを**物理的に**侵害し、**ユーザーがまだ**自分のアカウントでログインしている場合、次のコマンドを使用してドライブへのアクセス権を持つトークンを生成してログインすることができます:
 ```bash
 gcloud auth login --enable-gdrive-access
 ```
-攻撃者がユーザーのコンピュータを侵害した場合、彼はファイル `google-cloud-sdk/lib/googlecloudsdk/core/config.py` を変更し、**`CLOUDSDK_SCOPES`** にスコープ **`'https://www.googleapis.com/auth/drive'`** を追加することができます。
+攻撃者がユーザーのコンピュータを侵害した場合、`google-cloud-sdk/lib/googlecloudsdk/core/config.py`ファイルを変更し、**`CLOUDSDK_SCOPES`**にスコープ**`'https://www.googleapis.com/auth/drive'`**を追加することができます。
 
 <figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
 
 > [!WARNING]
-> したがって、次回ユーザーがログインすると、攻撃者がドライブにアクセスするために悪用できる**ドライブへのアクセスを持つトークン**が作成されます。もちろん、ブラウザは生成されたトークンがドライブへのアクセスを持つことを示しますが、ユーザーが自ら**`gcloud auth login`**を呼び出すため、彼はおそらく**何も疑わないでしょう。**
+> したがって、ユーザーが次回ログインすると、攻撃者がドライブにアクセスするために悪用できる**ドライブへのアクセスを持つトークン**が作成されます。もちろん、ブラウザは生成されたトークンがドライブへのアクセスを持つことを示しますが、ユーザーが自ら**`gcloud auth login`**を呼び出すため、彼はおそらく**何も疑わないでしょう。**
 >
 > ドライブファイルをリストするには: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**
 
@@ -148,13 +148,13 @@ gcloud auth login --enable-gdrive-access
 
 ### 特権GCPユーザーへのアクセス
 
-攻撃者がGWSに完全にアクセスできる場合、彼はGCPに対する特権アクセスを持つグループやユーザーにアクセスできるため、GWSからGCPへの移行は通常「簡単」です。なぜなら、**GWSのユーザーはGCPに対して高い特権を持っているからです**。
+攻撃者がGWSに完全にアクセスできる場合、GCPに対して特権アクセスを持つグループやユーザーにアクセスできるため、GWSからGCPへの移行は通常より「簡単」です。**GWSのユーザーはGCPに対して高い特権を持っています**。
 
 ### Googleグループの特権昇格
 
 デフォルトでは、ユーザーは**組織のWorkspaceグループに自由に参加できます**。これらのグループには**GCPの権限**が割り当てられている可能性があります（[https://groups.google.com/](https://groups.google.com/)でグループを確認してください）。
 
-**google groups privesc**を悪用することで、GCPへの何らかの特権アクセスを持つグループに昇格できるかもしれません。
+**google groups privesc**を悪用することで、GCPに対して何らかの特権アクセスを持つグループに昇格できるかもしれません。
 
 ### 参考文献
 
diff --git a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md
index c0bacd2fa..ae41b41b9 100644
--- a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md
+++ b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md
@@ -30,7 +30,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
 ## Google Doc Phishing
 
 過去には、**見た目上正当な文書**を作成し、コメントで**いくつかのメール（例：@user@gmail.com）を言及する**ことが可能でした。Googleはそのメールアドレスに**文書で言及されたことを通知するメールを送信しました**。\
-現在では、これは機能しませんが、**被害者に文書へのアクセスを与える**と、Googleはその旨を示すメールを送信します。誰かを言及したときに表示されるメッセージは次のとおりです：
+現在では、これは機能しませんが、**被害者に文書へのアクセスを与える**と、Googleはその旨を通知するメールを送信します。誰かを言及したときに表示されるメッセージは次のとおりです：
 
 <figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
 
@@ -87,9 +87,9 @@ gws-app-scripts.md
 **Google**は、ユーザーの代わりに**さまざまなGoogleサービス**（Gmail、Drive、GCPなど）と**対話**できるアプリケーションを作成することを許可しています。
 
 他のユーザーの代わりに**行動する**アプリケーションを作成する際、開発者は**GCP内にOAuthアプリ**を作成し、アプリがユーザーデータにアクセスするために必要なスコープ（権限）を指定する必要があります。\
-**ユーザー**がその**アプリケーション**を**使用**したい場合、スコープで指定されたデータへのアクセスをアプリケーションが持つことを**受け入れる**ように**促されます**。
+**ユーザー**がその**アプリケーション**を**使用**したい場合、彼らは**スコープ**で指定されたデータへのアクセスを**受け入れる**ように**促されます**。
 
-これは、非技術的なユーザーを**フィッシング**して**機密情報にアクセスするアプリケーション**を使用させる非常に魅力的な方法です。彼らは結果を理解していないかもしれません。しかし、組織のアカウントでは、これを防ぐ方法があります。
+これは、非技術的なユーザーを**機密情報にアクセスするアプリケーション**の使用に**フィッシング**する非常に魅力的な方法です。彼らは結果を理解していないかもしれません。しかし、組織のアカウントでは、これを防ぐ方法があります。
 
 ### 未確認アプリのプロンプト
 
@@ -98,7 +98,7 @@ gws-app-scripts.md
 このプロンプトは、次のようなアプリで表示されます：
 
 - プライベートデータにアクセスできるスコープを使用するアプリ（Gmail、Drive、GCP、BigQueryなど）
-- ユーザーが100人未満のアプリ（100人以上のアプリは、未確認プロンプトを表示しないためにレビューが必要です）
+- 100人未満のユーザーを持つアプリ（100人以上のアプリは、未確認プロンプトを表示しないためにレビューが必要です）
 
 ### 興味深いスコープ
 
@@ -111,19 +111,19 @@ gws-app-scripts.md
 
 **OAuthクライアントIDの作成を開始します**
 
-1. [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient)にアクセスし、同意画面の設定をクリックします。
+1. [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient)にアクセスし、同意画面を設定するをクリックします。
 2. 次に、**ユーザータイプ**が**内部**（組織内の人のみ）か**外部**かを尋ねられます。ニーズに合った方を選択してください。
 - 内部は、すでに組織のユーザーを侵害しており、別のユーザーをフィッシングするためにこのアプリを作成している場合に興味深いかもしれません。
 3. アプリに**名前**、**サポートメール**（自分を少し匿名化するためにgooglegroupメールを設定できることに注意）、**ロゴ**、**承認されたドメイン**、および**更新用の別のメール**を付けます。
 4. **OAuthスコープ**を**選択**します。
 - このページは、非機密の権限、機密の権限、および制限された権限に分かれています。新しい権限を追加するたびに、そのカテゴリに追加されます。要求された権限に応じて、ユーザーに対してこれらの権限がどれほど機密であるかを示す異なるプロンプトが表示されます。
 - **`admin.directory.user.readonly`**と**`cloud-platform`**は機密の権限です。
-5. **テストユーザーを追加します。** アプリのステータスがテスト中の間、これらのユーザーのみがアプリにアクセスできるため、**フィッシングするメールを追加することを確認してください**。
+5. **テストユーザーを追加します**。アプリのステータスがテスト中の間、これらのユーザーのみがアプリにアクセスできるため、**フィッシングするメールを追加することを確認してください**。
 
 次に、**以前に作成したOAuthクライアントID**を使用して**Webアプリケーションの資格情報を取得します**：
 
-1. [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient)に戻り、今回は異なるオプションが表示されます。
-2. **Webアプリケーションの資格情報を作成**を選択します。
+1. [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient)に戻ると、今回は異なるオプションが表示されます。
+2. **Webアプリケーションの資格情報を作成する**を選択します。
 3. 必要な**Javascriptオリジン**と**リダイレクトURI**を設定します。
 - テスト用に**`http://localhost:8000/callback`**のようなものを両方に設定できます。
 4. アプリケーションの**資格情報**を取得します。
@@ -142,7 +142,7 @@ python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
 アプリケーションは、簡単に使用できる**アクセストークンとリフレッシュトークン**を表示します。**これらのトークンの使用方法についての詳細は**以下を確認してください：
 
 {{#ref}}
-../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
+../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
 #### `glcoud`の使用