MSP経由で盗まれたEntra IDアプリ資格情報が27組織を横断——サービスプリンシパルが開けた静かな裏口です

今日の深掘りポイント

• サービスプリンシパル（アプリ登録）の秘密情報が一つ漏れるだけで、M365/Graphを横断して「正当なアプリ」として静かに侵入できる構造的リスクが露呈しました。
• MSPの権限委任（顧客テナントへの同意済みアプリや管理関係）を足掛かりに、多数テナントへ短時間で横展開する「サプライチェーン型クラウド侵害」の実害ケースです。
• MFAや従来の条件付きアクセスが効きづらい「ワークロードID（非人間ID）」の特性が、検知・封じ込めの遅延要因になりやすいです。
• 直近でやるべきは、アプリ資格情報の強制ローテーション、不要・不明なアプリ登録の即時棚卸し、サービスプリンシパルのサインイン監査の常時可観測化です。
• 中長期では、「ワークロードID向け条件付きアクセス」「ExchangeのApplication Access Policy」「GDAP最小化」「秘密情報レス（Federation/Managed Identity）」への移行が決め手になります。

はじめに

盗まれたMicrosoft Entra IDアプリ（サービスプリンシパル）の資格情報を用い、攻撃者が27の組織に認証済みアプリとして侵入した事案です。報道では、約45のアプリ登録が狙われ、33件で認証に成功、81ファイルがダウンロードされ、約2,279件のメールボックスアイテムにアクセスされたとされています。Microsoft側の基盤脆弱性は確認されておらず、「正規アプリとしての認証」を悪用した点が肝です。MSP経由での横展開という文脈から、国内の重要業種を含む多数テナント運用においても再現性が高いパターンで、即応が求められます。

この種の事案は、単にアプリの秘密が漏れたという範囲に留まらず、同意（consent）や委任（delegation）の設計、非人間IDのガバナンス、監査の可観測性といった「クラウド・アイデンティティ運用の土台」を試される出来事です。いま手元の環境で「どのアプリが何にアクセスでき、どこからサインインしているか」を、1時間以内に説明できるかが問われています。

参考情報は現時点で公開報道に依拠しており、詳細な侵入経路や特定のベンダー設定は未公表部分があるため、一部は仮説として提示します。

深掘り詳細

事実関係（確認できる点）

• 盗まれたMicrosoft Entra IDアプリの資格情報を用いた侵害で、27組織に影響が及んだと報じられています。
• 標的となったアプリ登録は約45件、そのうち33件で認証が成功しています。
• 攻撃者は81ファイルをダウンロードし、約2,279件のメールボックスアイテムにアクセスしています。
• 攻撃はMSP経由で行われ、正当なアプリとしての認証を悪用しており、クラウド基盤側の脆弱性は否定されています。
• 以上は公開報道に基づく数値であり、被害の全容や個別テナントでの横展開手口は精査が続く可能性があります。

出典: GBHackers – Hackers Use Stolen Microsoft Entra ID App Credentials

インサイト（編集部の視点）

• 非人間ID（ワークロードID）の盲点です
  アプリの「クライアント資格情報フロー（client credentials）」はユーザーのMFAや端末準拠性を通らず、条件付きアクセスも適用範囲や設定次第で素通りします。したがって、一度秘密情報（クライアントシークレットや証明書）が流出すると、正規アプリとして長期間・静かに活動されるリスクが現実化します。今回の「正当なアプリとしての認証」は、この構造的ギャップに依存しています。

• MSPを介した同意・委任の「繋がり」が増幅器になります
  MSPが保有する多テナント同意済みアプリ、権限の強いGraph Application Permission、旧DAPや広いGDAP、運用のためのCI/CDや自動化スクリプトに埋め込まれた秘密——どこか1点が破られると、短時間で多数テナントへ横展開されます。攻撃コスト対効果が非常に高く、供給網攻撃の定番化が進むと見ます。

• 「最小権限」と「作用域の明確化」が決定打です
  特にExchange OnlineとGraphのApplication Permissionは、テナント全体のメール・ファイルに横断的アクセスを与えがちです。ExchangeのApplication Access Policy（アプリがアクセスできるメールボックスをリストで限定する）や、Graph側も代替パターン（Delegated＋JIT昇格やスコープ制御）を検討し、アプリが「どこまで読めるか」を物理的に狭めることが実害を減らします。

• 監査の可観測性が「封じ込め速度」を左右します
  サービスプリンシパルのサインインログをSIEMに常時取り込み、普段アクセスしないIP/ASN、急増するGraph呼び出し、リソース横断のアクセス、未使用アプリからの突然のサインインといったふるまい変化を、日次ではなく「分単位」で検知できる体制が必要です。異常値監視はユーザーよりもワークロードIDにこそ効きます。

• メトリクス観点からの総合所見です
  本件は再現性が高く、攻撃者の成功確度も高い一方で、即応手順（ローテーション・無効化・棚卸し・ログ照合）で被害の増幅を抑えられる余地が十分あるタイプです。新規性は突出していないものの、MSPという増幅器と非人間IDの設計ギャップが重なることで、被害の広がりと検知遅延が同時に起きやすい構図です。CISO視点では、「人のID保護」と同等、もしくはそれ以上の優先度で「ワークロードIDのガバナンス」をロードマップ先頭に繰り上げる判断が肝になります。

脅威シナリオと影響

以下は公開情報を踏まえた仮説シナリオであり、実事案の詳細とは異なる可能性があります。

