脅威インテリジェンス

最前線からのガイダンス: SaaS を標的とした ShinyHunters を標榜するデータ盗難に対する予防的防御

2026年2月26日

Mandiant

Mandiant Services

Stop attacks, reduce risk, and advance your security.

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

はじめに

Mandiant は、ShinyHunters の名前のもとに行われるサイバー恐喝に関連する脅威クラスタの活動が大幅に拡大、エスカレートしている状況を追跡しています。関連レポート「Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft」（アクセスを目的としたビッシング: ShinyHunters を標榜する SaaS データ盗難の拡大を追跡）で詳しく説明しているように、こうしたキャンペーンでは、進化したビッシングと被害組織のブランドを模倣した認証情報の収集によりシングルサインオン（SSO）の認証情報を侵害し、被害組織の多要素認証（MFA）ソリューションに不正なデバイスを登録することに成功しています。

この活動は、ベンダーのプロダクトやインフラストラクチャのセキュリティ脆弱性が原因ではなく、ソーシャルエンジニアリングの有効性を頼りに、ID 管理を回避してクラウドベースの Software as a Service（SaaS）環境に侵入するものです。

この投稿では、組織がこうした脅威から身を守るために役立つ、セキュリティ強化、ロギング、検出に関する実用的な推奨事項を紹介します。組織が進行中のインシデントに対応する場合は、インフラストラクチャ環境、SaaS プラットフォーム、そしてラテラルムーブメントや永続化に一般的に使用される特定の ID ストアへのアクセスを遮断するなど、迅速な封じ込めに重点を置く必要があります。長期的な防御のためには、プッシュベースや SMS の認証よりもソーシャルエンジニアリングに強い、FIDO2 セキュリティキーやパスキーなど、フィッシング耐性のある MFA への移行が必要です。

封じ込め

こうした脅威クラスタによる侵入が進行中の場合や、その疑いがある場合には、迅速な封じ込めを優先して、攻撃者のアクセスを遮断し、さらなるデータの引き出しを防ぐ必要があります。こうしたキャンペーンはマルウェアではなく有効な認証情報を利用しているため、封じ込めを行うときは、セッショントークンの取り消しと、ID とアクセスの管理操作の制限を優先する必要があります。

即座の封じ込め対応

有効なセッションの取り消し: 不正使用されたアカウントを特定して無効にし、ID プロバイダ（IdP）と SaaS プラットフォームにわたり、有効なセッショントークンと OAuth 認可をすべて取り消します。
パスワードの再設定の制限: さらなる認証情報の不正操作を防止するため、一般公開されているセルフサービスによるパスワード再設定ポータルを一時的に無効にするか、大幅に制限します。管理アカウントのパスワードはセルフサービスで再設定できないようにします。
MFA 登録の一時停止: ユーザーが IdP に新しいデバイスを登録、加入、追加する機能を一時的に無効にします。
リモートアクセスの制限: VPN や仮想デスクトップインフラストラクチャ（VDI）など、上り（内向き）のリモートアクセスポイントを制限するか、一時的に無効にします。特に信頼できないデバイスや非準拠のデバイスからのアクセスを対象とします。
デバイスのコンプライアンスの適用: IdP と SaaS アプリケーションへのアクセスを制限し、組織が管理する準拠デバイスと、既知の信頼できる送出（egress）ポイントからのみ認証を開始できるようにします。
「シールドアップ」手順の実装: リスクが高まっていることをサービスデスクに通知し、アカウント関連のすべてのリクエストは、手動による信頼性の高い検証プロトコルに切り替えます。また、技術運用スタッフに、同僚からの SMS メッセージによる作業指示を受け入れないよう注意喚起します。

脅威活動が活発化している期間は、パスワードと MFA の再設定をすべて一時的に手動による厳格な本人確認プロトコル経由にすることをおすすめします。たとえば、この投稿の「セキュリティ強化」セクションでは、ビデオ通話による確認について説明しています。また、必要に応じて、エンドユーザー、人事パートナー、その他のビジネスユニットとコミュニケーションを取り、初期の封じ込めフェーズで警戒を怠らないようにする必要があります。不審な行為は必ず社内の IT チームとセキュリティチームに報告して、さらなる調査を依頼します。

1. セキュリティ強化

ShinyHunters ブランドの恐喝に関連する脅威クラスタに対抗するには、攻撃者が頻繁に悪用する高リスクの手動プロセスを厳格化することから始めます。特に、パスワードの再設定、デバイスの登録、MFA の変更が重要です。

ヘルプデスクの検証

これらのキャンペーンは、ソーシャルエンジニアリング、ビッシング、フィッシングを通じて人間主導のワークフローを標的とすることが多いため、組織はサポート対応、特にパスワードの再設定や MFA の変更などのアカウント変更を伴うリクエストに対して、より強力で多層的な本人確認プロセスを実装する必要があります。脅威アクターは、サードパーティベンダーになりすましてヘルプデスクにビッシングを行い、スタッフを説得して不正な SaaS アプリケーションの登録を承認またはインストールさせることも知られています。

組織は、リスクが高まっている期間の暫定的な対策として、発信者の身元、有効な ID、発信者と ID の視覚的な一致確認を含む検証を必須とする必要があります。

これを実装するには、ヘルプデスク担当者に次のことを求めます。

ユーザーが政府機関発行の身分証明書を顔の横に持った状態でビデオ通話を行うことを求める。エージェントは一致を目視で確認する。
身分証明書の名前が従業員の会社記録と一致していることを確認する。
再設定を処理する前に、ユーザーの既知の上司からの帯域外承認を要求する。
従業員 ID、社会保障番号、上司の名前のみに基づくリクエストは拒否する。ShinyHunters は、過去の侵害で得たこのデータを所持しており、身元確認に使用する可能性がある。
ユーザーがパスワードの再設定についてヘルプデスクに電話をかけてきた場合は、なりすましを防ぐため、必ずユーザーの既知の有効な電話番号に折り返し電話をかけてから再設定を行う。
ビデオ通話ができない場合は、信頼性の高い別の方法を要求する。場合によっては、ユーザーと対面で本人確認を行う必要もある。
やり取りが完了した後、ヘルプデスクエージェントは必要に応じて、ユーザーの上司にメールを送信し、変更をリクエストしたユーザーのビデオ通話の画像とともに、変更が完了したことを通知することもできる。

