脅威の調査と対処

このドキュメントでは、悪意のある行為者による Google Cloud 環境での不審なアクティビティの検出結果を調査するための非公式なガイダンスを提供します。このドキュメントでは、Security Command Center の検出結果にコンテキストを追加するための追加リソースも提供します。以下の手順により、潜在的な攻撃で何が起きたのかを理解し、影響を受けるリソースに対して想定されるレスポンスを作成できます。

このページで説明した手法が、過去、現在または将来、直面した脅威に対して有効であるとは限りません。Security Command Center が脅威に対する公式の修復策を提供していない理由については、脅威の修復をご覧ください。

始める前に

検出結果とログの表示および編集、Google Cloud リソースの変更を行うには、適切な Identity and Access Management（IAM）のロールが必要です。Security Command Center でアクセスエラーが発生した場合は、管理者に支援を依頼してください。また、ロールの詳細については、アクセス制御をご覧ください。リソースエラーを解決する方法については、影響を受けたプロダクトのドキュメントをご覧ください。

脅威の検出結果について

Event Threat Detection は、Cloud Logging ログストリーム内のイベントを既知のセキュリティ侵害インジケーター（IoC）と照合して、セキュリティの検出結果を生成します。Google 社内のセキュリティ ソースによって開発された IoC は、潜在的な脆弱性と攻撃を識別します。Event Threat Detection は、ロギング ストリームの既知の敵対的な戦術、手法、手順を特定し、組織またはプロジェクトの過去の動作からの逸脱を検出することでも脅威を検出します。組織レベルで Security Command Center Premium ティアを有効にすると、Event Threat Detection は Google Workspace のログもスキャンできます。

Container Threat Detection は、コンテナのゲストカーネルで観測された下位レベルの行動を収集、分析して、検出結果を生成します。

結果は Security Command Center に書き込まれます。組織レベルで Security Command Center プレミアム ティアを有効にする場合は、検出結果を Cloud Logging に書き込むように構成することもできます。

検出結果の確認

Google Cloud コンソールで脅威の検出結果を確認する方法は次のとおりです。

  1. Google Cloud コンソールで、Security Command Center の [検出] ページに移動します。

    [検出結果] に移動

  2. 必要に応じて、Google Cloud プロジェクト、フォルダ、または組織を選択します。

    プロジェクト セレクタ

  3. [クイック フィルタ] セクションで、適切なフィルタをクリックして、[検出結果クエリの結果] テーブルに必要な検出結果を表示します。たとえば、[ソースの表示名] サブセクションで [Event Threat Detection] または [Container Threat Detection] を選択した場合、選択したサービスの検出結果のみが結果に表示されます。

    テーブルに、選択したソースに関する結果が表示されます。

  4. 特定の検出の詳細を表示するには、[Category] の下にある検出結果の名前をクリックします。[検出の詳細] ペインが開き、検出結果の詳細のサマリーが表示されます。

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

インシデントに関係するリソースの名前と数値形式の ID、環境変数、アセット プロパティを確認できます。この情報を使用して、影響を受けたリソースを迅速に分離し、イベントの潜在的な影響範囲を判断できます。

調査に役立つように、脅威の検出には、次の外部リソースへのリンクも含まれます。

  • MITRE ATT&CK フレームワークのエントリ。このフレームワークは、クラウド リソースに対する攻撃の手口を説明し、修復するためのガイダンスを提供します。

  • VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する、Alphabet 社のサービスです。利用可能な場合、[VirusTotal インジケーター] フィールドに VirusTotal へのリンクが表示されます。これにより、潜在的なセキュリティ問題をさらに調査できます。

    VirusTotal は、別途料金が設定され、使用上限と機能が異なるサービスです。お客様は、VirusTotal の API 使用ポリシーと関連する費用を理解し、遵守する責任があります。詳細については、VirusTotal のドキュメントをご覧ください。

以降のセクションでは、脅威の検出に対して想定される対応について説明します。

脅威の検出の無効化

脅威の検出の原因となった問題を解決した後、Security Command Center で検出結果の状態が自動的に INACTIVE に設定されることはありません。脅威の検出状態は、state プロパティを手動で INACTIVE に設定しない限り、ACTIVE のままです。

偽陽性の場合は、検出結果の状態を ACTIVE のままにして、代わりに検出結果をミュートすることを検討してください。

偽陽性が持続または繰り返し発生する場合は、ミュートルールを作成します。ミュートルールを設定すると、管理する必要のある検出結果の数を削減できるため、真の脅威が発生したときに簡単に特定できます。

真の脅威の場合、検出結果の状態を INACTIVE に設定する前に、脅威を排除し、検出された脅威、侵入の程度、およびその他の関連する検出結果や問題について徹底的な調査を行います。

検出結果をミュートするか、状態を変更するには、次のトピックをご覧ください。

Event Threat Detection レスポンス

Event Threat Detection の詳細については、Event Threat Detection の仕組みをご覧ください。

このセクションには、組織がこれらの検出器に対して推奨されるアクションを定義しているため、Event Threat Detection 用のカスタム モジュールが生成した検出結果に対するレスポンスは含まれまれていません。

Evasion: Access from Anonymizing Proxy

匿名プロキシからの異常なアクセスは、Cloud Audit Logs で匿名の IP アドレス（Tor IP アドレスなど）から発生した Google Cloud サービスの変更を調査することで検出されます。

これらの検出結果への対応方法は以下のとおりです。

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

  1. 検出結果の確認の説明に沿って、Evasion: Access from Anonymizing Proxy の検出結果を開きます。[検出の詳細] パネルが開き、[概要] タブが表示されます。

  2. [検出の詳細] パネルの [概要] タブで、次のセクションに表示されている値を確認します。

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

  3. 必要に応じて、[JSON] タブをクリックして、追加の検出結果フィールドを表示します。

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

  1. この検出結果タイプに対応する MITRE ATT＆CK フレームワークのエントリ（プロキシ: マルチホップ プロキシ）を確認します。
  2. [principalEmail] フィールドにあるアカウントのオーナーに問い合わせてください。正当なオーナーによって行われた操作かどうか確認してください。
  3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Defense Evasion: Breakglass Workload Deployment Created

Breakglass Workload Deployment Created は、Cloud Audit Logs を調査し、ブレークグラス フラグを使用して Binary Authorization コントロールをオーバーライドするワークロードへのデプロイがあるかどうかを確認することで検出されます。

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

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

  1. 検出結果の確認の説明に従って、Defense Evasion: Breakglass Workload Deployment Created の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

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

    • 検出された内容（特に次のフィールド）:
      • プリンシパルのメール: 変更を行ったアカウント。
      • メソッド名: 呼び出されたメソッド。
      • Kubernetes Pod: Pod 名と Namespace。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの表示名: デプロイが発生した GKE Namespace。
    • 関連リンク:
      • 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 フレームワーク エントリ（Defense Evasion: Breakglass Workload Deployment）を確認します。
  2. 検出結果の詳細の [概要] タブで、[関連する検出結果] 行の [関連する検出結果] リンクをクリックして、関連する検出結果を確認します。
  3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Defense Evasion: Breakglass Workload Deployment Updated

Breakglass Workload Deployment Updated は、Cloud Audit Logs を調査し、ブレークグラス フラグを使用して Binary Authorization コントロールをオーバーライドするワークロードへの更新があるかどうかを確認することで検出されます。

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

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

  1. 検出結果の確認の説明に従って、Defense Evasion: Breakglass Workload Deployment Updated の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

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

    • 検出された内容（特に次のフィールド）:
      • プリンシパルのメール: 変更を行ったアカウント。
      • メソッド名: 呼び出されたメソッド。
      • Kubernetes Pod: Pod 名と Namespace。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの表示名: 更新が発生した GKE Namespace。
    • 関連リンク:
      • 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 フレームワーク エントリ（Defense Evasion: Breakglass Workload Deployment）を確認します。
  2. 検出結果の詳細の [概要] タブで、[関連する検出結果] 行の [関連する検出結果] リンクをクリックして、関連する検出結果を確認します。
  3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

