コンテンツに移動
Cloud
ブログ
お問い合わせ 無料で開始
Cloud
ブログ
お問い合わせ 無料で開始
脅威インテリジェンス

最前線からのサイバー犯罪の観測：UNC6040に対する予防的強化の推奨事項

2025年10月30日
Mandiant

 

※この投稿は米国時間 2025 年 10 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

背景

Software as a Service（SaaS）プラットフォームとアプリケーションを保護するには、包括的なセキュリティ戦略が必要です。このガイドでは、UNC6040 の具体的な攻撃手法の分析に基づき、予防的な強化対策、包括的なロギング プロトコル、高度な検出機能を網羅した、体系的な防御フレームワークを紹介します。これらの戦略は、特に Salesforce のセキュリティに関する推奨事項を重視しながら、組織が現在の脅威からSaaSエコシステムを保護するための実用的なアプローチを提供するものです。

Google Threat Intelligenceグループ（GTIG）は、UNC6040 を追跡しています。UNC6040 は、組織の Salesforce インスタンスを侵害して大規模なデータ窃取とその後の恐喝を行うことを目的とした、音声フィッシング（ビッシング）キャンペーンを専門とする金銭目的の脅威クラスタです。過去数か月間、UNC6040 は IT サポート担当者になりすまし、電話を使ったソーシャルエンジニアリング攻撃でネットワークへの侵入を相次いで成功させています。このアプローチは、従業員（多くの場合、多国籍企業の英語圏支社の従業員）を騙して攻撃者にアクセス権を付与させたり、機密性の高い認証情報を共有させたりすることで、組織の Salesforce データの窃取を容易にする点で特に効果的であることが実証されています。観測されたすべてのケースにおいて、攻撃者は Salesforce 固有の脆弱性を悪用するのではなく、エンドユーザーを操作する手法を用いていました。

UNC6040 の活動において頻繁に見られる手口は、被害者を欺いて組織の Salesforce ポータルに悪意のある接続アプリケーションを承認させる、というものです。このアプリケーションは Salesforce のデータローダを改変したものであることが多く、Salesforce によって承認されていないものです。ビッシング通話中、攻撃者は被害者を Salesforce の接続アプリケーション設定ページに誘導し、正規バージョンとは異なる名前やブランドを持つデータローダ アプリケーションのバージョンを承認させます。これが、侵害された Salesforce 顧客環境から直接機密情報にアクセスし、クエリを実行してデータを窃取するための重要な機能を UNC6040 に付与する攻撃者の手口です。悪意のある接続アプリケーションを介してデータローダの機能を悪用するこの手口は、Salesforce がこのような脅威から Salesforce 環境を保護するためのガイダンスで詳しく説明している最近の観測結果と一致しています。

UNC6040 の初期侵入活動から数か月が経過するまで恐喝活動が確認されなかった事例もあり、これは UNC6040 が窃取したデータへのアクセスを収益化する別の攻撃者と提携している可能性を示唆しています。これらの恐喝の試みにおいて、攻撃者は有名なハッキング グループ「ShinyHunters」との関連を主張しています。これは、被害者への圧力を高めるための戦略であると考えられます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/attack-flow-unc6040-hardening.max-1700x1700.png

図 1: データローダの攻撃フロー

UNC6040 の被害者については、次のパターンが確認されています。

  • 動機: UNC6040 は金銭目的の脅威クラスタであり、ビッシング ソーシャル エンジニアリングによって被害者のネットワークにアクセスします。

  • 焦点: アクセス権を取得すると、UNC6040 は Salesforce のデータローダ アプリケーションを使用して、被害者の Salesforce 環境からデータを即座に窃取することが確認されています。この最初のデータ窃盗の後、UNC6040 は、認証情報ハーベスティングやビッシングによって入手したエンドユーザーの認証情報を利用して被害者のネットワークを水平方向（ラテラル）に拡張し、Okta や Microsoft 365 などの他のクラウド プラットフォーム上の被害者のアカウントにアクセスしてデータを窃取することが確認されました。

  • 攻撃者のインフラストラクチャ: UNC6040 は主に Mullvad VPN の IP アドレスを使用して被害者の Salesforce 環境や被害者のネットワークの他のサービスにアクセスし、データを窃取していました。

予防的なセキュリティ強化策に関する推奨事項

以下のセクションでは、UNC6040 が使用する手口に対抗するための推奨事項を優先順位順に紹介します。このセクションは、次のカテゴリに分類されています。

  1. ID

    • ヘルプデスクとエンドユーザーの検証

    • ID の検証と保護

  2. SaaS アプリケーション

    • SaaS アプリケーション（例: Salesforce）のセキュリティ強化対策

  3. ロギングと検出

注: 以下の推奨事項には、SaaS アプリケーションを保護するための戦略が含まれていますが、ID プロバイダ（IdP）レイヤに適用可能な ID セキュリティ制御と検出、およびヘルプデスクなどの既存のプロセスのセキュリティ強化も対象としています。

1. ID

確実な本人確認

