脅威の調査と対処

このトピックでは、脅威を調査して対処し、追加のリソースを使用して 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 のプレミアム ティアを有効にすると、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 社のサービスです。

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

脅威の検出の無効化

脅威の検出の原因となった問題を解決した後、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

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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: Modify VPC Service Control

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

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

• 境界からプロジェクトが削除される
• アクセスレベル ポリシーが既存の境界に追加される
• アクセス可能なサービスのリストに 1 つ以上のサービスが追加される

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

ステップ 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」が有効になっているか、許可されたサービスとして追加されている場合は、そのサービスを開始したユーザーと転送するユーザーを確認します。

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 の調査を組み合わせる必要があります。

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. 検出結果の詳細パネルの [概要] タブで、次のセクションに表示されている値を確認します。

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

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: Chronicle で調査する

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

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

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

   [検出結果] に移動

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

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

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

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

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

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

Chronicle で調査を行う場合は、次のガイドをご覧ください。

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

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

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

• データが漏洩したプロジェクトのオーナーに連絡します。
• 調査が完了するまで、userEmail の権限を取り消すことを検討します。
• これ以上の漏洩を止めるには、影響を受けた BigQuery データセット（exfiltration.sources と exfiltration.targets）に制限付きの IAM ポリシーを追加します。
• 影響を受けるデータセットに含まれる機密情報をスキャンするには、機密データの保護を使用します。Security Command Center に機密データの保護のデータを送信することもできます。情報の量によっては、機密データの保護のコストが高額になる場合があります。機密データの保護のコストを抑えるためのベスト プラクティスに従ってください。
• BigQuery API へのアクセスを制限するには、VPC Service Controls を使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

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

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

• データが漏洩したプロジェクトのオーナーに連絡します。
• 調査が完了するまでは、検出結果の詳細の [概要] タブにある [プリンシパルのメール] 行のプリンシパルの権限を取り消すことを検討してください。
• これ以上の漏洩を防ぐため、影響を受ける BigQuery データセットに制限付きの IAM ポリシーを追加します。BigQuery データセットは、検出結果の詳細の [概要] タブにある [データの引き出しのソース] フィールドで確認できます。
• 影響を受けるデータセットに含まれる機密情報をスキャンするには、機密データの保護を使用します。Security Command Center に機密データの保護のデータを送信することもできます。情報の量によっては、機密データの保護のコストが高額になる場合があります。機密データの保護のコストを抑えるためのベスト プラクティスに従ってください。
• BigQuery API へのアクセスを制限するには、VPC Service Controls を使用します。
• バケットのオーナーの場合は、公開アクセス権限の取り消しを検討してください。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

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

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

• データが漏洩したプロジェクトのオーナーに連絡します。
• 調査が完了するまで、access.principalEmail フィールドのプリンシパルの権限を取り消すことを検討してください。
• これ以上の漏洩を止めるには、影響を受けた BigQuery データセット（exfiltration.sources）に制限付きの IAM ポリシーを追加します。
• 影響を受けるデータセットに含まれる機密情報をスキャンするには、機密データの保護を使用します。Security Command Center に機密データの保護のデータを送信することもできます。情報の量によっては、機密データの保護のコストが高額になる場合があります。機密データの保護のコストを抑えるためのベスト プラクティスに従ってください。
• BigQuery API へのアクセスを制限するには、VPC Service Controls を使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

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 ポリシーを追加します。
  • MySQL
  • PostgreSQL
  • SQL Server
• Cloud SQL Admin API へのアクセスとそこからのエクスポートを制限するには、VPC Service Controls を使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Exfiltration: Cloud SQL Restore Backup to External Organization

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

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

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

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

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

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

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

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

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

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

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

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

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

   [IAM] に移動

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

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

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

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 ポリシーを追加します。
  • MySQL
  • PostgreSQL
  • SQL Server
• Cloud SQL Admin API へのアクセスを制限するには、VPC Service Controls を使用します。
• 過度に制限の緩いロールを特定して修正するには、IAM Recommender を使用します。

Exfiltration: Cloud SQL Over-Privileged Grant

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Initial Access: Anonymous GKE resource created from the internet

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

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

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

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

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

Initial Access: GKE resource modified anonymously from the internet

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

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

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

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

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

Initial Access: Dormant Service Account Action

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

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

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

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

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

   検出された内容:

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

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

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

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

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

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