サードパーティベンダーのリクエストへの特別対応

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

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

アクセスや情報を提供せずに着信通話を終了する
信頼できる登録済みの連絡先情報を使用して、そのベンダーの指定されたアカウントマネージャーに個別に連絡する
リクエストの処理を進める前に、アカウントマネージャーによる明示的な確認を求める

エンドユーザーの教育

組織は、特に事前通知なしで直接連絡を受けた場合のベストプラクティスをエンドユーザーに周知する必要があります。

社内でビッシングとフィッシングの演習を実施し、エンドユーザーがセキュリティのベストプラクティスを取り入れていることを確認する。
パスワードは、相手が誰であっても共有すべきではないことを説明する。
特に業務時間外にパスワードや MFA の再設定を求められた場合は、細心の注意を払うよう促す。
連絡を受けた人物や番号が不明な場合は、すべてのコミュニケーションを停止し、既知のサポートチャネルに連絡してガイダンスを求めるよう指示する。

ID とアクセスの管理

組織は、あらゆる種類の ID を保護するために、多層的な制御を実装する必要があります。クラウド ID プロバイダ（IdP）、クラウドコンソール、SaaS アプリケーション、ドキュメントとコードのリポジトリへのアクセスは制限する必要があります。これらのプラットフォームは、権限昇格、データアクセス、長期的な永続化のためのコントロールプレーンになることが多いためです。

これを実現するには、次のようにします。

信頼できる下り（外向き）ポイントと物理的な場所にアクセスを限定する。
SaaS プラットフォーム内に存在する「ローカルアカウント」を確認して把握する。

デフォルトのユーザー名 / パスワードが組織のパスワードポリシーに従って更新されていることを確認する。
組織の一元的な主要 IdP の一部として管理されていない「ローカルアカウント」の使用を制限する。

非人間アカウント（アクセスキー、トークン、非人間アカウント）のスコープを縮小する。

該当する場合は、非人間アカウントにネットワーク制限を実装する。
認可済み / 信頼済みアプリケーションに関連付けられた有効期間の長いトークン（OAuth / API）に関連する操作をモニタリングして、異常な操作を検出する。

組織のリソースへのアクセスは、管理対象の準拠デバイスからに限定する。すべての管理対象デバイスにわたり、次のことを行う。

ID プロバイダを介してデバイスポスチャーチェックを実装する。
長期間使用されていないデバイスからのアクセスをブロックする。
エンドユーザーが個人用デバイスを登録できないようにする。

管理対象外のデバイスからのアクセスが必要な場合は次のことを行う。

管理対象外のデバイスをウェブのみのビューに制限する。
管理対象外の個人用デバイスに企業 / ビジネスデータをローカルにダウンロード / 保存できないようにする。
セッション継続時間を制限し、MFA による再認証を求める。

MFA 手法を迅速に強化する。例:

SMS、電話、プッシュ通知、メールを認証手段から除外する。
以下のようなフィッシング耐性の高い強力な MFA 手法を必須とする。

フィッシング耐性のある MFA を必要とする認証システムアプリ（FIDO2 パスキーのサポートを Microsoft Authenticator などの既存の方法に追加できる）。
特権ロールが割り当てられている ID の認証に FIDO2 セキュリティキーを使用する。

マルチコンテキスト基準を適用して認証トランザクションを強化する。

たとえば、認証トランザクションの一環として、ID 以外に特定のデバイスと場所の属性も検証する。

Google Workspace を利用している組織では、コンテキストアウェアアクセスポリシーを使用して、これらのコンセプトを適用できる。
Microsoft Entra ID を利用している組織では、条件付きアクセスポリシーを使用して、これらのコンセプトを適用できる。
Okta を利用している組織では、Okta のポリシーとルールを使用して、これらのコンセプトを適用できる。

攻撃者は、一貫して非人間 ID を標的にしています。非人間 ID は、検出が限られていること、正常な操作と異常な操作のベースラインがないこと、そして特権ロールの割り当てが一般的であることがその理由です。組織がすべきことは、次のとおりです。

環境全体で、プログラマティック ID とその使用状況をすべて特定して追跡します。これには、ID が作成された場所、アクセスするシステム、所有者などが含まれます。
シークレットマネージャー（クラウドネイティブまたはサードパーティ）にストレージを一元化し、認証情報がソースコード、構成ファイル、CI / CD パイプラインに埋め込まれないようにします。
技術的に可能な場合は、プログラマティック認証情報の認証 IP を制限し、信頼できるサードパーティまたは内部の IP 範囲からのみ使用できるようにします。
Workload Identity 連携への移行: 可能な場合は、有効期間が長い静的な認証情報（AWS アクセスキーやサービスアカウントキーなど）を Workload Identity 連携メカニズム（多くの場合 OIDC ベース）に置き換えます。これにより、アプリケーションはクラウドプロバイダが発行する有効期間の短い一時的なトークンを使用して認証できるようになり、コードリポジトリやファイルシステムから認証情報が盗まれるリスクが大幅に下がります。
認証情報を特定の API エンドポイント、サービス、リソースに関連付けることで、厳格なスコープ設定とリソースバインディングを適用します。たとえば、ただ単にストレージへの「読み取り」アクセス権を API キーに付与するだけでなく、特定のバケットや特定の接頭辞にアクセスを限定することで、侵害された場合の影響範囲を最小限に抑えることができます。
各認証情報タイプ（一般的なアクセス経路、接続先、頻度、ボリューム）に期待される動作のベースラインを定め、これをモニタリングやアラートに統合することで、異常を迅速に検出して調査できるようにします。

以下に、プラットフォームごとの追加のセキュリティ強化策を示します。

