TokyoBlackHatNews

google-threat-intel 46分で読了

最前線からのサイバー犯罪の観測：UNC6040に対するプロアクティブなハードニング推奨事項

執筆者：Omar ElAhdan、Matthew McWhirt、Michael Rudden、Aswad Robinson、Bhavesh Dhake、Laith Al、Ravi Kumar Raja

背景

Software-as-a-service（SaaS）プラットフォームとアプリケーションを保護するには、包括的なセキュリティ戦略が必要です。UNC6040の特定の攻撃手法の分析に基づき、本ガイドでは、プロアクティブなハードニング対策、包括的なログ記録プロトコル、高度な検知機能を含む、構造化された防御フレームワークを提示します。Salesforceに特化したセキュリティ推奨事項を強調しつつ、これらの戦略は、現在の脅威からSaaSエコシステムを保護するための実行可能なアプローチを組織に提供します。

Google Threat Intelligence Group（GTIG）はUNC6040を追跡しています。UNC6040は金銭目的の脅威クラスターで、組織のSalesforceインスタンスを侵害して大規模なデータ窃取とその後の恐喝を行うことを目的とした、音声フィッシング（vishing）キャンペーンを専門としています。過去数か月にわたり、UNC6040は、オペレーターがITサポート担当者になりすまし、説得力のある電話ベースのソーシャルエンジニアリングを行うことで、ネットワーク侵害に繰り返し成功していることが確認されています。この手口は、特に多国籍企業の英語圏拠点において、従業員をだまして攻撃者にアクセス権を与える行動を取らせたり、機微な認証情報を共有させたりする点で非常に効果的であり、最終的に組織のSalesforceデータの窃取を容易にします。観測されたすべての事例において、攻撃者はSalesforce固有の脆弱性を悪用するのではなく、エンドユーザーの操作に依存していました。

UNC6040の作戦で一般的な戦術の1つは、被害者をだまして、組織のSalesforceポータルに悪意のある接続アプリ（Connected App）を承認させることです。このアプリケーションは、SalesforceのData Loaderの改変版であることが多く、Salesforceによって承認されていません。vishingの通話中、攻撃者は被害者にSalesforceの接続アプリ設定ページへアクセスさせ、正規版とは異なる名称やブランド表示のData Loaderアプリのバージョンを承認するよう誘導します。この手順により、被害者は意図せずUNC6040に、侵害されたSalesforce顧客環境から機微情報へ直接アクセスし、クエリし、持ち出すための重要な権限を付与してしまいます。悪意のある接続アプリを介してData Loaderの機能を悪用するこの手法は、Salesforceが同様の脅威からSalesforce環境を保護するためのガイダンスで詳述している最近の観測結果とも一致します。

一部の事例では、最初のUNC6040侵入活動から数か月経過するまで恐喝活動が観測されておらず、これはUNC6040が、盗まれたデータへのアクセスを収益化する第2の脅威アクターと提携している可能性を示唆します。これらの恐喝の試みでは、攻撃者は、被害者への圧力を高める手段として、著名なハッキンググループであるShinyHuntersとの関係を主張しています。

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

図1：Data Loader攻撃フロー

UNC6040の被害者像（victimology）において、以下のパターンを観測しています：

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

  • 焦点： アクセスを得ると、UNC6040はSalesforceのData Loaderアプリケーションを使用して、被害者のSalesforce環境から直ちにデータを持ち出すことが観測されています。この初期のデータ窃取の後、UNC6040は、認証情報の収集（credential harvesting）またはvishingによって入手したエンドユーザーの認証情報を活用して被害者ネットワーク内を横展開し、OktaやMicrosoft 365など他のクラウドプラットフォーム上の被害者アカウントへアクセスしてデータを持ち出すことが観測されています。

  • 攻撃者インフラ： UNC6040は主にMullvad VPNのIPアドレスを使用して、被害者のSalesforce環境および被害者ネットワークの他サービスにアクセスし、データの持ち出しを実行していました。

プロアクティブなハードニング推奨事項

