OAuthリダイレクト悪用フィッシングとは何か：正規ログイン画面を経由して防御をすり抜ける新手口と対策
2026年に入り、「正規のOAuthログインの流れ」を逆手に取って、メールやブラウザの防御をすり抜けるフィッシングが目立っています。従来の“偽ログイン画面でID・パスワードを盗む”型と違い、リンク先の見た目が正規に見えやすく、しかも検知ロジックの盲点を突きやすいのが厄介な点です。この記事では、攻撃の仕組みと見抜き方、組織・個人それぞれが今すぐできる防御策を、手順ベースで整理します。
OAuthリダイレクト悪用フィッシングの要点
OAuthは、Microsoft 365やGoogle Workspaceなどのサービスで「外部アプリに権限を渡す」ために広く使われる仕組みです。通常は、利用者がログインし、同意（Consent）画面で権限を許可すると、指定された“リダイレクト先（redirect URI）”へ戻る流れになります。
今回のタイプは、ここで発生するリダイレクトを悪用します。攻撃者は、正規ドメイン上のOAuth関連URLや挙動を“踏み台”にし、最終的に被害者を攻撃者管理のページへ誘導します。ポイントは、入口が正規に見えやすいことです。メールゲートウェイやブラウザの保護機能が「最初に開いたドメイン」を重視している場合、そこで判定が甘くなり、次の遷移で危険サイトへ飛ばされる構図が成立します。
どうやって「防御を回避」するのか
この手口が厄介なのは、攻撃者が真正面から“偽サイト一本釣り”をしないところです。典型的には次のような流れになります。
-
フィッシングメール（例：Teamsの録画共有、パスワードリセット、請求書、セキュリティ通知など）でクリックを誘導
-
クリック先は一見「正規の認証フロー」や「OAuthに関連するURL」で、レピュテーション（評判）検知を抜けやすい
-
OAuthの仕様上の遷移やエラー処理、同意画面、あるいは条件付きのリダイレクトを利用し、最終的に攻撃者の配布ページへ到達
-
そこでマルウェア配布、偽ログイン、HTMLスモーリング、LNK/ZIP経由の実行誘導などに繋げる
つまり防御側から見ると、正規ページ→（仕様の範囲の遷移）→悪性サイトという段階構造になり、途中で「正規の手続き」を挟むことで検知を鈍らせます。
被害パターン：アカウント侵害だけでは終わらない
OAuth絡みの攻撃というと「同意を取られてSaaS権限を奪われる」印象が強いですが、近年はそれに加えて**端末感染（マルウェア）**に繋げる例が増えています。被害は大きく分けて3系統です。
-
端末感染型
ダウンロード誘導からZIP/LNK、HTMLスモーリング、署名付きの偽アプリなどを経由して感染し、遠隔操作ツールやバックドアで永続化する。 -
認証情報・セッション奪取型
最終到達点で偽ログインを実施し、ID/パスワードやMFA疲労攻撃（連打）に誘導する。 -
OAuth同意・トークン悪用型
利用者に「権限付与」を許可させ、メール・ファイル・連絡先などに継続アクセスする（パスワード変更後も影響が残る場合がある）。
企業で怖いのは、最初の入口が一人でも、SaaS内のメール転送ルール作成、共有リンク乱発、内部フィッシングの横展開などで被害が急拡大する点です。
見抜くためのチェックポイント（利用者向け）
攻撃は巧妙ですが、“最後のひと押し”の場面で違和感が出やすいです。次の観点で確認してください。
-
メールの用件が「急がせる」「今すぐ確認」「本日中に無効化」など焦らせていないか
-
リンク先が正規ドメインに見えても、遷移後の最終URLが不自然ではないか（見慣れないドメイン、短縮URL、多段リダイレクト）
-
「ファイルを開く」「ZIPを解凍」「ショートカット（.lnk）を実行」「HTMLを開く」など、業務上不要な操作を求められていないか
-
同意画面が出た場合、アプリ名・発行元・要求権限（メール閲覧、全ファイルアクセス等）が過剰ではないか
“正規ログイン画面を一度見た”こと自体は安全の証明になりません。最終的に何をさせようとしているかで判断するのがコツです。
管理者が優先してやるべき対策（Entra ID / Microsoft 365想定でも通用する考え方）
この手口は「メール」「ID」「端末」の境界をまたいで成立するので、どこか一つだけ強化しても抜けられます。優先度順にまとめます。
1) OAuthアプリと同意（Consent）の統制
-
ユーザーによるアプリ同意を無制限にしない（許可制・審査制へ）
-
既存の同意済みアプリを棚卸しし、不要なアプリや過剰権限を剥奪
-
高リスク権限（メール読み取り、全ファイル、オフラインアクセス等）の要求を監視・アラート化
2) 条件付きアクセスと高リスクサインインのブロック
-
未管理端末・未知の場所・匿名ネットワークからのサインイン制限
-
リスクの高いサインインを自動遮断、あるいは追加認証要求
-
“普段と違う”行動（短時間に多地点、異常な同意イベント）を検知できる設定へ
3) メール防御は「URLの最終到達点」前提で
-
多段リダイレクトを解決して評価するURL保護（サンドボックス、時間差リライト等）
-
“正規ドメインを踏む”ケースを想定し、本文の文脈・添付・誘導行為（実行指示）を重く見る
-
監査ログで、同じ件名・同じ誘導文の波状攻撃を早期に可視化
4) 端末側で“実行させない”
-
LNK、HTA、不要なスクリプト実行、危険な添付拡張子を制限
-
ダウンロード直後の実行や未知署名アプリの起動をブロック
-
ブラウザ隔離や、業務用アカウントの利用ブラウザを固定する運用も有効
インシデント対応の勘所：疑ったらどこを見るか
疑わしいメールが一通でも見つかったら、調査は「受信者の端末」だけで終わらせないのが重要です。
-
クリックしたユーザーのサインイン履歴（場所、端末、時間）
-
同意（Consent）やアプリ登録のイベント、権限付与の痕跡
-
メールの転送ルール、不審な受信トレイル（内部へのばらまき）
-
端末のダウンロード履歴、ZIP展開、LNK実行、未知プロセスの起動
被害が小さく見えても、OAuth絡みは“あとから効いてくる”ことがあります。パスワード変更だけで安心せず、同意済みアプリとトークンの扱いまで確認するのが鉄則です。
まとめ：正規フローを装う時代の新しい警戒ポイント
OAuthリダイレクト悪用のフィッシングは、「最初が正規に見える」ことを武器に、メール・ブラウザ・ID管理の隙間を通ってきます。対策の要は、(1)同意とアプリ権限の統制、(2)リスクベースのサインイン制御、(3)URLの最終到達点を前提にしたメール防御、(4)端末で実行させない、の四本柱です。
日々の運用では、「リンクを踏ませた後に何をさせるか」に注目し、ZIP/LNK/HTML実行の誘導や過剰権限の同意が出た時点で止める。ここを徹底するだけでも、被害確率は大きく下げられます。