Okta

Okta ThreatInsight を有効にして、不正と特定された IP アドレスを自動的にブロックする。
特権管理者権限を特定のネットワークゾーン（企業 VPN）に限定する。

Microsoft Entra ID

一般的な条件付きアクセスポリシーを実装して、不正な認証試行をブロックし、リスクの高いログインを制限する。
リスクが検出されたときにパスワードの変更や MFA をトリガーするリスクベースのポリシーを構成する。
Entra ID でアプリケーションを登録できるユーザーを制限し、アプリケーションの登録時に管理者の承認を必須とする。

Google Workspace

コンテキストアウェアアクセスのレベルを使用して、デバイス属性と IP アドレスに基づいて Google ドライブと管理コンソールへのアクセスを制限する。
すべての Google Workspace ユーザーに 2 段階認証プロセス（2SV）を適用する。
高度な保護機能を使用して、標的型フィッシング、マルウェア、アカウントの不正使用から、リスクの高いユーザーを保護する。

インフラストラクチャとアプリケーションのプラットフォーム

クラウドコンソールや SaaS アプリケーションなどのインフラストラクチャプラットフォームやアプリケーションプラットフォームは、認証情報の収集やデータの引き出しの標的になることがよくあります。これらのシステムを保護するには、通常、前述の ID 管理に加え、次のようなプラットフォーム固有のセキュリティガードレールを実装する必要があります。

管理プレーンへのアクセスを制限し、組織のネットワークと、承認された VPN 範囲からのみ到達できるようにする。
これらのプラットフォームに保存されている機密性の高い認証情報を含め、公開されているシークレットをスキャンして修復する。
デバイスのアクセス制御を適用して、アクセスを管理対象の準拠デバイスに限定する。
構成の変更をモニタリングして、新しく作成されたリソース、公開されたサービス、その他の不正な変更を特定し、調査する。
ロギングと検出を実装して、以下を特定する。

ネットワークセキュリティグループ（NSG）ルールやファイアウォールルールの新規作成または変更、リモートアクセスが可能なリソースの一般公開。
プログラマティックなキーや認証情報の作成（アクセスキーなど）。

管理プレーンのオペレーションに API / CLI アクセスが明示的に必要なユーザーにプログラマティックアクセスを限定することで、不要なユーザーの API / CLI アクセスを無効にする。

プラットフォーム固有の情報

GCP

VPC Service Controls（VPC-SC）でセキュリティ境界を構成し、有効な認証情報がある場合でも、データが不正な Google Cloud リソースにコピーされないようにします。組織ポリシーと拒否ポリシーを組織レベルで適用し、追加のガードレールを設定します。これにより、攻撃者に悪用される可能性がある開発者の構成ミスを防止できます。たとえば、「iam.disableServiceAccountKeyCreation」などの組織ポリシーを適用すると、簡単に引き出される可能性のある新しい管理対象外のサービスアカウントキーの生成を防ぐことができます。
機密性の高いロールバインディングに IAM Conditions を適用します。リソース名が特定の接頭辞で始まるか、リクエストが一定の業務時間内に届いた場合にのみロールが有効になるように制限します。これにより、認証情報が侵害された場合の影響範囲を限定できます。
Salesforce のブログ投稿「Protecting Salesforce Data After an Identity Compromise」をご覧ください。

2. ロギング

最近の SaaS への侵入で、ペイロードや技術的な脆弱性が悪用されることはほとんどありません。Mandiant が確認しているのは、有効なアクセス（多くの場合、ビッシングや MFA バイパスによって取得）を利用して、一括エクスポート、接続されたアプリ、管理構成の変更などのネイティブ SaaS 機能を悪用する攻撃者です。

この環境の状況を明確に把握できなければ、侵入の検出はほぼ不可能です。どの ID が認証されたか、どの権限が承認されたか、どのデータがエクスポートされたかを追跡できなければ、多くの場合、脅迫状が表示されるまでキャンペーンに気づかないことになります。

このセクションでは、これらのインシデントがエスカレートする前に検出して阻止できるよう、ID の操作、認可、SaaS エクスポートの動作に対する可視性を確保することに焦点を当てます。

ID プロバイダ

攻撃者がビッシングや MFA の不正操作によってアクセスを取得した場合、最初の信頼できるシグナルはワークステーション内ではなく、SSO コントロールプレーンに現れます。この例では、Okta と Entra ID のログで、認証されたユーザー、MFA の変更点、アクセス元を特定できるようにすることが目標です。

有効にして SIEM に取り込むもの

Okta

認証イベント（ログインの成功と失敗）
MFA ライフサイクルイベント（登録 / 有効化、認証要素またはデバイスの変更）
セキュリティ関連の操作を捕らえた管理 ID イベント（認証ポスチャーに影響する変更など）

Entra ID

認証イベント
MFA の変更 / 認証方法の監査ログ
認証に影響するセキュリティポスチャーの変更に関する監査ログ

条件付きアクセスポリシーの変更
名前付きの場所 / 信頼できる場所の変更

運用上「良好」な状態とは

次の情報をすばやく特定できる必要があります。

認証要素、デバイス登録操作、操作を行ったユーザー
登録に関連付けられたソース IP、位置情報（可能な場合は ASN）
アクセスが組織の想定する下り（外向き）ポイントから発生したかどうかと、アクセス経路の特定

プラットフォーム

Google Workspace のロギング

防御者は、OAuth 認可、メールボックスの削除操作（セキュリティ通知メールの削除を含む）、Google データエクスポート (Takeout) について把握できる必要があります。

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

適切なエディション + 利用可能な調査サーフェス: Workspace エディションが監査と調査ツール、セキュリティ調査ツール（使用予定の場合）をサポートしていることを確認します。
適切な管理者権限: アカウントに監査と調査の権限（OAuth / Gmail / データエクスポートのログイベントにアクセスするため）とセキュリティセンターの権限があることを確認します。
Gmail メッセージの内容が必要な場合: エディションと権限で、調査中にメッセージ内容の確認が許可されていることを確認します。

