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

概要

Azure Entra ID のサインインログバイパス脆弱性の詳細解説
GraphNinja と GraphGhost、さらに 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のログに対する信頼が揺らいだし、監査ログ全般にも少し疑念を持つようになった。人間が何をしたのかをちゃんと監査しているか確認しないとね。逆に、監査ログを使って推論しようとするなら、どうやって生成されたのかを理解しておくべきだと思う。もし私が陪審員だったら、監査ログを裁判で受け入れることは絶対にないね。監査ログがホットな嘘であることは、合理的な疑いの範囲内だし。

└

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

└

だからこそ、こういう大きな影響を持つ変更の前には、ポジティブな確認ステップが大事だと思ってる。変更内容をユーザーに見せて、すべての変更がマークされている状態で、もう一度それが本当にやりたいことか確認してから、その内容だけが実行されるべきだよね。ああいう「ゲーム」みたいなインターフェースで、暗黙のセーブや裏でAPI呼び出しがあるのはめっちゃ危険だと思う。

└

あのウェブポータル（新ポータルやレガシーポータルも含めて）では、いろんなおかしなことが起きてるから、こういう問題には驚かないよ。ボタンをクリックするたびに、違うオブジェクトに間違ったことが起きるんじゃないかって心配になる。表示が最悪の結果を反映することもあって、例えばユーザーをグループに追加すると、新しいグループメンバーシップがその1人の新しいユーザーだけを含んでるように見えることがある。パニックになる瞬間が結構あるよ。

これを使って母校から自分のAzureアカウントにアクセスできるかも。卒業した直後にメールが削除されたけど、Microsoftは10年近く、（予約したIPか何かのことで）請求してきてる。サポートはもちろん役に立たないし。

でもここには大きなトレードオフがあるよね。IT管理者はMicrosoftを買うのが大好きなんだ。で、犬がドッグフードについて文句を言おうとすると、ドッグフードを買った人はあんまり理解してくれない傾向がある。

└

これって年齢の問題じゃない？若い管理者はMicrosoftを本当に嫌ってる気がする。もしくは、ただ私の知り合いのサークルだけかな？

└

「Xを買ったことで誰も解雇されたことはない」ってことを理解しないと、キャリアの階段を上るのは難しいよね。

いろんなスクリプトでデータベースにログを取ってきた経験から言うと、これはフィールドのSQLカラムの長さがオーバーフローして、INSERT全体が失敗した単純な問題だったと思う。これはデータベースを扱い始めたばかりの初心者がよく犯すミスだよ。この部分がよく分からないんだけど、自分の言葉で言い換えようとしてる。以下の内容は合ってる？攻撃者はあまりにも長い入力を提供したため、データベースに拒否された。そして、SQLクエリをデータベースに送信したプログラムには、クエリ失敗を処理するロジックがなかったから、ログや他の場所にログイン試行の痕跡が残ってないんだ。

└

それが私の理解だった。二つのサービスがあって、一つは検証、もう一つはログを取るやつ。検証が失敗をトリガーして、監査データベースに挿入するようリクエストするけど、監査ログサービスが失敗しても、バリデーターが攻撃者にレスポンスを返すのをブロックしないみたい。記事を読み進めるうちに、こういう認証/認可のフローが全体的に複雑すぎるって思っちゃう。必要なケースもあるのは分かるけど、それが大多数ではないと思う。

動画はちょっとしか見てないけど、リクエストの一つがたくさんの繰り返しデータを含むアクセストークンを返してるのを見て驚いた。base64デコードしたら、ただ「\uDFFF\uDBFF」が繰り返されてるだけだったから、さらにびっくり。これが彼のエクスプロイトからのデータだったのかも。アクセストークンにそれが含まれてるのはちょっと変だよね。音はミュートにしてたから、彼がそれについて言及してたかもしれないけど。

サイバーセキュリティの現状は冗談みたいだよね。文明全体がこれらのシステムに依存してるのに。まるで、すべてのものを穴の開いたボートに移して、ダクトテープで塞いで、オープンオーシャンに向かって航海を始めたみたい。馬車を前に持ってくるのを忘れるどころか、古い雌馬はまだ厩舎にいて、馬車は3つの郡先の溝にひっくり返ってる状態だよ。

マイクロソフトがメモ帳に致命的な脆弱性を導入したから、これには驚かないよ。

ハクソク