Azure Entra IDのサインインログ回避脆弱性、3件目と4件目の事例が公開

 (trustedsec.com)
1 ポイント 投稿者 GN⁺ 2026-03-22 | 1件のコメント | WhatsAppで共有
  • 2023年以降、Azure Entra IDのサインインログ回避脆弱性が計4件発見されており、最近の2件は正規トークンの発行が可能な深刻な問題であることが確認された
  • GraphGoblinはOAuth2 ROPCフローでscopeパラメータを繰り返し入力することでログ生成を回避し、Graph**は5万文字を超えるUser-Agent文字列によってログを完全に欠落させる
  • 2つの脆弱性はいずれもSQLカラム長超過によるロギング失敗が原因とされ、Microsoftは報告後に修正を完了した
  • Microsoftは今回の問題を**「中程度(Medium)」に分類し、報奨金や公式な認定なしに静かに修正したが、CVSS基準ではHigh(7.5～8.7点)**相当と評価される
  • 入力値検証の失敗による欠陥が繰り返し発生しており、ログのクロス検証とKQLベースの検知ルール強化がセキュリティ担当者の必須課題として指摘されている

Azure Entra IDのサインインログ回避脆弱性が公開

  • 2023年以降、Azure Entra IDのサインインログ回避脆弱性が計4件発見された
    • 初期の2件はパスワードの有効性確認のみ可能だったが、最近の2件は正規トークンの発行まで可能な深刻なレベルの問題
    • すべての脆弱性は現在Microsoftによって修正済み

  • GraphNinjaおよびGraphGhostの要約

    • GraphNinja: 別テナントのエンドポイントを指定してサインインを試みると、パスワードの有効性は分かるがログは生成されない
      • 攻撃者は外部テナントに認証リクエストを送り、応答からパスワードが正しいかどうかを確認できる
      • Microsoftはその後、この問題を解決するため追加ロギングを導入した
    • GraphGhost: 誤ったClient IDを使うと、認証フローはパスワード検証後に失敗し、ログには失敗としてのみ表示される
      • パスワードが正しかったという情報は管理者ログに残らない
      • Microsoftはサインインログにパスワード検証の成否を追加して修正した

  • GraphGoblin脆弱性

    • GraphGoblinはOAuth2 ROPCフローでscopeパラメータを繰り返し入力することでログ生成を回避する
      • "openid openid openid ..."の形で数千回繰り返して入力すると正規トークンが発行されるが、Entra IDのサインインログには一切記録が残らない
    • 原因はSQLカラム長超過によるINSERT失敗とされる
      • 繰り返されたscope文字列がデータベースフィールド長を超え、ログ保存に失敗したと推定される
    • Microsoftは問題の再現に苦労したが、動画の証拠提示後に修正を完了した

  • Graph****** (User-Agentベースの回避)

    • User-Agentフィールドに50,000文字以上の長い文字列を入力するとログが生成されない
      • 認証リクエストは正常に処理されてトークンが発行されるが、ログは完全に欠落する
      • SQLカラム長超過によるロギング失敗と推定される
    • 2025年9月28日に発見され、10月8日にはMicrosoftが報告前にすでに修正を完了していた

  • タイムライン要約

    • 2025-09-20: GraphGoblinを初めて発見
    • 2025-09-26: MicrosoftにGraphGoblinを報告
    • 2025-09-28: Graph******を発見
    • 2025-10-08: Graph******の修正完了
    • 2025-11-21: MicrosoftがGraphGoblinの再現に成功し、修正開始

Microsoftの対応と評価

  • Microsoftは今回の脆弱性を**「中程度(Medium)」**に分類し、報奨金や公開での認定を行わなかった
    • 以前の2件(2023～2024年)では報奨金支払いと認定があった
    • 今回は正規トークンが発行される深刻な問題であるにもかかわらず、重要ではないと評価した
  • CVSS v3.1では7.5点(High)、v4.0では**8.7点(High)**と評価される
    • **Integrity(完全性)**への影響により高いスコアとなる
    • ログ欠落はセキュリティコンポーネントの直接的な損傷と見なされる
  • Microsoftは問題再現後、2週間で修正を完了した
    • 過去のGraphNinja修正には7か月、GraphGhostには5か月を要した

ログ回避の検知方法

  • KQLクエリにより、Graph ActivityログとSign-InログのSession IDまたはUniqueTokenIdentifierを比較する
    • Graph Activityには存在するがSign-Inログには存在しないセッションは、回避されたサインインと判断できる
    • ただし、Graph Activityログの収集にはE5ライセンスが必要
  • 例示KQLクエリ: 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • 必要に応じてSessionId基準でも比較可能
    • 検知結果に基づいてAzure Log Search Alert Ruleを設定できる

4つのサインインログ回避の要約

発見時期 手法 トークン発行の有無 Microsoft認定の有無
2023-08 / 2024-05 外部テナントID指定によるパスワード検証ログ未生成 X X
2024-12 / 2025-04 誤ったClient IDで認証失敗を誘導 X X
2025-09-20 scope反復入力によるSQLカラムオーバーフロー O X
2025-09-28 長大なUser-Agent文字列によるSQLカラムオーバーフロー O N/A