有効にして SIEM に取り込むもの

OAuth / アプリ認可ログ

トークン / アプリ認可ログを有効にして取り込み、以下の点を確認します。

認可されたアプリケーション（アプリ名 + ID）
アクセスを許可したユーザー
許可されたスコープ
認可のソース IP と位置情報

これは、メールボックスの不正操作につながる可能性のある、疑わしいアプリの認可とアドオンの有効化を検出するために必要なテレメトリーです。

Gmail の監査ログ

Gmail の監査イベントを有効にして取り込み、次の情報を取得します。

メッセージの削除操作（可能な場合は完全な削除を含む）
メッセージの方向インジケーター（特に送信クリーンアップ動作に便利）
セキュリティ通知メールを狙った削除の検出を可能にするメッセージメタデータ（件名など）

Google データエクスポートの監査ログ

データエクスポートのログを有効にして取り込み、以下の情報を取得します。

エクスポートの開始イベントと完了イベント
エクスポート操作のユーザーとソース IP / 位置情報

Salesforce のロギング

Mandiant が確認した操作には、Salesforce データローダーの使用や、基本的なログイン履歴ログのみを収集した場合には可視化されない大規模なアクセスパターンが含まれています。SaaS ネイティブのデータの引き出しを調査するには、ログイン、構成の変更、接続されたアプリ / API の操作、エクスポートの動作を記録する追加の Salesforce テレメトリーが必要です。これらの可視性のギャップに関する詳細な実装ガイダンスについては、Mandiant による Salesforce の対象を絞ったロギングと検出の制御をご覧ください。

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

利用資格の確認（必須）

ほとんどのセキュリティ関連の Salesforce ログには、Salesforce Shield またはイベントモニタリングアドオンを通じて提供されるイベントモニタリングが必要です。検出に使用するイベントタイプのライセンスがあることを確認してください。

運用に合った収集方法の選択

準リアルタイムの検出が必要な場合は、リアルタイムイベントモニタリング（RTEM）を使用します。
長期保存と遡及的調査のために予測可能な一括エクスポートが必要な場合は、イベントログファイル（ELF）を使用します。
Salesforce Object Query Language を使用してクエリ可能な履歴が必要な場合は、イベントログオブジェクト（ELO）を使用します（多くの場合、Shield / アドオンが必要）。

検出するイベントの有効化

イベントマネージャーを使用して、取り込む予定のイベントカテゴリを明示的に有効にし、適切なチームがデータ（プロファイル / 権限セット）を表示および運用できるようにします。

脅威の検出とトランザクションセキュリティの強化

環境で脅威の検出または ETS を使用している場合は、これらの制御にフィードされているイベントタイプを確認し、アラートの生成を想定しているイベントがログ取り込みプラットフォームで除外されていないことを確認します。

有効にして SIEM に取り込むもの

認証とアクセス

LoginHistory（誰が、いつ、どこからログインしたか、成功 / 失敗、クライアントタイプ）
LoginEventStream（より充実したログインテレメトリー、可能な場合）

管理 / 構成の把握

SetupAuditTrail（管理とセキュリティの構成の変更）

API とエクスポートの把握

ApiEventStream（ユーザーと接続されたアプリによる API の使用状況）
ReportEventStream（レポートのエクスポート / ダウンロード操作）
BulkApiResultEvent（ジョブの結果の一括ダウンロード - 一括抽出の把握に不可欠）

その他の価値の高いソース（テナントで利用可能な場合）

LoginAsEventStream（なりすまし / 「代理ログイン」操作）
PermissionSetEvent（権限の付与 / 変更）

SaaS ピボットロギング

脅威アクターは、侵害された SSO プロバイダから、DocuSign や Atlassian など別の SaaS プラットフォームに進むことがよくあります。これらのプラットフォームから SIEM 環境に監査ログを取り込むことで、ID の侵害後に発生する不審なアクセスや大規模なデータの引き出しを検出できます。

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

監査 / イベントロギングのアクセスと構成には、テナントレベルの管理者権限が必要です。
プラン / サブスクリプションに、収集しようとしている監査 / イベントの可視化が含まれていることを確認します（Atlassian の組織監査ログ機能はプラン / Guard ティアによって異なります。DocuSign の組織レベルのアクティビティモニタリングは DocuSign Monitor を介して提供されます）。
API アクセス（プログラムでログを取り出す場合）: テナントがベンダーの監査 / イベント API（DocuSign Monitor API、機能に応じて Atlassian 組織監査ログ API / Webhook）を使用できることを確認します。
保持の現実チェック: プラットフォームのネイティブな監査ログ保持期間が調査ニーズを満たしていることを検証します。

有効にして SIEM に取り込むもの

DocuSign（監査 / モニタリングログ）

認証イベント（ログインの成功 / 失敗、ログインが SSO / パスワードのどちらによるか（可能な場合））
管理上の変更（ユーザー / ロールの変更、組織レベルの設定の変更）
エンベロープへのアクセスと一括操作（エンベロープの閲覧 / ダウンロード、ドキュメントのダウンロード、一括送信、一括ダウンロード / エクスポート（可能な場合））
API の操作（API 呼び出し、統合キー / アプリの使用、クライアント / アプリの ID）
ソースコンテキスト（ソース IP / 位置情報、ユーザーエージェント / クライアントタイプ）

Atlassian（Jira / Confluence の監査ログ）

認証イベント（SSO ログイン、ログイン失敗）
権限と管理者の変更（ロール / グループメンバーシップの変更、組織管理者の操作）
Confluence / Jira データへの大規模なアクセス:

Confluence: スペース / ページビュー / ダウンロード / エクスポートのイベント（特にエクスポート）
Jira: プロジェクトへのアクセス、問題のエクスポート、一括操作（可能な場合）

API トークンとアプリの操作（API トークンの作成 / 取り消し、OAuth アプリの接続、Marketplace アプリのインストール / アンインストール）
ソースコンテキスト（ソース IP / 位置情報、ユーザーエージェント / クライアントタイプ）