誰かが、証明書署名リクエスト（CSR）を手動で削除しました。CSR はガベージ コレクション コントローラによって自動的に削除されますが、悪意のある行為者が検出を回避するために手動で削除する可能性があります。削除された CSR が承認され発行された証明書に対するものの場合、悪意のある行為者は、クラスタにアクセスするための追加の認証方法を取得します。証明書に関連付けられている権限は、含まれるサブジェクトによって異なりますが、高度な権限が付与される場合があります。Kubernetes は証明書の取り消しをサポートしていません。詳細については、このアラートのログ メッセージをご覧ください。

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

Defense Evasion: Modify VPC Service Control

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

監査ログが調査され、保護機能の低下を招く VPC Service Controls 境界に対する変更が検出されます。以下に、いくつかの例を示します。

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

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

  1. 検出結果の確認の説明に沿って、Defense Evasion: Modify VPC Service Control の検出結果を開きます。[検出の詳細] パネルが開き、[概要] タブが表示されます。

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

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

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

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

    • sourceProperties
      • properties
        • name: 変更された VPC Service Controls の境界の名前
        • policyLink: 境界を制御するアクセス ポリシーへのリンク
        • delta: 保護機能が低下した境界に対する変更（REMOVE または ADD）
        • restricted_resources: この境界の制限に従うプロジェクト。プロジェクトを削除すると保護が縮小する
        • restricted_services: この境界の制限によって実行が禁止されるサービス。制限付きサービスを削除すると保護が減少する
        • allowed_services: この境界の制限下で実行できるサービス。許可されたサービスを追加すると、保護が縮小する
        • access_levels: 境界内のリソースへのアクセスを許可するように構成されたアクセスレベル。 アクセスレベルを追加すると保護機能が低下する

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

  1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。
  2. 次のフィルタを使用して、VPC Service Controls の変更に関連する管理アクティビティ ログを検索します。
    • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
    • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

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

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

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

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

  • VPC Service Controls のポリシーおよび境界のオーナーにお問い合わせください。
  • 調査が完了するまで、境界の変更を元に戻すことを検討してください。
  • 調査が完了するまで、境界を変更したプリンシパルの Access Context Manager ロールを取り消すことを検討してください。
  • 縮小された保護機能がどのように使用されているかを調査してください。たとえば、「BigQuery Data Transfer Service API」が有効になっているか、許可されたサービスとして追加されている場合は、そのサービスを開始したユーザーと転送するユーザーを確認します。

Defense Evasion: Potential Kubernetes Pod Masquerading

誰かが、通常のクラスタ オペレーションのために GKE が作成するデフォルトのワークロードと同様の命名規則で Pod をデプロイしました。この手法はマスカレーディングと呼ばれます。詳細については、このアラートのログ メッセージをご覧ください。

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

Discovery: Can get sensitive Kubernetes object check

悪意のある行為者が kubectl auth can-i get コマンドを使用して、GKE 内で照会可能な機密オブジェクトを特定しようとしています。具体的には、行為者は次のいずれかのコマンドを実行しました。

  • kubectl auth can-i get '*'
  • kubectl auth can-i get secrets
  • kubectl auth can-i get clusterroles/cluster-admin

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

  1. 検出結果の確認の説明に従って、Discovery: Can get sensitive Kubernetes object check の検出結果を開きます。

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

    • 検出された内容:
      • Kubernetes アクセス レビュー: SelfSubjectAccessReview k8s リソースに基づいてリクエストされたアクセスのレビュー情報。
      • プリンシパルのメール: 連絡をしたアカウント。
    • [影響を受けるリソース] の:
      • リソースの表示名: アクションが発生した Kubernetes クラスタ。
    • 関連リンク:
      • Cloud Logging URI: Logging エントリへのリンク。

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

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

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

    • resource.labels.cluster_name="CLUSTER_NAME"

    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      以下を置き換えます。

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

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

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

  1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Discovery）を確認します。
  2. クエリされたオブジェクトの機密性を確認し、ログを参照して、プリンシパルによる他の悪意のあるアクティビティを示す徴候があるかどうかを確認します。

  3. [検出の詳細] の [プリンシパルのメール] 行でメモしたアカウントがサービス アカウントでない場合は、アカウントの所有者に連絡して、正当なオーナーがアクション行ったかどうか確認します。

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

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

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

誰かが、一般的にリバースシェルに関連付けられているコマンドまたは引数を含む Pod を作成しました。攻撃者はリバース シェルを使用して、クラスタへの初期アクセスを拡大または維持し、任意のコマンドを実行します。詳細については、このアラートのログ メッセージをご覧ください。

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

Execution: Suspicious Exec or Attach to a System Pod

誰かが、exec コマンドまたは attach コマンドを使用して、シェルを取得した、または、kube-system Namespace で実行されているコンテナに対してコマンドを実行しました。これらの方法は、正当なデバッグ目的で使用されることがあります。ただし、kube-system namespace は Kubernetes によって作成されたシステム オブジェクトを対象としており、予期しないコマンド実行やシェルの作成は確認する必要があります。詳細については、このアラートのログ メッセージをご覧ください。

  1. Cloud Logging で監査ログを確認して、これがプリンシパルによる想定されているアクティビティであるかどうかを判断します。
  2. ログを参照して、プリンシパルによる悪意のあるアクティビティを示す徴候がほかにあるかどうかを確認します。

このアクセスを許可した RBAC ロールとクラスタロールに対する最小権限の原則の使用に関するガイダンスを確認してください。

Exfiltration: BigQuery Data Exfiltration

Exfiltration: BigQuery Data Exfiltration によって返される検出結果には、可能性のある 2 つのサブルールのいずれかが含まれます。サブルールごとに重大度は異なります。

  • 重大度 = HIGH のサブルール exfil_to_external_table:
    • リソースが組織またはプロジェクト外に保存されました。
  • 重大度 = LOW のサブルール vpc_perimeter_violation:
    • VPC Service Controls が、BigQuery リソースへのコピー オペレーションまたは試行をブロックした。

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

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

  1. 検出結果の確認の説明に沿って、Exfiltration: BigQuery Data Exfiltration の検出結果を開きます。

  2. [検出の詳細] パネルの [概要] タブで、次のセクションに表示されている値を確認します。

    • 検出された内容:
      • 重要度: 重大度は、サブルール exfil_to_external_table の HIGH、またはサブルール vpc_perimeter_violation の LOW のいずれかです。
      • プリンシパルのメール: データの漏洩に使用されたアカウント。
      • データの引き出しのソース: データが漏洩したテーブルの詳細。
      • データの引き出しのターゲット: 漏洩したデータが格納されていたテーブルの詳細。
    • 影響を受けているリソース:
      • リソースの完全な名前: データが漏洩したプロジェクト、フォルダ、または組織の完全なリソース名。
    • 関連リンク:
      • Cloud Logging URI: Logging エントリへのリンク。
      • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
      • 関連する検出結果: 関連する検出結果へのリンク。
      • Google Security Operations: Google SecOps へのリンク。

  3. [ソース プロパティ] タブをクリックし、表示されたフィールドについて、特に次の点を確認します。

    • detectionCategory:
      • subRuleName: exfil_to_external_table または vpc_perimeter_violation。
    • evidence:
      • sourceLogId:
        • projectId: ソースの BigQuery データセットを含む Google Cloud プロジェクト。
    • properties
      • dataExfiltrationAttempt
        • jobLink: データが漏洩した BigQuery ジョブへのリンク。
        • query: BigQuery データセットで実行された SQL クエリ。

  4. 必要に応じて、[JSON] タブをクリックして、検出結果の JSON プロパティを一覧表示します。

