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

完全な開示:第三(および第四)の「Azure」サインインログバイパスが発見されました

2026年3月20日原文(trustedsec.com)

概要

  • Azure Entra ID のサインインログバイパス脆弱性の詳細解説
  • GraphNinjaGraphGhost、さらに GraphGoblin など複数のバイパス手法の紹介
  • バイパス手法の利用で 完全なトークン取得ログ記録の回避 が可能だった事例
  • Microsoft による対策と、それまでのリスク
  • KQLクエリ による検知方法や今後の注意点も解説

Azure Entra ID サインインログバイパスの全貌(2023-2026)

  • 2023年以降、Azure Entra IDにて4件のサインインログバイパス脆弱性を発見
  • いずれも 認証試行がログに記録されず、管理者による侵入検知が困難となる問題
  • GraphNinja :他テナントIDを指定し、パスワード検証のみ実施、ログ記録回避
  • GraphGhost :無効なClient ID指定で認証フロー失敗、パスワード検証は実施、ログには失敗のみ記録
  • GraphGoblin :scopeパラメータに同一値(例:openid)を大量指定し、SQLカラム長をオーバーフローさせてログ記録を失敗させる手法
  • いずれも OAuth2 ROPCフロー を利用し、curlなどで簡単に再現可能

主要バイパス手法一覧

| 名称 | 報告日 | 修正日 | 概要 | |--------------|-------------|-------------|-------------------------------------------------------| | GraphNinja | 2023年8月 | 2024年5月 | 外部テナントID指定でパスワード検証、ログ非記録 | | GraphGhost | 2024年12月 | 2025年4月 | 無効Client IDで認証失敗、パスワード検証は実施、ログ非記録| | GraphGoblin | 2025年 | (修正済) | scopeパラメータの繰り返し指定によるSQLオーバーフロー |

GraphNinja・GraphGhostの技術概要

  • GraphNinja

    • 認証エンドポイントに 他テナントのGUID を指定してPOST
    • 成功/失敗ログがどちらのテナントにも記録されない
    • パスワード検証の可否のみ取得可能、トークンは取得不可
  • GraphGhost

    • 無効なClient ID を指定し、パスワード検証後に認証フロー失敗
    • 管理者には単なる失敗ログとしてしか見えず、成功したパスワード推測は不可視
    • トークンは取得不可、パスワード検証結果のみ判別可能

GraphGoblinの詳細

  • scopeパラメータ に同じ値(例:openid)を 1万回以上繰り返し 指定
    • 例:scope=openid openid openid ...(1万回以上)
  • Azureの認証APIはscope値のバリデーションを形式のみで実施
  • scope値がSQLのカラム長を超えることで ログ記録用INSERTが失敗
  • 結果として サインインログに一切記録されず、完全なトークンを取得可能
  • 攻撃者は痕跡を残さずアカウント乗っ取りが可能 となる重大リスク

実証例(curlコマンド)

export TENANT_ID="[tenant-guid-goes-here]"
curl -X POST "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "client_id=f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" \
  --data-urlencode "client_info=1" \
  --data-urlencode "grant_type=password" \
  --data-urlencode "username=ユーザー名" \
  --data-urlencode "password=パスワード" \
  --data-urlencode "scope=$(for num in {1..10000}; do echo -n 'openid ';done)"

原因推測

  • SQLカラム長のオーバーフロー によるINSERT失敗が主因と考察
  • scope値の形式バリデーションは十分でも、内容の繰り返しや長さ制限が不十分
  • Microsoft内部のセキュリティレビュー やテストケースの網羅性に課題

実際のログ検証

  • 通常の失敗ログ・成功ログと GraphGoblinバイパス利用時のログを比較
    • GraphGoblin利用時のみ 完全にログが記録されていない ことを確認
  • Log Analytics でも該当イベントが一切記録されていないことを証明