Microsoft 365 監査ロギング

Mandiant は、脅威アクターがこのキャンペーンの一環として、PowerShell を利用して SharePoint と OneDrive から機密データをダウンロードしていることを確認しています。この操作を検出するには、クライアントコンテキスト（特にユーザーエージェント）とともにファイルダウンロード操作を記録する M365 監査テレメトリーを取り込む必要があります。

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

Microsoft Purview 監査が利用可能で有効になっていること: テナントで Microsoft Purview 監査が有効で、使用できる必要があります（監査の「Standard」と「Premium」が機能 / 保持に影響）。
監査の表示 / 検索に必要な権限: 監査の検索とレコードにアクセスするために必要なコンプライアンス / 監査ロールを割り当てます。
SharePoint / OneDrive の操作が統合監査ログに存在すること: SharePoint / OneDrive のファイル操作が記録されていることを検証します（ファイルのダウンロード / アクセスなどの操作はここで確認）。
クライアントコンテキストが取得されていること: 監査レコードに UserAgent が含まれていることを確認します（クライアントから提供されている場合）。これにより、SharePoint / OneDrive の操作で PowerShell ベースのアクセスパターンを特定できます。

有効にして SIEM に取り込むもの

FileDownloaded と FileAccessed（SharePoint / OneDrive）
ユーザーエージェント / クライアント ID（WindowsPowerShell スタイルのユーザーエージェントを明らかにするため）
ユーザー ID、ソース IP、位置情報
対象リソースの詳細

3. 検出

以下の検出は、Mandiant が ShinyHunters 関連の侵入で特定した行動パターンを対象としています。このようなシナリオでは、攻撃者は通常、SSO プラットフォームを侵害するか、MFA の設定を不正に操作して初期アクセスを獲得してから、ネイティブの SaaS 機能を利用してデータを引き出し、検出を回避します。以下のユースケースは、ID プロバイダや生産性プラットフォームなど、対象領域ごとに分類されています。

注: この活動は、ベンダーのプロダクトやインフラストラクチャのセキュリティ脆弱性を原因とするものではなく、ShinyHunters 関連の侵入の有効性に依存しています。

実装ガイドライン

これらのルールは、明確な検出ロジックとクロスプラットフォームの移植性を優先するために、YARA-L 疑似コードとして提示しています。フィールド名、イベントタイプ、属性パスは環境によって異なるため、次の変数を考慮してください。

取り込み元: ログが Google SecOps に取り込まれる方法の違い。
パーサーマッピング: 構成に固有の特定の UDM（統合データモデル）マッピング。
テレメトリーの利用可能性: 特定の SaaS ライセンスに基づくロギングレベルのバリエーション。
リファレンスリスト: ノイズを減らし、アラートを実用的なものにするために組織が作成する必要がある、厳選された許可リスト / ブロックリスト。

注: これらの検出は、環境内の正確なイベントマッピングを検証し、特定のテレメトリーに合わせて疑似フィールドを更新することで、デプロイ前にテストすることをおすすめします。

Okta

MFA デバイスの登録または変更（ビッシング後のシグナル）

ソーシャルエンジニアリングによるアカウント乗っ取りの直後に発生することが多い、MFA デバイスの登録と MFA ライフサイクルの変更を検出します。このアラートが発生した場合は、SaaS アプリケーション（Salesforce、Google Workspace、Atlassian、DocuSign など）全体で、影響を受けたユーザーのダウンストリームアクセスを直ちに確認し、大規模なアクセスやデータエクスポートの兆候がないか調べます。

高精度の理由: この侵入パターンでは、MFA の不正操作が「アカウントの乗っ取り」の主なステップです。MFA ライフサイクルイベントは、日常的なログインに比べて発生頻度が低いため、アクセスが取得された直後に変更が行われた場合は、侵害の可能性を高い精度で示す指標となります。

主要シグナル

Okta システムログ MFA ライフサイクルイベント（登録 / 有効化 / 無効化 / リセット）
principal.user、principal.ip、client.user_agent、位置情報 / ASN（拡張されている場合）
省略可: パスワードの再設定、復元、ログイン異常への近接（同じユーザー、短い期間）

疑似コード（YARA-L）

events:
$mfa.metadata.vendor_name = "Okta"
$mfa.metadata.product_event_type in ( "okta.user.mfa.factor.enroll", "okta.user.mfa.factor.activate",  "okta.user.mfa.factor.deactivate", "okta.user.mfa.factor.reset_all" )
$u= $mfa.principal.user.userid
$t_mfa = $mfa.metadata.event_timestamp

$ip = coalesce($mfa.principal.ip, $mfa.principal.asset.ip)
$ua = coalesce($mfa.network.http.user_agent, $mfa.extracted.fields["userAgent"], "") 

$reset.metadata.vendor_name = "Okta"
$reset.metadata.product_event_type in (
"okta.user.password.reset",  "okta.user.account.recovery.start" )
$t_reset = $reset.metadata.event_timestamp

$auth.metadata.vendor_name = "Okta"
$auth.metadata.product_event_type in ("okta.user.authentication.sso", "okta.user.session.start")
$t_auth = $auth.metadata.event_timestamp

match:
$u over 30m

condition:
// Always alert on MFA lifecycle change
$mfa and
// Optional sequence tightening (enrichment only, not mandatory):
// If reset/auth exists in the window, enforce it happened before the MFA change.
(
(not $reset and not $auth) or
(($reset and $t_reset < $t_mfa) or ($auth and $t_auth < $t_mfa))
)

匿名化された IP からの不審な admin.security 操作

管理操作が不審なネットワークコンテキスト（プロキシ / VPN のようなインジケーター）から、または通常とは異なる認証シーケンスの直後に発生した場合、Okta 管理者 / セキュリティポスチャーの変更に関するアラートを生成します。

高精度の理由: 管理者 / セキュリティ制御の変更は量が少なく、永続化の有効化や可視性の低下に直接つながる可能性があります。