Microsoftのセキュリティプロセスへの批判

  • Entra IDサインインロギング機能の複数パラメータで欠陥を発見

    • tenant ID, client ID, scope, user-agentなど中核フィールドで脆弱性が繰り返し発生
    • 単純な入力値検証の失敗による問題であり、複雑な攻撃ではない
    • Microsoftのセキュリティレビューおよび品質管理の欠如が指摘されている
    • 数年にわたり同一領域で類似の欠陥が繰り返されている
    • AIコード生成導入の有無や、コード管理過程での見落としの可能性も提起されている

  • 公開透明性の不足

    • 4件ともCVEは発行されておらず、公式発表もない
    • MicrosoftはCNAとして、自社脆弱性の公開可否を独占的に決定している

結論

  • Azure Entra IDのサインインログは、世界中の組織における侵入検知の中核データである
    • ログが欠落すると、攻撃検知体制全体が無力化される可能性がある
  • 発見された4つの脆弱性はいずれも**単純な入力値ファジング(fuzzing)**で検知可能なレベルだった
  • Microsoftには、このような反復的欠陥について公開での説明と透明なセキュリティレビュー手続きの強化が求められる
  • 管理者とセキュリティ担当者は、ログのクロス検証とKQLベースの検知ルールによって防御体制を補強する必要がある

関連記事

1件のコメント

 
GN⁺ 2026-03-22
Hacker Newsのコメント

  • CISAが公表したMicrosoft侵害事件報告書を思い出す
    国家支援ハッカーがMicrosoftを突破し、米国務省など複数の機関に侵入した事件だった
    驚くべきなのは、Microsoftではなく国務省のシステム管理者がメールログの異常を発見し、侵入を見つけたことだ
    CISA報告書リンク

  • ProPublicaとArsTechnicaがAzureを真正面から批判した記事では、連邦サイバー専門家がMicrosoftクラウドを「ひどい」と表現したという
    記事リンク

    • 実際には、ある専門家がそう表現したのは文書の品質で、ProPublicaがAzure全体に拡大解釈したようだ
    • Arsは単にライセンス再掲載しただけだ
    • 私の知るAzureセキュリティエンジニアはほぼメンタル崩壊状態だ。約12人のうち半分は燃え尽き、残りは能力が低すぎる
    • BloombergやCNBCはこの件を取り上げていない。誰かメディアとのつながりで知らせてほしい

  • 今のサイバーセキュリティの状態は、文明全体が依存するシステムにしてはあまりに脆弱だ
    まるで穴の開いた船をダクトテープで塞いで大洋に出るようなものだ

    • さらに深刻なのは、業界がその穴を塞ぐと言いながら機関銃塔を増やそうとするような対応をしていることだ

  • SQLログに関する議論では、攻撃者が長すぎる入力を送り、カラム長超過でINSERTが失敗した状況に見える
    その結果、ログイン試行の記録が残らなかったという説明だ

    • 2つのサービスが別々に動く構造だった。検証サービスが失敗を検知してログサービスに記録を依頼したが、ログサービスが失敗しても検証サービスはそのまま応答を返していた
      認証フローがあまりに複雑に設計された構造的問題に見える

  • Azureの監査ログが実際の動作と異なる形で記録された経験がある
    クライアントシークレットを削除したところ、UIはBを消すと言っていたのに、APIはAだけを残すように動作した
    結局ログには私が実行したように記録されたが、実際にはシステムのバグだった
    この経験以降、Azureログだけでなく監査ログ全般への信頼が揺らいだ
    法廷で証拠として使うには危険だと思う

    • だから私は、変更前に確認ステップを必ず挟むUIを好む。「ビデオゲーム風」の自動保存インターフェースは危険すぎる
    • Azureポータル（新旧どちらも）はバグだらけなので驚きはない。ボタンを1つ押し間違えるだけで別のオブジェクトが変わることもある
    • この事例は、同時編集環境におけるset演算 vs delete演算の危険性を示す良い教育例だ。ログは正確だったが、UI設計が問題だった
    • 結局、ユーザーは単に意図を表明するだけで、実際の実行はフロントエンドが制御しているのだと思うと恐ろしく感じる

  • 最近のEntraID脆弱性と比べれば、ログ回避はそれほど重要ではないように見える

    • だが、重要な認証ログが単なる“best-effort”でしか動作しないなら、セキュリティ監査の根拠としては深刻な問題だ
    • 結局、成功してしかも秘匿された攻撃は、複数の脆弱性の連携によって成り立つものだ

  • MicrosoftはNotepadにさえ致命的な脆弱性を入れたことがあるので、こういう話も驚きではない

  • 以前Azure VPNを評価したとき、接続成功/失敗のログがまったく残らなかった
    問題提起するとMicrosoftは、「それを新機能リクエストとして登録してくれ」と言った
    あの時Azureへの信頼を完全に失った。時間が経っても改善せず、むしろ悪化しているように感じる

  • IT管理者がMicrosoftを使い続ける理由は、選択肢がないからだ

    • 私のように.NETベースのLOBアプリや各種SaaSを管理しなければならない環境では、Microsoftソリューションが最も現実的な選択だ
      予算も少なく人手も足りないので、ただ給料をもらって定時で帰れる程度に維持している
    • 若い管理者はMicrosoftを嫌う傾向が強い。世代差かもしれない
    • 「Nobody ever got fired for buying X」という言葉のように、Microsoftを選ぶのはキャリア上のリスクが小さい

  • MicrosoftがAzure脆弱性の再現に失敗して動画証拠を求めたとき、たった1行のcurlコマンドで示したという点が印象的だった
    本当に痛快な瞬間だった