Initial Access: Dormant Service Account Key Created

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Initial Access: Leaked Service Account Key Used

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Initial Access: Excessive Permission Denied Actions

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

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

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

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

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

   検出された内容:

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

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

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

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

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

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

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

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

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

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

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

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

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

Brute Force: SSH

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

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

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

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

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

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

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

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

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

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

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

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

ステップ 2: Chronicle で調査する

この検出結果を調べるには、Chronicle を使用します。Chronicle は、タイムラインを使用して脅威の調査や関連エンティティ間の移動を簡単に行うことができる Google Cloud サービスです。Chronicle を使用すると、検出データの質を高め、関心のある指標を特定し、調査を簡単に進めることができます。

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

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

   [検出結果] に移動

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

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

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

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

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

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

Chronicle で調査を行う場合は、次のガイドをご覧ください。

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

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

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

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

2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、projectId に表示されているプロジェクトを選択します。

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

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

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

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

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

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

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

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

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

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

Credential Access: External Member Added To Privileged Group

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

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

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

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

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

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

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

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

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

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

1. Google グループに移動します。

   Google グループに移動

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

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

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

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

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

Credential Access: Sensitive Role Granted To Hybrid Group

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

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

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

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

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

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

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

   [IAM] に移動

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

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

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

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

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

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

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

   

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

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

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

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

Malware: Cryptomining Bad IP

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

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

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

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

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

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

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

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

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

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

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

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

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

2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、properties_project_id に表示されているプロジェクトを選択します。

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

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

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

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

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

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

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

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. 読み込まれたページで httpRequest フィールドを調べて、悪用の試みを示す ${jndi:ldap:// のような文字列トークンがないか確認します。

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

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

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

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

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

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

Active Scan: Log4j Vulnerable to RCE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Leaked credentials

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

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

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

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

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

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

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

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

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

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

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

   [IAM] に移動

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Malware

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

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

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

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

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

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

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

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

ステップ 2: Chronicle で調査する

この検出結果を調べるには、Chronicle を使用します。Chronicle は、タイムラインを使用して脅威の調査や関連エンティティ間の移動を簡単に行うことができる Google Cloud サービスです。Chronicle を使用すると、検出データの質を高め、関心のある指標を特定し、調査を簡単に進めることができます。

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

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

   [検出結果] に移動

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

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

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

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

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

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

Chronicle で調査を行う場合は、次のガイドをご覧ください。

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

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

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

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

2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウの [プロジェクトとフォルダを検索] フィールドに、[概要] タブの [プロジェクトのフルネーム] 行にあるプロジェクト番号を入力します。

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

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

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

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

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

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

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

     次のように置き換えます。

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

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

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

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

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

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

Malware: Outgoing DoS

Event Threat Detection は、VPC フローログを分析して、サービス拒否（DoS）攻撃を開始することを目的とする可能性があるインスタンスの使用を検出します。この検出結果に対応する手順は次のとおりです。

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

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

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

   • 検出された内容
     • 送信元 IP: DoS アクティビティの送信元 IP アドレス。
     • 送信元ポート: 接続の送信元ポート。
     • 宛先 IP: DoS アクティビティのターゲット IP アドレス。
     • 宛先ポート: 接続の宛先ポート。
   • 影響を受けているリソース
   • 関連リンク（特に次のフィールド）:
     • Cloud Logging URI: Logging エントリへのリンク。
     • MITRE ATT&CK 方式: MITRE ATT&CK ドキュメントへのリンク。
     • 関連する検出結果: 関連する検出結果へのリンク。
   1. 検出結果の詳細ビューで、[JSON] タブをクリックします。
   2. [JSON] で、次のフィールドを確認します。
   • sourceInstanceDetails: 影響を受けている Compute Engine VM インスタンス

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

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

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

2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、sourceInstanceDetails に表示されているプロジェクト ID を選択します。

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

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

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

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

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

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

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

     次のように置き換えます。

     • PROJECT_ID は、問題が発生したプロジェクトの ID に置き換えます。
     • SOURCE_IP は、検出結果 JSON の srcIP フィールドにある IP アドレスに置き換えます。
     • DESTINATION_IP は、検出結果 JSON の destIp フィールドにある IP アドレスに置き換えます。

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

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

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

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

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

Persistence: IAM Anomalous Grant

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ステップ 2: Chronicle で調査する

この検出結果を調べるには、Chronicle を使用します。Chronicle は、タイムラインを使用して脅威の調査や関連エンティティ間の移動を簡単に行うことができる Google Cloud サービスです。Chronicle を使用すると、検出データの質を高め、関心のある指標を特定し、調査を簡単に進めることができます。

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

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

   [検出結果] に移動

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

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

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

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

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

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

Chronicle で調査を行う場合は、次のガイドをご覧ください。

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

ステップ 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

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

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

ステップ 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 または 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

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

ステップ 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: 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 を使用します。

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

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

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

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

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

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

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

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

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

Inhibit System Recovery: Google Cloud Backup and DR remove plan

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

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

1. 検出結果の確認の説明に従って、Inhibit System Recovery: Google Cloud Backup and DR remove plan の検出結果を開きます。検出結果の詳細パネルが開き、[概要] タブが表示されます。
2. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • アプリケーション名: バックアップと 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 個のリソース
     • リソースの表示名: ポリシーが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • 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. 削除されたプロファイルが誤って削除された場合は、[プロファイルの作成] を選択して、バックアップ アプライアンスと DR アプライアンスのストレージ ターゲットを定義します。

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

監査ログが調査され、ストレージ プールの削除が検出されます。ストレージ プールは、Cloud Storage バケットをバックアップと 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 プールを追加] を選択して再度追加します。

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. [概要] タブで、次のセクションの情報を確認します。
   • 検出された内容（特に次のフィールド）:
     • アプライアンス名: バックアップと DR に接続されたデータベースまたは VM の名前
     • プリンシパルのサブジェクト: アクションを正常に実行したユーザー
   • 影響を受ける 1 個のリソース
     • リソースの表示名: アプライアンスが削除されたプロジェクト
   • 関連リンク（特に次のフィールド）:
     • MITRE ATTACK メソッド: MITRE ATT&CK ドキュメントへのリンク
     • Logging URI: ログ エクスプローラを開くリンク

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

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

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