主要シグナル

Okta の管理 / システムイベント（ポリシーの変更、MFA ポリシー、セッションポリシー、管理アプリのアクセスなど）
「匿名化された」ネットワークシグナル: VPN / プロキシ ASN、「データセンター」の評価、TOR リストなど
アクターが通常とは異なるクライアント / IP を管理操作に使用

リファレンスリスト

VPN_TOR_ASNS（プロキシ / VPN ASN リスト）

疑似コード（YARA-L）

events:
$a.metadata.vendor_name = "Okta"
$a.metadata.product_event_type in ("okta.system.policy.update","okta.system.security.change","okta.user.session.clear","okta.user.password.reset","okta.user.mfa.reset_all")  
userid=$a.principal.user.userid
// correlate with a recent successful login for the same actor if available
$l.metadata.vendor_name = "Okta"
$l.metadata.product_event_type = "okta.user.authentication.sso"
userid=$l.principal.user.userid

match:
userid over 2h

condition:
$a and $l

Google Workspace

ToogleBox Recall の OAuth 認可

メールボックスの不正操作を示す、ToogleBox Recall（または既知のアプリ ID）の OAuth / アプリ認可イベントを検出します。

高精度の理由: これは、観測された「セキュリティ通知メールの削除」という行動に関連付けられた、ツール固有のシグナルです。

主要シグナル

Workspace OAuth / トークン認可ログイベント
アプリ名、アプリ ID、許可されたスコープ、許可したユーザー、ソース IP / 位置情報
省略可: 特権ユーザーのコンテキスト（管理者、エグゼクティブアシスタントなど）

疑似コード（YARA-L）

events:
$e.metadata.vendor_name = "Google Workspace"
$e.metadata.product_event_type in ("gws.oauth.grant", "gws.token.authorize") // placeholders
// match app name OR app id if you have it
(lower($e.target.application) contains "tooglebox" or
lower($e.target.application) contains "recall")
condition:
$e

Gmail における Okta のセキュリティ通知メールの削除

Okta のセキュリティ通知メール（例: 「セキュリティ手法が登録されました」）の削除操作を検出します。

高精度の理由: セキュリティ通知を対象とする削除は、通常のメールの動作ではなく、意図的な回避です。

主要シグナル

Gmail の監査ログの削除 / 完全な削除（またはメールボックスのクリーンアップ）イベント
件名が少数のセキュリティ通知文字列と一致
時間的な相関: 受信後すぐに削除（省略可）

疑似コード（YARA-L）

events:
$d.metadata.vendor_name = "Google Workspace"
$d.metadata.product_event_type in ("gws.gmail.message.delete",
                                       "gws.gmail.message.trash",
                                       "gws.gmail.message.permanent_delete") // PLACEHOLDER
regex_match(lower($d.target.email.subject),
"(security method enrolled|new sign-in|new device|mfa|authentication|verification)")
$u = $d.principal.user.userid
$t = $d.metadata.event_timestamp

match:
$u over 30m

condition:
$d and count($d) >= 2   // tighten: at least 2 in 30m; adjust if too strict
}

Google データエクスポートの開始 / 完了

Google データエクスポートの開始 / 完了イベントを検出します。

高精度の理由: 企業環境ではデータエクスポートは一般的ではありません。このキャンペーンでは、直接的なデータエクスポート経路を表しています。

主要シグナル

データエクスポートの監査イベント（開始、完了など）
ユーザー、ソース IP / 位置情報、ボリューム

リファレンスリスト

TAKEOUT_ALLOWED_USERS（まれ: 人事部門の退職手続きワークフロー、法務部門のエクスポートワークフロー）

疑似コード（YARA-L）

events:
$start.metadata.vendor_name = "Google Workspace"
$start.metadata.product_event_type = "gws.takeout.export.start"      
$user = $start.principal.user.userid
$job  = $start.target.resource.id   // if available; otherwise remove job join

$done.metadata.vendor_name = "Google Workspace"
$done.metadata.product_event_type  = "gws.takeout.export.complete"   
$bytes = coalesce($done.target.file.size, $done.extensions.bytes_exported)

match:
// takeout can take hours; don't use 10m here, adjust accordingly
$start.principal.user.userid = $done.principal.user.userid over 24h
// if you have a job/export id, this makes it *much* cleaner
$start.target.resource.id = $done.target.resource.id
condition:
$start and $done and
$start.metadata.event_timestamp < $done.metadata.event_timestamp and
$bytes >= 500000000   // 500MB start point; tune
not ($u in %TAKEOUT_ALLOWED_USERS) // OPTIONAL: remove if you don't maintain it

SaaS 間

既知のキャンペーンプロキシ / IOC ネットワークからのログイン試行

複数の SaaS / SSO プロバイダにわたり、キャンペーンに関連付けられた IP / ASN からの認証の試行を検出します。

高精度の理由: これらの IP と ASN にはビジネスとの正当な重複がありません。一致は、侵害された認証情報と既知の攻撃者が制御するインフラストラクチャ間の直接的なやり取りを示しています。

主要シグナル

Okta / Salesforce / Workspace / Atlassian / DocuSign にわたる認証の試行
principal.ip が IOC の IP または ASN リストと一致

リファレンスリスト

SHINYHUNTERS_PROXY_IPS
VPN_TOR_ASNS

疑似コード（YARA-L）

events:
$e.metadata.product_event_type in (
      "okta.login.attempt", "workday.sso.login.attempt",
      "gws.login.attempt",  "salesforce.login.attempt",
      "atlassian.login.attempt", "docusign.login.attempt"
    ) 
(
      $e.principal.ip in %SHINYHUNTERS_PROXY_IPS or
      $e.principal.ip.asn in %VPN_TOR_ASNS
)

condition:
$e

通常の業務時間外の ID 関連の操作

高リスクの操作（ログイン、パスワードの再設定、新しい MFA の登録やデバイスの変更）に着目し、通常の業務時間外に発生した ID イベントを検出します。

