Microsoft OAuthリダイレクト悪用フィッシングの新潮流：正規ログイン画面を踏み台にマルウェアまで到達する手口と対策

「リンク先がMicrosoftだから大丈夫」──その前提を崩すフィッシングが増えています。OAuthの“仕様どおり”のリダイレクト挙動を逆手に取り、正規の認証ページを経由して攻撃者のサイトへ飛ばし、認証情報の窃取だけでなくマルウェア感染まで狙うのが特徴です。ここでは、攻撃の流れ・狙い・見抜きづらい理由を整理し、組織と個人が今日から取れる実践的な防御策までまとめます。 microsoft.com+1

• Microsoft OAuthリダイレクト悪用フィッシングの新潮流：正規ログイン画面を踏み台にマルウェアまで到達する手口と対策
  • 何が起きているのか：OAuthの「エラー時リダイレクト」を悪用
  • 典型的な攻撃シナリオ：メールから端末乗っ取りまで
    • 1) フィッシングメールでクリックさせる
    • 2) 正規のOAuth認証エンドポイントへ誘導（ここで安心させる）
    • 3) わざと失敗するパラメータで“エラー遷移”を起こす
    • 4) 転送先で二次被害：認証情報の奪取か、マルウェア配布
  • 「トークンを盗まない」のに危険な理由
  • なぜ見抜けないのか：従来の「リンク確認」対策が効きにくい
  • 守る側が取るべき実務対策（今日からできる順）
    • 1) OAuthアプリのガバナンスを強化する（最優先）
    • 2) メールからの侵入口を狭める
    • 3) 端末側で“実行”を止める
    • 4) サインイン体験の“安心感”を悪用されない運用
  • まとめ：OAuthは便利、だからこそ「信頼の連鎖」を監視する

何が起きているのか：OAuthの「エラー時リダイレクト」を悪用

OAuthは、Microsoft/GoogleなどのID基盤を使って他サービスに安全にサインインするための標準的な仕組みです。そしてOAuthには、特定条件（とくにエラー時）に“指定された戻り先（redirect URI）へ転送する”挙動があります。攻撃者はこの正当な挙動を利用し、認証処理をわざと失敗させてエラー遷移を発生させ、そこから攻撃者が用意したページへ誘導します。 microsoft.com

ここがポイントは「脆弱性を突く」というより、「仕様に沿った動き」を“踏み台”として使う点です。セキュリティ製品や利用者が「ログインドメインが正規＝安全」と判断しがちな心理・ロジックをすり抜けます。 Help Net Security+1

典型的な攻撃シナリオ：メールから端末乗っ取りまで

観測されている流れは、大まかに次のステージで説明できます。 microsoft.com

1) フィッシングメールでクリックさせる

誘導文面は業務っぽさ全振りです。電子署名依頼、Teams会議の録画共有、Microsoft 365のパスワードリセット、行政・公共系に刺さるテーマ（社会保障・政治的話題など）を混ぜ、受信者に「急いで開く理由」を与えます。リンクを本文に埋めるだけでなく、PDF添付の中に誘導URLを入れ、メール本文を空にする例も確認されています。 microsoft.com+1

2) 正規のOAuth認証エンドポイントへ誘導（ここで安心させる）

クリック直後は、Microsoft Entra ID などの正規ログインURLが開かれます。ユーザーは「Microsoftのログイン画面に見える」ため警戒が緩みます。 ザ・レジスター

3) わざと失敗するパラメータで“エラー遷移”を起こす

攻撃リンクは、OAuthのパラメータを細工して認証を成功させるのではなく、失敗させる設計です。たとえば prompt=none と不正な scope を組み合わせ、サイレント認証を要求しつつ確実にエラーに落とす、といった手口が紹介されています。エラー後の仕様により、登録済みのredirect先（攻撃者管理）へブラウザが転送されます。 microsoft.com+1

4) 転送先で二次被害：認証情報の奪取か、マルウェア配布

転送後は大きく2パターンです。