巧妙化するソーシャル エンジニアリングや認証情報の侵害攻撃から保護するには、組織は堅牢な多層プロセスを採用して ID を検証する必要があります。このプロセスは、簡単に侵害される時代遅れの方法から脱却し、すべてのサポート リクエスト、特にアカウントの変更（パスワードの再設定や多要素認証の変更など）を伴うリクエストに対して、より高いレベルの保証を確立するものです。

指針

  • すべてを疑う: 発信者が主張する ID を本質的に信頼しない。セキュリティ関連のすべてのリクエストで検証が必須です。

  • 多層防御: 複数の確認方法を組み合わせます。高リスクのアクションには、単一の要素では不十分です。

  • 安全ではない識別子を拒否する: 公開されているデータや簡単に見つけられるデータに依存しないようにします。たとえば、次のようなデータです。

    • 生年月日

    • マイナンバーの下 4 桁

    • 高校名

    • 上司の名前

このデータは、データ侵害によって漏洩したり、オープンソース インテリジェンス（OSINT）を通じて入手できることが多く、主要な検証要素として使用すべきではありません。

標準的な検証手順

ライブ動画による本人確認（主な方法）

これは、発信者を特定する最も信頼性の高い方法です。ヘルプデスク エージェントは、次のことを行う必要があります。

  1. ユーザーとのビデオ通話を開始する

  2. ユーザーに、有効な会社バッジまたは政府機関発行の写真付き身分証明書（運転免許証など）を顔の横に置いてカメラに提示するよう求める

  3. ビデオ通話の人物が身分証明書の写真と一致することを視覚的に確認する

  4. ユーザーの顔を社内の企業 ID システムの写真と照合する

  5. ID の名前が従業員の会社記録の名前と一致することを確認する動画が利用できない場合の代替手段: ライブ動画通話が不可能な場合、ユーザーは顔、写真付き ID、現在の日時が書かれた紙が写っている自撮り写真を提供する必要があります。さらに、リクエストを進める前に、ヘルプデスク担当者はユーザーのカレンダーで不在（OoO）または休暇のステータスを確認する必要があります。不在中のユーザーからのリクエストは、正式に復帰するまで原則として拒否されるべきです。

アウトオブバンド（OOB）検証（高リスクのリクエストの場合）

多要素認証（MFA）の再設定や特権アカウントのパスワード変更など、リスクの高い変更については、最初の本人確認後に追加の OOB 認証ステップが必要です。これには次のものが含まれます。

  • コールバック: 登録されているユーザーの電話番号に電話をかける

  • マネージャーの承認: 検証済みの企業コミュニケーション チャネルを通じて、ユーザーの直属のマネージャーに確認のリクエストを送信する

サードパーティ ベンダーのリクエストに関する特別な処理

Mandiant は、攻撃者がサードパーティ ベンダーのサポート担当者を装ってアクセス権を取得するインシデントを観測しています。このような状況では、標準的な検証の原則が適用されない場合があります。

ヘルプデスクは、いかなる状況でもアクセスを許可してはなりません。エージェントはリクエストを停止し、次の手順に従う必要があります。

  1. アクセスや情報を提供せずに着信通話を終了する

  2. 信頼できる登録済みの連絡先情報を使用して、そのベンダーの指定されたアカウント マネージャーに個別に連絡する

  3. リクエストを進める前に、アカウント マネージャーによる明示的な確認が必要

エンドユーザーへの働きかけ

Mandiant は、脅威アクター UNC6040 が SaaS アプリケーションへの昇格されたアクセス権限を持つエンドユーザーを標的にしていることを確認しました。UNC6040 は、ベンダーやサポート担当者を装ってこれらのユーザーに連絡し、悪意のあるリンクを提供します。ユーザーがリンクをクリックして認証すると、攻撃者はアプリケーションにアクセスしてデータを窃取します。

この脅威を軽減するために、組織はすべてのエンドユーザーに、サードパーティからのリクエストを検証することの重要性を徹底的に伝える必要があります。検証手順には以下を含める必要があります。

  • 電話を切って、登録されている電話番号で、身元がはっきりしているアカウント マネージャーに電話をかける

  • リクエスト担当者が会社の公式サポート ポータルからチケットを送信する必要がある

  • サポート コンソールで確認できる有効なチケット番号を尋ねる

また、組織は、エンドユーザーが不審な通信を報告するための明確でアクセスしやすいプロセスを提供し、この報告メカニズムがすべてのセキュリティ意識向上活動に含まれるようにする必要があります。

Salesforce には、参照できる追加のガイダンスがあります。

ID 保護 

SaaS アプリケーションへのアクセスは通常、中央の ID プロバイダ（例: Microsoft Entra ID、Okta）によって管理されるため、Mandiant は、組織がこれらのプラットフォーム内で直接、統合された ID セキュリティ制御を適用することを推奨します。

指針

Mandiant のアプローチは、次の基本原則に重点を置いています。

  • 認証境界: この原則は、ネットワーク コンテキストに基づいて信頼の基盤となるレイヤを確立します。機密リソースへのアクセスは、定義された境界内に制限する必要があります。主に、信頼できる企業ネットワークと VPN からの接続を許可し、信頼できる場所と信頼できない場所を明確に区別します。

  • 多層防御  この原則では、セキュリティを単一の制御に依存させることは認められません。組織は、強力な認証、デバイスのコンプライアンス チェック、セッション制御などの複数のセキュリティ対策を重ねる必要があります。

  • ID の検出と対応: 組織は、リアルタイムの脅威インテリジェンスに基づいて、アクセス可否を継続的に判断する必要があります。これにより、ID が侵害された場合や危険な動作を示した場合、脅威が修復されるまでアクセスが自動的に制限またはブロックされます。