次の対応計画は、この検出結果に適切な場合があります。調査で収集した情報を慎重に評価して、検出結果を解決する最適な方法を判断してください。 1. 操作が行われたプロジェクトで、管理コンソールに移動します。 2. [アプリ マネージャー] タブで、保護されていないアプリケーションを確認し、そのアプリケーションのバックアップ ポリシーを確認します。3. 新しいアプライアンスを作成して、保護されていないアプリに保護を再適用するには、Google Cloud コンソールで [バックアップと 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] を選択して、オンデマンド バックアップを作成するか、新しいバックアップをスケジュールします。

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

Privilege Escalation: AlloyDB Over-Privileged Grant

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Persistence: GCE Admin Added SSH Key

説明	操作
確立されたインスタンスで ssh-keys Compute Engine インスタンスのメタデータキーが変更されました。	7 日以上前に作成されたインスタンスで、Compute Engine インスタンスのメタデータキー ssh-keys が変更されました。この変更がメンバーによって意図的に行われたものか、攻撃者が新しい経路で組織に行ったものかを確認します。	次のフィルタを使用してログを確認します。 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
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1098/004/

Persistence: GCE Admin Added Startup Script

説明	操作
確立されたインスタンスで startup-script または startup-script-url Compute Engine インスタンスのメタデータキーが変更されました。	7 日以上前に作成されたインスタンスで、Compute Engine インスタンスのメタデータキー startup-script または startup-script-url が変更されました。この変更がメンバーによって意図的に行われたものか、攻撃者が新しい経路で組織に行ったものかを確認します。	次のフィルタを使用してログを確認します。 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
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1098/004/

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 に置き換えます。
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

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 に置き換えます。
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

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 に置き換えます。
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

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 に置き換えます。
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1562/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

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 に置き換えます。
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1078/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

Persistence: SSO Enablement Toggle

プロジェクト レベルで 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
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1098/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

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
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1098/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

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 に置き換えます。
		この検出結果をトリガーするイベントの調査結果: MITRE: https://attack.mitre.org/techniques/T1562/ Workspace イベントの詳細: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

Google Workspace の脅威に対処する

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

Google Workspace 管理者は、サービスの次のセキュリティ ツールを使用して脅威を解決できます。

• Google Workspace アラート センター
• Google Workspace セキュリティ センター

このツールにはアラート、セキュリティ ダッシュボード、セキュリティの推奨事項が含まれ、脅威の調査と解決に役立ちます。

Google Workspace 管理者でない場合は、次の手順を行います。