以下のセクションでは、UNC6040が利用する戦術に対抗するための優先度付き推奨事項を提供します。本セクションは次のカテゴリに分かれています： 

  1. アイデンティティ
    • ヘルプデスクおよびエンドユーザーの検証 
    • アイデンティティの検証と保護
    • プログラム用認証情報
  2. SaaSアプリケーション
    • SaaSアプリケーション（例：Salesforce）のハードニング対策 
  3. ログ記録と検知

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

1. アイデンティティ

確実な本人確認

高度化するソーシャルエンジニアリングおよび認証情報侵害攻撃から保護するため、組織は堅牢で多層的な本人確認プロセスを採用する必要があります。このプロセスは、時代遅れで容易に侵害される方法を超え、すべてのサポート要求、特にアカウント変更（例：パスワードリセットや多要素認証の変更）を伴う要求に対して、より高い保証水準を確立します。

指針となる原則
  • 何も前提にしない： 発信者が名乗る身元を当然のものとして信頼しないでください。セキュリティ関連の要求はすべて検証が必須です。
  • 多層防御： 複数の検証方法の組み合わせに依存してください。高リスクの操作において、単一要素だけで十分であってはなりません。
  • 安全でない識別子を拒否する： 公開情報や容易に推測可能なデータに依存することを避けてください。例えば以下の情報：

    • 生年月日

    • 社会保障番号の下4桁

    • 高校名

    • 上司の氏名

これらのデータは、データ侵害で漏えいしていることが多く、またオープンソースインテリジェンス（OSINT）で入手可能な場合もあるため、主要な検証要素として使用すべきではありません。

標準的な検証手順
ライブ動画による本人確認（主要手段）

これは発信者を特定する最も信頼性の高い方法です。ヘルプデスク担当者は以下を実施する必要があります：

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

  2. ユーザーに、有効な社員証または政府発行の写真付き身分証明書（例：運転免許証）を、顔の横でカメラに提示させる

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

  4. 社内のアイデンティティシステムに登録された写真とユーザーの顔を照合する

  5. 身分証明書の氏名が従業員の社内記録の氏名と一致することを確認する

    動画が利用できない場合の代替： ライブのビデオ通話が不可能な場合、ユーザーは、本人の顔、写真付き身分証明書、そして現在の日付と時刻を書いた紙を一緒に写した自撮り写真を提出する必要があります。さらに、いかなる要求を進める前にも、ヘルプデスク担当者はユーザーのカレンダーで外出中（OOO）または休暇のステータスを確認しなければなりません。OOOとマークされているユーザーからの要求は、正式に復帰するまで原則として拒否すべきです。

帯域外（OOB）検証（高リスク要求向け）

  • 折り返し電話： 登録済みの電話番号（記録上の番号）に電話をかける

  • 上長承認： 検証済みの社内コミュニケーションチャネルを通じて、ユーザーの直属の上長に確認依頼を送る

サードパーティベンダーからの要求に対する特別対応

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

いかなる状況でも、ヘルプデスクはアクセス許可を進めてはなりません。担当者は要求を停止し、次の手順に従う必要があります：

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

  2. 信頼できる記録済みの連絡先情報を使用して、そのベンダーの会社に指定されているアカウントマネージャーへ独立に連絡する

  3. いかなる要求を進める前にも、アカウントマネージャーから明示的な検証を得る

エンドユーザーへの周知 

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

この脅威を軽減するため、組織は、すべてのエンドユーザーに対し、サードパーティからの要求を検証する重要性を厳格に周知すべきです。検証手順には以下を含めるべきです：

  • いったん電話を切り、記録上の電話番号を用いて公式のアカウントマネージャーに電話する

  • 要求者に、公式の企業サポートポータルからチケットを提出させる

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

また、組織は、エンドユーザーが不審な連絡を報告できる明確で利用しやすいプロセスを提供し、この報告メカニズムをすべてのセキュリティ啓発活動に含めるべきです。

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

アイデンティティ保護 

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

指針となる原則