ID セキュリティ制御

中央の ID プロバイダを介して SaaS アプリケーションへのアクセスを保護するには、次の制御が不可欠です。

シングル サインオン（SSO）を利用する

SaaS アプリケーションにアクセスするすべてのユーザーに、企業が管理する SSO プロバイダ（例: Microsoft Entra ID や Okta など）を介してアクセスすることを義務付けて、プラットフォーム ネイティブのアカウントの使用は禁止します。プラットフォーム ネイティブのブレークグラス アカウントを作成し、緊急時にのみ使用できるように保管する必要があります。

企業が管理するプロバイダを介した SSO が利用できない場合は、Microsoft Entra ID や Okta の設定ではなく、該当する SaaS アプリケーション（例: Salesforce）固有のセキュリティ設定を参照してください。

フィッシング耐性のある MFA を義務付ける

SaaS アプリケーションにアクセスするすべてのユーザーに、フィッシング耐性のある MFA を適用する必要があります。これは、認証情報の盗難やアカウントの乗っ取りを防ぐための基本的な要件です。特権アクセスを持つアカウントには、物理的な FIDO2 キーの適用を検討してください。ビジネス クリティカルなアプリケーションに関連付けられた認証ポリシーに MFA バイパスが存在しないことを確認してください。

Microsoft Entra ID の場合:

Okta の場合:

Google Cloud Identity / Workspace の場合:

Salesforce の場合:

デバイスの信頼とコンプライアンスを適用

企業アプリケーションへのアクセスは、ドメインに参加しているか、組織のセキュリティ基準に準拠していることが確認されたデバイスに限定する必要があります。このポリシーにより、デバイスが機密データにアクセスする前に、最低限のセキュリティ ベースラインを満たしていることが保証されます。

デバイス ポスチャー チェックの主な項目:

  • 有効なホスト証明書: デバイスは、会社が発行した有効な証明書を提示する必要があります

  • 承認済みのオペレーティング システム: エンドポイントは、現在のバージョンとパッチの要件を満たす承認済みの OS を実行する必要があります。

  • アクティブな EDR エージェント: 企業のエンドポイント検出・対応（EDR）ソリューションがインストールされ、アクティブで、正常なステータスを報告している必要があります。

Microsoft Entra ID の場合:

Okta の場合:

Google Cloud Identity / Workspace の場合:

ID 脅威への対応を自動化

Mandiant は、組織が脅威にリアルタイムで対応する動的な認証ポリシーを実装することを推奨しています。ネイティブ プラットフォーム サービスとサードパーティ ソリューションの両方から得られる ID 脅威インテリジェンス フィードを認証プロセスに統合することで、ID が侵害された場合やリスクの高い行動を示した場合に、組織はアクセスを自動的にブロックまたは追加認証を要求できます。

このアプローチでは、主に次の 2 つのリスクカテゴリを評価します。

  • リスクの高いサインイン: 異常な移動、マルウェアに関連付けられた IP アドレス、パスワード スプレー攻撃などの要因により、認証リクエストが不正である可能性

  • リスクの高いユーザー: ユーザーの認証情報が侵害されている可能性、またはオンラインで漏洩している可能性

検出されたリスクレベルに基づいて、Mandiant は組織が段階的な対応アプローチを適用することを推奨しています。

リスクベースの推奨アクション

  • 高リスクのイベントの場合: 組織は最も厳格なセキュリティ管理を適用する必要があります。これには、アクセスを完全にブロックすることも含まれます。

  • 中リスクのイベントの場合: 厳格な検証が完了した場合のみアクセスを許可します。通常、これには、ユーザーの ID（強力な MFA を使用）とデバイスの完全性（コンプライアンスとセキュリティ ポスチャーを検証）の両方の証明を要求することが含まれます。

  • 低リスクのイベントの場合: この場合も、組織は、セッションの正当性を確保し、低レベルの脅威を軽減するために、標準的な MFA などによる再認証を要求する必要があります。

Microsoft Entra ID の場合:

Okta の場合:

Google Cloud Identity / Workspace の場合:

Salesforce Shield の場合: 

  • 概要

  • イベント モニタリング: ユーザーのアクション（データアクセス、レコードの変更、ログイン元など）の詳細なログを提供し、これらのログをエクスポートして外部で分析できるようにする

  • トランザクション セキュリティ ポリシー: 大量のデータのダウンロードなど、特定のユーザー アクティビティをモニタリングし、アクティビティが発生したときにアラートを自動的にトリガーしたり、アクションをブロックしたりするように構成できる

2. SaaS アプリケーション

Salesforce の対象を絞ったセキュリティ強化制御

このセクションでは、Salesforce インスタンスに適用できる具体的なセキュリティ管理について詳しく説明します。これらの制御は、Salesforce 内の広範なアクセス、データ流出、機密データへの不正アクセスから保護するように設計されています。