• シナリオA（MSPのアプリ資格情報流出からの横展開）

  1. 攻撃者がMSP管理下のアプリ登録（多テナント同意済み、Graph Application Permission保有）のクライアントシークレット/証明書を入手します。
  2. OAuth 2.0のクライアント資格情報フローでトークンを取得し、Microsoft Graph経由で顧客テナントのメール・ファイルにアクセスします。
  3. データを段階的に持ち出しつつ、アプリに新たな資格情報を追加して永続化を図ります（仮説）。
     MITRE ATT&CKマッピング（例）:
  • T1199 Trusted Relationship（MSPとの信頼関係悪用）
  • T1078.004 Valid Accounts: Cloud Accounts（クラウドの正規資格情報悪用）
  • T1098.003 Account Manipulation: Additional Cloud Credentials（サービスプリンシパルへの資格情報追加、仮説）
  • T1526 Cloud Service Discovery（Graph/リソースの列挙）
  • T1567 Exfiltration Over Web Service（Graph/HTTPS経由での持ち出し）

• シナリオB（CI/CD・リポジトリからの二次流出）

  1. Azure DevOpsや他のCI/CD環境に保存されたサービスプリンシパル資格情報、あるいはセッショントークンが再利用されます（仮説）。
  2. 自動化パイプラインと同一のふるまいを装い、監視の網をすり抜けます。
     MITRE（例）:
  • T1552 Unsecured Credentials（平文・不適切保管の秘密情報）
  • T1078.004 Valid Accounts: Cloud Accounts
  • T1036 Masquerading（自動化タスクのふるまい偽装、仮説）

• シナリオC（広権限アプリの多テナント同意悪用）

  1. 過去運用でFiles.Read.AllやMail.Read、Directory.Read.All等が「アプリケーション許可」で広く同意済み。
  2. 漏えいしたアプリ資格情報を用いて、広域にデータアクセスが成立。
     MITRE（例）:
  • T1078.004 Valid Accounts: Cloud Accounts
  • T1526 Cloud Service Discovery
  • T1567 Exfiltration Over Web Service

影響面では、メール・ファイルの静的な抜き取りだけでなく、組織横断での機密探索、将来のBEC（ビジネスメール詐欺）やサプライチェーン攻撃の踏み台化、規制・監査インパクトの波及が懸念されます。特に重要インフラや公共部門を抱えるMSPにとっては、単発のインシデントが地理的・業種的に広い連鎖を生む可能性が高く、封じ込めの初動速度が損害規模を決めます。

セキュリティ担当者のアクション

優先度順に、即日から30日スパンで整理します。

• いま直ちに（0–24時間）

  • 侵害懸念のあるアプリ登録の資格情報（シークレット/証明書）を強制ローテーションし、不要な資格情報を削除します。
  • Enterprise Applications/アプリ登録のうち「用途不明」「最終使用が古い」「所有者不明」を無効化し、所有者とビジネス責任者を再紐付けします。
  • サービスプリンシパルのサインインログをSIEMに全件投入し、下記の異常を探索します（直近30–90日）:
    • クライアント資格情報フローによるトークン発行の急増
    • これまで活動のなかったアプリからの突然のGraph/Exchangeアクセス
    • 新規ASN・プロキシ・国外IPからのAPIアクセス
    • アプリ権限に対して不釣り合いなリソース横断の読み取り
  • 「アプリへの新規資格情報追加」「権限変更」「管理関係（DAP/GDAP）の追加」といったディレクトリ監査イベントに対し、即席でも高優先度のアラートを設けます。

• 48時間以内

  • Exchange OnlineのApplication Access Policyを導入/点検し、アプリがアクセス可能なメールボックスを厳格に限定します。
  • GraphのApplication Permissionの棚卸しを実施し、Files/Mail/Directory系の広権限はDelegated＋JIT昇格やスコープ代替を検討します。
  • 条件付きアクセス（ワークロードID向け）を評価し、サービスプリンシパルのサインインを「許可された場所/ネットワーク/特定実行環境」へ絞り込みます。
  • MSP各社は旧DAPの無効化とGDAPの最小権限化、PIMでのJIT有効化、パートナー関係の再承認プロセスを徹底します。

• 1–2週間

  • 秘密情報の保管場所を全社横断で棚卸しし、Key Vault等の専用保管に統合、アクセスをRBAC/監査で制御します。
  • クライアントシークレット中心の運用から、証明書ベース、もしくはFederation（OIDC）/Managed Identity等の「秘密情報レス」へ段階移行します。
  • App Consentのワークフロー化（ユーザー同意の無効化、管理者同意の審査義務化）、App Governanceによる高権限アプリの継続監査を開始します。
  • SOC検知の常設ルール化（例）:
    • サービスプリンシパルの初回サインイン
    • 短時間におけるGraphのRead呼び出し急増（Mail/Drive/SharePoint）
    • アプリ許可変更/資格情報追加/所有者変更イベントのリアルタイム通知
    • 指定以外の国・ASNからのワークロードIDサインイン

• 30日以内（定着化）

  • アプリ登録のライフサイクル管理（作成—所有—権限—満了—廃止）を標準化し、所有者の人事異動・退職に連動した棚卸しを自動化します。
  • インシデント対応プレイブックを更新し、アプリ資格情報流出を前提にした封じ込め手順（ローテーション、権限剥奪、アクセス範囲遮断、法務/顧客通知）を整備します。
  • 定期的な「非人間IDレビュー会議」を設け、CISO/運用/開発/監査が同じリスト（全アプリ、全権限、全同意、全資格情報）を見る運用を根付かせます。

最後に、今回の事案は「クラウドIDは境界防御よりも早く壊れる」現実を突きつけます。守るべきは「人のID」だけではありません。サービスプリンシパルという無数の小さな鍵束を、見える化し、減らし、縛り、短命化し、そして常に疑うことが、次の横展開を止める最短距離です。

参考情報:

• Hackers Use Stolen Microsoft Entra ID App Credentials (GBHackers)