脅威の調査と対処

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワークのエントリ（Exfiltration Over Web Service: Exfiltration to Cloud Storage）を確認します。
2. 関連する検出結果を確認するには、ステップ 1 で説明した [関連する検出結果] 行のリンクをクリックします。関連する検出結果の検出タイプは、同じ Cloud SQL インスタンス上で同一です。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• データが漏洩したプロジェクトのオーナーに連絡します。
• 調査が完了するまで、access.principalEmail の権限を取り消すことを検討します。
• これ以上の漏洩を止めるには、影響を受けた Cloud SQL インスタンスに制限付きの IAM ポリシーを追加します。
  • MySQL
  • PostgreSQL
  • SQL Server
• Cloud SQL Admin API へのアクセスとそこからのエクスポートを制限するには、VPC Service Controls を使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Exfiltration: Cloud SQL Restore Backup to External Organization

監査ログを調べてバックアップから組織またはプロジェクト外の Cloud SQL インスタンスにデータが復元されたかどうかを判断することで、Cloud SQL バックアップからのデータ漏洩を検出します。Cloud SQL インスタンスとバックアップの全タイプがサポートされています。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Exfiltration: Cloud SQL Restore Backup to External Organization の検出結果を開きます。

2. [検出の詳細] パネルの [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: データの漏洩に使用されたアカウント。
     • データの引き出しのソース: バックアップの作成元となった Cloud SQL インスタンスの詳細。
     • データの引き出しのターゲット: バックアップ データの復元先の Cloud SQL インスタンスの詳細。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 復元されたバックアップのリソース名。
     • プロジェクトのフルネーム: バックアップの作成元となった Cloud SQL インスタンスを含む Google Cloud プロジェクト。

3. 関連リンク（特に次のフィールド）:

   • Cloud Logging URI: Logging エントリへのリンク。
   • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
   • 関連する検出結果: 関連する検出結果へのリンク。

4. [JSON] タブをクリックします。

5. [JSON] で、次のフィールドを確認します。

   • resource:
     • parent_name: バックアップ作成元の Cloud SQL インスタンスのリソース名
   • evidence:
     • sourceLogId:
       • projectId: ソースの BigQuery データセットを含む Google Cloud プロジェクト。
   • properties:
     • restoreToExternalInstance:
       • backupId: 復元されたバックアップ実行の ID

ステップ 2: 権限と設定を確認する

1. Google Cloud コンソールの [IAM] ページに移動します。

   [IAM] に移動

2. 必要に応じて、検出結果 JSON の projectId フィールドに表示されているインスタンスのプロジェクトを選択します（ステップ 1 から）。

3. 表示されたページの [フィルタ] ボックスに、[プリンシパルのメール]（ステップ 1 を参照）に表示されたメールアドレスを入力し、アカウントに割り当てられている権限を確認します。

ステップ 3: ログを確認する

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワークのエントリ（Exfiltration Over Web Service: Exfiltration to Cloud Storage）を確認します。
2. 関連する検出結果を確認するには、[関連する検出結果] 行のリンクをクリックします（ステップ 1 を参照）。関連する検出結果の検出タイプは、同じ Cloud SQL インスタンス上で同一です。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• データが漏洩したプロジェクトのオーナーに連絡します。
• 調査が完了するまで、[検出の詳細] の[概要] タブの [プリンシパルのメール] 行に表示されているプリンシパルの権限を取り消すことを検討してください。
• これ以上の漏洩を止めるには、影響を受けた Cloud SQL インスタンスに制限付きの IAM ポリシーを追加します。
  • MySQL
  • PostgreSQL
  • SQL Server
• Cloud SQL Admin API へのアクセスを制限するには、VPC Service Controls を使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Exfiltration: Cloud SQL Over-Privileged Grant

PostgreSQL データベース（またはデータベース内のすべての関数またはプロシージャ）に対するすべての権限が 1 人以上のデータベース ユーザーに付与されているかどうかを検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Exfiltration: Cloud SQL Over-Privileged Grant の検出結果を開きます。

2. 検出結果の詳細パネルの [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • データベース表示名: 影響を受けた Cloud SQL PostgreSQL インスタンス内のデータベース名。
     • データベースのユーザー名: 過剰な権限を付与した PostgreSQL ユーザー。
     • データベース クエリ: 実行して権限を付与した PostgreSQL クエリ。
     • データベース譲受人: 過剰な権限の譲受人。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 影響を受けた Cloud SQL PostgreSQL インスタンスのリソース名。
     • 親の完全な名前: Cloud SQL PostgreSQL インスタンスのリソース名。
     • プロジェクトのフルネーム: Cloud SQL PostgreSQL インスタンスを含む Google Cloud プロジェクト。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

3. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: データベース権限を確認する

1. PostgreSQL データベースに接続します。
2. 次のアクセス権を一覧表示します。
   • データベース。\l または \list メタコマンドを使用して、[データベース表示名] に表示されているデータベースに割り当てられた権限を確認します（ステップ 1 から）。
   • 関数またはプロシージャ。\df メタコマンドを使用して、[データベースの表示名] に表示されたデータベース内の関数またはプロシージャに割り当てられている権限を確認します（ステップ 1 から）。

ステップ 3: ログを確認する

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Exfiltration Over Web Service）を確認します。
2. 追加の修復手順が必要かどうかを判断するために、調査結果を MITRE の調査と組み合わせます。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 過剰な権限が付与されたインスタンスのオーナーに連絡してください。
• 調査が完了するまで、データベース譲受人に表示されている譲受人のすべての権限を取り消すことを検討してください。
• データベース（ステップ 1 のデータベース表示名から）へのアクセスを制限するには、譲受人（ステップ 1 のデータベース譲受人から）から不要な権限を取り消します。

Initial Access: Database Superuser Writes to User Tables

Cloud SQL データベースのスーパーユーザー アカウント（PostgreSQL の場合は postgres、MySQL の場合は root）がユーザー テーブルに書き込むタイミングを検出します。通常、スーパーユーザー（非常に幅広いアクセス権を持つロール）は、ユーザー テーブルへの書き込みに使用するべきではありません。通常の日常的なアクティビティでは、アクセスが制限されているユーザー アカウントを使用する必要があります。スーパーユーザーがユーザー テーブルに書き込む場合は、攻撃者が権限を昇格したか、デフォルトのデータベース ユーザーを不正使用してデータを変更している可能性があります。また、問題ではありませんが、安全でない手法であることを示している場合もあります。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Initial Access: Database Superuser Writes to User Tables の検出結果を開きます。

2. 検出結果の詳細パネルの [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • データベース表示名: 影響を受けた Cloud SQL PostgreSQL または MySQL インスタンスのデータベース名。
     • データベースのユーザー名: スーパーユーザー。
     • データベース クエリ: ユーザー テーブルへの書き込み中に実行された SQL クエリ。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 影響を受けた Cloud SQL インスタンスのリソース名。
     • 親の完全な名前: Cloud SQL インスタンスのリソース名。
     • プロジェクトのフルネーム: Cloud SQL インスタンスを含む Google Cloud プロジェクト。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

3. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: ログを確認する

1. Google Cloud コンソールで、ステップ 1 の cloudLoggingQueryURI のリンクをクリックしてログ エクスプローラに移動します。[ログ エクスプローラ] ページには、関連する Cloud SQL インスタンスに関するすべてのログが表示されます。
2. 次のフィルタを使用して、PostgreSQL の pgaudit ログか、Cloud SQL for MySQL の監査ログを確認します。このログにはスーパーユーザーによって実行されたクエリが含まれています。
   • protoPayload.request.user="SUPERUSER"

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Exfiltration Over Web Service）を確認します。
2. 追加の修復手順が必要かどうかを判断するために、調査結果を MITRE の調査と組み合わせます。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• データベースへの接続が許可されているユーザーを確認します。

  • PostgreSQL の場合は、ユーザーを作成して管理するをご覧ください。
  • MySQL の場合は、組み込みの認証を使用してユーザーを管理するをご覧ください。

• スーパーユーザーのパスワードを変更することを検討してください。

  • PostgreSQL の場合は、デフォルト ユーザーのパスワードを設定するをご覧ください。
  • MySQL の場合は、デフォルト ユーザーのパスワードを設定するをご覧ください。

• インスタンスで使用する各種クエリに対して、アクセスが制限されたユーザーを新しく作成することを検討してください。

  • 新しいユーザーには、クエリの実行に必要な権限のみを付与します。

    • PostgreSQL の場合は、付与（コマンド）をご覧ください。
    • MySQL の場合は、アクセス制御とアカウント管理をご覧ください。

  • Cloud SQL インスタンスに接続するクライアントの認証情報を更新します。

Initial Access: Anonymous GKE resource created from the internet

悪意のある行為者が、次の Kubernetes デフォルト ユーザーまたはユーザー グループのいずれかを使用して、クラスタに新しい Kubernetes リソースを作成したかどうかを検出します。

• system:anonymous
• system:authenticated
• system:unauthenticated

これらのユーザーとグループは実質的に匿名です。クラスタのロールベースのアクセス制御（RBAC）バインディングにより、そのユーザーにクラスタ内でこれらのリソースを作成する権限が付与されています。

作成されたリソースと関連する RBAC バインディングを確認して、バインディングが必要であることを確認します。バインディングが不要な場合は、削除します。詳しくは、この検出結果のログメッセージをご覧ください。

この問題を軽減するには、デフォルトのロールとグループを避けるをご覧ください。

Initial Access: GKE resource modified anonymously from the internet

悪意のある行為者が、次の Kubernetes デフォルト ユーザーまたはユーザー グループのいずれかを使用して、クラスタ内の Kubernetes リソースを変更したことを検出します。

• system:anonymous
• system:authenticated
• system:unauthenticated

これらのユーザーとグループは実質的に匿名です。クラスタ内のロールベースのアクセス制御（RBAC）バインディングにより、クラスタ内のリソースを変更する権限がユーザーに付与されています。

変更されたリソースと関連する RBAC バインディングを確認して、バインディングが必要であることを確認します。バインディングが不要な場合は、削除します。詳しくは、この検出結果のログメッセージをご覧ください。

この問題を軽減するには、デフォルトのロールとグループを避けるをご覧ください。

Initial Access: Dormant Service Account Action

使われていないユーザー管理サービス アカウントがアクションをトリガーしたイベントを検出します。この場合、180 日を超えてアクティブでないサービス アカウントは、使用されていないと見なされます。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Initial Access: Dormant Service Account Action の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容:

   • プリンシパルのメール: アクションを実行した休眠状態のサービス アカウント
   • サービス名: サービス アカウントによってアクセスされた Google Cloud サービスの API 名
   • メソッド名: 呼び出されたメソッド

ステップ 2: 攻撃とレスポンスの手法を調査する

1. 使われていないサービス アカウントのアクティビティを調査するには、Activity Analyzer などのサービス アカウント ツールを使用します。
2. [プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡してください。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するアプリケーションにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのアプリケーションを特定し、アプリケーションのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Google Cloud サポートからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Initial Access: Dormant Service Account Key Created

休眠状態のユーザー管理のサービス アカウント キーが作成されたイベントを検出します。この場合、180 日を超えてアクティブでないサービス アカウントは、使用されていないと見なされます。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Initial Access: Dormant Service Account Key Created の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容の以下のフィールド:

   • プリンシパルのメール: サービス アカウントのキーを作成したユーザー

   影響を受けているリソースの以下のフィールド:

   • リソース表示名: 新しく作成された休眠状態のサービス アカウント キー
   • プロジェクトのフルネーム: その休眠状態のサービス アカウントが存在するプロジェクト

ステップ 2: 攻撃とレスポンスの手法を調査する

1. 使われていないサービス アカウントのアクティビティを調査するには、Activity Analyzer などのサービス アカウント ツールを使用します。
2. [プリンシパルのメール] フィールドのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡します。
• プリンシパルのメールのオーナーのアクセス権が不正使用された場合は、そのアクセス権を削除します。
• [サービス アカウント] ページで、新しく作成されたサービス アカウント キーを無効にします。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するアプリケーションにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのアプリケーションを特定し、アプリケーションのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Cloud カスタマーケアからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Initial Access: Leaked Service Account Key Used

漏洩したサービス アカウント キーを使用してアクションを認証するイベントを検出します。ここで、漏洩したサービス アカウント キーは公共のインターネットに投稿されたものです。たとえば、サービス アカウント キーが GitHub の公開リポジトリに誤って投稿されることがあります。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Initial Access: Leaked Service Account Key Used の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容の以下のフィールド:

   • プリンシパルのメール: この操作で使用されるサービス アカウント
   • サービス名: サービス アカウントによってアクセスされた Google Cloud サービスの API 名
   • メソッド名: アクションのメソッド名
   • サービス アカウント キー名: この操作の認証に使用される漏洩したサービス アカウント キー
   • 説明: 検出された内容の説明。公共のインターネット上のサービス アカウント キーがある場所が含まれます。

   影響を受けているリソースの以下のフィールド:

   • リソースの表示名: アクションに関係するリソース

ステップ 2: ログを確認する

1. Google Cloud コンソールで、Cloud Logging URI のリンクをクリックして [ログ エクスプローラ] に移動します。
2. Google Cloud コンソールのツールバーで、プロジェクトまたは組織を選択します。

3. 読み込まれたページで、次のフィルタを使用して関連ログを見つけます。

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"

   PRINCIPAL_EMAIL は、[検出の詳細] の [プリンシパルのメール] フィールドからメモした値に置き換えます。 SERVICE_ACCOUNT_KEY_NAME は、[検出の詳細]の [サービス アカウント キー名] フィールドからメモした値に置き換えます。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• [サービス アカウント] ページで、サービス アカウント キーをすぐに取り消します。
• サービス アカウント キーが投稿されたウェブページまたは GitHub リポジトリを削除します。
• 不正使用されたサービス アカウントの削除を検討してください。
• 不正使用の可能性があるプロジェクトに対するサービス アカウントのアクセスキーをすべてローテーションして削除します。削除後は、このサービス アカウントを認証に使用するアプリケーションにアクセスできなくなります。削除する前に、セキュリティ チームは影響を受けるすべてのアプリケーションを特定し、アプリケーションのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Cloud カスタマーケアからの通知に対応します。

Initial Access: Excessive Permission Denied Actions

プリンシパルが複数のメソッドとサービス間で権限拒否エラーを繰り返しトリガーするイベントを検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Initial Access: Excessive Permission Denied Actions の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容:

   • プリンシパルのメール: 複数の権限拒否エラーをトリガーしたプリンシパル
   • サービス名: 権限拒否エラーが最後に発生した Google Cloud サービスの API 名
   • メソッド名: 最後の権限拒否エラーが発生したときに呼び出されたメソッド

3. [検出の詳細] の [ソース プロパティ] タブで、JSON 形式の次のフィールドの値をメモします。

   • properties.failedActions: 発生した権限拒否エラー。各エントリの詳細には、サービス名、メソッド名、失敗した試行回数、エラーが最後に発生した時刻が含まれます。最大 10 個のエントリが表示されます。

ステップ 2: ログを確認する

1. Google Cloud コンソールで、Cloud Logging URI のリンクをクリックして [ログ エクスプローラ] に移動します。
2. Google Cloud コンソールのツールバーでプロジェクトを選択します。

3. 読み込まれたページで、次のフィルタを使用して関連ログを見つけます。

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.status.code=7

   PRINCIPAL_EMAIL を、[検出の詳細] の [プリンシパルのメール] フィールドに記録した値に置き換えます。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Valid Accounts: Cloud Accounts）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• [プリンシパルのメール] フィールドにあるアカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。
• 覚えのない Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど、不正使用されたアカウントによって作成されたプロジェクト リソースを削除します。
• アカウントを持つプロジェクトのオーナーに連絡し、場合によってはアカウントを削除または無効にします。

Brute Force: SSH

ホストに対するブルート フォース攻撃で SSH 認証に成功した試行を検出しています。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Brute Force: SSH の検出結果を開きます。

2. [検出の詳細] パネルの [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:

     • 発信者の IP: 攻撃を行った IP アドレス。
     • ユーザー名: ログインしたアカウント。

   • 影響を受けているリソース

   • 関連リンク（特に次のフィールド）:

     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
     • Chronicle: Google SecOps へのリンク。

3. [JSON] タブをクリックします。

4. [JSON] で、次のフィールドを確認します。

   • sourceProperties:
     • evidence:
       • sourceLogId: ログエントリを識別するプロジェクト ID とタイムスタンプ
       • projectId: 検出結果を含むプロジェクト
     • properties:
       • attempts:
       • Attempts: ログイン試行回数
         • username: ログインしたアカウント
         • vmName: 仮想マシンの名前
         • authResult: SSH 認証の結果

ステップ 2: Google Security Operations で調査する

この検出結果を調べるには、Google Security Operations を使用します。Google SecOps は、脅威を調査し、使いやすいタイムラインで関連するエンティティをピボット分析できる Google Cloud サービスです。Google SecOps を使用すると、検出データの質を高め、関心のある指標を特定し、調査を簡単に進めることができます。

Google SecOps を使用できるのは、組織レベルで Security Command Center を有効にした場合のみです。

1. Google Cloud Console で Security Command Center の [検出] ページに移動します。

   [検出] に移動

2. [クイック フィルタ] パネルで、[ソースの表示名] までスクロールします。

3. [ソースの表示名] セクションで、[Event Threat Detection] を選択します。

   テーブルに、選択したソースタイプの検出結果が表示されます。

4. テーブルの [category] で、検出結果の Brute Force: SSH をクリックします。 検出結果の詳細パネルが開きます。

5. 検出結果の詳細パネルの [関連リンク] セクションで、[Chronicle で調査] をクリックします。

6. Google SecOps のガイド付きユーザー インターフェースの手順に沿って操作します。

次のガイドを使用して、Google SecOps で調査を行います。

• ユーザーの調査
• IP アドレスの調査
• アセットの調査

ステップ 3: 権限と設定を確認する

1. Google Cloud Console で、[ダッシュボード] に移動します。

   [ダッシュボード] に移動

2. projectId で指定されているプロジェクトを選択します。

3. [リソース] カードに移動し、[Compute Engine] をクリックします。

4. vmName の名前とゾーンと一致する VM インスタンスをクリックします。ネットワークやアクセスの設定など、インスタンスの詳細を確認します。

5. ナビゲーション パネルで、[VPC ネットワーク]、[ファイアウォール] の順にクリックします。ポート 22 で制限が緩すぎるファイアウォール ルールを削除するか無効にします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、Cloud Logging URI のリンクをクリックして [ログ エクスプローラ] に移動します。
2. 読み込まれたページで、次のフィルタを使用して、[検出の詳細] の [概要] タブの [プリンシパルのメール] 行に表示される IP アドレスに関連する VPC フローログを見つけます。
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

ステップ 5: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワークのエントリ（Valid Accounts: Local Accounts）を確認します。
2. [検出の詳細] の [概要] タブの [関連する検出結果] 行の [関連する検出結果] リンクをクリックして、関連する検出結果を確認します。 関連する検出結果とは、同じインスタンスとネットワークで検出された同じタイプの検出結果のことです。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 6: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• ブルート フォースの試みが成功したプロジェクトのオーナーに連絡します。
• 不正使用の可能性があるインスタンスを調査し、検出されたマルウェアをすべて削除します。検出と削除をサポートするには、エンドポイントの検出と対応ソリューションを使用します。
• VM への SSH アクセスを無効にすることを検討します。SSH 認証鍵の無効化については、VM からの SSH 認証鍵を制限するをご覧ください。この手順を行うと、VM への承認済みアクセスが中断される可能性があります。手順を行う前に組織のニーズを考慮してください。
• 承認済みの鍵を使った SSH 認証のみを使用します。
• ファイアウォール ルールを更新するか Google Cloud Armor を使用して、不正な IP アドレスをブロックします。Google Cloud Armor は、Security Command Center の [統合されたサービス] ページで有効にできます。情報量によっては、Google Cloud Armor の費用が高額になる場合があります。詳細については、Google Cloud Armor の料金ガイドをご覧ください。

Credential Access: External Member Added To Privileged Group

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

外部のメンバーが特権 Google グループ（機密性の高いロールまたは権限が付与されたグループ）に追加されたことを検出します。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Credential Access: External Member Added To Privileged Group の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 変更をしたアカウント。
   • 影響を受けているリソース
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

3. 詳細パネルで [JSON] タブをクリックします。

4. [JSON] で、次のフィールドを確認します。

   • groupName: 変更が行われた Google グループ
   • externalMember: 新しく追加された外部メンバー
   • sensitiveRoles: このグループに関連付けられている機密性の高いロール

ステップ 2: グループ メンバーを確認する

1. Google グループを開きます。

   Google グループを開きます。

2. 確認するグループの名前をクリックします。

3. ナビゲーション メニューで、[メンバー] をクリックします。

4. 新しく追加した外部メンバーがこのグループにない場合は、メンバー名の横にあるチェックボックスをオンにして、remove_circle_outline [メンバーを削除] または not_interested [メンバーを禁止] を選択します。

   メンバーを削除するには、Google Workspace 管理者であるか、Google グループのオーナーまたはマネージャーのロールが割り当てられている必要があります。詳しくは、グループのメンバーにロールを割り当てるをご覧ください。

ステップ 3: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。

2. 必要に応じて、プロジェクトを選択します。

   

3. 読み込まれたページで、次のフィルタを使用して Google グループのメンバーの変更のログを確認します。

   • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果に対応する MITRE ATT＆CK フレームワークのエントリ（有効なアカウント）を確認します。
2. 追加の修復手順が必要かどうかを判断するために、調査結果を MITRE の調査と組み合わせます。

Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

誰かが、手動で証明書署名リクエスト（CSR）を承認しようとしたが、操作が失敗しました。クラスタ認証用の証明書の作成は、侵害されたクラスタへの永続的なアクセスを作成するための攻撃者の一般的な方法です。証明書に関連付けられている権限は、含まれるサブジェクトによって異なりますが、高度な権限が付与される場合があります。詳細については、このアラートのログ メッセージをご覧ください。

1. Cloud Logging の監査ログと、この CSR に関連する他のイベントに関する追加のアラートを確認し、CSR が approved であり、発行されたかどうか、および、CSR 関連アクションがプリンシパルによって想定されたアクティビティであるかどうかを判断します。
2. Cloud Logging で監査ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候が他にないか判断します。例:
   • CSR の承認を試みたプリンシパルは、CSR を作成したプリンシパルとは異なりますか？
   • プリンシパルは他の CSR のリクエスト、作成、承認、削除を試みましたか？
3. CSR 承認が想定されていなかった場合、または悪意のあるものであると判断された場合、証明書を無効にするにはクラスタで認証情報のローテーションが必要になります。 クラスタ認証情報のローテーションの実行に関するガイダンスを確認してください。

Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)

誰かが、証明書署名リクエスト（CSR）を手動で承認しました。クラスタ認証用の証明書を作成することは、攻撃者が不正使用されたクラスタへの永続的なアクセスを作成する一般的な方法です。証明書に関連付けられる権限は、証明書に含まれるサブジェクトによって異なりますが、高い権限を持つ場合があります。詳細については、このアラートのログ メッセージをご覧ください。

1. Cloud Logging の監査ログと、他の CSR 関連イベントに関する追加のアラートを確認し、CSR 関連アクションがプリンシパルによる想定されたアクションであるかどうかを判断します。
2. Cloud Logging で監査ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候が他にないか判断します。例:
   • CSR を承認したプリンシパルは、CSR を作成したプリンシパルとは異なりますか？
   • CSR で組み込み署名者が指定されたが、署名者の基準を満たしていなかったために、最終的に手動で承認する必要がありましたか？
   • プリンシパルは他の CSR のリクエスト、作成、承認、削除を試みましたか？
3. CSR 承認が想定されていなかった場合、または悪意のあるものであると判断された場合、証明書を無効にするにはクラスタで認証情報のローテーションが必要になります。クラスタ認証情報のローテーションの実行に関するガイダンスを確認してください。

Credential Access: Privileged Group Opened To Public

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

特権 Google グループ（機密性の高いロールまたは権限が付与されたグループ）が一般公開に変更されていることを検出します。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Credential Access: Privileged Group Opened To Public の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 変更を行ったアカウント。不正に使用されている可能性があります。
   • 影響を受けているリソース
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
   1. [JSON] タブをクリックします。
   2. [JSON] で、次のフィールドを確認します。
   • groupName: 変更が行われた Google グループ
   • sensitiveRoles: このグループに関連付けられている機密性の高いロール
   • whoCanJoin: グループの参加設定

ステップ 2: グループのアクセス設定を確認する

1. Google グループの管理コンソールに移動します。コンソールにログインするには、Google Workspace 管理者である必要があります。

   管理コンソールにアクセス

2. ナビゲーション パネルで [ディレクトリ] をクリックし、[グループ] を選択します。

3. 確認するグループの名前をクリックします。

4. [アクセス設定] をクリックし、[グループに参加できるユーザー] でグループの参加設定を確認します。

5. 必要に応じて、プルダウン メニューで参加可能性を変更します。

ステップ 3: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。

2. 必要に応じて、プロジェクトを選択します。

   

3. 読み込まれたページで、次のフィルタを使用して Google グループの設定変更のログを確認します。

   • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果に対応する MITRE ATT＆CK フレームワークのエントリ（有効なアカウント）を確認します。
2. 追加の修復手順が必要かどうかを判断するために、調査結果を MITRE の調査と組み合わせます。

Credential Access: Secrets Accessed in Kubernetes Namespace

Pod の default Kubernetes サービス アカウントがクラスタ内の Secret オブジェクトへのアクセスにいつ使用されたかを検出します。Role オブジェクトまたは ClusterRole オブジェクトで明示的にアクセス権を付与しない限り、default Kubernetes サービス アカウントには Secret オブジェクトへのアクセス件がありません。

Credential Access: Sensitive Role Granted To Hybrid Group

外部のメンバーを持つ Google グループに機密性の高いロールと権限が付与された場合に検出します。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Credential Access: Sensitive Role Granted To Hybrid Group の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 変更を行ったアカウント。不正に使用されている可能性があります。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 新しいロールが付与されたリソース。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
   1. [JSON] タブをクリックします。
   2. [JSON] で、次のフィールドを確認します。
   • groupName: 変更が行われた Google グループ
   • bindingDeltas: このグループに新しく付与される機密性の高いロール

ステップ 2: グループの権限を確認する

1. Google Cloud コンソールで [IAM] ページに移動します。

   IAM に移動

2. [フィルタ] フィールドに、groupName にリストされているアカウント名を入力します。

3. グループに付与された機密性の高いロールを確認します。

4. 新しく追加した機密性の高いロールが必要ない場合は、ロールを取り消します。

   組織またはプロジェクトでロールを管理するには、特定の権限が必要です。詳細については、必要な権限をご覧ください。

ステップ 3: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。

2. 必要に応じて、プロジェクトを選択します。

   

3. 読み込まれたページで、次のフィルタを使用して Google グループの設定変更のログを確認します。

   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果に対応する MITRE ATT＆CK フレームワークのエントリ（有効なアカウント）を確認します。
2. 追加の修復手順が必要かどうかを判断するために、調査結果を MITRE の調査と組み合わせます。

Malware: Cryptomining Bad IP

VPC フローログと Cloud DNS ログで既知のコマンド、制御ドメイン、IP アドレスへの接続を調査して、マルウェアを検出します。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Malware: Cryptomining Bad IP の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • 送信元 IP: 暗号通貨のマイニングが疑われる IP アドレス。
     • 送信元ポート: 接続の送信元ポート（利用可能な場合）。
     • 宛先 IP: ターゲット IP アドレス。
     • 宛先ポート: 接続の宛先ポート（利用可能な場合）。
     • プロトコル: 接続に関連付けられている IANA プロトコル。
   • 影響を受けているリソース
   • 関連リンク（次のフィールドがあります）:
     • ロギング URI: ログエントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

3. [検出の詳細] ビューで、[参照元プロパティ] タブをクリックします。

4. [プロパティ] を開いて、次のフィールドのプロジェクトとインスタンスの値をメモします。

   • instanceDetails: プロジェクト ID と Compute Engine インスタンスの名前をメモします。プロジェクト ID とインスタンス名は次の例のようになります。

     /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

5. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: 権限と設定を確認する

1. Google Cloud コンソールで、[ダッシュボード] ページに移動します。

   [ダッシュボード] に移動

2. properties_project_id で指定されているプロジェクトを選択します。

3. [リソース] カードに移動し、[Compute Engine] をクリックします。

4. properties_sourceInstance に一致する VM インスタンスをクリックします。不正使用された可能性のあるインスタンスがないか調査します。

5. ナビゲーション パネルで、[VPC ネットワーク]、[ファイアウォール] の順にクリックします。制限が緩すぎるファイアウォール ルールを削除するか無効にします。

ステップ 3: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud Console のツールバーでプロジェクトを選択します。

3. 読み込まれたページで、次のフィルタを使用して、Properties_ip_0 に関連する VPC フローログを見つけます。

   • logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
   • (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ「Resource Hijacking（英語）」を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• マルウェアが存在するプロジェクトのオーナーに連絡します。
• 不正使用の可能性があるインスタンスを調査し、検出されたマルウェアをすべて削除します。検出と削除をサポートするには、エンドポイントの検出と対応ソリューションを使用します。
• 必要に応じて、不正使用されたインスタンスを停止し、新しいインスタンスに置き換えます。
• ファイアウォール ルールを更新するか Google Cloud Armor を使用して、不正な IP アドレスをブロックします。Google Cloud Armor は、Security Command Center の [統合されたサービス] ページで有効にできます。データ量によっては、Google Cloud Armor の費用が高額になる可能性があります。詳細については、Google Cloud Armor の料金ガイドをご覧ください。

Initial Access: Log4j Compromise Attempt

ヘッダーまたは URL パラメータ内の Java 命名規則とディレクトリ インターフェース（JNDI）のルックアップが検出されると、この検出結果が生成されます。これらのルックアップは、Log4Shell の悪用を示す場合があります。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の詳細を確認するの手順に沿って Initial Access: Log4j Compromise Attempt の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容
   • 影響を受けているリソース
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
   • 検出結果の詳細ビューで、[JSON] タブをクリックします。

   • [JSON] で、次のフィールドを確認します。

   • properties

     • loadBalancerName: JNDI ルックアップが実行されたロードバランサの名前
     • requestUrl: HTTP リクエストのリクエスト URL。存在する場合、JNDI ルックアップが行われています。
     • requestUserAgent: HTTP リクエストを送信したユーザー エージェント。 存在する場合、JNDI ルックアップが行われています。
     • refererUrl: HTTP リクエストを送信したページの URL。存在する場合、JNDI ルックアップが行われています。

ステップ 2: ログを確認する

1. Google Cloud コンソールで、Cloud Logging の URI リンク（ステップ 1 を参照）をクリックして、ログ エクスプローラに移動します。

2. 読み込まれたページで、悪用の試みを示す ${jndi:ldap:// のような文字列トークンがないか、httpRequest フィールドを確認します。

   検索する文字列やクエリの例については、Logging ドキュメントの CVE-2021-44228: Detect Log4Shell Exploit をご覧ください。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果に対応する MITRE ATT&CK フレームワーク エントリ（一般公開されたアプリケーションの悪用）を確認します。
2. [検出の詳細] の [概要] タブの [関連する検出結果] 行の [関連する検出結果] リンクをクリックして、関連する検出結果を確認します。 関連する検出結果とは、同じインスタンスとネットワークで検出された同じタイプの検出結果のことです。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• Log4j2 の最新バージョンにアップグレードします。
• Google Cloud の推奨する「Apache Log4j 2」の脆弱性の調査と対応の手順を行います。
• Apache Log4j のセキュリティ脆弱性にある推奨の緩和策を実装します。
• Google Cloud Armor を使用している場合は、新規または既存の Google Cloud Armor セキュリティ ポリシーに cve-canary rule をデプロイします。詳細については、Apache Log4j の脆弱性を緩和する Google Cloud Armor WAF ルールをご覧ください。

Active Scan: Log4j Vulnerable to RCE

サポートされている Log4j 脆弱性スキャナは、難読化された JNDI ルックアップを HTTP パラメータ、URL、テキスト フィールドに挿入し、スキャナの制御下にあるドメインへのコールバックを組み込みます。この検出結果は、難読化されていないドメインの DNS クエリが検出されると生成されます。このようなクエリは、JNDI ルックアップが成功し、アクティブな Log4j 脆弱性がある場合にのみ発生します。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の詳細を確認するの手順に沿って Active Scan: Log4j Vulnerable to RCE の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: Log4j RCE に対して脆弱な Compute Engine インスタンスの完全なリソース名。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

3. 検出結果の詳細ビューで、[JSON] タブをクリックします。

4. [JSON] で、次のフィールドを確認します。

   • properties
     • scannerDomain: JNDI ルックアップの一部としてスキャナが使用するドメイン。これにより、脆弱性を識別したスキャナを確認できます。
     • sourceIp: DNS クエリを行うために使用される IP アドレス
     • vpcName: DNS クエリが実行されたインスタンス上のネットワークの名前

ステップ 2: ログを確認する

1. Google Cloud コンソールで、Cloud Logging の URI リンク（ステップ 1 を参照）をクリックして、ログ エクスプローラに移動します。

2. 読み込まれたページで、悪用の試みを示す ${jndi:ldap:// のような文字列トークンがないか、httpRequest フィールドを確認します。

   検索する文字列やクエリの例については、Logging ドキュメントの CVE-2021-44228: Detect Log4Shell Exploit をご覧ください。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果に対応する MITRE ATT&CK フレームワーク エントリ（リモート サービスの悪用）を確認します。
2. [検出の詳細] の [概要] タブの [関連する検出結果] 行の [関連する検出結果] リンクをクリックして、関連する検出結果を確認します。 関連する検出結果とは、同じインスタンスとネットワークで検出された同じタイプの検出結果のことです。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• Log4j2 の最新バージョンにアップグレードします。
• Google Cloud の推奨する「Apache Log4j 2」の脆弱性の調査と対応の手順を行います。
• Apache Log4j のセキュリティ脆弱性にある推奨の緩和策を実装します。
• Google Cloud Armor を使用している場合は、新規または既存の Google Cloud Armor セキュリティ ポリシーに cve-canary rule をデプロイします。詳細については、Apache Log4j の脆弱性を緩和する Google Cloud Armor WAF ルールをご覧ください。

Leaked credentials

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

この検出結果は、Google Cloud サービス アカウントの認証情報が誤ってオンラインに流出した場合や、不正に使用された場合に生成されます。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の詳細を確認するの手順に沿って account_has_leaked_credentials の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

• 検出された内容
• 影響を受けているリソース

1. [参照元プロパティ] タブをクリックし、次のフィールドを確認します。

   • Compromised_account: 不正使用の可能性があるサービス アカウント
   • Project_identifier: 漏洩した可能性のあるアカウント認証情報を含むプロジェクト
   • URL: GitHub リポジトリへのリンク

2. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: プロジェクトとサービス アカウントの権限を確認する

1. Google Cloud コンソールの [IAM] ページに移動します。

   IAM に移動

2. 必要に応じて、Project_identifier に表示されているプロジェクトを選択します。

3. 表示されたページの [フィルタ] ボックスに、Compromised_account に表示されているアカウント名を入力して、割り当てられている権限を確認します。

4. Google Cloud コンソールで、[サービス アカウント] ページに移動します。

   [サービス アカウント] に移動

5. 表示されるページの [フィルタ] ボックスに、不正使用されているサービス アカウントの名前を入力して、サービス アカウントのキーとキーの作成日を確認します。

ステップ 3: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud Console のツールバーでプロジェクトを選択します。

3. 読み込まれたページで、次のフィルタを使用して、新規または更新された IAM リソースのアクティビティ ログを確認します。

   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
   • protoPayload.methodName="InsertProjectOwnershipInvite"
   • protoPayload.authenticationInfo.principalEmail="Compromised_account"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ「Valid Accounts: Cloud Accounts（英語）」を確認します。
2. 関連する検出結果を確認するには、relatedFindingURI のリンクをクリックします。関連する検出結果とは、検出結果タイプが同じで、インスタンスおよびネットワークが同じものです。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 認証情報が漏洩したプロジェクトのオーナーに連絡します。
• 不正使用されたサービス アカウントを削除し、不正使用されたプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、認証にこのサービス アカウントを使用するリソースはアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのリソースを特定し、リソースのオーナーと協力してそのビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど、覚えのないリソースを特定します。承認済みアカウントで作成されていないリソースは削除します。
• Google Cloud サポートからの通知に対応する。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。
• URL リンクを開き、漏洩した認証情報を削除します。不正使用されているアカウントに関する詳細な情報を収集して、オーナーに連絡します。

Malware

VPC フローログと Cloud DNS ログで既知のコマンド、制御ドメイン、IP アドレスへの接続を調査して、マルウェアを検出します。現在、Event Threat Detection は、一般的なマルウェア検出（Malware: Bad IP と Malware: Bad Domain）と、特に Log4j 関連のマルウェアの検出機能（Log4j Malware: Bad IP と Log4j Malware: Bad Domain）を提供しています。

次のステップでは、IP ベースの検出結果を調査し、対処する方法について説明します。修復手順は、ドメインベースの検出結果の場合も同様です。

ステップ 1: 検出結果の詳細を確認する

1. 該当するマルウェアの検出結果を開きます。以下のステップでは、検出結果の確認で説明されているように、Malware: Bad IP の検出結果を使用します。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • Indicator domain: Bad domain 検出結果の場合、検出結果をトリガーしたドメイン。
     • Indicator IP: Bad IP 検出結果の場合、検出結果をトリガーした IP アドレス。
     • 送信元 IP: Bad IP 検出結果の場合、マルウェアの既知のコマンドと制御 IP アドレス。
     • 送信元ポート: Bad IP 検出結果の場合、接続の送信元ポート。
     • 宛先 IP: Bad IP の検出結果の場合、マルウェアのターゲット IP アドレス。
     • 宛先ポート: Bad IP 検出結果の場合、接続の宛先ポート。
     • プロトコル: Bad IP 検出結果の場合、接続に関連付けられている IANA プロトコル番号。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 影響を受ける Compute Engine インスタンスの完全なリソース名。
     • プロジェクトの完全な名前: 検出結果を含むプロジェクトの完全なリソース名。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
     • Chronicle: Google SecOps へのリンク。
     • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

   1. [JSON] タブをクリックして、次のフィールドを確認します。

      • evidence:
      • sourceLogId:
        • projectID: 問題が検出されたプロジェクトの ID。
      • properties:
      • InstanceDetails: Compute Engine インスタンスのリソース アドレス

ステップ 2: Google Security Operations で調査する

この検出結果を調べるには、Google Security Operations を使用します。Google SecOps は、脅威を調査し、使いやすいタイムラインで関連するエンティティをピボット分析できる Google Cloud サービスです。Google SecOps を使用すると、検出データの質を高め、関心のある指標を特定し、調査を簡単に進めることができます。

Google SecOps を使用できるのは、組織レベルで Security Command Center を有効にした場合のみです。

1. Google Cloud Console で Security Command Center の [検出] ページに移動します。

   [検出] に移動

2. [クイック フィルタ] パネルで、[ソースの表示名] までスクロールします。

3. [ソースの表示名] セクションで、[Event Threat Detection] を選択します。

   テーブルに、選択したソースタイプの検出結果が表示されます。

4. テーブルの [カテゴリ] で、検出結果の Malware: Bad IP をクリックします。検出結果の詳細パネルが開きます。

5. 検出結果の詳細パネルの [関連リンク] セクションで、[Chronicle で調査] をクリックします。

6. Google SecOps のガイド付きユーザー インターフェースの手順に沿って操作します。

次のガイドを使用して、Google SecOps で調査を行います。

• IP アドレスの調査
• アセットの調査

ステップ 3: 権限と設定を確認する

1. Google Cloud コンソールで、[ダッシュボード] ページに移動します。

   [ダッシュボード] に移動

2. [概要] タブの [プロジェクトのフルネーム] 行で指定されたプロジェクトを選択します。

3. [リソース] カードに移動し、[Compute Engine] をクリックします。

4. [リソースの完全な名前] の名前とゾーンに一致する VM インスタンスをクリックします。ネットワークやアクセスの設定など、インスタンスの詳細を確認します。

5. ナビゲーション パネルで、[VPC ネットワーク]、[ファイアウォール] の順にクリックします。制限が緩すぎるファイアウォール ルールを削除するか無効にします。

ステップ 4: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。

2. 読み込まれたページで、次のフィルタを使用して [送信元 IP] の IP アドレスに関連する VPC フローログを見つけます。

   • logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")

     以下を置き換えます。

     • PROJECT_ID は、projectId に表示されているプロジェクトに置き換えます。
     • SOURCE_IP は、[検出の詳細] の [概要] タブの [送信元 IP] 行に表示される IP アドレスに置き換えます。

ステップ 5: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Dynamic Resolution と Command and Control）を確認します。
2. [検出の詳細] の [概要] タブの [関連する検出結果] 行の [関連する検出結果] リンクをクリックして、関連する検出結果を確認します。 関連する検出結果とは、同じインスタンスとネットワークで検出された同じタイプの検出結果のことです。
3. VirusTotal インジケーターのリンクをクリックして、VirusTotal でフラグが付けられた URL とドメインを確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
4. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 6: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• マルウェアが存在するプロジェクトのオーナーに連絡します。
• 不正使用の可能性があるインスタンスを調査し、検出されたマルウェアをすべて削除します。検出と削除をサポートするには、エンドポイントの検出と対応ソリューションを使用します。
• マルウェアの侵入を可能にするアクティビティと脆弱性を追跡するには、不正使用されたインスタンスに関連付けられた監査ログと syslog を確認します。
• 必要に応じて、不正使用されたインスタンスを停止し、新しいインスタンスに置き換えます。
• ファイアウォール ルールを更新するか Google Cloud Armor を使用して、不正な IP アドレスをブロックします。Google Cloud Armor は、Security Command Center の [統合されたサービス] ページで有効にできます。データ量によっては、Google Cloud Armor の費用が高額になる可能性があります。詳細については、Google Cloud Armor の料金ガイドをご覧ください。
• VM イメージへのアクセスと使用を制御するには、Shielded VM と信頼できるイメージの IAM ポリシーを使用します。

Persistence: IAM Anomalous Grant

監査ログを確認することで、疑わしい IAM（IAM）ロール付与の追加を検出します。

次に異常な付与の例を示します。

• gmail.com ユーザーなどの外部ユーザーを、プロジェクト オーナーとして Google Cloud コンソールから招待する
• 機密情報に関わる権限を付与するサービス アカウント
• 機密情報に関わる権限を付与するカスタムロール
• 組織またはプロジェクトの外部から追加されたサービス アカウント

IAM Anomalous Grant の検出結果にはサブルールが含まれ、この検出結果の各インスタンスに関するより具体的な情報が提供されます。これは、この検出結果に特有のものです。この検出結果の重大度の分類は、サブルールによって異なります。対応はサブルールごとに異なる場合があります。

次のリストに、可能性のあるすべてのサブルールとその重大度を示します。

• external_service_account_added_to_policy:
  • HIGH: 機密性の高いロールが付与されたか、中程度の機密性のロールが組織レベルで付与されている場合。詳細については、機密性の高いロールをご覧ください。
  • MEDIUM: 中程度の機密性のロールが付与された場合。詳細については、機密性が中程度のロールをご覧ください。
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH: 機密性の高いロールが付与されたか、中程度の機密性のロールが組織レベルで付与されている場合。詳細については、機密性の高いロールをご覧ください。
  • MEDIUM: 中程度の機密性のロールが付与された場合。詳細については、機密性が中程度のロールをご覧ください。
• custom_role_given_sensitive_permissions: MEDIUM
• service_account_granted_sensitive_role_to_member: HIGH
• policy_modified_by_default_compute_service_account: HIGH

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Persistence: IAM Anomalous Grant の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: ロールを割り当てられたユーザーまたはサービス アカウントのメールアドレス。

   • 影響を受けているリソース

   • 関連リンク（特に次のフィールド）:

     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
     • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。
     • Chronicle: Google SecOps へのリンク。

3. [JSON] タブをクリックします。検出結果の完全な JSON が表示されます。

4. 検出結果の JSON で、次のフィールドを確認します。

   • detectionCategory:
     • subRuleName: 発生した異常な付与のタイプに関する、より具体的な情報。サブルールにより、この検出結果の重大度の分類が決定されます。
   • evidence:
     • sourceLogId:
     • projectId: 検出結果が含まれているプロジェクトの ID。
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: ユーザーが行った操作
       • Role: ユーザーに割り当てられたロール
       • member: ロールを付与されたユーザーのメールアドレス

ステップ 2: Google Security Operations で調査する

この検出結果を調べるには、Google Security Operations を使用します。Google SecOps は、脅威を調査し、使いやすいタイムラインで関連するエンティティをピボット分析できる Google Cloud サービスです。Google SecOps を使用すると、検出データの質を高め、関心のある指標を特定し、調査を簡単に進めることができます。

プロジェクト レベルで Security Command Center を有効にすると、Chronicle で Security Command Center の検出結果を調査できません。

1. Google Cloud Console で Security Command Center の [検出] ページに移動します。

   [検出] に移動

2. [クイック フィルタ] パネルで、[ソースの表示名] までスクロールします。

3. [ソースの表示名] セクションで、[Event Threat Detection] を選択します。

   テーブルに、選択したソースタイプの検出結果が表示されます。

4. テーブルの [category] で、検出結果の Persistence: IAM Anomalous Grant をクリックします。 検出結果の詳細パネルが開きます。

5. 検出結果の詳細パネルの [関連リンク] セクションで、[Chronicle で調査] をクリックします。

6. Google SecOps のガイド付きユーザー インターフェースの手順に沿って操作します。

次のガイドを使用して、Google SecOps で調査を行います。

• ユーザーの調査
• アセットの調査

ステップ 3: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。
2. 読み込まれたページで、次のフィルタを使用して新規または更新された IAM リソースを探します。
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Valid Accounts: Cloud Accounts）を確認します。
2. [検出の詳細] の [概要] タブの [関連する検出結果] 行のリンクをクリックして、関連する検出結果を確認します。 関連する検出結果とは、同じインスタンスとネットワークで検出された同じタイプの検出結果のことです。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• アカウントが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されたサービス アカウントを削除し、不正使用されたプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除します。削除後は、認証にこのサービス アカウントを使用するリソースはアクセスできなくなります。
• 覚えのない Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど、未承認のアカウントで作成されたプロジェクト リソースを削除します。
• gmail.com ユーザーの追加を制限するには、組織のポリシーを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Persistence: Impersonation Role Granted for Dormant Service Account

休眠状態のユーザー管理のサービス アカウントになりすますことを許可する権限借用ロールがプリンシパルに付与されたイベントを検出します。この検出結果では、休眠状態のサービス アカウントが影響を受けるリソースであり、サービス アカウントが 180 日以上非アクティブになっていた場合に休眠状態とみなされます。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Persistence: Impersonation Role Granted for Dormant Service Account の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容:

   • プリンシパルのメール: 付与アクションを実行したユーザー
   • 不適切なアクセス許可: プリンシパル名: 権限借用ロールが付与されたプリンシパル

   影響を受けているリソースの以下のフィールド:

   • リソース表示名: リソースとしての休眠状態のサービス アカウント
   • プロジェクトのフルネーム: その休眠状態のサービス アカウントが存在するプロジェクト

ステップ 2: 攻撃とレスポンスの手法を調査する

1. 使われていないサービス アカウントのアクティビティを調査するには、Activity Analyzer などのサービス アカウント ツールを使用します。
2. [プリンシパルのメール] フィールドのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: ログを確認する

1. 検出の詳細パネルの [概要] タブの [関連リンク] で、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡します。
• プリンシパルのメールのオーナーのアクセス権が不正使用された場合は、そのアクセス権を削除します。
• 新しく付与された権限借用ロールを、ターゲット メンバーから削除します。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するアプリケーションにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのアプリケーションを特定し、アプリケーションのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Cloud カスタマーケアからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Persistence: Unmanaged Account Granted Sensitive Role

管理対象外のアカウントに機密性の高いロールが付与されたイベントを検出します 管理対象外アカウントは、システム管理者によって制御できません。たとえば、関連付けられた従業員が退職した場合、管理者はアカウントを削除できません。したがって、管理対象外アカウントに機密性の高いロールを付与すると、組織にセキュリティ リスクが生じる可能性があります。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Persistence: Unmanaged Account Granted Sensitive Role の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容:

   • プリンシパルのメール: 付与アクションを実行したユーザー
   • 不適切なアクセス許可: プリンシパル名: 付与を受ける管理対象外アカウント
   • 不適切なアクセス許可: 付与されたロール: 付与された機密性の高いロール

ステップ 2: 攻撃とレスポンスの手法を調査する

1. [プリンシパルのメール] フィールドのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。
2. [不適切なアクセス許可: プリンシパル名] フィールドのオーナーに確認し、管理対象外アカウントの起源を把握します。

ステップ 3: ログを確認する

1. 検出の詳細パネルの [概要] タブの [関連リンク] で、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡します。
• プリンシパルのメールのオーナーのアクセス権が不正使用された場合は、そのアクセス権を削除します。
• 新しく付与された機密性の高いロールを管理対象外アカウントから削除します。
• 移行ツールを使用して管理対象外アカウントを管理対象アカウントに変換し、このアカウントをシステム管理者の管理下に移行することを検討してください。

Persistence: New API Method

組織、フォルダ、プロジェクトで、不正な可能性のある行為者による異常な管理アクティビティが検出されました。異常なアクティビティは、次のいずれかになります。

• 組織、フォルダ、プロジェクトのプリンシパルによる新たなアクティビティ
• 組織、フォルダ、プロジェクトのプリンシパルでしばらく確認されていないアクティビティ

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Persistence: New API Method の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   • 検出された内容:
     • プリンシパルのメール: 連絡をしたアカウント
     • サービス名: アクションで使用される Google Cloud サービスの API 名
     • メソッド名: 呼び出されたメソッド
   • 影響を受けているリソース:
     • リソースの表示名: 影響を受けるリソースの名前。組織、フォルダ、プロジェクトの名前と同じでもかまいません。
     • リソースパス: アクティビティが発生したリソース階層内の場所

ステップ 2: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Persistence）を確認します。
2. 操作は組織、フォルダ、プロジェクトで保証されたものであるかどうか、アカウントの正当な所有者によって行われた処理であるかどうかを調査します。[リソースパス] 行に組織、フォルダ、プロジェクトが表示され、[プリンシパルのメール] 行にアカウントが表示されます。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Persistence: New Geography

この検出結果は、プロジェクト レベルの有効化には使用できません。

IAM ユーザーまたはサービス アカウントが、リクエスト元の IP アドレスの位置情報に基づいて、異常なロケーションから Google Cloud にアクセスしています。

ステップ 1: 検出結果の詳細を確認する

1. このページの検出結果の詳細を確認するの説明に沿って Persistence: New Geography の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

• 検出された内容（特に次のフィールド）:
  • プリンシパルのメール: 不正使用の疑いがあるユーザー アカウント。
• 影響を受けているリソース（特に次のフィールド）:
  • プロジェクトのフルネーム: 不正使用の疑いがあるユーザー アカウントを含むプロジェクト。
• 関連リンク（特に次のフィールド）:
  • Cloud Logging URI: Logging エントリへのリンク。
  • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
  • 関連する検出結果: 関連する検出結果へのリンク。

1. 検出結果の詳細ビューで、[JSON] タブをクリックします。

2. JSON で、次の sourceProperties フィールドを確認します。

   • affectedResources:
     • gcpResourceName: 影響を受けるリソース
   • evidence:
     • sourceLogId:
     • projectId: 検出結果が含まれているプロジェクトの ID
   • properties:
     • anomalousLocation:
     • anomalousLocation: ユーザーの推定位置。
     • callerIp: 外部 IP アドレス
     • notSeenInLast: 通常の動作のベースラインを確立するために使用される期間。
     • typicalGeolocations: ユーザーが Google Cloud リソースに通常アクセスするロケーション

ステップ 2: プロジェクトとアカウントの権限を確認する

1. Google Cloud コンソールの [IAM] ページに移動します。

   [IAM] に移動

2. 必要に応じて、検出結果 JSON の projectID フィールドに表示されているプロジェクトを選択します。

3. 表示されたページの [フィルタ] ボックスに、[プリンシパルのメール] に表示されているアカウント名を入力し、付与されているロールを確認します。

ステップ 3: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。
2. 必要に応じて、プロジェクトを選択します。
3. 読み込まれたページで、次のフィルタを使用して、新規または更新された IAM リソースのアクティビティ ログを確認します。
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Valid Accounts: Cloud Accounts）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• アカウントが不正使用されているプロジェクトのオーナーに連絡します。
• anomalousLocation、typicalGeolocations、notSeenInLast フィールドを確認して、アクセスに異常がないかどうかと、アカウントが不正使用されているかどうかを確認できます。
• 覚えのない Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど、未承認のアカウントで作成されたプロジェクト リソースを削除します。
• 新しいリソースの作成を特定のリージョンに制限するには、リソース ロケーションの制限をご覧ください。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Persistence: New User Agent

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

異常なユーザー エージェントによって示されるように、IAM サービス アカウントは不審なソフトウェアを使用して Google Cloud にアクセスしています。

ステップ 1: 検出結果の詳細を確認する

1. このページで前述の検出結果の詳細を確認するの説明に沿って Persistence: New User Agent の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 不正使用の疑いがあるサービス アカウント。
   • 影響を受けているリソース（特に次のフィールド）:
     • プロジェクトのフルネーム: 不正使用の疑いがあるサービス アカウントを含むプロジェクト。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
   1. 検出結果の詳細ビューで、[JSON] タブをクリックします。
   2. [JSON] で、次のフィールドを確認します。
   • projectId: 不正使用された可能性のあるサービス アカウントを含むプロジェクト
   • callerUserAgent: 異常なユーザー エージェント
   • anomalousSoftwareClassification: ソフトウェアのタイプ
   • notSeenInLast: 通常の動作のベースラインを確立するために使用される期間。

ステップ 2: プロジェクトとアカウントの権限を確認する

1. Google Cloud コンソールの [IAM] ページに移動します。

   IAM に移動

2. 必要に応じて、projectId に表示されているプロジェクトを選択します。

3. 表示されたページの [フィルタ] ボックスに、検出結果の詳細の [概要] タブの [プリンシパルのメール] 行に表示されているアカウント名を入力し、付与されているロールを確認します。

4. Google Cloud コンソールで、[サービス アカウント] ページに移動します。

   [サービス アカウント] に移動

5. 表示されたページの [フィルタ] ボックスに、検出結果の詳細の [概要] タブの [プリンシパルのメール] 行に表示されているアカウント名を入力します。

6. サービス アカウントのキーとキーの作成日を確認します。

ステップ 3: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。
2. 必要に応じて、プロジェクトを選択します。
3. 読み込まれたページで、次のフィルタを使用して、新規または更新された IAM リソースのアクティビティ ログを確認します。
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ「Valid Accounts: Cloud Accounts（英語）」を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• アカウントが不正使用されているプロジェクトのオーナーに連絡します。
• anomalousSoftwareClassification、callerUserAgent、behaviorPeriod フィールドを確認して、アクセスに異常がないかどうかと、アカウントが不正使用されているかどうかを確認できます。
• 覚えのない Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど、未承認のアカウントで作成されたプロジェクト リソースを削除します。
• 新しいリソースの作成を特定のリージョンに制限するには、リソース ロケーションの制限をご覧ください。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

権限の昇格を目的として、悪質な可能性のある行為者が PUT または PATCH のリクエストを使用して、機密性の高い cluster-admin ロールの ClusterRole、RoleBinding または ClusterRoleBinding ロールベースのアクセス制御（RBAC）オブジェクトを変更しようとしました。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: Changes to sensitive Kubernetes RBAC objects の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 連絡をしたアカウント。
     • メソッド名: 呼び出されたメソッド。
     • Kubernetes バインディング: 変更された機密性の高い Kubernetes のバインディングまたは ClusterRoleBinding。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの表示名: アクションが発生した Kubernetes クラスタ。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

3. [検出された内容] セクションで、[Kubernetes バインディング] 行のバインディングの名前をクリックします。バインディングの詳細が表示されます。

4. 表示されたバインディングで、バインディングの詳細をメモします。

ステップ 2: ログを確認する

1. Google Cloud コンソールの検出結果の詳細の概要タブで、[Cloud Logging URI] フィールドにあるリンクをクリックしてログ エクスプローラに移動します。

2. [メソッド名] の値が PATCH メソッドの場合、リクエストの本文で変更されたプロパティを確認します。

   update（PUT）呼び出しでは、オブジェクト全体がリクエストで送信されるため、変更はそれほど明確ではありません。

3. 次のフィルタを使用して、プリンシパルが行ったその他のアクションを確認します。

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     以下を置き換えます。

   • CLUSTER_NAME: 検出結果の詳細の [リソース表示名] フィールドにメモした値。

   • PRINCIPAL_EMAIL: 検出結果の詳細の [プリンシパル メール] フィールドにメモした値。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Privilege Escalation）を確認します。
2. オブジェクトの機密性を確認し、変更が正当なものであるかどうかを確認します。
3. バインディングについては、サブジェクトをチェックして、サブジェクトがバインドされているロールが必要かどうかを判断できます。
4. ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候がほかにあるかどうかを確認します。

5. プリンシパルのメールがサービス アカウントでない場合は、そのアカウントの所有者に、正当なオーナーが操作を行ったかどうかを確認してください。

   プリンシパル メールがサービス アカウント（IAM または Kubernetes）である場合は、変更のソースを特定して、正当性を判断します。

6. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Privilege Escalation: Create Kubernetes CSR for master cert

権限を昇格させるため、悪意のある行為者が、cluster-admin アクセス権を付与する Kubernetes マスターの証明書署名リクエスト（CSR）を作成しました。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: Create Kubernetes CSR for master cert の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 連絡をしたアカウント。
     • メソッド名: 呼び出されたメソッド。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの表示名: アクションが発生した Kubernetes クラスタ。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

ステップ 2: ログを確認する

1. Google Cloud コンソールの検出結果の詳細の概要タブで、[Cloud Logging URI] フィールドにあるリンクをクリックしてログ エクスプローラに移動します。
2. protoPayload.resourceName フィールドの値を確認して、特定の証明書署名リクエストを識別します。

3. 次のフィルタを使用して、プリンシパルが行ったその他のアクションを確認します。

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     以下を置き換えます。

   • CLUSTER_NAME: 検出結果の詳細の [リソース表示名] フィールドにメモした値。

   • PRINCIPAL_EMAIL: 検出結果の詳細の [プリンシパル メール] フィールドにメモした値。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Privilege Escalation）を確認します。
2. cluster-admin へのアクセス権の付与が正当なものであるかどうかを調査します。

3. プリンシパルのメールがサービス アカウントでない場合は、そのアカウントの所有者に、正当なオーナーが操作を行ったかどうかを確認してください。

   プリンシパル メールがサービス アカウント（IAM または Kubernetes）である場合は、アクションのソースを特定して、正当性を判断します。

4. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Privilege Escalation: Creation of sensitive Kubernetes bindings

権限を昇格させるため、悪意のある可能性がある行為者が cluster-admin ロールに新しい RoleBinding オブジェクトまたは ClusterRoleBinding オブジェクトを作成しようとしました。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: Creation of sensitive Kubernetes bindings の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 連絡をしたアカウント。
     • Kubernetes バインディング: 作成された機密性の高い Kubernetes のバインディングまたは ClusterRoleBinding。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの表示名: アクションが発生した Kubernetes クラスタ。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

ステップ 2: ログを確認する

1. Google Cloud コンソールの検出結果の詳細の概要タブで、[Cloud Logging URI] フィールドにあるリンクをクリックしてログ エクスプローラに移動します。

2. 次のフィルタを使用して、プリンシパルが行ったその他のアクションを確認します。

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     以下を置き換えます。

   • CLUSTER_NAME: 検出結果の詳細の [リソース表示名] フィールドにメモした値。

   • PRINCIPAL_EMAIL: 検出結果の詳細の [プリンシパル メール] フィールドにメモした値。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Privilege Escalation）を確認します。
2. 作成されたバインディングの機密性と、サブジェクトにロールが必要かどうかを確認します。
3. バインディングについては、サブジェクトをチェックして、サブジェクトがバインドされているロールが必要かどうかを判断できます。
4. ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候がほかにあるかどうかを確認します。

5. プリンシパルのメールがサービス アカウントでない場合は、そのアカウントの所有者に、正当なオーナーが操作を行ったかどうかを確認してください。

   プリンシパル メールがサービス アカウント（IAM または Kubernetes）である場合は、アクションのソースを特定して、正当性を判断します。

6. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

誰かが、次のいずれかのユーザーまたはグループを参照する RBAC バインディングを作成しました。

• system:anonymous
• system:authenticated
• system:unauthenticated

これらのユーザーとグループは実質的に匿名であるため、RBAC ロールへのロール バインディングまたはクラスタロール バインディングを作成する場合は使用しないでください。バインディングが必要なことを確認します。バインディングが不要な場合は、削除します。詳細については、この検出結果のログメッセージを参照してください。

1. system:anonymous ユーザー、system:unauthenticated group グループ、または system:authenticated グループに権限を付与するバインディングが作成されているかどうかを確認します。
2. Cloud Logging で監査ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候が他にないか判断します。

悪意のあるアクティビティを示す徴候がある場合は、このアクセスを許可したバインディングの調査と削除についてのガイダンスを確してください。

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

権限を昇格させるため、悪意のある行為者が漏洩したブートストラップ認証情報を使用して kubectl コマンドを実行し、証明書署名リクエスト（CSR）をクエリしました。

以下に、このルールが検出するコマンドの例を示します。

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 連絡をしたアカウント。
     • メソッド名: 呼び出されたメソッド。
   • [影響を受けるリソース] の:
     • リソースの表示名: アクションが発生した Kubernetes クラスタ。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

ステップ 2: ログを確認する

検出結果の詳細の [メソッド名] フィールドのメソッド名が GET メソッドの場合は、次の操作を行います。

1. Google Cloud コンソールの検出結果の詳細の概要タブで、[Cloud Logging URI] フィールドにあるリンクをクリックしてログ エクスプローラに移動します。
2. protoPayload.resourceName フィールドの値を確認して、特定の証明書署名リクエストを識別します。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Privilege Escalation）を確認します。
2. 特定の CSR がログエントリに存在する場合は、証明書の機密性と、アクションが正当かどうかを調べます。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Privilege Escalation: Launch of privileged Kubernetes container

悪意のある可能性がある行為者が、特権コンテナまたは権限昇格機能を備えたコンテナを含む Pod を作成しました。

特権コンテナの privileged フィールドは true に設定されています。権限昇格機能を備えたコンテナの allowPrivilegeEscalation フィールドが true に設定されています。詳細については、Kubernetes ドキュメントの SecurityContext v1 core API リファレンスをご覧ください。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: Launch of privileged Kubernetes container の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: 連絡をしたアカウント。
     • Kubernetes Pod: 特権コンテナを使用して新しく作成された Pod。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの表示名: アクションが発生した Kubernetes クラスタ。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

3. [JSON] タブで、検出結果のフィールドの値をメモします。

   • findings.kubernetes.pods[].containers: Pod 内で特権コンテナを起動します。

ステップ 2: ログを確認する

1. Google Cloud コンソールの検出結果の詳細の概要タブで、[Cloud Logging URI] フィールドにあるリンクをクリックしてログ エクスプローラに移動します。

2. 次のフィルタを使用して、プリンシパルが行ったその他のアクションを確認します。

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     以下を置き換えます。

   • CLUSTER_NAME: 検出結果の詳細の [リソース表示名] フィールドにメモした値。

   • PRINCIPAL_EMAIL: 検出結果の詳細の [プリンシパル メール] フィールドにメモした値。

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Privilege Escalation）を確認します。
2. 作成されたコンテナがホストリソースとカーネル機能にアクセスする必要があることを確認します。
3. ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候がほかにあるかどうかを確認します。

4. プリンシパルのメールがサービス アカウントでない場合は、アカウントの所有者に連絡して、正当なオーナーが操作を行ったかどうかを確認してください。

   プリンシパル メールがサービス アカウント（IAM または Kubernetes）である場合は、アクションのソースを特定して、正当性を判断します。

5. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Privilege Escalation: Dormant Service Account Granted Sensitive Role

機密性の高い IAM ロールが休眠状態のユーザー管理サービス アカウントに付与されたイベントを検出します。この場合、180 日を超えてアクティブでないサービス アカウントは、使用されていないと見なされます。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: Dormant Service Account Granted Sensitive Role の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容:

   • プリンシパルのメール: 付与アクションを実行したユーザー
   • 不適切なアクセス許可: プリンシパル名: 機密性の高いロールを受け取った休眠状態のサービス アカウント
   • 不適切なアクセス許可: 付与されたロール: 割り当てられた機密性の高い IAM ロール

   影響を受けているリソース:

   • リソース表示名: 機密性の高い IAM ロールが休眠状態のサービス アカウントに付与されている組織、フォルダ、またはプロジェクト。

ステップ 2: 攻撃とレスポンスの手法を調査する

1. 使われていないサービス アカウントのアクティビティを調査するには、Activity Analyzer などのサービス アカウント ツールを使用します。
2. [プリンシパルのメール] フィールドのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: ログを確認する

1. 検出の詳細パネルの [概要] タブの [関連リンク] で、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡します。
• プリンシパルのメールのオーナーのアクセス権が不正使用された場合は、そのアクセス権を削除します。
• 新しく割り当てられた機密性の高い IAM ロールを休眠状態のサービス アカウントから削除します。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するリソースにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのリソースを確認し、リソースのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Cloud カスタマーケアからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

管理アクティビティ監査ログを調査して、サービス アカウントの権限借用リクエストに異常がないかどうか確認し、サービス アカウントの異常な権限借用を検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: Google Cloud へのアクセスに使用された権限借用リクエストの最後のサービス アカウント。
     • サービス名: 権限借用リクエストに関連する Google Cloud サービスの API 名。
     • メソッド名: 呼び出されたメソッド。
     • サービス アカウントの委任情報: 委任チェーンのサービス アカウントの詳細。リストの下部にあるプリンシパルが、権限借用リクエストの呼び出し元です。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: クラスタの名前。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

1. [プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。
2. 委任チェーンのプリンシパルを調査して、リクエストが異常なものかどうか、アカウントが不正使用されているかどうかを確認します。
3. サービス アカウントの委任情報リストにある権限借用の呼び出し元に連絡してください。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡してください。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するリソースにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのリソースを確認し、リソースのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Google Cloud サポートからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

管理アクティビティ監査ログを調査して、サービス アカウントの権限借用リクエストに異常がないかを確認し、Anomalous Multistep Service Account Delegation を検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: Google Cloud へのアクセスに使用された権限借用リクエストの最後のサービス アカウント。
     • サービス名: 権限借用リクエストに関連する Google Cloud サービスの API 名。
     • メソッド名: 呼び出されたメソッド。
     • サービス アカウントの委任情報: 委任チェーンのサービス アカウントの詳細。リストの下部にあるプリンシパルが、権限借用リクエストの呼び出し元です。
   • 影響を受けているリソース
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

1. [プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。
2. 委任チェーンのプリンシパルを調査して、リクエストが異常なものかどうか、アカウントが不正使用されているかどうかを確認します。
3. サービス アカウントの委任情報リストにある権限借用の呼び出し元に連絡してください。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡してください。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するリソースにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのリソースを確認し、リソースのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Google Cloud サポートからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

データアクセス監査ログを調査して、サービス アカウントの権限借用リクエストに異常がないかを確認し、Anomalous Multistep Service Account Delegation を検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プリンシパルのメール: Google Cloud へのアクセスに使用された権限借用リクエストの最後のサービス アカウント
     • サービス名: 権限借用リクエストに関連する Google Cloud サービスの API 名
     • メソッド名: 呼び出されたメソッド
     • サービス アカウントの委任情報: 委任チェーンのサービス アカウントの詳細。リストの下部にあるプリンシパルが、権限借用リクエストの呼び出し元です。
   • 影響を受けているリソース
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

1. [プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。
2. 委任チェーンのプリンシパルを調査して、リクエストが異常なものかどうか、アカウントが不正使用されているかどうかを確認します。
3. サービス アカウントの委任情報リストにある権限借用の呼び出し元に連絡してください。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡してください。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するリソースにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのリソースを確認し、リソースのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Google Cloud サポートからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

管理アクティビティ監査ログを調査して、サービス アカウントの権限借用リクエストに異常がないかを確認し、Anomalous Service Account Impersonator を検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:

     • プリンシパルのメール: Google Cloud へのアクセスに使用された権限借用リクエストの最後のサービス アカウント
     • サービス名: 権限借用リクエストに関連する Google Cloud サービスの API 名
     • メソッド名: 呼び出されたメソッド
     • サービス アカウントの委任情報: 委任チェーンのサービス アカウントの詳細。リストの下部にあるプリンシパルが、権限借用リクエストの呼び出し元です。

   • 影響を受けているリソース

   • 関連リンク（特に次のフィールド）:

     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

1. [プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。
2. 委任チェーンのプリンシパルを調査して、リクエストが異常なものかどうか、アカウントが不正使用されているかどうかを確認します。
3. サービス アカウントの委任情報リストにある権限借用の呼び出し元に連絡してください。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡してください。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するリソースにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのリソースを確認し、リソースのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Google Cloud サポートからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

データアクセス監査ログを調査して、サービス アカウントの権限借用リクエストに異常がないかを確認し、サービス アカウントの異常な権限借用を検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: Anomalous Service Account Impersonator for Data Access の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のフィールドの値をメモします。

   検出された内容:

   • プリンシパルのメール: Google Cloud へのアクセスに使用された権限借用リクエストの最後のサービス アカウント
   • サービス名: 権限借用リクエストに関連する Google Cloud サービスの API 名
   • メソッド名: 呼び出されたメソッド
   • サービス アカウントの委任情報: 委任チェーンのサービス アカウントの詳細。リストの下部にあるプリンシパルが、権限借用リクエストの呼び出し元です。

ステップ 2: 攻撃とレスポンスの手法を調査する

1. [プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。
2. 委任チェーンのプリンシパルを調査して、リクエストが異常なものかどうか、アカウントが不正使用されているかどうかを確認します。
3. サービス アカウントの委任情報リストにある権限借用の呼び出し元に連絡してください。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡してください。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するリソースにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのリソースを確認し、リソースのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Google Cloud サポートからの通知に対応します。
• サービス アカウントを作成できるユーザーを制限するには、組織のポリシー サービスを使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Privilege Escalation: ClusterRole with Privileged Verbs

誰かが、動詞 bind、escalate、impersonate を含む RBAC ClusterRole オブジェクトを作成しました。これらの動詞を使用してロールにバインドされたサブジェクトは、より高い権限を持つ他のユーザーの権限を借用したり、追加の権限を含む追加の Role オブジェクトまたは ClusterRole オブジェクトにバインドしたり、自身の ClusterRole 権限を変更したりできます。これにより、これらのサブジェクトが cluster-admin 権限を取得する可能性があります。詳細については、このアラートのログ メッセージをご覧ください。

1. ClusterRole と関連する ClusterRoleBindings を見直して、サブジェクトが実際にこれらの権限を必要とするかどうかを確認します。
2. 可能であれば、bind、escalate、impersonate 動詞を含むロールを作成しないようにしてください。
3. Cloud Logging で監査ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候が他にないか判断します。
4. RBAC ロールで権限を割り当てる場合は、最小権限の原則に沿って、タスクの実行に必要な最小限の権限を付与します。最小権限の原則を使用すると、クラスタが侵害された場合の権限昇格のリスクが軽減され、過剰なアクセスによってセキュリティ インシデントが発生する可能性が低くなります。

Privilege Escalation: ClusterRoleBinding to Privileged Role

誰かが、デフォルトの system:controller:clusterrole-aggregation-controller ClusterRole を参照する RBAC ClusterRoleBinding を作成しました。このデフォルトの ClusterRole には、escalate 動詞があり、サブジェクトが自身のロールの権限を変更でき、権限昇格が可能になります。詳細については、このアラートのログ メッセージを参照してください。

1. system:controller:clusterrole-aggregation-controller ClusterRole を参照する ClusterRoleBinding を確認します。
2. system:controller:clusterrole-aggregation-controller ClusterRole に対する変更を確認します。
3. Cloud Logging の監査ログを参照して、ClusterRoleBinding を作成したプリンシパルによる悪意のあるアクティビティを示す徴候が他にないか判断します。

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

誰かが、コンテナ エスケープまたはクラスタに対して他の攻撃を実行するために使用される一般的なツールと同様の命名規則で Pod をデプロイしました。詳細については、このアラートのログ メッセージをご覧ください。

1. Pod が正当であることを確認します。
2. Cloud Logging の監査ログを参照して、Pod またはプリンシパルによる悪意のあるアクティビティを示す徴候が他にないか確認します。
3. プリンシパルがサービス アカウント（IAM または Kubernetes）でない場合は、サービス アカウントのオーナーに連絡して、正当なオーナーがそのアクションを実行したかどうかを確認します。
4. プリンシパルがサービス アカウント（IAM または Kubernetes）である場合は、アクションのソースを特定して、正当性を判断します。
5. Pod が正当ではない場合は、その Pod、関連するすべての RBAC バインディング、ワークロードが使用したサービス アカウント、その作成を許可したサービス アカウントを削除します。

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

誰かが、ホストノードのファイル システム上の機密パスにマウントされる hostPath ボリュームを含むワークロードを作成しました。ホスト ファイル システム上のこれらのパスへのアクセスは、ノード上の特権情報や機密情報へのアクセス、およびコンテナ エスケープに使用できます。可能であれば、クラスタ内の hostPath ボリュームを許可しないでください。詳細については、このアラートのログ メッセージをご覧ください。

1. ワークロードを確認して、この hostPath ボリュームが目的の機能に必要であるどうかを判断します。必要である場合は、できるだけ具体的なディレクトリ パスを指定します。たとえば、/ や /etc ではなく /etc/myapp/myfiles。
2. Cloud Logging で監査ログを参照して、このワークロードに関連する悪意のあるアクティビティを示す徴候が他にないか判断します。

クラスタで hostPath ボリュームのマウントをブロックするには、Pod セキュリティ標準の適用に関するガイダンスを確認してください

Privilege Escalation: Workload with shareProcessNamespace enabled

誰かが、shareProcessNamespace オプションを true に設定してワークロードをデプロイし、すべてのコンテナが同じ Linux プロセス名前空間を共有できるようにしました。これにより、信頼できないコンテナや不正使用されたコンテナが、他のコンテナで実行中のプロセスから環境変数、メモリ、その他の機密データにアクセスして制御することで、権限を昇格させるおそれがあります。一部のワークロードは、ログ処理サイドカー コンテナやコンテナのデバッグなど、正当な理由でこの機能を動作させる必要がある場合があります。詳細については、このアラートのログ メッセージをご覧ください。

1. ワークロード内のすべてのコンテナの共有プロセス名前空間に対するアクセス権が、そのワークロードに実際に必要であることを確認します。
2. Cloud Logging で監査ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候が他にないか確認します。
3. プリンシパルがサービス アカウント（IAM または Kubernetes）でない場合は、サービス アカウントのオーナーに連絡して、そのアクションを実行したかどうかを確認します。
4. プリンシパルがサービス アカウント（IAM または Kubernetes）である場合は、サービス アカウントがそのアクションを実行した理由の正当性を判断します。

Service account self-investigation

サービス アカウントの認証情報は、同じサービス アカウントに関連付けられたロールと権限の調査に使用されます。この検出結果は、サービス アカウントの認証情報が不正使用された可能性があるため、早急に対処する必要があることを示しています。

ステップ 1: 検出結果の詳細を確認する

1. このページで前述の検出結果の詳細を確認するの説明に沿って Discovery: Service Account Self-Investigation の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • 重要度: 検出結果に割り当てられたリスクレベルこの検出結果をトリガーした API 呼び出しが許可されていない場合、重大度は HIGH になります。サービス アカウントには、projects.getIamPolicy API で独自の IAM 権限をクエリする権限がありません。
     • プリンシパルのメール: 不正使用の疑いがあるサービス アカウント。
     • 発信者の IP: 内部または外部 IP アドレス
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前:
     • プロジェクトのフルネーム: 漏洩の疑いがあるアカウント認証情報を含むプロジェクト。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
   1. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: プロジェクトとサービス アカウントの権限を確認する

1. Google Cloud コンソールの [IAM] ページに移動します。

   [IAM] に移動

2. 必要に応じて、検出結果 JSON の projectID フィールドに表示されているプロジェクトを選択します。

3. 表示されたページの [フィルタ] ボックスに、[プリンシパルのメール] に表示されているアカウント名を入力して、割り当てられている権限を確認します。

4. Google Cloud コンソールで、[サービス アカウント] ページに移動します。

   [サービス アカウント] に移動

5. 表示されるページの [フィルタ] ボックスに、不正使用されているサービス アカウントの名前を入力して、サービス アカウントのキーとキーの作成日を確認します。

ステップ 3: ログを確認する

1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。
2. 必要に応じて、プロジェクトを選択します。
3. 読み込まれたページで、次のフィルタを使用して、新規または更新された IAM リソースのアクティビティ ログを確認します。
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプの MITRE ATT&CK フレームワークのエントリ「Permission Groups Discovery: Cloud Groups（英語）」を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• アカウントが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されたサービス アカウントを削除し、不正使用されたプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除します。削除後は、認証にこのサービス アカウントを使用するリソースはアクセスできなくなります。
• 覚えのない Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど、不正使用されたアカウントによって作成されたプロジェクト リソースを削除します。

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection は、監査ログを調べて、Backup and DR サービスで保護されているアプリケーションを実行しているホストの削除を検出します。ホストを削除すると、そのホストに関連付けられているアプリケーションをバックアップできなくなります。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Deleted Google Cloud Backup and DR host の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • アプリケーション名: Backup and DR に接続されているデータベースまたは VM の名前
     • ホスト名: Backup and DR に接続されているホストの名前
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: ホストが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

1. アクションが実行されたプロジェクトで、管理コンソールに移動します。
2. 削除したホストが Backup and DR のホストのリストにもう表示されなくなったことを確認します。
3. [ホストを追加] オプションを選択して、削除したホストを再度追加します。

Inhibit System Recovery: Google Cloud Backup and DR remove plan

Security Command Center は、監査ログを調べて、アプリケーションにバックアップ ポリシーを適用するために使用される Backup and DR サービスのバックアップ プランの異常な削除を検出します。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR remove plan の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • アプリケーション名: Backup and DR に接続されているデータベースまたは VM の名前
     • プロファイル名: アプリケーションと VM データのバックアップを保存するストレージ ターゲットを指定します
     • テンプレート名: バックアップの頻度、スケジュール、保持時間を定義する一連のポリシーの名前
   • 影響を受ける 1 個のリソース
     • リソースの表示名: プランが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

1. アクションが実行されたプロジェクトで、管理コンソールに移動します。
2. [アプリ マネージャー] タブで、保護されなくなった影響を受けるアプリを見つけて、それぞれのバックアップ ポリシーを確認します。

Inhibit System Recovery: Google Cloud Backup and DR delete template

Security Command Center は、監査ログを調べて、テンプレートの異常な削除を検出します。テンプレートは、複数のアプリケーションに適用できるバックアップの基本構成です。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR delete template の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • テンプレート名: バックアップの頻度、スケジュール、保持期間を定義する一連のポリシーの名前
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: テンプレートを削除したプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパル メール] 項目で、サービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

1. アクションが実行されたプロジェクトで、管理コンソールに移動します。
2. [アプリ マネージャー] タブで、保護されなくなった影響を受けるアプリを見つけて、それぞれのバックアップ ポリシーを確認します。
3. テンプレートを再度追加するには、[バックアップ プラン] タブに移動し、[テンプレート] を選択してから、[テンプレート] の作成オプションを選択します。

Inhibit System Recovery: Google Cloud Backup and DR delete policy

ポリシーの削除を検出するために監査ログが調べられます。ポリシーは、バックアップの取得方法と保存場所を定義します。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR delete policy の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • ポリシー名: バックアップの頻度、スケジュール、保持期間を定義する、1 つのポリシーの名前
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: ポリシーが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのメール] フィールドにあるサービス アカウントのオーナーに連絡します。 正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。 1. アクションが実行されたプロジェクトで、管理コンソールに移動します。 2. [アプリ マネージャー] タブで、影響を受けるアプリを選択し、そのアプリに適用されている [ポリシー] の設定を確認します。

Inhibit System Recovery: Google Cloud Backup and DR delete profile

プロファイルの削除を検出するために監査ログが調べられます。プロファイルは、バックアップの保存に使用するストレージ プールを定義します。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR delete profile の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • プロファイル名: アプリケーションと VM データのバックアップを保存するストレージ ターゲットを指定します
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: プロファイルが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのメール] フィールドにあるサービス アカウントのオーナーに連絡します。 正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。 1. アクションが実行されたプロジェクトで、管理コンソールに移動します。 2. [バックアップ プラン] タブで、[プロファイル] を選択してすべてのプロファイルのリストを表示します。3. プロファイルを見直して、必要なプロファイルがすべて設定されていることを確認します。4. 削除されたプロファイルが誤って削除された場合は、[プロファイルを作成] を選択して、Backup and DR アプライアンスのストレージ ターゲットを定義します。

Inhibit System Recovery: Google Cloud Backup and DR delete storage pool

ストレージ プールの削除を検出するために監査ログが調べられます。ストレージ プールは、Cloud Storage バケットを Backup and DR に関連付けます。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR delete storage pool の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • ストレージ プール名: バックアップが保存されるストレージ バケットの名前
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: ストレージ プールが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのメール] フィールドにあるサービス アカウントのオーナーに連絡します。 正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。 1. アクションが実行されたプロジェクトで、管理コンソールに移動します。 2. [管理] タブで、[ストレージ プール] を選択してすべてのストレージ プールのリストを表示します。3. バックアップ アプライアンスとストレージ プールの関連付けを確認します。4. アクティブ アプライアンスに関連付けられたストレージ プールがない場合は、[OnVault Pool を追加] を選択して再度追加します。

Data Destruction: Google Cloud Backup and DR expire image

悪意のある行為者がバックアップ イメージの削除をリクエストしました。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR expire image の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • ポリシー名: バックアップの頻度、スケジュール、保持期間を定義する、1 つのポリシーの名前
     • テンプレート名: バックアップの頻度、スケジュール、保持期間を定義する一連のポリシーの名前
     • プロファイル名: アプリケーションと VM データのバックアップを保存するストレージ ターゲットを指定します
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: バックアップ イメージが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのメール] フィールドにあるサービス アカウントのオーナーに連絡します。 正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。 1. アクションが実行されたプロジェクトで、管理コンソールに移動します。 2. [モニタリング] タブに移動して [ジョブ] を選択し、バックアップ削除ジョブのステータスを確認します。 3. 削除ジョブが承認されていない場合は、IAM 権限に移動して、バックアップ データにアクセスできるユーザーを確認します。

Data Destruction: Google Cloud Backup and DR expire all images

悪意のある行為者が、アプリケーションに関連付けられているすべてのバックアップ イメージを削除するようリクエストしました。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR expire all images の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • ポリシー名: バックアップの頻度、スケジュール、保持期間を定義する、1 つのポリシーの名前
     • テンプレート名: バックアップの頻度、スケジュール、保持期間を定義する一連のポリシーの名前
     • プロファイル名: アプリケーションと VM データのバックアップを保存するストレージ ターゲットを指定します
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: バックアップ イメージが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのメール] フィールドにあるサービス アカウントのオーナーに連絡します。 正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。 1. アクションが実行されたプロジェクトで、管理コンソールに移動します。 2. [モニタリング] タブに移動して [ジョブ] を選択し、バックアップ削除ジョブのステータスを確認します。 3. 削除ジョブが承認されていない場合は、IAM 権限に移動して、バックアップ データにアクセスできるユーザーを確認します。

Data Destruction: Google Cloud Backup and DR remove appliance

バックアップおよびリカバリ アプライアンスの削除を検出するために監査ログが調べられます。バックアップとリカバリのアプライアンスは、バックアップ オペレーションに不可欠なコンポーネントです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR remove appliance の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • アプライアンス名: Backup and DR に接続されているデータベースまたは VM の名前
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: アプライアンスが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのメール] フィールドにあるサービス アカウントのオーナーに連絡します。 正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。 1. アクションが実行されたプロジェクトで、管理コンソールに移動します。 2. [アプリ マネージャー] タブで、保護されなくなったアプリケーションを見つけて、それぞれのバックアップ ポリシーを確認します。 3. 新しいアプライアンスを作成して、保護されていないアプリに保護を再適用するには、Google Cloud コンソールで [Backup and DR] に移動し、[別のバックアップまたは復元アプライアンスをデプロイする] オプションを選択します。 4. [ストレージ] メニューで、ストレージ ターゲットを使用して新しい各アプライアンスを構成します。アプライアンスを構成すると、アプリケーションのプロファイルを作成するときにオプションとして表示されます。

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection は、監査ログを調べて、バックアップと DR サービス アプライアンスでのバックアップの有効期限が短縮されたかどうかを検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Impact: Google Cloud Backup and DR reduced backup expiration の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • 説明: 検出に関する情報
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザーまたはサービス アカウント
   • 影響を受ける 1 個のリソース
     • リソースの表示名: バックアップの有効期限が短縮されたプロジェクト。
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク。
     • Logging URI: ログ エクスプローラを開くリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのサブジェクト] フィールドにあるサービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

1. アクションが実行されたプロジェクトで、管理コンソールに移動します。
2. [アプリ マネージャー] タブで、バックアップの有効期限が短縮されたアプリケーションを見つけて、有効期限がプリンシパルによって意図されたものであることを確認します。
3. アプリケーションの新しいバックアップを開始するには、[Manage Backup Configurations] を選択して、オンデマンド バックアップを作成するか、新しいバックアップをスケジュールします。

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection は、監査ログを調べて、バックアップの頻度を低下させるためにバックアップ プランが変更されたかどうかを検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Impact: Google Cloud Backup and DR reduced backup frequency の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • 説明: 検出に関する情報
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザーまたはサービス アカウント
   • 影響を受ける 1 個のリソース
     • リソースの表示名: バックアップの頻度が低下されたプロジェクト。
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク。
     • Logging URI: ログ エクスプローラを開くリンク。

ステップ 2: 攻撃とレスポンスの手法を調査する

[プリンシパルのサブジェクト] フィールドにあるサービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

1. アクションが実行されたプロジェクトで、管理コンソールに移動します。
2. [アプリ マネージャー] タブで、バックアップの頻度が低下したアプリケーションを見つけて、変更がプリンシパルによって意図されたものであることを確認します。
3. アプリケーションの新しいバックアップを開始するには、[Manage Backup Configurations] を選択して、オンデマンド バックアップを作成するか、新しいバックアップをスケジュールします。

Impact: Suspicious Kubernetes Container Names - Coin Mining

誰かが、一般的な暗号通貨マイナーと同様の命名規則で Pod をデプロイしました。これは、クラスタへの初期アクセスを達成した攻撃者が暗号通貨のマイニングにクラスタのリソースを使用する試みである可能性があります。詳細については、このアラートのログ メッセージをご覧ください。

1. Pod が正当であることを確認します。
2. Cloud Logging の監査ログを参照して、Pod またはプリンシパルによる悪意のあるアクティビティを示す徴候が他にないか確認します。
3. プリンシパルがサービス アカウント（IAM または Kubernetes）でない場合は、サービス アカウントのオーナーに連絡して、正当なオーナーがそのアクションを実行したかどうかを確認します。
4. プリンシパルがサービス アカウント（IAM または Kubernetes）である場合は、アクションのソースを特定して、正当性を判断します。
5. Pod が正当ではない場合は、その Pod、関連するすべての RBAC バインディング、ワークロードが使用したサービス アカウント、その作成を許可したサービス アカウントを削除します。

Lateral Movement: Modified Boot Disk Attached to Instance

監査ログを確認することで、Compute Engine インスタンス リソース間での不審なディスク移動を検出します。変更されている可能性のあるブートディスクが Compute Engine にアタッチされています。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Lateral Movement: Modify Boot Disk Attaching to Instance の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のフィールドの値をメモします。

   検出された内容の以下のフィールド:

   • プリンシパルのメール: アクションを実行したサービス アカウント
   • サービス名: サービス アカウントによってアクセスされた Google Cloud サービスの API 名
   • メソッド名: 呼び出されたメソッド

ステップ 2: 攻撃とレスポンスの手法を調査する

1. 関連付けられているサービス アカウントのアクティビティを調査するには、Activity Analyzer などのサービス アカウント ツールを使用します。
2. [プリンシパルのメール] フィールドにあるサービス アカウントのオーナーに連絡します。正当なオーナーが操作を行ったかどうかを確認します。

ステップ 3: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 操作が行われたプロジェクトのオーナーに連絡します。
• Compute Engine VM インスタンスでセキュアブートを使用することを検討してください。
• 不正使用された可能性のあるサービス アカウントを削除し、不正使用された可能性のあるプロジェクトのサービス アカウントのアクセスキーをすべてローテーションして削除することを検討します。削除後は、このサービス アカウントを認証に使用するアプリケーションにアクセスできなくなります。続行する前に、セキュリティ チームは影響を受けるすべてのアプリケーションを特定し、アプリケーションのオーナーと協力してビジネスの継続性を確保する必要があります。
• セキュリティ チームと協力して、覚えのないリソース（Compute Engine インスタンス、スナップショット、サービス アカウント、IAM ユーザーなど）を特定します。承認済みアカウントで作成されていないリソースを削除します。
• Google Cloud サポートからの通知に従って対応します。

Privilege Escalation: AlloyDB Over-Privileged Grant

AlloyDB for PostgreSQL データベース（またはデータベース内のすべての関数またはプロシージャ）に対するすべての権限が 1 人以上のデータベース ユーザーに付与されているかどうかを検出します。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: AlloyDB Over-Privileged Grant の検出結果を開きます。

2. 検出結果の詳細パネルの [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • データベース表示名: 影響を受けた AlloyDB for PostgreSQL インスタンスのデータベース名。
     • データベースのユーザー名: 過剰な権限を付与した PostgreSQL ユーザー。
     • データベース クエリ: 実行して権限を付与した PostgreSQL クエリ。
     • データベース譲受人: 過剰な権限の譲受人。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 影響を受けた AlloyDB for PostgreSQL インスタンスのリソース名。
     • 親の完全な名前: AlloyDB for PostgreSQL インスタンスのリソース名。
     • プロジェクトのフルネーム: AlloyDB for PostgreSQL インスタンスを含む Google Cloud プロジェクト。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。

3. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: データベース権限を確認する

1. AlloyDB for PostgreSQL インスタンスに接続します。
2. 次のアクセス権を一覧表示します。
   • データベース。\l または \list メタコマンドを使用して、[データベース表示名] に表示されているデータベースに割り当てられた権限を確認します（ステップ 1 から）。
   • 関数またはプロシージャ。\df メタコマンドを使用して、[データベースの表示名] に表示されたデータベース内の関数またはプロシージャに割り当てられている権限を確認します（ステップ 1 から）。

ステップ 3: ログを確認する

ステップ 4: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Exfiltration Over Web Service）を確認します。
2. 追加の修復手順が必要かどうかを判断するために、調査結果を MITRE の調査と組み合わせます。

ステップ 5: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• 過剰な権限が付与されたインスタンスのオーナーに連絡してください。
• 調査が完了するまで、データベース譲受人に表示されている譲受人のすべての権限を取り消すことを検討してください。
• データベース（ステップ 1 のデータベース表示名から）へのアクセスを制限するには、譲受人（ステップ 1 のデータベース譲受人から）から不要な権限を取り消します。

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

AlloyDB for PostgreSQL データベースのスーパーユーザー アカウント（postgres）がユーザー テーブルに書き込むタイミングを検出します。通常、スーパーユーザー（非常に幅広いアクセス権を持つロール）は、ユーザー テーブルへの書き込みに使用するべきではありません。通常の日常的なアクティビティでは、アクセスが制限されているユーザー アカウントを使用する必要があります。スーパーユーザーがユーザー テーブルに書き込む場合は、攻撃者が権限を昇格したか、デフォルトのデータベース ユーザーを不正使用してデータを変更している可能性があります。また、問題ではありませんが、安全でない手法であることを示している場合もあります。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Privilege Escalation: AlloyDB Database Superuser Writes to User Tables の検出結果を開きます。

2. 検出結果の詳細パネルの [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • データベース表示名: 影響を受けた AlloyDB for PostgreSQL インスタンスのデータベース名。
     • データベースのユーザー名: スーパーユーザー。
     • データベース クエリ: ユーザー テーブルへの書き込み中に実行された SQL クエリ。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 影響を受けた AlloyDB for PostgreSQL インスタンスのリソース名。
     • 親の完全な名前: AlloyDB for PostgreSQL インスタンスのリソース名。
     • プロジェクトのフルネーム: AlloyDB for PostgreSQL インスタンスを含む Google Cloud プロジェクト。
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。

3. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: ログを確認する

1. Google Cloud コンソールで、ステップ 1 の cloudLoggingQueryURI のリンクをクリックしてログ エクスプローラに移動します。[ログ エクスプローラ] ページに、関連する AlloyDB for PostgreSQL インスタンスに関するすべてのログが表示されます。
2. 次のフィルタを使用して、PostgreSQL の pgaudit ログを確認します。このログにはスーパーユーザーによって実行されたクエリが含まれています。
   • protoPayload.request.user="postgres"

ステップ 3: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Exfiltration Over Web Service）を確認します。
2. 追加の修復手順が必要かどうかを判断するために、調査結果を MITRE の調査と組み合わせます。

ステップ 4: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• データベースへの接続が許可されているユーザーを確認します。
• スーパーユーザーのパスワードを変更することを検討してください。
• インスタンスで使用する各種クエリに対して、アクセスが制限されたユーザーを新しく作成することを検討してください。
  • 新しいユーザーには、クエリの実行に必要な権限のみを付与します。
  • AlloyDB for PostgreSQL インスタンスに接続するクライアントの認証情報を更新します。

Compute Engine 管理メタデータの検出

Persistence: GCE Admin Added SSH Key

Persistence: GCE Admin Added Startup Script

Google Workspace のログの検出

Google Workspace のログを Cloud Logging と共有すると、Event Threat Detection は複数の Google Workspace の脅威に対して検出結果を生成できます。Google Workspace のログは組織レベルであるため、組織レベルで Security Command Center を有効にした場合のみ、Event Threat Detection がスキャンを実行します。

Event Threat Detection はログイベントを拡充し、検出結果を Security Command Center に書き込みます。次の表に、Google Workspace の脅威、関連する MITRE ATT&CK フレームワークのエントリ、検出結果をトリガーするイベントの詳細を示します。特定のフィルタを使用してログを調べたり、すべての情報を組み合わせて Google Workspace の脅威に対応することもできます。

Initial Access: Disabled Password Leak

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Initial Access: Suspicious Login Blocked

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Initial Access: Account Disabled Hijacked

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Impair Defenses: Two Step Verification Disabled

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Initial Access: Government Based Attack

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Persistence: SSO Enablement Toggle

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Persistence: SSO Settings Changed

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Impair Defenses: Strong Authentication Disabled

プロジェクト レベルで Security Command Center を有効にした場合、この検出結果は使用できません。

Google Workspace の脅威に対処する

Google Workspace の検出結果は、Security Command Center を組織レベルで有効にした場合にのみ使用できます。プロジェクト レベルで有効にしている場合、Google Workspace ログをスキャンすることはできません。

Google Workspace 管理者は、サービスの次のセキュリティ ツールを使用して脅威を解決できます。

• Google Workspace アラート センター
• Google Workspace セキュリティ センター

このツールにはアラート、セキュリティ ダッシュボード、セキュリティの推奨事項が含まれ、脅威の調査と解決に役立ちます。

Google Workspace 管理者でない場合は、次の手順を行います。

• アカウントにアクセスできる場合は、パスワードを変更または再設定し、2 段階認証プロセスを有効にします。
• Google Workspace 管理者に問い合わせるか、Google Workspace アカウントを管理している社内のチームに連絡してください。この検出結果は、アカウント侵害の可能性を示しています。

Cloud IDS 脅威検出

Cloud IDS: THREAT_ID

Cloud IDS の検出結果は Cloud IDS によって生成されます。これは、脅威について Google Cloud リソースとの間のトラフィックをモニタリングするセキュリティ サービスです。Cloud IDS は脅威を検出すると、送信元 IP アドレス、宛先アドレス、ポート番号などの脅威に関する情報を Event Threat Detection に送信し、脅威の検出結果を発行します。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Cloud IDS: THREAT_ID の検出結果を開きます。

2. [検出の詳細] の [概要] タブで、次のセクションに表示される値を確認します。

   • 検出された内容（特に次のフィールド）:
     • プロトコル: 使用されたネットワーク プロトコル
     • イベント時間: イベントが発生した日時
     • 説明: 検出結果の詳細
     • 重大度: アラートの重大度
     • 宛先 IP: ネットワーク トラフィックのターゲット IP アドレス
     • 宛先ポート: ネットワーク トラフィックのターゲット ポート
     • 送信元 IP: ネットワーク トラフィックの送信元 IP アドレス
     • 送信元ポート: ネットワーク トラフィックの送信元ポート
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: 脅威が存在するネットワークを含むプロジェクト
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Cloud IDS Logging エントリへのリンク - これらのエントリには、Palo Alto Networks の Threat Vault を検索するために必要な情報があります。
   • 検出サービス
     • 検出結果カテゴリ: Cloud IDS の脅威の名前

3. 検出結果の完全な JSON を表示するには、[JSON] タブをクリックします。

ステップ 2: 攻撃と対応の手法を検索する

検出結果の詳細を確認したら、脅威アラートの調査に関する Cloud IDS ドキュメントを参照して、適切な対応を決定してください。

検出結果の詳細で [Cloud Logging URI] フィールドのリンクをクリックすると、元のログエントリで検出されたイベントの詳細を確認できます。

Container Threat Detection レスポンス

Container Threat Detection の詳細については、Container Threat Detection の仕組みをご覧ください。

Added Binary Executed

元のコンテナ イメージの一部ではなかったバイナリが実行されました。一般に、攻撃者は最初の侵害後に不正なツールやマルウェアをインストールします。コンテナが不変であることを確認することは、重要なベスト プラクティスです。組織がこのベスト プラクティスに準拠していない可能性があるため、この検出結果の重大度は低いです。バイナリのハッシュが既知のセキュリティ侵害インジケーター（IoC）である場合は、対応する Execution: Added Malicious Binary Executed 検出結果があります。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Added Binary Executed の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: 追加されたバイナリの絶対パス。
     • 引数: 追加されたバイナリを呼び出すときに指定する引数。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。

3. [JSON] をクリックし、次のフィールドを確認します。

   • resource:
     • project_display_name: クラスタを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • Container_Image_Uri: デプロイされているコンテナ イメージの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

4. このコンテナで同時に発生した他の検出結果を特定します。関連する検出結果は、このアクティビティがベスト プラクティスに準拠していないのではなく、悪意のあるものであることを示している可能性があります。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name にリストされているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタと、Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   以下を置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 次のコマンドを実行して、追加されたバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   local_file は、追加されたライブラリを格納するローカル ファイルのパスに置き換えます。

6. 次のコマンドを実行して、コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer、Native API）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• バイナリをコンテナに含める予定の場合は、そのバイナリを含めてコンテナ イメージを再ビルドします。こうして、コンテナを不変にすることができます。
• または、コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Added Library Loaded

元のコンテナ イメージに含まれていないライブラリが読み込まれました。コード実行保護を回避し、悪意のあるコードを非表示にするために、攻撃者が既存のプログラムに悪意のあるプログラムを読み込むおそれがあります。コンテナが不変であることを確認することは、重要なベスト プラクティスです。組織がこのベスト プラクティスに従っていない可能性があるため、これは重大度の低い検出結果です。バイナリのハッシュが既知のセキュリティ侵害インジケーター（IoC）である場合、対応する Execution: Added Malicious Library Loaded 検出結果があります。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Added Library Loaded の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: ライブラリを読み込んだプロセス バイナリのフルパス。
     • ライブラリ: 追加されたライブラリの詳細。
     • 引数: プロセス バイナリを呼び出すときに指定する引数。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: クラスタの完全なリソース名。

3. [JSON] タブをクリックして、次のフィールドを確認します。

   • resource:
     • project_display_name: アセットを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • Container_Image_Uri: 実行されているコンテナ イメージの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

4. このコンテナで同時に発生した他の検出結果を特定します。関連する検出結果は、このアクティビティがベスト プラクティスに準拠していないのではなく、悪意のあるものであることを示している可能性があります。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. resource.name に表示されるクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name にリストされているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタと、Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. 次のコマンドを実行して、追加されたライブラリを取得します。

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   local_file は、追加されたライブラリを格納するローカル ファイルのパスに置き換えます。

6. 次のコマンドを実行して、コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer、Shared Modules）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• ライブラリをコンテナに含める予定の場合は、ライブラリを含めてコンテナ イメージを再ビルドします。こうして、コンテナを不変にすることができます。
• または、コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Added Malicious Binary Executed

元のコンテナ イメージの一部でなかった悪意のあるバイナリが実行されました。一般に、攻撃者は最初の侵害後に不正なツールやマルウェアをインストールします。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Execution: Added Malicious Binary Executed の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: 追加されたバイナリの絶対パス。
     • 引数: 追加されたバイナリを呼び出すときに提供される引数。
     • コンテナ: 影響を受けるコンテナの名前。
     • コンテナ URI: デプロイされているコンテナ イメージの名前。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。
   • 関連リンク（特に次のフィールド）:
     • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

3. [JSON] タブをクリックして、次のフィールドを確認します。

   • sourceProperties:
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name に表示されているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタと、Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   以下を置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 追加された悪意のあるバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   local_file は、追加された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer、Native API）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。
3. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Added Malicious Library Loaded

元のコンテナ イメージに含まれていないライブラリが読み込まれました。コード実行保護を回避し、悪意のあるコードを非表示にするために、攻撃者が既存のプログラムに悪意のあるプログラムを読み込むおそれがあります。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Execution: Added Malicious Library Loaded の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: ライブラリを読み込んだプロセス バイナリのフルパス。
     • ライブラリ: 追加されたライブラリの詳細。
     • 引数: プロセス バイナリを呼び出すときに指定する引数。
     • コンテナ: 影響を受けるコンテナの名前。
     • コンテナ URI: デプロイされているコンテナ イメージの名前。
   • 影響を受けているリソース（特に次のフィールド）:
     • 完全なリソース名: クラスタの完全なリソース名。
   • 関連リンク（特に次のフィールド）:
     • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

3. [JSON] タブをクリックして、次のフィールドを確認します。

   • sourceProperties:
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 検出結果の詳細の [概要] タブにある [リソースの完全な名前] 行のクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name に表示されているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタと、Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. 追加された悪意のあるライブラリを取得します。

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   local_file は、追加された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer、Shared Modules）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。
3. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているライブラリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Built in Malicious Binary Executed

次のバイナリで実行されたバイナリ:

• 元のコンテナ イメージに含まれていた。
• 脅威インテリジェンスに基づいて悪意があると識別された。

攻撃者は、悪意のあるバイナリがコンテナ イメージに挿入される、コンテナ イメージ リポジトリまたは作成パイプラインをコントロールします。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Execution: Built in Malicious Binary Executed の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: 組み込みバイナリの絶対パス。
     • 引数: 組み込みバイナリを呼び出すときに指定する引数。
     • コンテナ: 影響を受けるコンテナの名前。
     • コンテナ URI: デプロイされているコンテナ イメージの名前。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。
   • 関連リンク（特に次のフィールド）:
     • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

3. [JSON] をクリックし、次のフィールドを確認します。

   • sourceProperties:
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name に表示されているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタと、Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   以下を置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 組み込みの悪意のあるバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   local_file は、組み込みの悪意のあるバイナリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer、Native API）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。
3. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Malicious Python executed

機械学習モデルが、実行された Python コードを悪意があるものとして識別しました。攻撃者は、Python を使用してツールを転送し、バイナリなしでコマンドを実行します。コンテナが不変であることを確認することは、重要なベスト プラクティスです。 ツールの転送にスクリプトを使用すると、攻撃者が Ingress ツール転送の手法を模倣し、望ましくない検出が発生する可能性があります。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Execution: Malicious Python executed の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: スクリプトを呼び出したインタープリタの詳細。
     • スクリプト: ディスク上のスクリプト名の絶対パス。この属性は、ディスクに書き込まれたスクリプトに対してのみ表示され、リテラル スクリプトの実行では表示されません（例: python3 -c）。
     • 引数: スクリプトの起動時に指定する引数
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。

3. 検出結果の詳細ビューで、[JSON] タブをクリックします。

4. [JSON] で、次のフィールドを確認します。

   • finding:
     • processes:
     • script:
       • contents: 実行されたスクリプトの内容。パフォーマンス上の理由で切り捨てられる場合があります。これは調査に役立ちます
       • sha256: script.contents の SHA-256 ハッシュ
   • resource:
     • project_display_name: アセットを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • Container_Image_Uri: 実行されているコンテナ イメージの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

5. このコンテナで同時に発生した他の検出結果を特定します。たとえば、スクリプトがバイナリをドロップした場合は、バイナリに関連する検出結果を確認します。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。VM_Instance_Name にリストされているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes Engine の [ワークロード] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、resource.name に表示されているクラスタと Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. resource.labels.cluster_name に表示されたクラスタの名前をクリックします。

3. [クラスタ] ページで [接続] をクリックし、[Cloud Shell で実行] をクリックします。

   Cloud Shell が起動し、ターミナルにクラスタに対するコマンドが挿入されます。

4. Enter キーを押します。[Cloud Shell を承認] ダイアログが表示されたら、[承認] をクリックします。

5. 次のコマンドを実行して、コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ「Command and Scripting Interpreter, Ingress Tool Transfer（英語）」を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• Python がコンテナに意図した変更を加えた場合は、変更が不要になるようにコンテナ イメージを再構築します。こうして、コンテナをimmutableにすることができます。
• または、コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Modified Malicious Binary Executed

次のバイナリで実行されたバイナリ:

• 元のコンテナ イメージに含まれていた。
• コンテナ ランタイム中に変更された。
• 脅威インテリジェンスに基づいて悪意があると識別された。

一般に、攻撃者は最初の侵害後に不正なツールやマルウェアをインストールします。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Execution: Modified Malicious Binary Executed の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: 変更されたバイナリの絶対パス。
     • 引数: 変更されたバイナリを呼び出すときに提供される引数。
     • コンテナ: 影響を受けるコンテナの名前。
     • コンテナ URI: デプロイされているコンテナ イメージの名前。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。
   • 関連リンク（特に次のフィールド）:
     • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

3. [JSON] をクリックし、次のフィールドを確認します。

   • sourceProperties:
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name に表示されているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタと、Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   以下を置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 変更された悪意のあるバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   local_file は、変更された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer、Native API）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。
3. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Modified Malicious Library Loaded

次のライブラリで読み込まれたライブラリ:

• 元のコンテナ イメージに含まれていた。
• コンテナ ランタイム中に変更された。
• 脅威インテリジェンスに基づいて悪意があると識別された。

コード実行保護を回避し、悪意のあるコードを非表示にするために、攻撃者が既存のプログラムに悪意のあるプログラムを読み込むおそれがあります。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に沿って、Execution: Modified Malicious Library Loaded の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: ライブラリを読み込んだプロセス バイナリのフルパス。
     • ライブラリ: 変更されたライブラリの詳細。
     • 引数: プロセス バイナリを呼び出すときに指定する引数。
     • コンテナ: 影響を受けるコンテナの名前。
     • コンテナ URI: デプロイされているコンテナ イメージの名前。
   • 影響を受けているリソース（特に次のフィールド）:
     • 完全なリソース名: クラスタの完全なリソース名。
   • 関連リンク（特に次のフィールド）:
     • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

3. [JSON] タブをクリックして、次のフィールドを確認します。

   • sourceProperties:
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. resource.name に表示されるクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name に表示されているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタと、Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. 変更された悪意のあるライブラリを取得します。

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   local_file は、変更された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer、Shared Modules）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。
3. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているライブラリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Malicious Script Executed

機械学習モデルが、実行された Bash コードを悪意があるものとして識別しました。 攻撃者は、Bash を使用してツールを転送し、バイナリなしでコマンドを実行します。コンテナが不変であることを確認することは、重要なベスト プラクティスです。 ツールの転送にスクリプトを使用すると、攻撃者が Ingress ツール転送の手法を模倣し、望ましくない検出が発生する可能性があります。

この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Malicious Script Executed の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: スクリプトを呼び出したインタープリタの詳細。
     • スクリプト: ディスク上のスクリプトの名前の絶対パス。この属性は、ディスクに書き込まれたスクリプトに対してのみ表示され、リテラル スクリプトの実行では表示されません（例: bash -c）。
     • 引数: スクリプトの起動時に指定する引数
   • 影響を受けているリソース（特に次のフィールド）:
     • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。

3. 検出結果の詳細ビューで、[JSON] タブをクリックします。

4. [JSON] で、次のフィールドを確認します。

   • finding:
     • processes:
     • script:
       • contents: 実行されたスクリプトの内容。パフォーマンス上の理由で切り捨てられる場合があります。これは調査に役立ちます
       • sha256: script.contents の SHA-256 ハッシュ
   • resource:
     • project_display_name: アセットを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • Container_Image_Uri: 実行されているコンテナ イメージの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

5. このコンテナで同時に発生した他の検出結果を特定します。たとえば、スクリプトがバイナリをドロップした場合は、バイナリに関連する検出結果を確認します。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [検出の詳細] の [概要] タブの [リソースの完全な名前] 行に表示されているクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。VM_Instance_Name にリストされているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes Engine の [ワークロード] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、resource.name に表示されているクラスタと Pod_Namespace に表示されている Pod の名前空間でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. resource.labels.cluster_name に表示されたクラスタの名前をクリックします。

3. [クラスタ] ページで [接続] をクリックし、[Cloud Shell で実行] をクリックします。

   Cloud Shell が起動し、ターミナルにクラスタに対するコマンドが挿入されます。

4. Enter キーを押します。[Authorize Cloud Shell] ダイアログが表示されたら、[承認] をクリックします。

5. 次のコマンドを実行して、コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Command and Scripting Interpreter、Ingress Tool Transfer）を確認します。
2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• スクリプトがコンテナに意図した変更を行っていた場合は、変更が不要になるようにコンテナ イメージを再構築します。こうして、コンテナを不変にすることができます。
• または、コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Malicious URL Observed

Container Threat Detection は、実行可能プロセスの引数リストに悪意のある URL を検出しました。攻撃者は、悪意のある URL を介してマルウェアや悪意のあるライブラリを読み込む可能性があります。

この検出結果に対応するには、次の手順を実行します。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Malicious URL Observed の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • URI: 検出された悪意のある URI。
     • 追加のバイナリ: 悪意のある URL を含む引数を受け取ったプロセス バイナリのフルパス。
     • 引数: プロセス バイナリを呼び出すときに指定する引数。
     • 環境変数: プロセス バイナリが呼び出されたときに有効だった環境変数。
     • コンテナ: コンテナの名前。
     • Kubernetes Pod: Pod 名と Namespace。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソース表示名: 影響を受けるリソースの名前。
     • 完全なリソース名: クラスタの完全なリソース名。完全なリソース名には、次の情報が含まれます。
       • クラスタを含むプロジェクト: projects/PROJECT_ID
       • クラスタが配置されているロケーション（zone/ZONE または locations/LOCATION）
       • クラスタの名前（projects/CLUSTER_NAME）

3. [JSON] タブの sourceProperties 属性にある VM_Instance_Name プロパティの値をメモします。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. 必要に応じて Google Cloud コンソールのツールバーで、[完全なリソース名]（resource.name）に表示されているプロジェクトを選択します。プロジェクト名は、完全なリソース名の /projects/ の後にあります。

3. 検出結果の概要の [リソース表示名]（resource.display_name）でメモしたクラスタ名をクリックします。[クラスタ] ページが開きます。

4. **クラスタの詳細ページの [メタデータ] セクションで、クラスタ オーナーを特定する情報など、脅威の解決に役立ちそうなユーザー定義の情報をメモします。

5. [ノード] タブをクリックします。

6. リストされたノードから、先ほどの検出結果の JSON でメモした VM_Instance_Name の値と一致するノードを選択します。

7. [ノードの詳細] ページの [詳細] タブで、[アノテーション] セクション内の container.googleapis.com/instance_id アノテーションの値をメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes Engine の [ワークロード] に移動

2. 必要に応じて Google Cloud コンソールのツールバーで、検出結果の概要に含まれるクラスタの [完全なリソース名]（resource.name）でメモしたプロジェクトを選択します。

3. [システム ワークロードを表示] をクリックします。

4. 検出結果の概要の [完全なリソース名]（resource.name）でメモしたクラスタ名、および必要に応じてメモした Pod の [名前空間]（kubernetes.pods.ns）でワークロードのリストをフィルタリングします。

5. 前の検出結果の JSON でメモした VM_Instance_Name プロパティの値と一致するワークロード名をクリックします。[Pod の詳細] ページが開きます。

6. [Pod の詳細] ページで、脅威の解決に役立つ Pod に関する情報をメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. 必要に応じて Google Cloud コンソールのツールバーで、[完全なリソース名]（resource.name）に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod（kubernetes.pods.name）の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • POD_NAME
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. resource.labels.cluster_name に表示されたクラスタの名前をクリックします。

3. [クラスタ] ページで [接続] をクリックし、[Cloud Shell で実行] をクリックします。

   Cloud Shell が起動し、ターミナルにクラスタに対するコマンドが挿入されます。

4. Enter キーを押します。[Authorize Cloud Shell] ダイアログが表示されたら、[承認] をクリックします。

5. 次のコマンドを実行して、コンテナ環境に接続します。

     kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
   

   CONTAINER_NAME は、前に検出結果の概要でメモしたコンテナの名前に置き換えます。

   このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

ステップ 6: 攻撃とレスポンスの手法を調査する

1. セーフ ブラウジングのサイト ステータスで、URL が悪意のあるものとして分類される理由の詳細を確認します。
2. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer）を確認します。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 7: レスポンスを実装する

次の対応計画は、この検出結果に適切な場合もありますが、運用に影響する可能性もあります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。

• コンテナが不正使用されているプロジェクトのオーナーに連絡します。
• 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Reverse Shell

リモート接続ソケットへのストリーム リダイレクトで始まるプロセス。ネットワーク接続されたシェルを生成すると、攻撃者が限られた初期侵害の後に、任意のアクションを実行できるようになります。この検出結果に対応する手順は次のとおりです。

ステップ 1: 検出結果の詳細を確認する

1. 検出結果の確認の説明に従って、Reverse Shell の検出結果を開きます。 検出結果の詳細パネルが開き、[概要] タブが表示されます。

2. [概要] タブで、次のセクションの情報を確認します。

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: リモート ソケットへのストリーム リダイレクトで始まるプロセスの絶対パス。
     • 引数: プロセス バイナリを呼び出すときに指定する引数
   • 影響を受けているリソース（特に次のフィールド）:
     • 完全なリソース名: クラスタの完全なリソース名。
     • プロジェクトのフルネーム:
   • 検出結果の詳細ビューで、[JSON] タブをクリックします。
   • [JSON] で、次のフィールドを確認します。
   • resource:
     • project_display_name: アセットを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。
     • Reverse_Shell_Stdin_Redirection_Dst_Ip: 接続のリモート IP アドレス
     • Reverse_Shell_Stdin_Redirection_Dst_Port: リモートポート
     • Reverse_Shell_Stdin_Redirection_Src_Ip: 接続のローカル IP アドレス
     • Reverse_Shell_Stdin_Redirection_Src_Port: ローカルポート
     • Container_Image_Uri: 実行されているコンテナ イメージの名前。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. resource.name に表示されるクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。 VM_Instance_Name にリストされているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、[Kubernetes Workloads] ページに移動します。

   Kubernetes ワークロードに移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. 必要に応じて、resource.name に表示されているクラスタと Pod_Namespace に表示されている Pod の Namespace でフィルタリングします。

4. Pod_Name に表示されている Pod を選択します。Pod とそのオーナーに関するメタデータをメモします。

ステップ 4: ログを確認する

1. Google Cloud コンソールで、[ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod_Name のポッドログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"