Mandiantのアプローチは、以下の中核原則に焦点を当てています：

  • 認証境界 この原則は、ネットワークコンテキストに基づく信頼の基盤層を確立します。機微なリソースへのアクセスは定義された境界内に限定し、主に信頼された社内ネットワークおよびVPNからの接続を許可することで、信頼できる場所と信頼できない場所を明確に区別します。

  • 多層防御 この原則は、セキュリティが単一の制御に依存できないことを示します。組織は、強力な認証、デバイス準拠チェック、セッション制御など、複数のセキュリティ対策を重ねるべきです。

  • アイデンティティの検知と対応  組織は、リアルタイムの脅威インテリジェンスをアクセス判断に継続的に統合しなければなりません。これにより、アイデンティティが侵害されたりリスクの高い挙動を示したりした場合、脅威が是正されるまでアクセスが自動的に封じ込められるかブロックされます。

アイデンティティセキュリティ制御 

以下の制御は、中央のアイデンティティプロバイダを通じて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： エンドポイントは、現行のバージョンおよびパッチ要件を満たす承認済みOSで稼働していなければならない
  • 稼働中のEDRエージェント： 企業のEndpoint Detection and Response（EDR）ソリューションがインストールされ、稼働し、健全な状態を報告していなければならない

Microsoft Entra IDの場合：

Oktaの場合：

Google Cloud Identity / Workspaceの場合：

アイデンティティ脅威への対応を自動化する

Mandiantは、リアルタイムで脅威に反応する動的な認証ポリシーを実装することを推奨します。アイデンティティ脅威インテリジェンスのフィード（プラットフォーム標準サービスおよびサードパーティソリューションの双方）を認証プロセスに統合することで、アイデンティティが侵害されたりリスクの高い挙動を示したりした場合に、アクセスを自動的にブロックまたは追加検証（チャレンジ）できます。

このアプローチは主に、次の2種類のリスクを評価します：

  • リスクの高いサインイン： 異常な移動、マルウェアに関連するIPアドレス、パスワードスプレー活動などの要因により、認証要求が不正である可能性
  • リスクの高いユーザー： ユーザーの認証情報が侵害された、またはオンラインで漏えいしている可能性

検知されたリスクレベルに基づき、Mandiantは段階的な是正アプローチを適用することを推奨します。

推奨されるリスクベースの対応
  • 高リスクイベント： 組織は最も厳格なセキュリティ制御を適用すべきです。これにはアクセスの完全ブロックが含まれます。
  • 中リスクイベント： 大幅な追加検証の後にのみアクセスを許可すべきです。通常、ユーザーの本人性（強力なMFA）とデバイスの完全性（準拠およびセキュリティポスチャの検証）の双方の証明が必要になります。
  • 低リスクイベント： 低精度の脅威を軽減し、セッションの正当性を確保するため、標準的なMFAなどの追加認証チャレンジを引き続き要求すべきです。

Microsoft Entra IDの場合：

Oktaの場合：

Google Cloud Identity / Workspaceの場合：

Salesforce Shieldの場合： 

  • 概要
  • イベントモニタリング： データアクセス、レコード変更、ログイン元などのユーザー操作の詳細ログを提供し、外部分析のためにエクスポートできます
  • トランザクションセキュリティポリシー： 大量データのダウンロードなど特定のユーザー活動を監視し、発生時にアラートを自動的にトリガーしたり、操作をブロックしたりするよう設定できます
プログラム用認証情報の保護、ログ記録、検知

プログラム用認証情報は、APIキー、OAuthトークン、サービスアカウント、アクセスキーといった、独立した、かつ標的化が進むアイデンティティのクラスを表します。歴史的に、これらの認証情報は「設定したら放置」という考え方のもとで作成・構成されてきました。チームは作成・構成し、暗黙の信頼を確立する一方で、セキュリティ制御は最小限、ログは限定的、期待される活動と想定外の活動の行動ベースライン化はほとんど、あるいはまったく行われていませんでした。 

さらに、現代のプログラム用アイデンティティは通常長寿命であり、ゼロトラストのアーキテクチャおよび実践に整合する原則に基づく継続的な検証や、その後の再認証基準の対象になっていません。プログラム用アイデンティティに付与される初期権限は、監視された行動パターンと結び付けられていないことが多いです。このため、UNC6040のような脅威アクターは、これらのアイデンティティの大量侵害に強く注力しています。なぜなら、これらは機微データを保管していることが多いシステムやリポジトリに対する直接的なプログラムアクセスを提供し、検知や認証中心のセキュリティ制御を回避できるからです。