高精度の理由: 機密性の高い操作や、それらをほとんど実行しないユーザーに限った場合、異常なユーザー行動の強い兆候となります。

主要シグナル

ユーザーのログイン、パスワードの再設定、MFA の登録、デバイスの登録
タイムスタンプバケット: 深夜 / 金曜日の午後 / 週末

疑似コード（YARA-L）

events:
$e.metadata.vendor_name = "Okta"
$e.metadata.product_event_type in ("okta.user.password.reset","okta.user.mfa.factor.activate","okta.user.mfa.factor.reset_all") // PLACEHOLDER
outside_business_hours($e.metadata.event_timestamp, "America/New_York") 
// Include the business hours your organization functions in
$u = $e.principal.user.userid

condition:
$e

新しい場所から新しい MFA 方式を使ったログインの成功

新しい位置情報からであると同時に、新しく登録された MFA 方式を使用したログインを検出します。

高精度の理由: このパターンは、MFA の不正操作と馴染みのないアクセスコンテキストと一致する複合条件を表しています。

主要シグナル

認証の成功
ユーザーのベースラインと比較して新しい位置情報
ユーザーのベースライン（または最近の MFA 登録）と比較して新しい要素方式
省略可能なシーケンス: ログイン後に MFA 登録の実行

疑似コード（YARA-L）

events:
$login.metadata.vendor_name = "Okta"
$login.metadata.product_event_type = "okta.login.success" 
$u = $login.principal.user.userid
$geo = $login.principal.location.country
$t_l = $login.metadata.event_timestamp
$m = $login.security_result.auth_method // if present; otherwise join to factor event

condition:
$login and
first_seen_country_for_user($u, $geo) and
first_seen_factor_for_user($u, $m)

同じソース IP から複数の異なるユーザーによる複数の MFA 登録

同じソース IP が短期間に複数のユーザーの MFA を登録または変更したことを検出します。

高精度の理由: このパターンは、脅威アクターがヘルプデスク管理者を操って、被害者の MFA に不正なデバイスを登録させるという、既知のソーシャルエンジニアリング戦術を反映しています。この戦術は、同じソースアドレスから複数のユーザーに及ぶ可能性があります。

主要シグナル

Okta MFA ライフサイクルイベント
同じ src_ip
異なるユーザー数の基準
短い期間

疑似コード（YARA-L）

events:
$m.metadata.vendor_name = "Okta"
$m.metadata.product_event_type in ("<OKTA_MFA_ENROLL_EVENT>", "<OKTA_MFA_DEVICE_ENROLL_EVENT>") 
$ip  = coalesce($m.principal.ip, $m.principal.asset.ip)
$uid = $m.principal.user.userid

match:
$ip over 10m

condition:
count_distinct($uid) >= 3

ネットワーク

認証情報の収集、ポータルなりすましドメインへのウェブ / DNS アクセス

ブランドと SSO / ログインキーワードの類似パターンに一致する DNS クエリまたは HTTP リファラーを検出します。

高精度の理由: ネットワークテレメトリーがある場合、認証情報を収集するインフラストラクチャパターンを捕らえます。

主要シグナル

DNS クエリ名または HTTP リファラー / URL
ブランド + SSO キーワードの正規表現一致
正当なドメインの除外

リファレンスリスト

正当なドメインの許可リスト（小）（省略可）

疑似コード（YARA-L）

events:
$event.metadata.event_type in ("NETWORK_HTTP", "NETWORK_DNS")
// pick ONE depending on which log source you're using most
// DNS:
$domain = lower($event.network.dns.questions.name)
// If you’re using HTTP instead, swap the line above to:
// $domain = lower($event.network.http.referring_url)

condition:
regex_match($domain, ".*(yourcompany(my|sso|internal|okta|access|azure|zendesk|support)|(my|sso|internal|okta|access|azure|zendesk|support)yourcompany).*"
)
and not regex_match($domain, ".*yourcompany\\.com.*")
and not regex_match($domain, ".*okta\\.yourcompany\\.com.*")

Microsoft 365

M365 SharePoint / OneDrive: WindowsPowerShell ユーザーエージェントによる FileDownloaded

短い期間内にバイト基準またはカウント基準を超える PowerShell ユーザーエージェントによる SharePoint / OneDrive のダウンロードを検出します。

高精度の理由: PowerShell を使用した SharePoint のダウンロードとバーストボリュームは、スクリプトによる情報取得を示しています。

主要シグナル

FileDownloaded / FileAccessed
ユーザーエージェントに PowerShell が含まれている
期間内の転送バイト数またはダウンロード数
タイムスタンプ期間（順序は暗黙的）と最小値 < 最大値のチェック

疑似コード（YARA-L）

events:
  $e.metadata.vendor_name = "Microsoft"
  (
    $e.target.application = "SharePoint" or
    $e.target.application = "OneDrive"
  )
  $e.metadata.product_event_type = /FileDownloaded|FileAccessed/
  $e.network.http.user_agent = /PowerShell/ nocase
  $user = $e.principal.user.userid
  $bytes = coalesce($e.target.file.size, $e.extensions.bytes_transferred) 
  $ts = $e.metadata.event_timestamp

match:
  $user over 15m

condition:
  // keep your PowerShell constraint AND require volume
  $e and (sum($bytes) >= 500000000 or count($e) >= 20) and min($ts) < max($ts)

M365 SharePoint: 大量のドキュメント FileAccessed イベント

短い期間内にカウント基準と一意のファイル形式の最小数を超える SharePoint ドキュメントファイルのアクセスイベントを検出します。

高精度の理由: バーストボリュームは、スクリプトによる情報取得や、SharePoint 内の「アプリで開く」機能の使用を示している可能性があります。

主要シグナル

FileAccessed
一般的なドキュメントファイル形式でフィルタ（PDF など）
期間内のダウンロード数
一意のファイル形式の最小数