• アカウントにアクセスできる場合は、パスワードを変更または再設定し、2 段階認証プロセスを有効にします。
• Google Workspace 管理者に問い合わせるか、Google Workspace アカウントを管理している社内のチームに連絡してください。この検出結果は、アカウント侵害の可能性を示しています。

Cloud IDS 脅威検出

Cloud IDS: THREAT_ID

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

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 ロギング エントリへのリンク - これらのエントリには、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

元のコンテナ イメージの一部でなかったバイナリが実行されました。一般に、攻撃者は最初の侵害後に不正なツールやマルウェアをインストールします。この検出結果に対応する手順は次のとおりです。

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

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

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

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

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

   • resource:
     • project_display_name: クラスタを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • Container_Image_Uri: デプロイされているコンテナ イメージの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

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

3. 「Cloud Shell をアクティブにする」 をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   次のように置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 次のコマンドを実行して、追加されたバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

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

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Added Library Loaded

元のコンテナ イメージに含まれていないライブラリが読み込まれました。コード実行保護を回避し、悪意のあるコードを非表示にするために、攻撃者が既存のプログラムに悪意のあるプログラムを読み込むおそれがあります。この検出結果に対応する手順は次のとおりです。

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

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

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

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

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

   • resource:
     • project_display_name: アセットを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • Container_Image_Uri: 実行されているコンテナ イメージの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

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

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. 次のコマンドを実行して、追加されたライブラリを取得します。

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

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

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

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Execution: Added Malicious Binary Executed

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

元のコンテナ イメージの一部でなかった悪意のあるバイナリが実行されました。一般に、攻撃者は最初の侵害後に不正なツールやマルウェアをインストールします。この検出結果に対応する手順は次のとおりです。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

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

3. 「Cloud Shell をアクティブにする」 をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   次のように置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 追加された悪意のあるバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   local_file は、追加された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Execution: Added Malicious Library Loaded

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

元のコンテナ イメージに含まれていないライブラリが読み込まれました。コード実行保護を回避し、悪意のあるコードを非表示にするために、攻撃者が既存のプログラムに悪意のあるプログラムを読み込むおそれがあります。この検出結果に対応する手順は次のとおりです。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

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

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. 追加された悪意のあるライブラリを取得します。

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   local_file は、追加された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Execution: Built in Malicious Binary Executed

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

次のバイナリで実行されたバイナリ:

• 元のコンテナ イメージに含まれています。
• 脅威インテリジェンスから悪意があると特定された。

攻撃者がコンテナ イメージ リポジトリまたは作成パイプラインを制御し、悪意のあるバイナリがコンテナ イメージに挿入されます。この検出結果に対応する手順は次のとおりです。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

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

3. 「Cloud Shell をアクティブにする」 をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   次のように置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 組み込みの悪意のあるバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   local_file は、組み込みの悪意のあるバイナリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Execution: Modified Malicious Binary Executed

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

次のバイナリで実行されたバイナリ:

• 元のコンテナ イメージに含まれています。
• コンテナ ランタイム中に変更されます。
• 脅威インテリジェンスから悪意があると特定された。

一般に、攻撃者は最初の侵害後に不正なツールやマルウェアをインストールします。この検出結果に対応する手順は次のとおりです。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

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

3. 「Cloud Shell をアクティブにする」 をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   次のように置き換えます。

   • cluster_name: resource.labels.cluster_name に表示されているクラスタ
   • location: resource.labels.location に表示されているロケーション
   • project_name: resource.project_display_name に表示されているプロジェクト名

5. 変更された悪意のあるバイナリを取得します。

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   local_file は、変更された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Execution: Modified Malicious Library Loaded

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

次のライブラリで読み込まれたライブラリ:

• 元のコンテナ イメージに含まれています。
• コンテナ ランタイム中に変更されます。
• 脅威インテリジェンスから悪意があると特定された。

コード実行保護を回避し、悪意のあるコードを非表示にするために、攻撃者が既存のプログラムに悪意のあるプログラムを読み込むおそれがあります。この検出結果に対応する手順は次のとおりです。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールに移動します。

   Google Cloud コンソールを開く

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

3. [Cloud Shell をアクティブにする] をクリックします。

4. 次のコマンドを実行して、クラスタの GKE 認証情報を取得します。

   ゾーンクラスタの場合:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   リージョン クラスタの場合:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. 変更された悪意のあるライブラリを取得します。

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   local_file は、変更された悪意のあるライブラリを格納するローカルパスに置き換えます。

6. コンテナ環境に接続します。

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Malicious Script Executed