ネットワークとログインの制御

信頼できるネットワーク ロケーションからのログインのみに制限します。

ネットワーク アクセスとプロファイルに基づく IP の制限に関する Salesforce のガイダンス

IP アドレスによるログインの制限

この制御により、未承認のネットワークからの認証情報の不正使用を防ぎ、攻撃者が有効なユーザー認証情報を盗んだ場合でもアクセスを効果的にブロックします。

  • プロファイル レベルでログイン IP 範囲を定義し、企業ネットワークと信頼できるネットワークのアドレスからのアクセスのみを許可します。

  • [セッション設定] で [すべてのリクエストにログイン IP 範囲を適用する] を有効にして、既存のセッションによるチェックのバイパスを回避します。

信頼できる IP 範囲の設定に関する Salesforce のガイダンスをご覧ください。

アプリケーションと API アクセスのガバナンス

接続されたアプリと API アクセスを管理

攻撃者が一般的な API クライアントと盗まれた OAuth トークンを利用し、対話型ログイン制御を回避することは少なくありません。このポリシーでは、モデルを「デフォルトで許可」から「デフォルトで拒否」に変更し、審査済みのアプリケーションのみが接続できるようにします。

  • 「デフォルトで拒否」API ポリシーを有効にする: [API アクセス制御] に移動し、[管理者によって承認されたユーザーの場合、API アクセスを許可された接続済みアプリのみに制限する] を有効にします。これにより、承認されていないすべてのクライアントがブロックされます。

  • アプリケーションの許可リストを最小限に維持する: 必須のアプリとの接続のみを明示的に承認します。この許可リストを定期的に見直して、使用されていないアプリや承認されていないアプリを削除します。

  • アプリごとに厳格な OAuth ポリシーを適用する: 承認されたアプリごとに、信頼できる IP 範囲へのアクセス制限、MFA の適用、適切なセッションと更新トークンのタイムアウトの設定など、きめ細かいセキュリティ ポリシーを構成します。

  • アプリを削除する際にセッションを取り消す: アプリのアクセス権を取り消す際は、関連するすべてのアクティブな OAuth トークンとセッションも取り消して、そのアプリによるアクセスを完全に遮断します。

  • 組織のプロセスとポリシー: サードパーティとのアプリケーション統合を管理するポリシーを作成します。ビジネスクリティカルなアプリケーション（Salesforce、Google Workspace、Workday など）との統合すべてについて、サードパーティ リスク管理レビューを実施します。

API アクセスの管理に関する Salesforce のガイダンス

ユーザーの権限とアクセスの管理

最小権限の原則を実装する

ユーザーには、職務を遂行するために必要な最小限の権限のみを付与する必要があります。

  • 「最小アクセス」プロファイルをベースラインとして使用する: 最小限の権限でベース プロファイルを構成し、デフォルトですべての新規ユーザーに割り当てます。「すべて表示」権限と「すべて変更」権限の割り当てを制限します。

  • 権限セットを介して権限を付与する: アクセスを追加で付与する際は、多数のカスタム プロファイルを作成するのではなく、職務に基づいて明確に定義された権限セットを使います。

  • 重要でないユーザーの API アクセスを無効にする: データローダなどのツールには、「API の有効化」権限が必要です。この権限をすべてのユーザー プロフィールから削除し、制御された権限セットを介して、少数の、正当な理由を持つユーザーにのみ付与します。

  • 管理者以外のユーザーから [設定] メニューを非表示にする: 管理者以外のすべてのプロファイルについて、管理用の [設定] メニューへのアクセスを削除し、不正な構成変更を防止します。

  • 機密性の高い操作には高保証セッションを適用する: レポートのエクスポートなどの機密性の高い操作に対して高保証（認証強化）セッションを要求するように、セッション設定を構成します。

セッションのセキュリティ設定の変更に関する Salesforce のガイダンス

高保証セッション セキュリティを要求する際の Salesforce のガイダンス

「すべて表示」権限と「すべて変更」権限に関する Salesforce のガイダンス

きめ細かいデータアクセス ポリシー

組織全体の共有のデフォルト（OWD）を「非公開」に設定

  • すべての機密オブジェクトについて、内部および外部の組織全体のデフォルト（OWD）を「非公開」に設定します。

  • ロール階層による広範なアクセスに頼るのではなく、共有ルールやその他の共有メカニズムを使って、データアクセスを戦略的に許可します。

制限ルールを利用して行レベルのセキュリティを確保する

制限ルールは、他のすべての共有設定の上に適用されるフィルタとして機能し、ユーザーが表示できるレコードをきめ細かく制御できます。

制限ルールに関する Salesforce のガイダンス

Salesforce サポート ログイン アクセスを取り消す

機密データにアクセスできるユーザーや、基盤となる Salesforce インスタンスへの特権アクセス権を持つユーザーが、Salesforce サポートへのアクセス権の付与に厳格なタイムアウトを設定していることを確認します。

保留中のリクエストをすべて取り消し、特定のユースケースに対してのみ、厳格な時間制限を設けてから再度有効にします。管理アカウントからこれらのアクセス許可を有効にすることには注意が必要です。