これらのリスクを低減するため、組織はプロアクティブに以下を実施すべきです：

  • 特定と追跡：環境全体にわたるすべてのプログラム用アイデンティティとその利用状況（作成場所、アクセス先システム、所有者）を把握・追跡する。

  • 保管の集中化：シークレットマネージャー（クラウドネイティブまたはサードパーティ）に集中保管し、認証情報がソースコード、設定ファイル、CI/CDパイプラインに埋め込まれることを防ぐ。

  • 認証IPの制限：技術的に可能な限り、プログラム用認証情報が信頼できるサードパーティまたは内部のIPレンジからのみ使用できるようにする。

  • 認証情報の保護とローテーション：継続的に実施し、最小権限と、可能な限り期限付きまたはジャストインタイムのアクセスを強制する。

  • Workload Identity Federationへの移行：可能な場合、長寿命の静的認証情報（AWSアクセスキーやサービスアカウントキーなど）を、ワークロードアイデンティティフェデレーション（多くはOIDCに基づく）に置き換える。これにより、アプリケーションはクラウドプロバイダが発行する短寿命の一時トークンを用いて認証でき、コードリポジトリやファイルシステムからの認証情報窃取リスクを大幅に低減します。

  • 厳格なスコープ設定とリソースバインディングを強制：認証情報を特定のAPIエンドポイント、サービス、またはリソースに紐付ける。例えば、APIキーは単にストレージへの「読み取り」アクセスを持つのではなく、特定のバケット、さらには特定のプレフィックスに限定し、侵害時の影響範囲（blast radius）を最小化する。

  • 期待される挙動のベースライン化：認証情報タイプごとに（典型的なアクセス経路、宛先、頻度、量）をベースライン化し、監視とアラートに統合して、異常を迅速に検知・調査できるようにする。

  • SDLCへのシークレットスキャン統合：pre-commitフック、CI/CDパイプライン、既存リポジトリや保管場所の定期スキャンを含め、新たな露出を早期に検出する。

  • 対応プレイブックの準備：露出した認証情報に対して、自動失効、強制ローテーション、下流影響評価を含むプレイブックを用意する。

Mandiantは一貫して、これらのアイデンティティがファイルストレージシステム、コードリポジトリ、その他の場所に平文で保存されていることが多いと観測しています。Mandiantは、組織がサードパーティまたはオープンソースのツールを使用して、安全でない場所に保存されたプログラム用認証情報を発見し是正することを推奨します。例えば、TruffleHogのようなツールは、リポジトリやファイルシステムをスキャンし、露出したシークレットを特定し、カスタム検証ルールや文字列を用いて検証できます。これにより、チームは高リスクの認証情報を迅速に優先順位付けし、失効させ、置き換えることができます。

ログ記録