機械学習モデルが、実行された bash スクリプトを悪意があるものとして識別しました。攻撃者は、bash を使用してツールを転送し、バイナリなしでコマンドを実行します。

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

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

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

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

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

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

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

   • finding:
     • processes:
     • script:
       • contents: 実行されたスクリプトのファイル コンテンツの接頭辞。これは調査に役立ちます。パフォーマンス上の理由でコンテンツが切り捨てられる場合があります。
       • sha256: script.contents の SHA-256 ハッシュ
   • resource:
     • project_display_name: アセットを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • Container_Image_Uri: 実行されているコンテナ イメージの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。

ステップ 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 Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

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

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

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. resource.labels.cluster_name に表示されたクラスタの名前をクリックします。

3. [クラスタ] ページで [接続] をクリックし、[Cloud Shell で実行] をクリックします。

   Cloud Shell が起動し、ターミナルにクラスタに対するコマンドが挿入されます。

4. Enter キーを押します。[Authorize Cloud Shell] ダイアログが表示されたら、[承認] をクリックします。

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

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

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

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

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

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

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

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

Malicious URL Observed

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

Container Threat Detection は、実行可能プロセスの引数リストに悪意のある URL を検出しました。攻撃者は、悪意のある URL を介してマルウェアや悪意のあるライブラリを読み込む可能性があります。

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

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

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

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

   • 検出された内容（特に次のフィールド）:
     • URI: 検出された悪意のある URI。
     • 追加のバイナリ: 悪意のある URL を含む引数を受け取ったプロセス バイナリのフルパス。
     • 引数: プロセス バイナリを呼び出すときに指定する引数。
     • 環境変数: プロセス バイナリが呼び出されたときに有効だった環境変数。
     • コンテナ: コンテナの名前。
     • Kubernetes Pod: Pod 名と Namespace。
   • 影響を受けているリソース（特に次のフィールド）:
     • リソース表示名: 影響を受けるリソースの名前。
     • 完全なリソース名: クラスタの完全なリソース名。完全なリソース名には、次の情報が含まれます。
       • クラスタを含むプロジェクト（projects/PROJECT_ID）
       • クラスタが配置されているロケーション（zone/ZONE または locations/LOCATION）
       • クラスタの名前: projects/CLUSTER_NAME

3. [JSON] タブの sourceProperties 属性にある VM_Instance_Name プロパティの値をメモします。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. 必要に応じて Google Cloud コンソールのツールバーで、[リソースの完全な名前]（resource.name）に表示されているプロジェクトを選択します。プロジェクト名は、完全なリソース名の /projects/ の後にあります。

3. 検出結果の概要の [リソース表示名]（resource.display_name）でメモしたクラスタ名をクリックします。[クラスタ] ページが開きます。

4. **クラスタの詳細ページの [メタデータ] セクションで、クラスタ オーナーを特定する情報など、脅威の解決に役立ちそうなユーザー定義の情報をメモします。

5. [ノード] タブをクリックします。

6. 表示されたノードのリストから、先ほどの検出結果の JSON でメモした VM_Instance_Name の値と一致するノードを選択します。

7. [ノードの詳細] ページの [詳細] タブで、[アノテーション] セクション内の container.googleapis.com/instance_id アノテーションの値をメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、Kubernetes Engine の [ワークロード] ページに移動します。

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

2. 必要に応じて Google Cloud コンソールのツールバーで、検出結果の概要に含まれるクラスタの [リソースの完全な名前]（resource.name）でメモしたプロジェクトを選択します。

3. [システム ワークロードを表示] をクリックします。

4. 検出結果の概要の [リソースの完全な名前]（resource.name）でメモしたクラスタ名と、必要に応じてメモした Pod の [名前空間]（kubernetes.pods.ns）で、ワークロードのリストをフィルタリングします。

5. 前の検出結果の JSON でメモした VM_Instance_Name プロパティの値と一致するワークロード名をクリックします。[Pod の詳細] ページが開きます。

6. [Pod の詳細] ページで、脅威の解決に役立つ Pod に関する情報をメモします。

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

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

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

2. 必要に応じて Google Cloud コンソールのツールバーで、[リソースの完全な名前]（resource.name）に表示されているプロジェクトを選択します。

3. [期間の選択] を目的の期間に設定します。