Salesforce サポートへのログイン アクセス権の付与に関する Salesforce のガイダンス

Mandiant は、Salesforce Security Health Check ツールを実行して構成ミスを特定し、対処することを推奨しています。その他の強化に関する推奨事項については、Salesforce セキュリティ ガイドをご覧ください。

3. ロギングと検出

Salesforce の対象を絞ったロギングと検出の制御

このセクションでは、Salesforce インスタンスの主要なロギングと検出の戦略について説明します。これらの制御は、SaaS 環境内の高度な脅威を特定して対応するために不可欠です。

SaaS アプリケーションのロギング

攻撃者が SaaS アプリケーションに対して使用する戦術、技術、手順（TTP）を可視化するために、Mandiant は、組織の Salesforce 環境で重要なログタイプを有効にし、それらのログをセキュリティ情報およびイベント管理（SIEM）に取り込むことを推奨しています。

ロギングの前に必要なもの

収集を有効にするか、検出を記述する前に、組織が使用する予定のログに対する権利を実際に持っていること、および適切な機能が有効になっていることを確認してください。

利用資格の確認（必須）

      1. ほとんどのセキュリティ ログ / 機能は、Salesforce Shield または Event Monitoring アドオンを介したイベント モニタリングのライセンスを要求します。これは、リアルタイム イベント モニタリング（RTEM）のストリーミングと表示に適用されます。

ユースケースごとにデータモデルを選択

      1. RTEM - ストリーム（ほぼリアルタイムのアラート）: Enterprise / Unlimited / Developer サブスクリプションで利用可能。ストリーミング イベントは 3 日間保持。

      2. RTEM - ストレージ: 多くのオブジェクトが Big Object（ネイティブ ストレージ）で、一部は標準オブジェクト（脅威検出ストアなど）。

      3. イベントログファイル（ELF）- CSV モデル（バッチ エクスポート）: Enterprise / Performance / Unlimited エディションで利用可能。

      4. イベントログ オブジェクト（ELO）- SOQL モデル（クエリ可能な履歴）: Shield / アドオンが必要。

必要な機能を有効にする（アクセス範囲を設定する）

      1. イベント マネージャーを使用して、イベントごとにストリーミングと保存を有効 / 無効にしたり、RTEM イベントを表示したりできます。

      2. RTEM と Threat Detection の UI のプロファイル / 権限セットを介してアクセスを許可します。

脅威の検出と ETS

    1. 脅威検出イベントは、Shield / アドオンで UI に表示され、対応する EventStore オブジェクトに保存されます。

    2.  リアルタイム イベントに対するブロック / MFA / 通知アクションの RTEM には、拡張トランザクション セキュリティ（ETS）が含まれています。

モニタリングする推奨ログソース

  • ログイン履歴（LoginHistory）: ユーザー名、時間、IP アドレス、ステータス（成功 / 失敗）、クライアント タイプなど、すべてのログイン試行を追跡します。これにより、異常なログイン時間、不審な場所、繰り返しの失敗を特定できます。これらは、認証情報の不正使用やアカウントの侵害を示している可能性があります。

  • ログイン イベント（LoginEventStream）: LoginEvent は、Salesforce にログインするユーザーのログイン アクティビティを追跡します。

  • 設定監査証跡（SetupAuditTrail）: Salesforce 環境内での管理および構成の変更を記録します。これにより、権限、セキュリティ設定、その他の重要な構成に加えられた変更を追跡し、監査とコンプライアンスの取り組みを促進できます。

  • API 呼び出し（ApiEventStream）: ユーザーまたは接続されたアプリによる呼び出しを追跡することで、API の使用状況と潜在的な不正使用をモニタリングします。

  • レポートのエクスポート（ReportEventStream）: レポートのダウンロードに関する分析情報を提供し、データ流出の試みを検出するのに役立ちます。

  • リストビュー イベント（ListViewEventStream）: リストビューでのユーザー操作を追跡します。これには、ビュー内のデータへのアクセスや操作が含まれます。

  • Bulk API イベント（BulkApiResultEvent）: ユーザーが Bulk API リクエストの結果をダウンロードしたときに追跡します。

  • 権限の変更（PermissionSetEvent）: 権限セットと権限セット グループの変更を追跡します。このイベントは、権限セットに権限が追加または削除されたときに開始されます。

  • API の異常（ApiAnomalyEvent）: 通常とは異なる API 呼び出しのパターンを追跡します。

  • 一意のクエリ イベントタイプ: 一意のクエリ イベントは、ユーザーが実行した検索クエリ（SOQL）、フィルタ ID、レポート ID と、それらが内部でどのようなデータベース クエリ（SQL）に変換されたかを記録します。

  • 外部 ID プロバイダのイベントログ: SSO を使用したログイン試行の情報を追跡します（IdP イベントログのモニタリングと収集については、ID プロバイダから提供されたガイダンスに従ってください）。

これらのログソースにより、組織は、攻撃者が使用する一般的な TTP を適切に収集して監視するためのロギング機能を利用できます。各 TTP でモニタリングする主なログソースと、観測可能な Salesforce アクティビティは次のとおりです。

 

TTP