前述の保護策を支援し、ベースライン化と検知を実用的にするため、組織は以下のイベントが十分にログ記録され、集中監視へ転送されることを確実にすべきです：

  • すべてのSaaS、クラウド、内部サービスにおけるプログラム認証イベント

  • 収集項目：プログラム主体（API Key ID、サービスアカウント、OAuthクライアント）、対応する人間の所有者、テナント/組織、送信元IPとネットワーク、ユーザーエージェント、成功/失敗、ポリシー判断。

  • トークンおよび認証情報のライフサイクル活動

    • APIキー、OAuthアプリ、サービスアカウント、接続アプリについて、作成、ローテーション、失効、スコープ/ロール変更をログに記録し、誰が、いつ、どの管理インターフェースまたはCI/CDパイプラインを通じて変更したかを含める。

  • シークレットへのアクセスおよび変更イベント

    • シークレットマネージャーおよびCI/CDシステムから、どのワークロードまたはアイデンティティが、どのシークレットに、どこから、どの程度の頻度でアクセスしたかを、すべての操作とともにログに記録する。これらのイベントは、プログラム用アイデンティティの中央インベントリと相関付け、機微な認証情報へのアクセスを所有者とアプリケーションに遡れるようにする。

  • プログラムによるデータアクセスおよびエクスポート活動

    • API、バルクジョブ、レポートエクスポートについて、対象オブジェクト/リソース、操作種別、レコード数または転送バイト数、ジョブID、実行コンテキストをログに記録する。

  • プログラム用アイデンティティに影響するセキュリティおよびポリシー変更

    • IP許可リスト、信頼ネットワーク、セッションおよび条件付きアクセス ポリシー、「バイパス」フラグ、接続アプリ、統合ユーザー、サービスプリンシパルに対する制限を緩和するあらゆる設定の変更をログに記録する。

    これらすべてのテレメトリは正規化され、アナリストがプログラム用アイデンティティ、人間の所有者、テナント/組織、送信元ネットワーク、影響を受けたデータセットで横断分析できるようにし、認証情報ごとの期待される挙動をベースライン化して時間経過で監視できるようにすべきです。

    検知

    前述のテレメトリが整備されたら、組織は、プログラム用認証情報の侵害を最も示唆する挙動に焦点を当てた、少数の高精度検知を優先すべきです：

    • 想定外または高リスクのネットワークから使用されたプログラム用認証情報APIキー、サービスアカウント、またはOAuth/接続アプリのトークンが盗まれると、攻撃者は通常、組織の通常の送信経路ではなく、自身のインフラからそれをリプレイします。正当な統合や自動化は、ほぼ常に少数の安定したIPレンジから実行され、地理情報やASNも一貫しています。同一の認証情報について、コンシューマISP、Tor/VPN出口、または無関係なクラウドプロバイダへの突然の変化は強い指標です。

    $e.metadata.product_name = "SALESFORCE"
$e.metadata.log_type=”SALESFORCE”
$e.metadata.event_type=”USER_LOGIN”
$programmatic_user=$e.principal.user.userid
$programmatic_user in %saas_programmatic_identities
$source_ip=$e.principal.ip
$source_ip != “”
condition:
$e and not $source_ip in %programmatic_trusted_networks

    • プログラム用認証情報による異常なデータアクセスまたは大量エクスポート攻撃者がプログラム用認証情報を入手すると、可能な限り多くのデータを収集するために、オブジェクト全体のダンプ、大規模レポートのエクスポート、REST/BULK APIの反復といった、高ボリュームまたは広範囲のデータアクセスが実行されます。

    $api.metadata.product_name = "SALESFORCE"