• フィッシング・アズ・ア・サービス（PhaaS）へ接続
  EvilProxyのような“攻撃者が間に入る”仕組みへ飛ばし、資格情報やセッションクッキーを奪います。CAPTCHAや中間ページでセキュリティ検知をかわす構成も典型です。 microsoft.com+1

• マルウェア配布
  自動でZIPを落とし、LNKショートカットやHTML smuggling（ブラウザ側でファイル生成して落とす）などで実行に誘導します。ある例では、PowerShellで調査コマンドを実行 → 正規EXEを悪用してDLLサイドロード → 追加ペイロードをメモリ実行 → C2へ通信、という“端末制圧”の流れが説明されています。 microsoft.com+1

「トークンを盗まない」のに危険な理由

OAuth悪用＝アクセストークンを奪う、というイメージが先行しがちですが、この手口は「トークン窃取が主目的ではない」ケースがあるのが厄介です。認可が成立していない（ユーザー同意がない）ためトークンは取れない一方、**正規ドメイン経由で“攻撃者サイトに到達させる導線”**としてOAuthが利用されます。結果として、情報窃取よりも直接的なマルウェア感染・端末乗っ取りに繋がります。 microsoft.com+1

なぜ見抜けないのか：従来の「リンク確認」対策が効きにくい

従来の啓発は「URLを見て怪しいドメインなら開くな」でした。しかしこの攻撃は、最初に開くのが正規の認証URLであることが多く、ユーザー教育だけでは止めにくい。さらに、攻撃者はredirect先を頻繁に切り替えられるため、ブロックリスト型の防御も追いつきにくい構造です。 microsoft.com+1

守る側が取るべき実務対策（今日からできる順）

ここからは“手口に刺さる”対策だけを、優先度順に並べます。

1) OAuthアプリのガバナンスを強化する（最優先）

• ユーザーによるアプリ同意（consent）を制限し、例外は申請制にする

• テナント内のアプリ登録・権限を定期棚卸しし、不要・過剰権限を削除

• 不審なアプリ/サービスプリンシパルの作成やリダイレクトURI変更を監視・アラート化
  この手口は“OAuthアプリとredirect先”が中核なので、管理面の強化が最も効きます。 microsoft.com

2) メールからの侵入口を狭める

• PDF添付内リンクも含めてURL抽出・検査（サンドボックス/URLリライト）

• 「会議録画」「署名依頼」「パスワード期限」などの業務ルアーを想定したルールチューニング

• 大量送信ツール由来・クラウドVM送信などの特徴を踏まえた検知強化
  攻撃はほぼメール起点なので、ここを硬くすると成功率が落ちます。 microsoft.com+1

3) 端末側で“実行”を止める

• LNKの不審実行、PowerShellの怪しい引数、tar を使った展開などをEDRで検知

• ダウンロード直後のZIP展開→ショートカット実行の連鎖を遮断

• 署名済み正規EXEの悪用（DLLサイドロード）を前提に、振る舞い検知を重視
  マルウェア配布型は「最後に実行させる」必要があるため、端末制御が効きます。 microsoft.com+1

4) サインイン体験の“安心感”を悪用されない運用

• 「正規ログイン画面が出た後に別ドメインへ飛ぶ」挙動を社内教育で明確にNG化

• MFA導入だけで満足せず、セッションクッキー窃取（AiTM）を想定して条件付きアクセスやリスクベース制御を併用

• 重要システムはフィッシング耐性の高い認証（FIDO2等）も検討
  PhaaS型はMFAをすり抜ける設計が多いので、“MFAさえあれば安心”を捨てるのが重要です。 microsoft.com+1

まとめ：OAuthは便利、だからこそ「信頼の連鎖」を監視する

今回の潮流は、OAuthそのものを危険視する話ではありません。問題は、攻撃者が“仕様どおりのリダイレクト”を使って、正規ドメインの信頼を連鎖させ、最終的に攻撃者の配布基盤へ到達させる点です。防御側は「リンクが正規ドメインに見える」だけで許可しない設計へ切り替え、OAuthアプリの統制・メール検知・端末での実行阻止を組み合わせることで、被害を現実的に抑えられます。 microsoft.com+2Help Net Security+2