ハクソク

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

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

250日前原文(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パートナーのクソみたいなことも絡んでる。

└

このFUBARの周りには、企業がこのクソを乗り越える手助けをして生計を立てている業界があるんだよ。大手も小手もいて、他に使えるものがあるなんて教えるインセンティブは全然ない。月額サービス料が美味しすぎるからね。

└

テナントを作成するのが面倒で、変更できないデフォルトのテナントができるの？ テナント作成時に何が面倒なの？ すごく簡単だと思うけど。変更できないデフォルトのテナントって何を指してるの？ そんなこと思い浮かばないけど。使い方を間違えてるんじゃない？

└

テナントを作成するのに2分もかからないよ。次へを何回かクリックして、クレジットカード情報を入れたら終わり。アカウントの種類や請求方法もいろいろあるし、顧客数は数億人いると思う。みんな選択肢が欲しいから、特に問題はないと思うけど。

すごい仕事だね！これを見て思ったんだけど、Microsoftの長期サポートへのコミットメントが問題の一部かもしれない。古いAPIを廃止する代わりに、延命措置をしてるけど、新しいインターフェースとの相互作用に関する「回帰テスト」を忘れてる感じ。P0のWindowsレジストリの話みたいで、新しいコードには脆弱性がなかったけど、古い動作が新しい機能とどう絡むかに問題があった。

└

Microsoftはこのレガシーコードを維持せざるを得ないんだよね。大きな契約を持つほとんどの企業クライアントは、これを強制できるし、MSは顧客が移行するまで、または移行するかどうか分からない限りサポートし続ける必要がある。大きなレガシー企業ソフトウェアについては、永遠にレガシーコードをサポートするより、全体を作り直す方が簡単だと思うけど、モチベーションやリソースがあってもそれができないんだよね。

まあ、少なくとも誰かがEntra IDを使ってログインできたみたいだね！

└

笑った。コーヒーが鼻から出てきたよ… :D

リンクされたCVEには、ちょっと変だなと思う点がある。攻撃の「攻撃の複雑さ」が「高い」とされてるんだ。つまり、>「成功した攻撃は攻撃者の制御を超えた条件に依存する。」ということ。成功する攻撃は意図的にはできず、攻撃者が脆弱なコンポーネントに対して成功する攻撃を期待する前に、準備や実行に一定の努力を投資する必要があるってこと。たとえば、成功する攻撃には、攻撃者が脆弱なターゲット/コンポーネントが存在する環境についての知識を集めたり、攻撃の信頼性を高めるためにターゲット環境を準備したり、ターゲットと被害者が要求するリソースの間の論理的なネットワークパスに自分を注入して、ネットワーク通信を読み取ったり修正したりする（例えば、中間者攻撃）必要があるかもしれない。でも、Dirk-janの記事を読むと、必要なのはEntra IDの基本的な管理知識と、ターゲット環境の任意のユーザーのnetIdだけで、それはブルートフォース列挙で見つけられる。残りは公知の情報だよ。厳密に言えば、攻撃者は一定の努力を投資する必要があるけど、それはCVEを見栄えよくするために定義を引き伸ばしてるように感じる。

└

自分の経験から言うと、セキュリティ業界で6年間働いてきたけど、ほとんどの人はCVSSを本来の意図通りに使ってない。彼らはほぼ恣意的にCVSSの入力を調整して、自分たちが好きな出力を得てる。君の言う通り、この場合、攻撃の複雑さは高くないはずだよね。でも、CVSSスコアを計算している人は、攻撃の複雑さが高くないと設定しなかったら、スコアが高すぎると思ったんじゃないかな。CVSSには他にも問題があって、脆弱性でないものに適用しようとする人もいる。見かけのCVSSスコアは無視して、問題が何なのかを読んで、自分で判断した方がいいよ。

└

「Entra IDの基本的な管理知識があれば十分」 > そうだね、だって「Entra IDの基本的な知識を持つ基本ユーザー」が、文書化されていないトークンの種類を見つけて、別のGraph APIの脆弱性と組み合わせてユーザーをなりすましてるから… 基本的なEntra IDユーザーは、Entra IDトークンが何かも正確には知らないんだよね。

└

公平に言うと、認証されたユーザーとしてEntraで最も基本的なタスクを行うのも「高い複雑性」だから、攻撃の難易度はそこからさらに上がる一方だよね。

└

「1.1 2025年9月18日 この脆弱性のCVSSスコアは、攻撃の複雑さのメトリックが高から低に変更されたことを反映して更新されました。」 https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

オランダの人が「ランダムなMicrosoft 365テナントからすべてのデータを取得する」って話を思い出した。これ、めっちゃ面白いトークだったよ。

以前にEntra IDに関連する似たような攻撃を聞いた気がするけど、正確には思い出せないな（たぶん[0]か[1]？）。このシステムは複雑だって理解してるけど、比較的重大な脆弱性が見つかってるのは心配だよね。[0]: https://securitylabs.datadoghq.com/articles/i-spy-escalating... [1]: https://www.semperis.com/blog/unoauthorized-privilege-elevat...

└

マイクロソフトのテナントには、どんなEntraアカウントでも入れるみたいだね。なんでかっていうと、マイクロソフトの開発者たちですら、Entraの認証や認可がどうなってるか理解してないからなんだよ。大体のケースでは、ログイン後にそのアカウントが保護されたリソースにアクセスできるか確認しなきゃいけないんだけど（これはアクセスするリソースのOauthログインフロー内でやらなきゃいけないし、誰も代わりにやってくれない）。これ、俺が自分のSaaSサービスで偶然発見して（もちろん修正したけど！）、その時にEntra B2B認証にも対応してたんだよね。マイクロソフトの研究者が同じことを発見する前にね。 https://research.eye.security/consent-and-compromise/ HNのディスカッションスレッド: https://news.ycombinator.com/item?id=44850681