Microsoftの対応

  • 2026年時点で全てのバイパスは修正済
  • 追加のバリデーションログ記録強化 が実施済み
  • 今後も 新たなバイパス手法が発見される可能性 に注意

管理者・SOC向けアドバイス

  • KQLクエリ 等で不審な認証フローやログギャップを監視
    • 例:連続するCorrelation IDや時刻でログ抜けを検出
  • サインインログの整合性確認異常値の分析 を定期的に実施
  • Microsoftのセキュリティアドバイザリ や脆弱性情報を継続チェック

今後の課題と備え

  • クラウド認証基盤のログ信頼性確保 が最重要課題
  • 過去のバイパス事例 から学び、 未知の脆弱性 への備え強化
  • ユーザー教育多層防御の徹底

Hackerたちの意見

昨日、ProPublicaとArsTechnicaがAzureについての批判記事を出したよ。「連邦のサイバー専門家たちはMicrosoftのクラウドを『クソの山』と呼んだけど、それでも承認した」... https://arstechnica.com/information-technology/2026/03/feder...

ある専門家が提供されたドキュメントを「クソの山」と呼んで、それをProPublicaがAzure自体にまで広げたんだ。

Arsはライセンスの下で再発行しただけだよ。

知ってるAzureのセキュリティエンジニアは、今の状況で自傷行為寸前か、もしくは出会った中で一番頭の悪いICで、セキュリティエンジニアになるべきじゃなかったと思う。サンプルサイズは約12人。

BloombergやCNBCはこれについて報道してないみたいだけど、誰かコネのある人が知らせてあげられないかな?

ログをバイパスすることは、最近見たEntraIDの脆弱性に比べると、あんまり重要じゃない気がする。

成功して気づかれない攻撃をするには、いろんなエクスプロイトが必要だね。

これ、CISAの報告書を思い出させるな。州が支援するグループがMicrosoftに侵入して、さらに国務省や他のいくつかの機関に入ったってやつ。まるで強盗映画みたいだよ。 https://www.cisa.gov/sites/default/files/2024-03/CSRB%20Revi... その話で一番驚いたのは、侵入を発見したのがMicrosoftじゃなくて、国務省のシステム管理者だったってこと。メールログにおかしな点があって調べたらしい。

心配しないで、CISAや他の関係する規制当局はDOGEにやられたから。

ああ、そういえば、アメリカが実際にサイバー防衛を持っていて、各分野で働ける専門家がいた頃のことだね。

確か、(報告したかどうかは覚えてないけど)Azureの監査ログは、UIからクライアントシークレットを削除するときに現実を反映してないんだよね。問題を正しく覚えていれば、クライアントシークレットが消えちゃって、誰がやったのか監査ログを見に行ったら、私がやったことになってた。でも、私はやってないって知ってた。結局、古いページの読み込みにバグがあったことがわかったんだ。ページが読み込まれたときには「A」と「B」のシークレットしかなかったのに、「B」を削除するアイコンをクリックしたら、Azureは「B」と「C」を削除しちゃったんだ… これはページの読み込み以降に追加されたものだった。要するに、UIは「この行を削除」と言ってたけど、APIは「シークレットのセットを{A}に設定」となってた。監査ログはAPIを「正しく」記録してたけど、私が何をしたのかという現実的な観点からは全く間違ってた。なんとか解決できたけど、Azureのログに対する信頼が揺らいだし、監査ログ全般にも少し疑念を持つようになった。人間が何をしたのかをちゃんと監査しているか確認しないとね。逆に、監査ログを使って推論しようとするなら、どうやって生成されたのかを理解しておくべきだと思う。もし私が陪審員だったら、監査ログを裁判で受け入れることは絶対にないね。監査ログがホットな嘘であることは、合理的な疑いの範囲内だし。

それはクレイジーだし、かなりいい指摘だね。ループ内の人間は実際に何が行われるかをコントロールしてるわけじゃなくて、フロントエンドに意図を伝えるだけなんだ。

Hacker Newsで議論の続きを見る