ハクソク

世界を動かす技術を、日本語で。

すべてを支配する一つのトークン – すべての Entra ID テナントでグローバル管理者を取得する方法

2025年9月18日原文(dirkjanm.io)

概要

  • 2024年7月のBlack HatおよびDEF CON講演準備中に、 Entra ID史上最大級の脆弱性 を発見
  • この脆弱性により、 全世界のEntra IDテナントを完全に乗っ取る ことが可能
  • 問題の根本は 未公開のActorトークン と Azure AD Graph APIの認証不備
  • Microsoftは即日対応し、脆弱性を修正しCVE-2025-55241を発行
  • 攻撃の痕跡が残らない ため、検出や防御が非常に困難

Entra IDの重大な脆弱性と全テナント乗っ取りリスク

  • 2024年7月の Black Hat/DEF CON講演準備中、Entra IDの 史上最悪級の脆弱性 を発見
  • この脆弱性により、 世界中のEntra IDテナント （ナショナルクラウドを除く）を 完全に制御可能
  • 管理者視点では、 自分のテナント全体が乗っ取られる レベルのインパクト
  • 脆弱性の構成要素は 2つ ：
    • Microsoft内部で使われる未公開の“Actorトークン”
    • Azure AD Graph APIのテナント検証不備
  • Actorトークンは サービス間通信（S2S） 用で、 条件付きアクセスなどのセキュリティポリシーを回避
  • APIアクセスログやトークン発行ログが一切残らない ため、侵害の証跡がほぼ皆無

技術的詳細：ActorトークンとAPI認証不備

  • Actorトークン はAccess Control Serviceが発行し、 Microsoft内部やSharePoint/Exchange連携 で利用
  • Exchange Online SPなどが証明書資格情報でトークン取得、 任意ユーザーへのなりすまし が可能
  • Actorトークン自体は署名付きJWT だが、 実際のなりすましトークンは未署名JWT で作成
  • “trustedfordelegation” 属性がTrueなら、 他のユーザーへのなりすましが24時間有効
  • Microsoftアプリ以外が取得するとtrustedfordelegationはFalse
  • なりすましトークンは署名なし で、 Exchange等が自由に生成・利用可能
  • 発行・利用時にEntra IDやリソース側にログが残らない ため、追跡・検知が困難
  • トークン漏洩時のインパクトは甚大 で、 全テナントのデータ・権限を横断的に取得可能

Azure AD Graph APIの認証不備

  • 本来、 APIはトークンのテナントIDとリクエスト先テナントIDが一致 しなければ拒否すべき
  • 実態は、 異なるテナントIDでなりすましトークンを送信しても受理される 重大な認証不備
  • 攻撃者は被害テナントのユーザーnetIdさえ知っていれば、任意ユーザーになりすまし可能
  • グローバル管理者になりすまし→全オブジェクト・設定の改変・新規権限付与が可能
  • Microsoft 365やAzureリソースにも無制限アクセス
  • ディレクトリ情報の読み出しは一切痕跡なし、書き込み操作も正規管理者の操作に偽装

脆弱性のインパクトとMicrosoftの対応

  • 報告当日中にMicrosoft Security Response Center（MSRC）へ通報
  • 数日以内にサーバー側で修正完了、ActorトークンによるGraph APIリクエストを全面ブロック
  • CVE-2025-55241 として公式に脆弱性情報公開
  • Microsoftの内部テレメトリで悪用の痕跡なし と報告
  • APIレベルの詳細な監査ログは現状ほぼ存在せず、防御・検知が難しい

攻撃が可能だった内容一覧

  • ユーザー情報（個人情報含む）
  • グループ・ロール情報
  • テナント設定・条件付きアクセス等のポリシー
  • アプリケーション・サービスプリンシパル・権限割当
  • デバイス情報・BitLockerキー
  • Microsoft 365/SharePoint Online/Exchange Online/Azureリソースへの横断的な完全アクセス

検知・監査の困難さ

  • Actorトークンの発行・利用ログが残らない
  • APIレベルの監査ログが未整備（Microsoft Graphは一部対応、Azure AD Graphは未整備）
  • 攻撃痕跡のKQL検出例を公開 （詳細は元記事参照）

総括

  • Actorトークン設計自体が極めて危険 で、現代的なセキュリティ要件を満たさない
  • Microsoftはレガシー実装の廃止を進めているが、全サービスの移行状況は非公開
  • この脆弱性を通じて、クラウドID基盤の設計・監査の重要性が改めて浮き彫り

Hackerたちの意見

発信元テナントの検証がちゃんとできてないのは、設計した人たちがそのフィールドの意味を考えたことがあるのか疑問だよね。「テナント」って言葉もすごく示唆的だし、結局はただの賃貸で、「大家」がいつも鍵を持ってるってことだ。

└

さらに悪いことに、「これらのアクター トークンの性質上、条件付きアクセスのようなセキュリティポリシーの対象にはならない」って。これは良いセキュリティ設計の原則に反してるよ。特定のアクションを指定せずにルートアクセスを与えるトークンなんて、誤用や悪用を招くだけだよね。これらのトークンはJWTやマカロンみたいに、特定の範囲やテナント内での特定の権限を持ってるべきだと思ってたのに、残念だ。

└

サービスの標準的な名前付けだよ。マルチテナンシーは存在するけど、この文脈では家主のことじゃない。

うわ、何回かこれに近づいたことあるよ。いろんなISEウィンドウでPowerShellを実行して、時々別のテナントにコピー＆ペーストしたりしてたから、ほんとに明らかな脆弱性に見えた！

まじで狂ってる。セキュリティがこんなに弱いなんて、意図的なバックドアを発見したみたいだね。

└

私のNSL検出器がここで振り切れちゃってる。

└

Microsoftがサービス間（S2S）で使う「アクタートークン」と呼ばれる偽装トークン。文字通り、すべての「セキュリティ」フレームワークが非人間のアイデンティティに対してゴッドモードの長寿命トークンを使ってる。 （SPIFFEを除いて、あれはニッチなものでKubernetesのクソにしか使われてないけど。）「セキュリティ」という分野全体が、道化師たちによって運営されてる茶番だよ。

36年経って、Kerberosはようやく安定してて、安全で、サポートも充実してるみたいだね。なんでEntraが必要なんだろう？

└

Kerberosには良い月次定期収入の「ストーリー」がないんだよね。

└

Kerberosはウェブではあまりうまく機能しないね。

└

大きな問題の一つがダブルホップ問題だね。これは重要なセキュリティ境界でもあり、プロトコルの中で一番面倒な部分でもある。https://techcommunity.microsoft.com/blog/askds/understanding... 単一の組織階層内ではうまく機能するけど、「SaaS」と考えるとかなり厄介になる。

最近、初めてEntra IDを使って、うちのサイトのMicrosoft OAuthを設定しなきゃいけなかったんだけど、なんでこんなにデザインがひどいの？テナントを作るだけでもめんどくさいし、変更できないデフォルトのテナントがあって、Microsoft 365にお金を払わないとダメって？それにサブスクリプション、Microsoftパートナー、企業アカウントと個人アカウントの違いとか、もうごちゃごちゃ。古いADの名前変更や、古いスクリーンショットのドキュメント、Microsoftパートナーのクソみたいなことも絡んでる。

Hacker Newsで議論の続きを見る