$api.metadata.log_type=”SALESFORCE”
$api.metadata.event_type=”RESOURCE_READ”
$api.metadata.product_event_type=”ApiEvent”
or $api.metadata.product_event_type=”RestApi”
or $api.metadata.product_event_type=”BulkApi”
or $api.metadata.product_event_type=”BulkApi2”
$programmatic_user=$e.principal.user.userid
$programmatic_user in %saas_programmatic_identities
$response_bytes=$api.network.received_bytes
$response_bytes > 0
match:
$programmatic_user over 1h
condition:
// Tune these thresholds for your environment
// Example: >=50 API calls and >= 100 MB returned in 1 hour
#api>=50
and $total_response_bytes >= 100000000

    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のガイダンスを参照してください。

    ユーザー権限とアクセス管理
    最小権限の原則を実装する

    ユーザーには、職務を遂行するために必要な最小限の権限のみを付与すべきです。

    • ベースラインとして「最小アクセス」プロファイルを使用： 最小限の権限を持つベースプロファイルを構成し、新規ユーザーにはデフォルトで割り当てます。「すべて表示（View All）」および「すべて変更（Modify All）」権限の付与を制限します。 

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

    • 不要なユーザーのAPIアクセスを無効化： 「API有効（API Enabled）」権限はData Loaderのようなツールに必要です。すべてのユーザープロファイルからこの権限を削除し、正当な理由のある少数のユーザーに対してのみ、制御された権限セットで付与します。

    • 非管理者ユーザーから「設定（Setup）」メニューを隠す： すべての非管理者プロファイルについて、管理用の「設定（Setup）」メニューへのアクセスを削除し、不正な構成変更を防ぎます。

    • 機微な操作に高保証セッションを強制： レポートのエクスポートなど機微な操作に対して高保証セッションを要求するよう、セッション設定を構成します。

    セッションセキュリティ設定の変更に関するSalesforceのガイダンスを参照してください。

    高保証セッションセキュリティの要求に関するSalesforceのガイダンスを参照してください。

    「すべて表示（View All）」および「すべて変更（Modify All）」権限に関するSalesforceのガイダンスを参照してください。  

    きめ細かなデータアクセス ポリシー
    組織全体の共有デフォルト（OWD）を「非公開（Private）」に強制する

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

    • ロール階層による広範なアクセスに依存するのではなく、戦略的な共有ルールまたは他の共有メカニズムを使用して、より広いデータアクセスを付与します。

    行レベルセキュリティに制限ルールを活用する

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

    制限ルールに関するSalesforceのガイダンスを参照してください。

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

    機微データへのアクセス権を持つ、または基盤となるSalesforceインスタンスへの特権アクセスを持つユーザーについては、Salesforceサポートアクセス付与に厳格なタイムアウトを設定していることを確認してください。

    恒常的な要求は取り消し、特定のユースケースに対して厳格な時間制限付きでのみ再有効化してください。管理者アカウントからこれらの付与を有効化することには注意してください。

    Salesforceサポートログインアクセス付与に関するSalesforceのガイダンスを参照してください。 

    Mandiantは、誤設定を特定して対処するためにSalesforce Security Health Checkツールの実行を推奨します。追加のハードニング推奨事項については、Salesforce Security Guideを参照してください。

    3. ログ記録と検知

    Salesforceを対象としたログ記録および検知制御 

    本セクションでは、Salesforceインスタンス向けの主要なログ記録および検知戦略を概説します。これらの制御は、SaaS環境内の高度な脅威を特定し対応するために不可欠です。

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

    SaaSアプリケーションに対して脅威アクターが用いる戦術・技術・手順（TTP）を可視化するため、Mandiantは、組織のSalesforce環境で重要なログ種別を有効化し、ログをSecurity Information and Event Management（SIEM）に取り込むことを推奨します。

    ログ記録の前に必要な準備

    収集を有効化したり検知ルールを書いたりする前に、組織が実際に使用予定のログを利用する権利（エンタイトルメント）を有していること、そして必要な機能が有効になっていることを確認してください。 

    1. エンタイトルメント確認（必須） 

    1. 多くのセキュリティログ/機能は、Salesforce ShieldまたはEvent MonitoringアドオンによるEvent Monitoringの背後にあります。これは、Real-Time Event Monitoring（RTEM）のストリーミングおよび閲覧にも適用されます。

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

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

    2. RTEM – Storage：多くはBig Objects（ネイティブストレージ）。一部は標準オブジェクト（例：Threat Detectionの保存先）

    3. Event Log Files（ELF）- CSVモデル（バッチエクスポート）：Enterprise/Performance/Unlimitedエディションで利用可能。

    4. Event Log Objects（ELO）- SOQLモデル（クエリ可能な履歴）：Shield/アドオンが必要。

  • 必要なものを有効化（およびアクセス範囲を制限）

    1. Event Managerを使用して、イベントごとにストリーミングと保存を有効/無効化し、RTEMイベントを閲覧します。

    2. RTEMおよびThreat Detection UIへのアクセスを、プロファイル/権限セットで付与します。

  • Threat Detection & ETS

    1. Threat DetectionイベントはShield/アドオンでUI上で閲覧し、対応するEventStoreオブジェクトに保存されます。

    2.  Enhanced Transaction Security（ETS）はRTEMに含まれ、リアルタイムイベントに対してブロック/MFA/通知アクションを実行できます。

    監視すべき推奨ログソース

    • ログイン履歴（LoginHistory）：ユーザー名、時刻、IPアドレス、ステータス（成功/失敗）、クライアント種別を含む、すべてのログイン試行を追跡します。これにより、異常なログイン時刻、不明な場所、繰り返しの失敗を特定でき、認証情報詰め込み（credential stuffing）やアカウント侵害の兆候となり得ます。

    • ログインイベント（LoginEventStream）：LoginEventは、Salesforceにログインするユーザーのログイン活動を追跡します。

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

    • API呼び出し（ApiEventStream）：ユーザーまたは接続アプリによる呼び出しを追跡し、API利用および潜在的な悪用を監視します。

    • レポートエクスポート（ReportEventStream）：レポートのダウンロードに関する洞察を提供し、データ持ち出しの試みを検知するのに役立ちます。

    • リストビューイベント（ListViewEventStream）：リストビューにおけるデータへのアクセスや操作を含む、ユーザーのリストビュー操作を追跡します。

    • Bulk APIイベント（BulkApiResultEvent）：ユーザーがBulk API要求の結果をダウンロードしたタイミングを追跡します。

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

    • API異常（ApiAnomalyEvent）：ユーザーがAPI呼び出しを行う方法における異常を追跡します。 

    • ユニーククエリイベントタイプ：ユニーククエリイベントは、処理された特定の検索クエリ（SOQL）、フィルターID、レポートID、および基盤となるデータベースクエリ（SQL）を取得します。

    • 外部アイデンティティプロバイダのイベントログ：SSOを使用したログイン試行の情報を追跡します。（IdPイベントログの監視と収集については、利用しているアイデンティティプロバイダが提供するガイダンスに従ってください。）

    これらのログソースにより、組織は、脅威アクターが用いる一般的なTTPを適切に収集・監視するためのログ記録能力を得られます。監視すべき主要ログソースと、各TTPに対して観測可能なSalesforce活動は以下のとおりです：

    TTP

    観測可能なSalesforce活動

    ログソース

    Vishing

    • 不審なログイン試行（急速な失敗）。

    • 異常なIP/ASNからのログイン（例：Mullvad/Tor）。 

    • 未認識クライアントからのOAuth（「Remote Access 2.0」）。

    • ログイン履歴 

    • LoginEventStream/LoginEvent

    • 設定監査証跡

    悪意のある接続アプリの承認（例：Data Loader、カスタムスクリプト）

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

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

    • 権限によるAPI Enabled / 「接続アプリの管理」の付与。

    • 設定監査証跡  

    • PermissionSetEvent 

    • LoginEventStream/LoginEvent（OAuth）

    データ持ち出し（API、Data Loader、レポート経由）

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

    • レポートおよびリストビューでの大きなRowsProcessed/RecordCount（分割）。

    • バルクジョブ結果のダウンロード。 

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

    • ApiEventStream/ApiEvent  

    • ReportEventStream/ReportEvent  

    • ListViewEventStream/ListViewEvent  

    • BulkApiResultEvent  

    • FileEvent/FileEventStore  

    • ApiAnomalyEvent/ReportAnomalyEvent

    • ユニーククエリイベントタイプ

    横展開/永続化（Salesforce内または他クラウドプラットフォームへ）

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

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

    • LoginAs活動。 

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

    • Okta/M365へのピボット、その後Graphでのデータ取得。

    • 設定監査証跡  

    • PermissionSetEvent  

    • LoginAsEventStream  
    SaaSアプリケーションの検知  

    ネイティブのSIEM脅威検知は一定の保護を提供しますが、複雑な環境にまたがる分断されたイベントを結び付けるために必要な集中可視性が不足していることがよくあります。カスタムのターゲット検知ルールを開発することで、組織は悪意のある活動をプロアクティブに検知できます。 

    データ持ち出し & SaaS間の横展開（承認後） 

    MITREマッピング：TA0010 – Exfiltration（持ち出し） & TA0008 – Lateral Movement（横展開）

    シナリオ & 目的

    ユーザーが（悪意のある、または偽装された）接続アプリを承認した後、UNC6040は通常：

    1. 迅速にデータ持ち出しを実行（RESTのページネーションバースト、Bulk APIダウンロード、大量/機微レポートのエクスポート）。

    2. 同じリスクの高い送信元IPからOkta/Microsoft 365へピボットし、アクセスを拡大してさらにデータを窃取します。 

    ここでの目的は、Salesforce OAuth → 10分以内の持ち出し、Salesforce OAuth → 60分以内のOkta/M365ログイン（同一のリスクIP）、および単一シグナルでノイズの少ない持ち出しパターンを検知することです。

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

    vishingフェーズで既に維持しているリストを再利用し、コンテンツ焦点のための正規表現ヘルパーを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の成功の後、同一ユーザーによるBulk結果ダウンロード、RESTページネーションバースト、または機微/大規模レポートのエクスポートが10分以内に続く。

    高精度である理由：UNC6040の「承認 → 吸い上げ」パターンに一致。短い時間窓＋ボリューム閾値。

    主要シグナル：

    • OAuth成功（不明なアプリ OR 許可リスト＋リスク送信元）、ユーザーで紐付け。

    • その後、以下のいずれか：

    • RowsProcessed/RecordCountが大きいBulkApiResultEvent

    • ApiEventStreamで多数のquery/queryMore呼び出し

    • 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のようなProduct Event Typeのみを単一イベントルールとして使用して監視する場合、マルチイベントルールの代わりに単一イベントルールも使用できます。ただし、単一イベントルールは非常にノイズが多くなり得るため、参照リストを能動的に監視する必要がある点に注意してください。

    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がquery、queryMore、query_all、queryall、10分で回数が閾値以上、ユーザーが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 → 同一リスクIPからのOkta/M365ログイン（60分以内）（マルチイベント）

    不審なSalesforce OAuthの後、60分以内に同一のパブリックIPからOktaまたはEntra IDへのログインが続く。IPが社外、またはVPN/Tor ASNである。

    高精度である理由：攻撃者の送信元IPを、短い時間窓でSaaS間にまたがって結び付ける。

    主要シグナル：

    • Salesforce OAuthのポスチャ（不明なアプリ OR 許可リスト＋リスク送信元）

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

    リスト/調整項目：ENTERPRISE_EGRESS_CIDRS、VPN_TOR_ASNS。（任意：アイデンティティが正規化されている場合、ユーザーのメールで紐付ける兄弟ルール。）

    $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データ取得

    リスクの高い送信元からの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
    チューニング & 例外

    • アイデンティティ結合：横展開ルールは堅牢性のためIPでグルーピングします。強力なアイデンティティ正規化（Salesforce <-> Okta <-> M365）がある場合は、複製してIPではなくユーザーのメールでマッチさせてください。

    • 時間窓の変更：承認済みのデータ移行/接続アプリのオンボーディング中は、時間制限ルールを抑制します（ベンダーアプリを一時的にALLOWLIST_CONNECTED_APP_NAMESへ追加）。

    • 統合アカウント：KNOWN_INTEGRATION_USERSを最新に保ってください。持ち出しルールのノイズの大半はスケジュールされたETLから発生します。

    • 送信元衛生：ENTERPRISE_EGRESS_CIDRSを最新に保ってください。古いNAT/VPNレンジはVPN/Torの検出を増加させます。

    • ストリーミング vs 保存：前述のルールはReal-Time Event MonitoringのStreamオブジェクト（例：ApiEventStream、ReportEventStream、ListViewEventStream、BulkApiResultEvent）を前提としています。過去のハンティングでは、同等の保存オブジェクト（例：ApiEvent、ReportEvent、ListViewEvent）を同じロジックでクエリしてください。

    IOCベースの検知

    シナリオ & 目的

    悪意のある脅威アクターが、組織のネットワークへのアクセスに成功した、またはアクセスを試みた。

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

    参照リスト

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

    • STRING

    • UNC6040_IOC_LIST（脅威インテリジェンスソース（例：VirusTotal）からのIPアドレス）

    侵害指標（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に感謝いたします。

    掲載先

    翻訳元: https://cloud.google.com/blog/topics/threat-intelligence/unc6040-proactive-hardening-recommendations/

    ソース: cloud.google.com
    #Connected App悪用 #Data Loader #ID管理（SSO・MFA） #Salesforceセキュリティ #UNC6040 #サイバー犯罪 #データ窃取（エクスフィルトレーション） #ボイスフィッシング（Vishing） #ログ監視・検知（SIEM） #脅威インテリジェンス

    関連記事

    ViewState逆シリアル化脆弱性を通じたKnowledgeDeliverの悪用

    中国語フィッシングサービスの進化

    BlackFileへようこそ：ビッシング恐喝作戦の内部