4. 読み込まれたページで、次の操作を行います。

   1. 次のフィルタを使用して、Pod（kubernetes.pods.name）の Pod ログを検索します。
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
   2. 次のフィルタを使用して、クラスタの監査ログを検索します。
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • POD_NAME
   3. 次のフィルタを使用して、GKE ノード コンソールのログを検索します。
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

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

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

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

2. resource.labels.cluster_name に表示されたクラスタの名前をクリックします。

3. [クラスタ] ページで [接続] をクリックし、[Cloud Shell で実行] をクリックします。

   Cloud Shell が起動し、ターミナルにクラスタに対するコマンドが挿入されます。

4. Enter キーを押します。[Authorize Cloud Shell] ダイアログが表示されたら、[承認] をクリックします。

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

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

   CONTAINER_NAME は、前に検出結果の概要でメモしたコンテナの名前に置き換えます。

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

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

1. セーフ ブラウジングのサイト ステータスで、URL が悪意のあるものとして分類される理由の詳細を確認します。
2. この検出結果タイプに対応する MITRE ATT&CK フレームワーク エントリ（Ingress Tool Transfer）を確認します。
3. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

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

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

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

Reverse Shell

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

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

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

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

   • 検出された内容（特に次のフィールド）:
     • プログラム バイナリ: リモート ソケットへのストリーム リダイレクトで始まるプロセスの絶対パス。
     • 引数: プロセス バイナリを呼び出すときに指定する引数。
   • 影響を受けているリソース（特に次のフィールド）:
     • 完全なリソース名: クラスタの完全なリソース名。
     • プロジェクトのフルネーム:
   • 検出結果の詳細ビューで、[JSON] タブをクリックします。
   • [JSON] で、次のフィールドを確認します。
   • resource:
     • project_display_name: アセットを含むプロジェクトの名前。
   • sourceProperties:
     • Pod_Namespace: Pod の Kubernetes Namespace の名前。
     • Pod_Name: GKE Pod の名前。
     • Container_Name: 影響を受けるコンテナの名前。
     • VM_Instance_Name: Pod が実行された GKE ノードの名前。
     • Reverse_Shell_Stdin_Redirection_Dst_Ip: 接続のリモート IP アドレス
     • Reverse_Shell_Stdin_Redirection_Dst_Port: リモートポート
     • Reverse_Shell_Stdin_Redirection_Src_Ip: 接続のローカル IP アドレス
     • Reverse_Shell_Stdin_Redirection_Src_Port: ローカルポート
     • Container_Image_Uri: 実行されているコンテナ イメージの名前。

ステップ 2: クラスタとノードを確認する

1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

   [Kubernetes クラスタ] に移動

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

3. resource.name に表示されるクラスタを選択します。クラスタとそのオーナーに関するメタデータをメモします。

4. [ノード] タブをクリックします。VM_Instance_Name に表示されているノードを選択します。

5. [詳細] タブをクリックし、container.googleapis.com/instance_id アノテーションをメモします。

ステップ 3: Pod を確認する

1. Google Cloud コンソールで、Kubernetes Engine の [ワークロード] ページに移動します。

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

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 の Pod ログを検索します。
      • 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. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

ステップ 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

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 Engine の [ワークロード] ページに移動します。

   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 の Pod ログを検索します。
      • 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. 対応計画を策定するには、独自の調査結果と MITRE の調査を組み合わせる必要があります。

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

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

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

VM Threat Detection レスポンス

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

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. Google Cloud コンソールで、[ダッシュボード] ページに移動します。

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

2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、検出結果の詳細の [概要] タブにある [リソースの完全な名前] 行のプロジェクトを選択します。

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

4. [リソースの完全な名前] のプロジェクトと一致する 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 の分析ページへのリンク。
     • Chronicle: Chronicle へのリンク。

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

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

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

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

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

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

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

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

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

2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、検出結果の詳細の [概要] タブにある [リソースの完全な名前] 行のリソース名に含まれているプロジェクトを選択します。

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

4. resourceName に一致する 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 の両方のレスポンス手順を実施します。

関連する脆弱性を修正する

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

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

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 の検出結果で提供される豊富な情報を駆使し、問題を修復して将来の攻撃を阻止する最適な方法を判断する必要があります。

次のステップ

• Event Threat Detection が検出するサービスと脅威の詳細については、Event Threat Detection の概要をご覧ください。

• Container Threat Detection のサービスの動作については、Container Threat Detection の概要をご覧ください。

• VM Threat Detection が検出するサービスと脅威の詳細については、VM Threat Detection の概要をご覧ください。