Entra ID OAuth リダイレクト悪用で進むフィッシング攻撃

はじめに: なぜ重要なのか

Microsoft Entra ID のような広く知られた identity provider (IdP) への OAuth リンクは、ユーザーから信頼されやすく、場合によってはセキュリティ制御でも比較的寛容に扱われます。Microsoft の最新調査では、"仕様どおり"の OAuth リダイレクト動作が悪用され、正規のログインドメインから攻撃者のインフラへユーザーを誘導していることが明らかになりました。これにより、通常のサインイン フローに見せかけたまま、フィッシングやマルウェア配布が可能になります。

これは、観測された活動で特に標的となっていた政府機関や公共部門組織の IT 管理者にとって、特に重要な問題です。

新たな情報 / 主な調査結果

Microsoft Defender Security Research Team は、メール、ID、エンドポイントのシグナル全体で、OAuth リダイレクトの仕組みを悪用したフィッシング主導の攻撃を確認しました。

• silent OAuth flow の悪用: 攻撃者は prompt=none などのパラメーターを使って OAuth 認可 URL を作成し、silent な認証チェック（UI なし）を試みます。
• 意図的に無効な scope を指定してエラー経路を強制: リクエストには scope=<invalid_scope>（または他の失敗トリガー）が含まれ、確実に OAuth エラーを発生させます。
• エラー駆動で攻撃者管理下の URI にリダイレクト: IdP がエラー（たとえば interaction_required）を返すと、ブラウザーは アプリに登録された redirect URI にリダイレクトされます。攻撃者はこれをフィッシングページやマルウェア配布サイトに向けて設定します。
• リダイレクトにトークン窃取は不要: 攻撃者は必ずしも OAuth を正常完了させる必要はなく、主目的はリダイレクトそのものです。
• パーソナライズのための state parameter の悪用: 本来はリクエストとレスポンスの対応付けに使う state parameter が、被害者のメールアドレス（平文、hex、Base64、または独自エンコード）を渡す用途に転用され、フィッシングページ側で識別子を自動入力できるようにしていました。
• 攻撃キャンペーンの配信パターン: フィッシングの誘導文には、電子署名リクエスト、金融/社会保障関連のテーマ、ドキュメント共有、Teams/会議コンテンツ、パスワード リセット通知などが含まれていました。PDF 添付ファイルに埋め込みリンクを使う例や、.ics カレンダー招待を使う例も確認されています。
• 後続で使われるツール: リダイレクト先のページでは、認証情報や session cookie の窃取を狙う EvilProxy のようなフィッシング フレームワーク（attacker-in-the-middle）が多用され、CAPTCHA や中間ページが追加される場合もありました。

IT 管理者とエンド ユーザーへの影響

• クリック率上昇のリスク: リンクが信頼された IdP ドメイン（たとえば login.microsoftonline.com）から始まるため、ユーザーの安心感が高まります。
• 防御回避の圧力: 従来の URL レピュテーション チェックは初期ドメインに注目しがちで、最終的な遷移先を見逃す可能性があります。
• レイヤー横断の可視性が必要: Microsoft は email、identity、endpoint をまたいで Defender がシグナルを相関分析したと説明しており、単一の制御だけでは検知が不十分な可能性を示しています。
• 継続中の脅威: Microsoft Entra は観測された悪意ある OAuth アプリを無効化しましたが、関連する活動は継続しており、監視は引き続き必要です。

対応項目 / 次のステップ

1. 不審な OAuth authorize パターンをログと proxy telemetry で探索。特に以下を確認します。
   • prompt=none と異常または無効な scope 値の組み合わせ
   • OAuth 失敗の頻発後に non-corporate domain へリダイレクトされる動き
   • 予期しない大量フィッシング文脈での /common/ の使用
2. アプリ同意と app registration を見直して制限:
   • 新規作成されたアプリと redirect URI を監査し、信頼できないドメインがないか確認する
   • Entra ID で、アプリ登録や redirect URI 変更を行えるユーザーをより厳格に制限する
3. 「信頼されたドメイン」チェックを超えるフィッシング対策を強化:
   • URL detonation / safe-link ツールがリダイレクト先まで追跡するようにする
   • 「Microsoft サインインから始まる」ことは安全の保証ではないとユーザーに教育する
4. Conditional Access と session control を検証:
   • サインインおよび OAuth エラーの telemetry を監視し、異常や標的ユーザー グループへの集中を確認する
5. Defender の相関分析を活用:
   • Microsoft Defender for Office 365 と Defender for Identity/Endpoint を活用し、メール誘導、サインイン動作、エンドポイント上の payload アクティビティを相関分析する。