ステップ 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] を選択します。

    このテーブルには、Event Threat Detection からの検出結果が表示されます。

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

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

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

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

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

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

    [IAM] に移動

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

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

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

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

  2. 次のフィルタを使用して、BigQuery ジョブに関連する管理アクティビティ ログを検索します。

    • protoPayload.methodName="Jobservice.insert"
    • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

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

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

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

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

Exfiltration: BigQuery Data Extraction

BigQuery からのデータの漏洩は、監査ログで次の 2 つのシナリオを調べることで検出できます。

  • リソースが組織外の Cloud Storage バケットに保存される。
  • リソースが、組織の所有する一般公開 Cloud Storage バケットに保存される。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

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

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

  2. [検出の詳細] パネルの [概要] タブで、次のセクションに表示されている値を確認します。

    • 検出された内容:
      • プリンシパルのメール: データの漏洩に使用されたアカウント。
      • データの引き出しのソース: データが漏洩したテーブルの詳細。
      • データの引き出しのターゲット: 漏洩したデータが格納されていたテーブルの詳細。
    • 影響を受けているリソース:
      • リソースの完全な名前: データが漏洩した BigQuery リソースの名前。
      • プロジェクトのフルネーム: ソースの BigQuery データセットを含む Google Cloud プロジェクト。
    • 関連リンク:
      • Cloud Logging URI: Logging エントリへのリンク。
      • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
      • 関連する検出結果: 関連する検出結果へのリンク。

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

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

    • sourceProperties:
      • evidence:
        • sourceLogId:
        • projectId: ソースの BigQuery データセットを含む Google Cloud プロジェクト。
      • properties:
        • extractionAttempt:
        • jobLink: データが漏洩した BigQuery ジョブへのリンク

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

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

    IAM に移動

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

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

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

  1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。
  2. 次のフィルタを使用して、BigQuery ジョブに関連する管理アクティビティ ログを検索します。
    • protoPayload.methodName="Jobservice.insert"
    • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

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

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

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

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

Exfiltration: BigQuery Data to Google Drive

BigQuery からのデータ漏洩は、次のシナリオで監査ログを調べることで検出できます。

  • リソースが Google ドライブのフォルダに保存される。

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

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

  1. 検出結果の確認の説明に沿って、Exfiltration: BigQuery Data to Google Drive の検出結果を開きます。

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

    • 検出された内容（以下のフィールドが含まれます）:
      • プリンシパルのメール: データの漏洩に使用されたアカウント。
      • データの引き出しのソース: データが漏洩した BigQuery テーブルの詳細。
      • データの引き出しターゲット: Google ドライブの転送先の詳細。
    • 影響を受けているリソース:
      • リソースの完全な名前: データが漏洩した BigQuery リソースの名前。
      • プロジェクトのフルネーム: ソースの BigQuery データセットを含む Google Cloud プロジェクト。
    • 関連リンク（以下のリンクが含まれます）:
      • Cloud Logging URI: Logging エントリへのリンク。
      • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
      • 関連する検出結果: 関連する検出結果へのリンク。

  3. 詳細情報を確認するには、[JSON] タブをクリックします。

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

    • sourceProperties:
      • evidence:
        • sourceLogId:
        • projectId: ソースの BigQuery データセットを含む Google Cloud プロジェクト。
      • properties:
        • extractionAttempt:
        • jobLink: データが漏洩した BigQuery ジョブへのリンク

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

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

    [IAM] に移動

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

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

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

  1. [検出の詳細] パネルの [概要] タブで、[Cloud Logging URI] リンクをクリックして [ログ エクスプローラ] を開きます。
  2. 次のフィルタを使用して、BigQuery ジョブに関連する管理アクティビティ ログを検索します。
    • protoPayload.methodName="Jobservice.insert"
    • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

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

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

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

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

Exfiltration: Cloud SQL Data Exfiltration

Cloud SQL からのデータの漏洩は、監査ログで次の 2 つのシナリオを調べることで検出できます。

  • 組織外の Cloud Storage バケットにエクスポートされたライブ インスタンス データ。
  • 組織が所有し、一般公開される Cloud Storage バケットにエクスポートされたライブ インスタンス データ。

Cloud SQL インスタンスの全タイプがサポートされています。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

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

  1. 検出結果の確認の説明に沿って、Exfiltration: Cloud SQL Data Exfiltration の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

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

    • 検出された内容（特に次のフィールド）:
      • プリンシパルのメール: データの漏洩に使用されたアカウント。
      • データの引き出しのソース: データが漏洩した Cloud SQL インスタンスの詳細。
      • データの引き出しのターゲット: データのエクスポート先の Cloud Storage バケットの詳細。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: データが漏洩した Cloud SQL のリソース名。
      • プロジェクトのフルネーム: ソースの Cloud SQL データを含む Google Cloud プロジェクト。
    • 関連リンク（以下のリンクが含まれます）:
      • Cloud Logging URI: Logging エントリへのリンク。
      • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
      • 関連する検出結果: 関連する検出結果へのリンク。

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

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

    • sourceProperties:
      • evidence:
      • sourceLogId:
        • projectId: ソースの Cloud SQL インスタンスを含む Google Cloud プロジェクト。
      • properties
      • bucketAccess: Cloud Storage バケットが一般公開か、組織外部かどうか。
      • exportScope: エクスポートされたデータの量（インスタンス全体、1 つ以上のデータベース、1 つ以上のテーブル、クエリで指定されたサブセットなど）

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

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

    [IAM] に移動

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

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

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

  1. Google Cloud コンソールで、Cloud Logging の URI リンクをクリックして、ログ エクスプローラに移動します（ステップ 1 から）。 [ログ エクスプローラ] ページには、関連する Cloud SQL インスタンスに関するすべてのログが表示されます。

ステップ 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 ポリシーを追加します。
  • 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: ログを確認する

  1. Google Cloud コンソールで、Cloud Logging の URI リンクをクリックして、ログ エクスプローラに移動します（ステップ 1 から）。 [ログ エクスプローラ] ページには、関連する Cloud SQL インスタンスに関するすべてのログが表示されます。

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

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

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

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

  • データが漏洩したプロジェクトのオーナーに連絡します。
  • 調査が完了するまで、[検出の詳細] の[概要] タブの [プリンシパルのメール] 行に表示されているプリンシパルの権限を取り消すことを検討してください。
  • これ以上の漏洩を止めるには、影響を受けた Cloud SQL インスタンスに制限付きの IAM ポリシーを追加します。
  • 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: ログを確認する

  1. Google Cloud コンソールで、Cloud Logging の URI リンクをクリックして、ログ エクスプローラに移動します（ステップ 1 から）。 [ログ エクスプローラ] ページには、関連する Cloud SQL インスタンスに関するすべてのログが表示されます。
  2. ログ エクスプローラで、次のフィルタを使用して、データベースに対して実行されたクエリを記録する PostgreSQL pgaudit ログを確認します。
    • protoPayload.request.database="var class="edit">database"