観測可能な Salesforce アクティビティ

ログのソース

ビッシング

  • 不審なログイン試行（短時間での失敗）。

  • 通常とは異なる IP / ASN からのログイン（例: Mullvad / Tor）

  • 認識されないクライアントからの OAuth（「リモート アクセス 2.0」）。

  • ログイン履歴

  • LoginEventStream / LoginEvent

  • 監査証跡の設定

悪意のある接続アプリの認証 （例: データローダ、カスタム スクリプト）

  • 新しい接続アプリの作成 / 変更（広範なスコープ: api、refresh_token、offline_access）。

  • ポリシーの緩和（許可されたユーザー、IP 制限）。

  • 権限を介して API を有効にする / [接続済みアプリを管理] を付与する。

  • 監査証跡の設定

  • PermissionSetEvent

  • LoginEventStream / LoginEvent（OAuth）

データの引き出し（API、データローダ、レポート経由）

  • 高レートの Query / QueryMore / QueryAll バースト。

  • レポートとリストビューで処理された行数 / レコード数が大きい（チャンク化）。

  • ジョブの結果を一括ダウンロード。

  • 大規模なファイル / 添付ファイルのダウンロード。

  • ApiEventStream / ApiEvent

  • ReportEventStream / ReportEvent

  • ListViewEventStream / ListViewEvent

  • BulkApiResultEvent

  • FileEvent / FileEventStore

  • ApiAnomalyEvent / ReportAnomalyEvent

  • 一意のクエリ イベントタイプ

水平方向の拡張 / 永続性 （Salesforce 内または他のクラウド プラットフォームに対し）

  • 権限の昇格（例: すべてのデータの表示 / 変更、API 有効）。

  • 新しいユーザー アカウント / サービス アカウント。

  • LoginAs アクティビティ。

  • SF OAuth 後の VPN / Tor からのログイン。

  • Okta / M365 に移動し、グラフデータを取得。

  • 監査証跡の設定

  • PermissionSetEvent

  • LoginAsEventStream

SaaS アプリケーションの検出

ネイティブの SIEM 脅威検出は一定の保護を提供しますが、複雑な環境全体で異なるイベントを関連付けるために必要な一元化された可視性が欠けていることがよくあります。カスタムの標的型検出ルールを開発すれば、組織は悪意のあるアクティビティをプロアクティブに検出できます。

データ流出と Cross-SaaS の水平方向の拡張（認証後） 

MITRE マッピング: TA0010 - データ窃取と TA0008 - 水平方向の拡張

シナリオと目標

ユーザーが（悪意のある、またはなりすましの）接続アプリを承認すると、UNC6040 は通常、次のことを行います。

  1. データの引き出しを迅速に実行（REST ページネーション バースト、Bulk API ダウンロード、大規模 / 高機密性のレポートのエクスポート）。

  2. 同じ危険なエグレス IP から Okta / Microsoft 365 に移動してアクセスを拡大し、より多くのデータを窃取。

ここで検出すべきパターンは、以下のとおりです：Salesforce OAuth 後 10 分以内のデータ漏洩、Salesforce OAuth 後 60 分以内の Okta / M365 ログイン（同じ危険な IP）、および単一シグナルで低ノイズのデータ漏洩パターン。

ベースラインと許可リスト

ビッシング フェーズですでに管理しているリストを再利用し、機密性の高いコンテンツを検出するための 2 つの正規表現を追加します。

  • STRING

    • ALLOWLIST_CONNECTED_APP_NAMES 

    • KNOWN_INTEGRATION_USERS（OAuth を正当に使用するユーザーの ID / メールアドレス）

    • VPN_TOR_ASNS（文字列としての ASN）

  • CIDR

    • ENTERPRISE_EGRESS_CIDRS（企業 / VPN のパブリック エグレス（外向きトラフィック））

  • REGEX

    • SENSITIVE_REPORT_REGEX

(?i)\b(all|export|dump)\b.*\b(contact|lead|account|customer|pii|email|phone|ssn)\b
    • M365_SENSITIVE_GRAPH_REGEX