疑似コード（YARA-L）

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.metadata.product_event_type = "FileAccessed"
  $e.target.application = "SharePoint"
  $e.target.file.full_path = /\.(doc[mx]?|xls[bmx]?|ppt[amx]?|pdf)$/ nocase)
  $file_extension_extract = re.capture($e.target.file.full_path, `\.([^\.]+)$`)
  $session_id = $e.network.session_id

match:
  $session_id over 5m

outcome:
  $target_url_count = count_distinct(strings.coalesce($e.target.file.full_path))
  $extension_count = count_distinct($file_extension_extract)

condition:
  $e and $target_url_count >= 50 and $extension_count >= 3

M365 SharePoint: 大量のドキュメント FileDownloaded イベント

短い期間内にカウント基準と一意のファイル形式の最小数を超える SharePoint ドキュメントファイルのダウンロードイベントを検出します。

高精度の理由: バーストボリュームは、スクリプトによる情報取得を示している可能性があります。これは、正当なバックアッププロセスによって生成されている可能性もあります。

主要シグナル

FileDownloaded
一般的なドキュメントファイル形式でフィルタ（PDF など）
期間内のダウンロード数
一意のファイル形式の最小数

疑似コード（YARA-L）

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.metadata.product_event_type = "FileDownloaded"
  $e.target.application = "SharePoint"
  $e.target.file.full_path = /\.(doc[mx]?|xls[bmx]?|ppt[amx]?|pdf)$/ nocase)
  $file_extension_extract = re.capture($e.target.file.full_path, `\.([^\.]+)$`)
  $session_id = $e.network.session_id

match:
  $session_id over 5m

outcome:
  $target_url_count = count_distinct(strings.coalesce($e.target.file.full_path))
  $extension_count = count_distinct($file_extension_extract)

condition:
  $e and $target_url_count >= 50 and $extension_count >= 3

M365 SharePoint: 特定の文字列のクエリ

機密文書、平文の認証情報、専有情報など、特定の文字列に関連するファイルの SharePoint クエリを検出します。

高精度の理由: 1 つのアカウントが特定の文字列を複数回検索することは、頻繁には発生しません。一般に、ユーザーは一般的なラベル（「機密情報」など）よりも、プロジェクトやタスクに固有の文字列を検索します。

主要シグナル

SearchQueryPerformed
機密情報や秘匿特権対象情報に関連付けられることが多い文字列でフィルタ

疑似コード（YARA-L）

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.metadata.product_event_type = "SearchQueryPerformed"
  $e.target.application = "SharePoint"
  $e.additional.fields["search_query_text"] = /\bpoc\b|proposal|confidential|internal|salesforce|vpn/ nocase

condition:
  $e

M365 Exchange における MFA 変更通知メールの削除

Okta や他のプラットフォームのセキュリティ通知メール（例: 「セキュリティ手法が登録されました」）の削除操作を検出します。

高精度の理由: セキュリティ通知を対象とする削除は意図的な回避であり、通常はメールユーザーが行うものではありません。

主要シグナル

M365 Exchange の監査ログの削除 / 完全な削除（またはメールボックスのクリーンアップ）イベント
件名が少数のセキュリティ通知文字列と一致
時間的な相関: 受信後すぐに削除（省略可）

疑似コード（YARA-L）

events:
  $e.metadata.vendor_name = "Microsoft"
  $e.target.application = "Exchange"
  $e.metadata.product_event_type = /^(SoftDelete|HardDelete|MoveToDeletedItems)$/ nocase
  $e.network.email.subject = /new\s+(mfa|multi-|factor|method|device|security)|\b2fa\b|\b2-Step\b|(factor|method|device|security|mfa)\s+(enroll|registered|added|change|verify|updated|activated|configured|setup)/ nocase

  // filtering specifically for new device registration strings
  $e.network.email.subject = /enroll|registered|added|change|verify|updated|activated|configured|setup/ nocase

  // tuning out new device logon events
  $e.network.email.subject != /(sign|log)(-|\s)?(in|on)/ nocase

condition:
  $e

投稿先

脅威インテリジェンス

Threat Intelligence

戦場を越えて: 防衛産業基盤への脅威

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

Threat Intelligence

BRICKSTORM から GRIMBOLT へ: UNC6201 が Dell RecoverPoint for Virtual Machines のゼロデイ脆弱性を悪用

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

Threat Intelligence

UNC1069、新たなツールと AI を活用したソーシャルエンジニアリングで暗号通貨セクターを標的に

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

Threat Intelligence

GTIG AI 脅威トラッカー: 敵対的な使用を目的とした AI モデルの抽出（蒸留）、実験、（継続的な）統合

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

最前線からのガイダンス: SaaS を標的とした ShinyHunters を標榜するデータ盗難に対する予防的防御

Mandiant

Mandiant Services

はじめに

封じ込め

1. セキュリティ強化

匿名化された IP からの不審な admin.security 操作

Google Workspace

Gmail における Okta のセキュリティ通知メールの削除

Google データ エクスポートの開始 / 完了

SaaS 間

通常の業務時間外の ID 関連の操作

新しい場所から新しい MFA 方式を使ったログインの成功

同じソース IP から複数の異なるユーザーによる複数の MFA 登録

ネットワーク

Microsoft 365

M365 SharePoint: 大量のドキュメント FileAccessed イベント

M365 SharePoint: 大量のドキュメント FileDownloaded イベント

M365 SharePoint: 特定の文字列のクエリ

M365 Exchange における MFA 変更通知メールの削除

関連記事

戦場を越えて: 防衛産業基盤への脅威

BRICKSTORM から GRIMBOLT へ: UNC6201 が Dell RecoverPoint for Virtual Machines のゼロデイ脆弱性を悪用

UNC1069、新たなツールと AI を活用したソーシャル エンジニアリングで暗号通貨セクターを標的に

GTIG AI 脅威トラッカー: 敵対的な使用を目的とした AI モデルの抽出（蒸留）、実験、（継続的な）統合

Google データエクスポートの開始 / 完了

UNC1069、新たなツールと AI を活用したソーシャルエンジニアリングで暗号通貨セクターを標的に