ステップ 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: レスポンスを実装する

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

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 ドキュメントへのリンク。
      • 関連する検出結果: 関連する検出結果へのリンク。
      • Google Security Operations で調査: 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. 検出結果の詳細パネルの [関連リンク] セクションで、[Google Security Operations で調査] をクリックします。

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

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

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

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

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

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

    メンバーを削除するには、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

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

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

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

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

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

  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: レスポンスを実装する

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

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: レスポンスを実装する

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

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

既知のコマンドと制御ドメインおよび IP アドレスへの接続について、VPC フローログと Cloud DNS ログを調べてマルウェアを検出します。現在、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 ドキュメントへのリンク。
      • 関連する検出結果: 関連する検出結果へのリンク。
      • Google Security Operations で調査: Google SecOps へのリンク。
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。
      • Flow Analyzer（プレビュー）: Network Intelligence Center の Flow Analyzer 機能にリンクします。このフィールドは、VPC フローログが有効になっている場合にのみ表示されます。

    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. 検出結果の詳細パネルの [関連リンク] セクションで、[Google Security Operations で調査] をクリックします。

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

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

ステップ 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: Flow Analyzer を確認する

次のプロセスを実行するには、VPC フローログを有効にする必要があります。

  1. ログバケットがログ分析を使用できるようにアップグレードされていることを確認します。手順については、Log Analytics を使用するためにログバケットをアップグレードするをご覧ください。アップグレードに追加料金はかかりません。

  2. Google Cloud コンソールで、[Flow Analyzer] ページに移動します。

    Flow Analyzer に移動

    [検出結果の詳細] ペインの [概要] タブの [関連リンク] セクションにある [Flow Analyzer URL] リンクから Flow Analyzer にアクセスすることもできます。

  3. Event Threat Detection の検出結果に関する情報をさらに調査するには、アクションバーの時間範囲選択ツールを使用して期間を変更します。期間には、検出結果が最初に報告された日付を反映する必要があります。たとえば、検出結果が過去 2 時間以内に報告された場合は、期間を [過去 6 時間] に設定します。これにより、検出結果が報告された時間が Flow Analyzer の期間に含まれます。

  4. Flow Analyzer をフィルタして、悪意のある IP 検出結果に関連付けられている IP アドレスの適切な結果を表示します。

    1. [クエリ] セクションの [ソース] 行の [フィルタ] メニューで、[IP] を選択します。

    2. [値] フィールドに検出結果に関連付けられている IP アドレスを入力し、[新しいクエリを実行] をクリックします。

      Flow Analyzer に IP アドレスの結果が表示されない場合は、[送信元] 行のフィルタをクリアし、[宛先] 行で同じフィルタを使用してクエリを再度実行します。

  5. 結果を分析します。特定のフローの詳細を確認するには、[すべてのデータフロー] 表で [詳細] をクリックして [フロー詳細] ペインを開きます。

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

  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 の分析ページへのリンク。
      • Google Security Operations で調査: 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 を有効にすると、Google SecOps で Security Command Center の検出結果を調査できません。

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

    [検出] に移動

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

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

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

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

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

  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: ログを確認する

  1. Google Cloud コンソールで、Cloud Logging の URI リンクをクリックして、ログ エクスプローラに移動します（ステップ 1 から）。 [ログ エクスプローラ] ページには、関連する Cloud SQL インスタンスに関するすべてのログが表示されます。
  2. ログ エクスプローラで、次のフィルタを使用して、データベースに対して実行されたクエリを記録する PostgreSQL pgaudit ログを確認します。
    • protoPayload.request.database="var class="edit">database"

ステップ 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: レスポンスを実装する

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

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

Persistence: GCE Admin Added SSH Key

説明 操作
確立されたインスタンスで ssh-keys Compute Engine インスタンスのメタデータキーが変更されました。 Compute Engine インスタンスのメタデータキー ssh-keys が、7 日以上前に作成されたインスタンスで変更されました。 この変更がメンバーによって意図的に行われたものか、攻撃者が新しい経路で組織に行ったものかを確認します。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

以下を置き換えます。

  • INSTANCE_ID: 検出結果にリストされている gceInstanceId
  • ORGANIZATION_ID: 組織 ID

この検出結果をトリガーするイベントの調査結果:

Persistence: GCE Admin Added Startup Script

説明 操作
確立されたインスタンスで startup-script または startup-script-url Compute Engine インスタンスのメタデータキーが変更されました。 Compute Engine インスタンスのメタデータキー startup-script または startup-script-url が、7 日以上前に作成されたインスタンスで変更されました。 この変更がメンバーによって意図的に行われたものか、攻撃者が新しい経路で組織に行ったものかを確認します。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )

OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

以下を置き換えます。

  • INSTANCE_ID: 検出結果にリストされている gceInstanceId
  • ORGANIZATION_ID: 組織 ID

この検出結果をトリガーするイベントの調査結果:

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 を有効にした場合、この検出結果は使用できません。

説明 操作
パスワード漏洩が検出されたため、メンバーのアカウントが無効になっています。 影響を受けるアカウントのパスワードを再設定し、企業アカウントに安全で一意のパスワードを使用するようにメンバーに伝えます。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID は、実際の組織 ID に置き換えます。

この検出結果をトリガーするイベントの調査結果:

Initial Access: Suspicious Login Blocked

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

説明 操作
メンバーのアカウントへの不審なログインが検出され、ブロックされました。 このアカウントは攻撃者にとって標的である可能性があります。ユーザー アカウントが、強力なパスワードと多要素認証に関する組織のセキュリティ ガイドラインに従っていることを確認します。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID は、実際の組織 ID に置き換えます。

この検出結果をトリガーするイベントの調査結果:

Initial Access: Account Disabled Hijacked

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

説明 操作
不審なアクティビティが検出されたため、メンバーのアカウントが停止されました。 このアカウントは不正使用されています。アカウントのパスワードを再設定し、企業アカウントに安全性の高い一意のパスワードを作成するようユーザーに伝えます。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID は、実際の組織 ID に置き換えます。

この検出結果をトリガーするイベントの調査結果:

Impair Defenses: Two Step Verification Disabled

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

説明 操作
メンバーが 2 段階認証プロセスを無効にしました。 ユーザーが 2 段階認証プロセスを無効にするかどうかを確認します。組織で 2 段階認証プロセスが必要な場合は、ユーザーがすぐに有効にしてください。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID は、実際の組織 ID に置き換えます。

この検出結果をトリガーするイベントの調査結果:

Initial Access: Government Based Attack

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

説明 操作
政府の支援を受けた攻撃者がメンバー アカウントまたはパソコンの不正使用を試みた可能性があります。 このアカウントは攻撃者にとって標的である可能性があります。ユーザー アカウントが、強力なパスワードと多要素認証に関する組織のセキュリティ ガイドラインに従っていることを確認します。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID は、実際の組織 ID に置き換えます。

この検出結果をトリガーするイベントの調査結果:

Persistence: SSO Enablement Toggle

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

説明 操作
管理者アカウントで [Enable SSO (single sign-on)] 設定が無効になりました。 組織の SSO の設定が変更されました。この変更がメンバーによって意図的に行われたものか、攻撃者が新しい経路で組織に行ったものかを確認します。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

以下を置き換えます。

  • DOMAIN_NAME: 検出結果にリストされている domainName
  • ORGANIZATION_ID: 組織 ID

この検出結果をトリガーするイベントの調査結果:

Persistence: SSO Settings Changed

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

説明 操作
管理者アカウントの SSO 設定が変更されました。 組織の SSO の設定が変更されました。この変更がメンバーによって意図的に行われたものか、攻撃者が新しい経路で組織に行ったものかを確認します。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