(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/(users|me)/messages
(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/drives/.*/items/.*/content
(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/reports/
(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/users(\?|$)

高精度検出カタログ（擬似コード）

Salesforce OAuth → 10 分以内のデータ流出（複数イベント）

不審な OAuth の 10 分以内に、同じユーザーによる結果の一括ダウンロード、REST ページネーション バースト、機密性の高いレポートや大容量レポートのエクスポートが続く。

精度が高い理由: UNC6040 の「承認 → 引き出し」パターンと一致。ウィンドウとボリュームのしきい値が厳密。

主要シグナル

  • OAuth 成功（不明なアプリまたは許可リスト登録済み + リスクの高いエグレス）、ユーザーにバインド。

  • その後、次のいずれか: 

    • RowsProcessed / RecordCount が大きい BulkApiResultEvent

    • ApiEventStream のクエリ / クエリの続きの呼び出しが多い

    • ReportEventStream の大規模 / 機密レポートのエクスポート

  • リスト / ノブ: ENTERPRISE_EGRESS_CIDRS、VPN_TOR_ASNS、SENSITIVE_REPORT_REGEX。

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$bulk.metadata.product_name = "SALESFORCE"
$bulk.metadata.log_type = "SALESFORCE"
$bulk.metadata.product_event_type = "BulkApiResultEvent"
$uid = coalesce($bulk.principal.user.userid, $bulk.extracted.fields["UserId"])

match:
$uid over 10m

または

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$api.metadata.product_name = "SALESFORCE"
$api.metadata.log_type = "SALESFORCE"
$api.metadata.product_event_type = "ApiEventStream"
$uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"])

match:
$uid over 10m

または

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$report.metadata.product_name = "SALESFORCE"
$report.metadata.log_type = "SALESFORCE"
$report.metadata.product_event_type = "ReportEventStream"
strings.to_lower(coalesce($report.extracted.fields["ReportName"], "")) in regex SENSITIVE_REPORT_REGEX
$uid = coalesce($report.principal.user.userid, $report.extracted.fields["UserId"])

match:
$uid over 10m

注: このケースでは、ApiEventStream、BulkApiResultEvent、ReportEventStream などのプロダクト イベントタイプのみをモニタリング対象の単一イベントルールとして使用できるため、マルチイベントルールの代わりに単一イベントルールを使用することもできます。ただし、単一のイベントルールを確立する場合は注意が必要です。ノイズが多くなる可能性があるため、参照リストを積極的にモニタリングする必要があります。

Bulk API 大規模結果ダウンロード（統合ユーザー以外）

人間ユーザーによる、しきい値を超える Bulk API / Bulk v2 の結果のダウンロード。

精度が高い理由: 明確なデータ窃取の証跡。

重要なシグナル: BulkApiResultEvent、ユーザーが KNOWN_INTEGRATION_USERS に含まれていない。

リスト / ノブ: KNOWN_INTEGRATION_USERS、サイズしきい値。

$e.metadata.product_name = "SALESFORCE"
$e.metadata.log_type = "SALESFORCE"
$e.metadata.product_event_type = "BulkApiResultEvent"
not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)

REST クエリのページネーション バースト（query / queryMore）

短期間に高頻度で query* / queryMore 呼び出しが行われている。

精度が高い理由: スクリプトによる引き出しを模倣。人間の安定した使用ではバーストのしきい値に達しない。

主なシグナル: ApiEventStream、クエリ内の Operation、queryMore、query_all、queryall、10 分間にしきい値以上の count、ユーザーが KNOWN_INTEGRATION_USERS に含まれていない。

リスト / ノブ: バーストしきい値、KNOWN_INTEGRATION_USERS。

$api.metadata.product_name = "SALESFORCE"
$api.metadata.log_type = "SALESFORCE"
$api.metadata.product_event_type = "ApiEventStream"
not (coalesce($api.principal.user.userid, $api.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)
strings.to_lower(coalesce($api.extracted.fields["Operation"], "")) in regex `(?i)^(query|querymore|query_all|queryall)$`
$uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"])

統合されていないユーザーによる機密レポートのエクスポート

人間による、名前が機密情報を含むレポートや大規模なレポートのエクスポート。

精度が高い理由: レポートのエクスポートは攻撃者がよく使う手法だが、ログに記録されやすく、検出精度が高い。

主なシグナル: ReportEventStream、RowsProcessed が高い、ReportName が SENSITIVE_REPORT_REGEX と一致する、ユーザーが KNOWN_INTEGRATION_USERS に含まれていない。

リスト / ノブ: SENSITIVE_REPORT_REGEX、KNOWN_INTEGRATION_USERS。

$e.metadata.product_name = "SALESFORCE"
$e.metadata.log_type = "SALESFORCE"
$e.metadata.product_event_type = "ReportEventStream"
not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)
strings.to_lower(coalesce($e.extracted.fields["ReportName"], "")) in regex %SENSITIVE_REPORT_REGEX

Salesforce OAuth → Okta / M365 ログイン（同じ危険な IP から 60 分以内）（複数イベント）

Salesforce OAuth の不審なアクティビティが検出された 60 分以内に、同じパブリック IP から Okta または Entra ID へのログインが検出された。この IP は社外または VPN / Tor ASN である。

精度が高い理由: 攻撃者のエグレス IP を SaaS 全体で狭い時間枠で結び付ける。

主要シグナル

  • Salesforce OAuth ポスチャー（不明なアプリまたは許可リスト登録済み + リスクの高いエグレス）

  • 同じ IP からの OKTA* または OFFICE_365 USER_LOGIN

リスト / ノブ: ENTERPRISE_EGRESS_CIDRS、VPN_TOR_ASNS。（ID が正規化されている場合は、ユーザーのメールアドレスによるオプションの並列ルール バインディング）

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS )
$ip = coalesce($oauth.principal.asset.ip, $oauth.principal.ip)

$okta.metadata.log_type in "OKTA"
$okta.metadata.event_type = "USER_LOGIN"
$ip = coalesce($okta.principal.asset.ip, $okta.principal.ip) = $ip

$o365.metadata.log_type = "OFFICE_365"
$o365.metadata.event_type = "USER_LOGIN"
$ip = coalesce($o365.principal.asset.ip, $o365.principal.ip)

match:
$ip over 10m

M365 Graph Data-Pull After Risky Login

リスクの高いエグレスからの Entra ID ログインに続いて、メール、ファイル、レポートを取得する Microsoft Graph エンドポイント。

精度が高い理由: アカウントの不正使用でよく観察される、ログイン後のデータアクセスを捕捉する。

主なシグナル: 企業外の IP または VPN / Tor ASN を使用した OFFICE_365 USER_LOGIN の後、数時間以内に同じアカウントで M365_SENSITIVE_GRAPH_REGEX に一致する URL への HTTP が発生。

リスト / ノブ: ENTERPRISE_EGRESS_CIDRS、VPN_TOR_ASNS、M365_SENSITIVE_GRAPH_REGEX。

$login.metadata.log_type = "OFFICE_365"
$login.metadata.event_type = "USER_LOGIN"
$ip  = coalesce($login.principal.asset.ip, $login.principal.ip)
( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
 or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS )
$acct = coalesce($login.principal.user.userid, $login.principal.user.email_addresses)

$http.metadata.product_name in ("Entra ID","Microsoft")
($http.metadata.event_type = "NETWORK_HTTP" or $http.target.url != "")
$acct = coalesce($http.principal.user.userid, $http.principal.user.email_addresses)
strings.to_lower(coalesce($http.target.url, "")) in regex %M365_SENSITIVE_GRAPH_REGEX

match:
$acct over 30m

チューニングと例外

  • ID の結合 - 堅牢性を確保するため、水平方向の拡張ルールは IP でグループ化されます。強力な ID 正規化（Salesforce <-> Okta <-> M365）がある場合は、それを複製し、IP の代わりにユーザーのメールアドレスで照合します。

  • 期間の変更 - 承認されたデータ移行 / 接続済みアプリのオンボーディング中は、時間制限付きのルールを抑制する（ベンダーアプリを ALLOWLIST_CONNECTED_APP_NAMES に一時的に追加する）

  • 統合アカウント - KNOWN_INTEGRATION_USERS を最新の状態に保ちます。データ漏洩ルールのノイズのほとんどは、スケジュール設定された ETL から発生します。

  • エグレスの管理 - ENTERPRISE_EGRESS_CIDRS を最新の状態に保つ。NAT / VPN の範囲が古くなると、VPN / Tor の検出結果が増加する。

  • ストリーミングと保存 - 前述のルールは、リアルタイム イベント モニタリング ストリーム オブジェクト（ApiEventStream、ReportEventStream、ListViewEventStream、BulkApiResultEvent）を前提としています。過去のハンティングでは、保存された同等のもの（ApiEvent、ReportEvent、ListViewEvent）を同じロジックで処理します。

IOC ベースの検出

シナリオと目標

攻撃者が、組織のネットワークにアクセスしたか、アクセスを試みました。

目的は、利用可能なすべてのログに基づいて、環境内に既知の UNC6040 IOC が存在するかどうかを検出することです。

リファレンス リスト

組織が維持すべき参照リスト:

  • STRING

    • UNC6040_IOC_LIST（脅威インテリジェンス ソースからの IP アドレスなど。VirusTotal

セキュリティ侵害インジケーター（IOC）のリスト

高精度検出カタログ（擬似コード）

UNC6040 IP_IoC が検出されました

UNC6040 に関連付けられた既知の IOC が、組織の環境で、送信元または宛先の接続から検出されました。

  • 送信元または宛先 IP アドレスが既知の UNC6040 IOC と一致する場合、精度が高い。

($e.principal.ip in %unc6040_IoC_list) or ($e.target.ip in %unc6040_IoC_list)

謝辞

このガイドの作成にご協力いただいた Salesforce に感謝いたします。

-Mandiant、執筆者: Omar ElAhdan、Matthew McWhirt、Michael Rudden、Aswad Robinson、Bhavesh Dhake、Laith Al

 

投稿先
関連記事
https://storage.googleapis.com/gweb-cloudblog-publish/images/03_ThreatIntelligenceWebsiteBannerIdeas_BANN.max-700x700.png
Threat Intelligence

警視庁「サイバーセキュリティ有識者研修」に Google Cloud が登壇──捜査・業務を変革する生成 AI と脅威インテリジェンスの最前線

執筆者: Google Cloud Japan Team • 所要時間: 2 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/03_ThreatIntelligenceWebsiteBannerIdeas_BANN.max-700x700.png
Threat Intelligence

今後の脅威に備える: Cybersecurity Forecast 2026

執筆者: Adam Greenberg • 所要時間: 3 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/03_ThreatIntelligenceWebsiteBannerIdeas_BANN.max-700x700.png
Threat Intelligence

ブロック上の新しいグループ: UNC5142 が EtherHiding を利用してマルウェアを配布

執筆者: Mandiant • 所要時間: 60 分

https://storage.googleapis.com/gweb-cloudblog-publish/images/03_ThreatIntelligenceWebsiteBannerIdeas_BANN.max-700x700.png
Threat Intelligence

求人広告: ベトナムのアクターが偽の求人情報キャンペーンを利用してマルウェアを配信して認証情報を盗み出す

執筆者: Google Threat Intelligence Group • 所要時間: 4 分