以下を置き換えます。

  • DOMAIN_NAME: 検出結果にリストされている domainName
  • ORGANIZATION_ID: 組織 ID

この検出結果をトリガーするイベントの調査結果:

Impair Defenses: Strong Authentication Disabled

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

説明 操作
組織で 2 段階認証プロセスが無効になりました。 組織で 2 段階認証プロセスが不要になりました。管理者が意図的にポリシーの変更を行ったのか、攻撃者がアカウントを簡単に乗っ取ったのかを調査します。

次のフィルタを使用してログを確認します。

protopayload.resource.labels.service="admin.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

ORGANIZATION_ID は、実際の組織 ID に置き換えます。

この検出結果をトリガーするイベントの調査結果:

Google Workspace の脅威に対処する

Google Workspace の検出結果は、Security Command Center を組織レベルで有効にした場合にのみ使用できます。プロジェクト レベルで有効にしている場合、Google Workspace ログをスキャンすることはできません。

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. [概要] タブで、次のセクションの情報を確認します。

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: 追加されたバイナリの絶対パス。
      • 引数: 追加されたバイナリを呼び出すときに指定する引数。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。
    • 関連リンク（特に次のフィールド）:
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

  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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

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

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

  • バイナリをコンテナに含める予定の場合は、そのバイナリを含めてコンテナ イメージを再ビルドします。こうして、コンテナを不変にすることができます。
  • または、コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Added Library Loaded

元のコンテナ イメージの一部ではなかったライブラリが読み込まれました。 コード実行保護を回避し、悪意のあるコードを非表示にするために、攻撃者が既存のプログラムに悪意のあるプログラムを読み込むおそれがあります。コンテナが不変であることを確認することは、重要なベスト プラクティスです。これは重大度が低い検出結果です。組織がこのベスト プラクティスに準拠していない可能性があります。バイナリのハッシュが既知のセキュリティ侵害インジケーター（IoC）である場合、対応する Execution: Added Malicious Library Loaded 検出結果があります。この検出結果に対応する手順は次のとおりです。

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

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

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

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: ライブラリを読み込んだプロセス バイナリのフルパス。
      • ライブラリ: 追加されたライブラリの詳細。
      • 引数: プロセス バイナリを呼び出すときに指定する引数。
    • 影響を受けているリソース（特に次のフィールド）:
    • 関連リンク（特に次のフィールド）:
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

  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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

ステップ 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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

ステップ 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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

ステップ 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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Container Escape

コンテナ エスケープ アクティビティの既知の不審なツールのバイナリが実行されました。これは、コンテナ内のプロセスが分離から抜け出し、ホストシステムや他のコンテナとやり取りしようとするコンテナ エスケープの試行を示している可能性があります。これは重大度の高い検出結果です。攻撃者がコンテナの境界を超えてアクセスしようとしており、ホストやその他のインフラストラクチャを侵害する可能性があることを示しています。コンテナ エスケープは、構成ミス、コンテナ ランタイムの脆弱性、特権コンテナの悪用が原因で発生する可能性があります。

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

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

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

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

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: 実行されたバイナリの絶対パス。
      • 引数: バイナリ実行時に渡される引数。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。

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

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

    • resource:
      • project_display_name: クラスタを含むプロジェクトの名前。
    • finding:
      • processes:
      • binary:
        • path: 実行されたバイナリのフルパス。
      • args: バイナリの実行時に指定された引数。
    • 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 ワークロード ページに移動します。

    [Kubernetes ワークロード] に移動

  2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

  3. 必要に応じて、検出結果の詳細の [概要] タブにある [リソースの完全な名前] 行のクラスタと、[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"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

  1. Google Cloud Console に移動します。

    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 に表示されているプロジェクト名

  1. 実行されたバイナリを取得します。

    kubectl cp \
      POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
      -c CONTAINER_NAME \
      LOCAL_FILE

    local_file は、追加されたバイナリを格納するローカル ファイルのパスに置き換えます。

  2. 次のコマンドを実行して、コンテナ環境に接続します。

    kubectl exec \
      --namespace=POD_NAMESPACE \
      -ti POD_NAME \
      -c CONTAINER_NAME \
      -- /bin/sh

    このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

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

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

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Kubernetes Attack Tool Execution

Kubernetes 攻撃ツールがコンテナ内で実行されました。これは、Kubernetes 環境の脆弱性を悪用しようとする試みを示しています。攻撃者は、権限の昇格、横方向の移動、クラスタ内の他のリソースの侵害に、これらのツールをよく使用します。このようなツールの実行は、API サーバー、ノード、ワークロードなどの Kubernetes コンポーネントを制御するための意図的な試みを示唆するため、重大な重大度の検出結果です。攻撃者は、これらのツールを使用してセキュリティ制御を回避したり、構成を操作したり、機密データを漏洩させたりすることができます。

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

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

  1. 検出結果の確認の説明に沿って、Execution: Kubernetes Attack Tool Execution の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

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

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: 実行されたバイナリの絶対パス。
      • 引数: バイナリ実行時に渡される引数。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。

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

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

    • resource:
      • project_display_name: クラスタを含むプロジェクトの名前。
    • finding:
      • processes:
        • binary:
        • path: 実行されたバイナリのフルパス。
      • args: バイナリの実行時に指定された引数。
    • 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 ワークロード ページに移動します。

    [Kubernetes ワークロード] に移動

  2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

  3. 必要に応じて、検出結果の詳細の [概要] タブにある [リソースの完全な名前] 行のクラスタと、[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"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

  1. Google Cloud Console に移動します。

    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 に表示されているプロジェクト名

  1. 実行されたバイナリを取得します。

    kubectl cp \
      POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
      -c CONTAINER_NAME \
      LOCAL_FILE

    LOCAL_FILE は、実行されたバイナリを格納するローカル ファイルのパスに置き換えます。

  2. 次のコマンドを実行して、コンテナ環境に接続します。

    kubectl exec \
      --namespace=POD_NAMESPACE \
      -ti POD_NAME \
      -c CONTAINER_NAME \
      -- /bin/sh

    このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

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

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

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Local Reconnaissance Tool Execution

ローカル偵察ツールがコンテナ内で実行されました。これは、攻撃者がネットワーク構成、アクティブなプロセス、マウントされたファイル システムなど、コンテナ環境に関する情報を収集していることを示しています。このタイプのツールは、攻撃の初期段階で、潜在的なターゲットをマッピングし、弱点を特定するためによく使用されます。これは中程度の重大度の検出結果です。攻撃者がさらなる悪用機会を求めてコンテナを積極的にプローブしていることを示します。

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

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

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

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

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: 実行されたバイナリの絶対パス。
      • 引数: バイナリ実行時に渡される引数。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。

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

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

    • resource:
      • project_display_name: クラスタを含むプロジェクトの名前。
    • finding:
      • processes:
        • binary:
        • path: 実行されたバイナリのフルパス。
      • args: バイナリの実行時に指定された引数。
    • 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 ワークロード ページに移動します。

    [Kubernetes ワークロード] に移動

  2. Google Cloud コンソールのツールバーで、必要に応じて resource.project_display_name に表示されているプロジェクトを選択します。

  3. 必要に応じて、検出結果の詳細の [概要] タブにある [リソースの完全な名前] 行のクラスタと、[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"

ステップ 5: 実行中のコンテナを調査する

コンテナがまだ実行中の場合は、コンテナ環境を直接調査できる場合があります。

  1. Google Cloud Console に移動します。

    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 に表示されているプロジェクト名

  1. 追加されたバイナリを取得します。

    kubectl cp \
      POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
      -c CONTAINER_NAME \
      LOCAL_FILE

    LOCAL_FILE は、追加されたバイナリを格納するローカル ファイルのパスに置き換えます。

  2. 次のコマンドを実行して、コンテナ環境に接続します。

    kubectl exec \
      --namespace=POD_NAMESPACE \
      -ti POD_NAME \
      -c CONTAINER_NAME \
      -- /bin/sh

    このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

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

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

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Execution: Malicious Python executed

機械学習モデルが、実行された Python コードを悪意があるものとして識別しました。攻撃者は、Python を使用してツールを転送し、バイナリなしでコマンドを実行します。コンテナが不変であることを確認することは、重要なベスト プラクティスです。 ツールの転送にスクリプトを使用すると、攻撃者が Ingress ツール転送の手法を模倣し、望ましくない検出が発生する可能性があります。

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

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

  1. 検出結果の確認の説明に沿って、Execution: Malicious Python executed の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

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

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: スクリプトを呼び出したインタープリタの詳細。
      • スクリプト: ディスク上のスクリプト名の絶対パス。この属性は、ディスクに書き込まれたスクリプトに対してのみ表示され、リテラル スクリプトの実行では表示されません（例: python3 -c）。
      • 引数: スクリプトの起動時に指定する引数
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。
    • 関連リンク（特に次のフィールド）:
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

  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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

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

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

  • Python がコンテナに意図した変更を行っていた場合は、変更が不要になるようにコンテナ イメージを再ビルドします。こうして、コンテナを不変にすることができます。
  • または、コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

ステップ 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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Malicious Script Executed

機械学習モデルが、実行された Bash コードを悪意があるものとして識別しました。 攻撃者は、Bash を使用してツールを転送し、バイナリなしでコマンドを実行します。コンテナが不変であることを確認することは、重要なベスト プラクティスです。 ツールの転送にスクリプトを使用すると、攻撃者が Ingress ツール転送の手法を模倣し、望ましくない検出が発生する可能性があります。

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

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

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

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

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: スクリプトを呼び出したインタープリタの詳細。
      • スクリプト: ディスク上のスクリプトの名前の絶対パス。この属性は、ディスクに書き込まれたスクリプトに対してのみ表示され、リテラル スクリプトの実行では表示されません（例: bash -c）。
      • 引数: スクリプトの起動時に指定する引数
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: プロジェクト番号、ロケーション、クラスタ名を含むクラスタの完全なリソース名。
    • 関連リンク（特に次のフィールド）:
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

  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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

ステップ 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
    • 関連リンク（特に次のフィールド）:
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

  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. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  4. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Reverse Shell

リモート接続ソケットへのストリーム リダイレクトで始まるプロセス。ネットワーク接続されたシェルを生成すると、攻撃者が限られた初期侵害の後に、任意のアクションを実行できるようになります。この検出結果に対応する手順は次のとおりです。

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

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

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

    • 検出された内容（特に次のフィールド）:
      • プログラム バイナリ: リモート ソケットへのストリーム リダイレクトで始まるプロセスの絶対パス。
      • 引数: プロセス バイナリを呼び出すときに指定する引数
    • 影響を受けているリソース（特に次のフィールド）:
      • 完全なリソース名: クラスタの完全なリソース名。
      • プロジェクトのフルネーム: 影響を受ける Google Cloud プロジェクト。
    • 関連リンク（特に次のフィールド）:
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

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

  4. [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"

ステップ 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 exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

    このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

    コンテナ内で実行中のすべてのプロセスを表示するには、コンテナシェルで次のコマンドを実行します。

      ps axjf

    このコマンドを実行するには、コンテナに /bin/ps がインストールされている必要があります。

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

  1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Command and Scripting Interpreter、Ingress Tool Transfer）を確認します。
  2. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

Unexpected Child Shell

Container Threat Detection が、子シェルプロセスを予期せず生成するプロセスを検出しました。このイベントは、攻撃者がシェルのコマンドとスクリプトを不正使用しようとしていることを示す場合があります。

この検出結果に対応するには、次の操作を行います。

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

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

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

    • 検出された内容（特に次のフィールド）:
      • 親プロセス: 子シェルプロセスが予期せず作成されたプロセス。
      • 子プロセス: 子シェルプロセス。
      • 引数: 子シェルのプロセス バイナリに渡される引数。
      • 環境変数: 子シェルのプロセス バイナリの環境変数。
      • コンテナ: コンテナの名前。
      • コンテナ URI: コンテナのイメージ URI。
      • Kubernetes Pod: Pod 名と Namespace。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソース表示名: 影響を受けるリソースの名前。
      • 完全なリソース名: クラスタの完全なリソース名。完全なリソース名には、次の情報が含まれます。
        • クラスタを含むプロジェクト: projects/PROJECT_ID
        • クラスタが配置されているロケーション（zone/ZONE または locations/LOCATION）
        • クラスタの名前: projects/CLUSTER_NAME
    • 関連リンク（特に次のフィールド）:
      • VirusTotal インジケーター: VirusTotal の分析ページへのリンク。

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

+processes: 検出結果に関連するすべてのプロセスを含む配列。この配列には、子シェルと親プロセスが含まれます。+resource: +project_display_name: アセットを含むプロジェクトの名前。+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 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.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 exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

    このコマンドを実行するには、コンテナの /bin/sh にシェルがインストールされている必要があります。

    コンテナ内で実行中のすべてのプロセスを表示するには、コンテナシェルで次のコマンドを実行します。

      ps axjf

    このコマンドを実行するには、コンテナに /bin/ps がインストールされている必要があります。

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

  1. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Command and Scripting Interpreter: Unix Shell）を確認します。
  2. [VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。
  3. 対応計画を策定するには、調査結果を MITRE の調査と VirusTotal の分析と組み合わせます。

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

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

  • コンテナが不正使用されているプロジェクトのオーナーに連絡します。
  • 不正使用されているコンテナを停止するか削除して、新しいコンテナに置き換えます。

VM Threat Detection レスポンス

VM Threat Detection の詳細については、VM Threat Detection の概要をご覧ください。

Defense Evasion: Rootkit

VM Threat Detection は、Compute Engine VM インスタンスで既知のカーネルモード ルートキットに対応するシグナルの組み合わせを検出しました。

Defense Evasion: Rootkit 検出結果カテゴリは、次の検出結果カテゴリのスーパーセットです。したがって、このセクションはこれらの検出結果カテゴリにも適用されます。

これらの検出結果への対応方法は次のとおりです。

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

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

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

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

      • カーネル ルートキット名: 検出されたルートキットのファミリー名（例: Diamorphine）。
      • 予期しないカーネルコード ページ: カーネルコード ページが、カーネルまたはモジュール コードの想定されていないリージョンに存在するかどうか。
      • 予期しないシステムコール ハンドラ: システムコール ハンドラが、想定されていないカーネルまたはモジュール コード リージョンに存在するかどうか。

    • 影響を受けているリソース（特に次のフィールド）:

      • リソースの完全な名前: 影響を受ける VM インスタンスの完全なリソース名。この VM を含むプロジェクトの ID が含まれます。

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

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

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

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

  2. Google Cloud コンソールのツールバーで、検出結果の詳細の [概要] タブにある [リソースの完全な名前] 行の VM インスタンスを含むプロジェクトを選択します。

  3. ログで、該当する VM インスタンスの侵入の兆候を確認します。たとえば、不審なアクティビティや不明なアクティビティ、不正使用された認証情報の兆候を探します。

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

  1. 検出結果の詳細の [概要] タブの [リソースの完全な名前] フィールドで、リンクをクリックします。
  2. ネットワークやアクセスの設定など、VM インスタンスの詳細を確認します。

ステップ 4: 影響を受ける VM を検査する

カーネル メモリの改ざんの兆候がないか VM を調べるの手順に沿って操作します。

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

  1. 防御回避の MITRE ATT&CK フレームワーク エントリを確認します。
  2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

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

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

  1. VM のオーナーに連絡します。

  2. 必要に応じて、不正使用されたインスタンスを停止し、新しいインスタンスに置き換えます。

  3. フォレンジック分析の場合は、仮想マシンと永続ディスクのバックアップを検討してください。詳細については、Compute Engine ドキュメントのデータ保護オプションをご覧ください。

  4. VM インスタンスを削除します。

  5. 詳細な調査が必要な場合は、Mandiant などのインシデント対応サービスをご検討ください。

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection は、暗号通貨マイニング ソフトウェアの既知のメモリハッシュと実行中のプログラムのメモリハッシュを照合することにより、暗号通貨マイニング アクティビティを検出しました。

これらの検出結果への対応方法は以下のとおりです。

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

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

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

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

      • バイナリ ファミリー: 検出された暗号通貨アプリケーション。
      • プログラム バイナリ: プロセスの絶対パス。
      • 引数: プロセス バイナリを呼び出すときに指定する引数
      • プロセス名: VM インスタンスで実行され、シグネチャとの一致が検出されたプロセスの名前。

      VM Threat Detection は、主要な Linux ディストリビューションのカーネルビルドを認識できます。影響を受ける VM のカーネルビルドを認識できると、アプリケーションのプロセス詳細を特定し、検出結果の processes フィールドに値を挿入します。VM Threat Detection がカーネルを認識できない場合（カーネルがカスタムビルドされている場合など）、検出結果の processes フィールドに値は挿入されません。

    • 影響を受けているリソース（特に次のフィールド）:

      • リソースの完全な名前: 影響を受ける VM インスタンスの完全なリソース名。この VM を含むプロジェクトの ID が含まれます。

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

    • indicator
      • signatures:
        • memory_hash_signature: メモリページのハッシュに対応するシグネチャ。
        • detections
          • binary: 暗号通貨アプリケーションのバイナリの名前（例: linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0）。
          • percent_pages_matched: メモリ内で、ページハッシュ データベースの既知の暗号通貨アプリケーションと一致するページの割合。

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

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

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

  2. Google Cloud コンソールのツールバーで、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行で指定された、VM インスタンスを含むプロジェクトを選択します。

  3. ログで、該当する VM インスタンスの侵入の兆候を確認します。たとえば、不審なアクティビティや不明なアクティビティ、不正使用された認証情報の兆候を探します。

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

  1. 検出結果の詳細の [概要] タブの [リソースの完全な名前] フィールドで、リンクをクリックします。
  2. ネットワークやアクセスの設定など、VM インスタンスの詳細を確認します。

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

  1. 実行の MITRE ATT&CK フレームワーク エントリを確認します。
  2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

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

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

検出と削除をサポートするには、エンドポイントの検出と対応ソリューションを使用します。

  1. VM のオーナーに連絡します。

  2. アプリケーションがマイニング アプリケーションかどうかを確認します。

    • 検出されたアプリケーションのプロセス名とバイナリパスが使用可能な場合は、調査の [検出の詳細] の [概要] タブで、[プログラム バイナリ]、[引数]、[プロセス名] の各行の値を検討します。

    • プロセスの詳細を取得できない場合は、メモリハッシュ シグネチャのバイナリ名が手がかりになるかどうか確認します。linux-x86-64_xmrig_2.14.1 というバイナリについて考えてみましょう。grep コマンドを使用すると、ストレージ内の重要なファイルを検索できます。検索パターンで、バイナリ名のわかりやすい部分（この場合は xmrig）を使用します。検索結果を確認します。

    • 実行中のプロセス、特に CPU 使用率の高いプロセスを調べて、不明なプロセスがないか確認します。関連付けられているアプリケーションがマイニング アプリケーションかどうかを確認します。

    • ストレージでファイルを検索して、マイニング アプリケーションで使用される一般的な文字列（btc.com、ethminer、xmrig、cpuminer、randomx など）を探します。検索できる文字列のその他の例については、ソフトウェア名と YARA ルールと、リストにある各ソフトウェアに関連するドキュメントをご覧ください。

  3. アプリケーションがマイニング アプリケーションであり、そのプロセスが実行されている場合は、プロセスを終了します。VM のストレージでアプリケーションの実行バイナリを見つけ、削除します。

  4. 必要に応じて、不正使用されたインスタンスを停止し、新しいインスタンスに置き換えます。

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection は、暗号通貨マイニング ソフトウェアによって使用されることが確認されているメモリパターン（作業証明定数など）を照合することで、暗号通貨マイニング アクティビティを検出しました。

これらの検出結果への対応方法は以下のとおりです。

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

  1. 検出結果の確認の説明に沿って、Execution: Cryptocurrency Mining YARA Rule の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。

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

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

      • YARA ルール名: YARA 検出項目用にトリガーされるルール。
      • プログラム バイナリ: プロセスの絶対パス。
      • 引数: プロセス バイナリを呼び出すときに指定する引数
      • プロセス名: VM インスタンスで実行され、シグネチャとの一致が検出されたプロセスの名前

      VM Threat Detection は、主要な Linux ディストリビューションのカーネルビルドを認識できます。影響を受ける VM のカーネルビルドを認識できると、アプリケーションのプロセス詳細を特定し、検出結果の processes フィールドに値を挿入します。VM Threat Detection がカーネルを認識できない場合（カーネルがカスタムビルドされている場合など）、検出結果の processes フィールドに値は挿入されません。

    • 影響を受けているリソース（特に次のフィールド）:

      • リソースの完全な名前: 影響を受ける VM インスタンスの完全なリソース名。この VM を含むプロジェクトの ID が含まれます。

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

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

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

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

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

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

  2. Google Cloud コンソールのツールバーで、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行で指定された、VM インスタンスを含むプロジェクトを選択します。

  3. ログで、該当する VM インスタンスの侵入の兆候を確認します。たとえば、不審なアクティビティや不明なアクティビティ、不正使用された認証情報の兆候を探します。

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

  1. 検出結果の詳細の [概要] タブの [リソースの完全な名前] フィールドで、リンクをクリックします。
  2. ネットワークやアクセスの設定など、VM インスタンスの詳細を確認します。

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

  1. 実行の MITRE ATT&CK フレームワーク エントリを確認します。
  2. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

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

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

検出と削除をサポートするには、エンドポイントの検出と対応ソリューションを使用します。

  1. VM のオーナーに連絡します。

  2. アプリケーションがマイニング アプリケーションかどうかを確認します。

    • 検出されたアプリケーションのプロセス名とバイナリパスが使用可能な場合は、調査の [検出の詳細] の [概要] タブで、[プログラム バイナリ]、[引数]、[プロセス名] の各行の値を検討します。

    • 実行中のプロセス、特に CPU 使用率の高いプロセスを調べて、不明なプロセスがないか確認します。関連付けられているアプリケーションがマイニング アプリケーションかどうかを確認します。

    • ストレージでファイルを検索して、マイニング アプリケーションで使用される一般的な文字列（btc.com、ethminer、xmrig、cpuminer、randomx など）を探します。検索できる文字列のその他の例については、ソフトウェア名と YARA ルールと、リストにある各ソフトウェアに関連するドキュメントをご覧ください。

  3. アプリケーションがマイニング アプリケーションであり、そのプロセスが実行されている場合は、プロセスを終了します。VM のストレージでアプリケーションの実行バイナリを見つけ、削除します。

  4. 必要に応じて、不正使用されたインスタンスを停止し、新しいインスタンスに置き換えます。

Execution: cryptocurrency mining combined detection

VM Threat Detection は、1 日に 1 つのソースから複数のカテゴリの検出結果を検出しました。1 つのアプリケーションで Execution: Cryptocurrency Mining YARA Rule と Execution: Cryptocurrency Mining Hash Match findings を同時にトリガーする場合があります。

検出結果を組み合わせてレスポンスに対応するには、Execution: Cryptocurrency Mining YARA Rule と Execution: Cryptocurrency Mining Hash Match findings の両方のレスポンス手順を実施します。

Malware: Malicious file on disk (YARA)

VM Threat Detection は、既知のマルウェアのシグネチャに関して VM の永続ディスクをスキャンし、悪質な可能性のあるファイルを検出しました。

これらの検出結果への対応方法は以下のとおりです。

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

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

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

    • 検出された内容（特に次のフィールド）:
      • YARA ルール名: 一致した YARA ルール。
      • ファイル:: パーティション UUID と、検出された悪意のある可能性のあるファイルの相対パス。
    • 影響を受けているリソース（特に次のフィールド）:
      • リソースの完全な名前: 影響を受ける VM インスタンスの完全なリソース名。この VM を含むプロジェクトの ID が含まれます。

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

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

    • indicator
      • signatures:
        • yaraRuleSignature: 一致した YARA ルールに対応するシグネチャ。

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

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

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

  2. Google Cloud コンソールのツールバーで、[検出の詳細] の [概要] タブの [リソースの完全な名前] 行で指定された、VM インスタンスを含むプロジェクトを選択します。

  3. ログで、該当する VM インスタンスの侵入の兆候を確認します。たとえば、不審なアクティビティや不明なアクティビティ、不正使用された認証情報の兆候を探します。

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

  1. 検出結果の詳細の [概要] タブの [リソースの完全な名前] フィールドで、リンクをクリックします。
  2. ネットワークやアクセスの設定など、VM インスタンスの詳細を確認します。

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

[VirusTotal インジケーター] でリンクをクリックして、VirusTotal で悪意があるというフラグが付いているバイナリの SHA-256 ハッシュ値を確認します。VirusTotal は、悪意のある可能性のあるファイル、URL、ドメイン、IP アドレスに関するコンテキストを提供する Alphabet 社のサービスです。

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

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

  1. VM のオーナーに連絡します。

  2. 必要に応じて、悪意のある可能性のあるファイルを探して削除します。パーティション UUID とファイルの相対パスを取得するには、検出の詳細の [概要] タブにある [ファイル] フィールドをご覧ください。検出と削除をサポートするには、エンドポイントの検出と対応ソリューションを使用します。

  3. 必要に応じて、不正使用されたインスタンスを停止し、新しいインスタンスに置き換えます。

  4. フォレンジック分析の場合は、仮想マシンと永続ディスクのバックアップを検討してください。詳細については、Compute Engine ドキュメントのデータ保護オプションをご覧ください。

  5. 詳細な調査が必要な場合は、Mandiant などのインシデント対応サービスをご検討ください。

脅威の再発を防ぐため、関連する脆弱性と構成ミスの検出結果を確認して修正します。

関連する検出結果を確認するには、次の操作を行います。

  1. Google Cloud コンソールで、Security Command Center の [検出] ページに移動します。

    [検出結果] に移動

  2. 脅威の検出結果を確認し、関連する脆弱性や構成ミスの検出結果に表示される可能性が高い属性の値（プリンシパル メールアドレスや影響を受けるリソースの名前など）をコピーします。

  3. [検出結果] ページで [クエリを編集] をクリックして、[Query Editor] を開きます。

  4. [フィルタを追加] をクリックします。[フィルタを選択] メニューが開きます。

  5. メニューの左側にあるフィルタ カテゴリのリストから、脅威の検出結果でメモした属性を含むカテゴリを選択します。

    たとえば、影響を受けるリソースの完全な名前をメモした場合は、[リソース] を選択します。[Full name] 属性など、[リソース] カテゴリの属性タイプが右側の列に表示されます。

  6. 表示された属性から、脅威の検出でメモした属性のタイプを選択します。右側に属性値の検索パネルが開き、選択した属性タイプの検出された値がすべて表示されます。

  7. [フィルタ] フィールドに、脅威の検出結果からコピーした属性値を貼り付けます。表示された値のリストが更新され、貼り付けた値と一致する値のみが表示されます。

  8. 表示された値のリストから 1 つ以上の値を選択し、[適用] をクリックします。[検出結果クエリの結果] パネルが更新され、一致する検出結果のみが表示されます。

  9. 検出結果が多数ある場合は、[クイック フィルタ] パネルで追加のフィルタを選択して、検出結果をフィルタします。

    たとえば、Vulnerability ～Misconfiguration選択した属性値を含むクラスの検出結果検出結果クラスセクションのクイック フィルタパネルを選択して選択し、脆弱性～構成ミスから選択します。

Palo Alto Networks のユーザーは、Google が提供するセキュリティ侵害の指標に加えて、Palo Alto Networks の AutoFocus Threat Intelligence を Event Threat Detection と統合できます。AutoFocus は、ネットワークの脅威に関する情報を提供する脅威インテリジェンス サービスです。詳細については、Google Cloud コンソールの [AutoFocus] ページをご覧ください。

脅威の修復

Event Threat Detection と Container Threat Detection の検出結果の修復は、Security Command Center によって検出された構成ミスと脆弱性を修正するだけではありません。

構成ミスやコンプライアンス違反によって、悪用されるおそれのあるリソースの脆弱性を特定できます。通常、構成ミスには、ファイアウォールを有効にする、暗号鍵をローテーションするなど、簡単に実装できる既知の修正方法が存在します。

脅威は、動的であるという点で脆弱性とは異なり、1 つ以上のリソースを悪用している可能性があります。悪用するために使用された手法が正確にはわからない可能性もあるため、修復の推奨はリソースの保護に効果的でない場合があります。

たとえば、Added Binary Executed 検出結果は、コンテナで未承認のバイナリが起動されたことを示します。基本的な修復策として、コンテナの隔離とバイナリの削除を勧めるとしても、これでは攻撃者にバイナリの実行を許した根本原因の問題は解決されないままとなる可能性があります。悪用された問題を修復するには、コンテナ イメージの破損を調べる必要があります。ファイルが不適切な設定のポートを経由して追加されたのか、あるいはその他の方法で追加されたのかを判断するには、詳細な調査を行う必要があります。システムに精通したアナリストが、システムの脆弱性を調べる必要があります。

悪意のある手法は、さまざまな手法を使用してリソースを攻撃します。そのため、特定の悪用攻撃に対する修正を適用しても、その攻撃の亜種には効果がない可能性があります。たとえば、Brute Force: SSH の検索に応じて、一部のユーザーのアカウントに対する権限レベルを下げて、リソースへのアクセスを制限できます。ただし、脆弱なパスワードは攻撃パスに利用される可能性があります。

攻撃ベクトルが多岐にわたるため、あらゆる状況に対応できる修復手順を提供することは困難です。クラウド セキュリティ計画における Security Command Center の役割は、影響を受けるリソースをほぼリアルタイムで特定し、直面している脅威がどんなものかを伝え、調査を支援するための裏付けとコンテキストを提供することです。なお、セキュリティ担当者は、Security Command Center の検出結果の豊富な情報を使い、問題を修復し将来の攻撃からリソースを保護する最適な方法を判断する必要があります。

次のステップ