Microsoftが警告した「OAuthリダイレクト悪用」フィッシングとは何か：メール・ブラウザ防御をすり抜ける最新手口と今すぐできる対策

「正規のログイン画面に見えるのに、気づいたら不審なサイトへ飛ばされ、ZIPを落とさされる」──そんな“防御の隙間”を突く攻撃が現実に広がっています。Microsoftは、OAuthのリダイレクト機能が悪用され、従来のメール/ブラウザ対策を回避してマルウェア配布や認証情報窃取につながるキャンペーンを確認したとして注意喚起しました。Microsoft+1

• Microsoftが警告した「OAuthリダイレクト悪用」フィッシングとは何か：メール・ブラウザ防御をすり抜ける最新手口と今すぐできる対策
  • OAuthとは：便利さが攻撃面になる瞬間
  • 何が新しいのか：メールとブラウザの“王道対策”が効きにくい理由
  • 攻撃の流れ（観測された典型例）
  • 企業が最優先でやるべき対策（“クリック前/後”の両方で潰す）
    • 1) 添付・ダウンロード運用の再設計：ZIPとLNKを業務で許すか決める
    • 2) “OAuthを悪用した遷移”を前提に、条件付きアクセスと同意（Consent）を締める
    • 3) 入口はメール、出口はPowerShell：検知ポイントを“実行”側へ寄せる
  • 個人・現場メンバー向け：迷ったらこれだけ守るチェック
  • なぜ今この話が重要か：OAuth悪用は「理論」ではなく“運用されている攻撃”になった
  • まとめ：防御の主戦場を「リンク」から「実行と同意」へ移す

OAuthとは：便利さが攻撃面になる瞬間

OAuth（Open Authorization）は、他サービスのアカウントを使って「パスワードを渡さずに」外部サイトへログインできる仕組みです。いわゆる「Googleでログイン」「Microsoftでサインイン」の裏側で動く標準技術で、利用者はパスワード入力を減らせます。
一方で、ログイン手順の途中で“戻り先（リダイレクト先）”へ遷移させる機能があり、ここが今回の攻撃の足場にされました。Microsoft

何が新しいのか：メールとブラウザの“王道対策”が効きにくい理由

一般的なフィッシング対策は「怪しい送信元」「怪しいURL」「怪しいドメイン」などの特徴量に依存します。しかし今回の要点は、攻撃の入口が“正規のOAuthフローに見えるリンク”になり得ることです。
被害者がクリックするとOAuthが開き、パラメータを細工してエラーを起こし、その結果として“正規手順の一部”のように見える形で攻撃者管理のページへリダイレクトされます。これにより「リンク先を見て判断する」「ブラウザが危険サイトとして止める」タイプの防御をすり抜けやすくなります。Microsoft+1

攻撃の流れ（観測された典型例）

Microsoftが示した観測例は、公共部門・政府系組織などを狙い、業務文脈に溶け込むテーマを使います。Microsoft

1. フィッシングメール送付
   「Teams会議の録画共有」「Microsoft 365のパスワードリセット」など、受信者がクリックしやすい題材を採用。TechRadar+1

2. 細工されたOAuthリンクをクリック
   OAuthの画面を出しつつ、意図的にエラーへ誘導。

3. エラー後のリダイレクトで攻撃者サイトへ
   攻撃者が管理する“PhaaS（Phishing-as-a-Service）”系のページへ遷移し、ここでペイロード配布が行われます。ドメインが遮断されても、リダイレクト先を素早く差し替えられる点が厄介です。Microsoft

4. ZIPをダウンロード→ショートカット（LNK）/HTML Smugglingで実行誘導
   ZIP内のLNK（ショートカット）やHTML Smugglingローダーを起点に、PowerShell実行へつなげ、最終段で外部C2（指令サーバ）へ通信する流れが確認されています。TechRadar+2Microsoft+2

企業が最優先でやるべき対策（“クリック前/後”の両方で潰す）

1) 添付・ダウンロード運用の再設計：ZIPとLNKを業務で許すか決める

• メール経由でのZIP受領を原則禁止、例外は申請制に

• Windows環境でLNK（ショートカット）の実行を制限（少なくともメール/ダウンロード起点はブロック）

• 「請求書」「録画」「リセット」などの文脈でも、ZIP配布は原則クラウドストレージに限定（アクセスログが取れる経路に寄せる）

2) “OAuthを悪用した遷移”を前提に、条件付きアクセスと同意（Consent）を締める

• Microsoft Entra ID（旧Azure AD）側で、アプリ同意ポリシーを見直し

  • ユーザーが勝手に同意できる範囲を最小化

  • 不審なアプリ登録/同意を即時検知できる運用へ

• 条件付きアクセスで、高リスクサインインや未知の端末からの操作を追加認証・遮断に
  Microsoftは調査の過程で複数の悪性OAuthアプリを特定・削除したと述べており、アプリ起点の監視が重要です。Microsoft

3) 入口はメール、出口はPowerShell：検知ポイントを“実行”側へ寄せる

この手口は最終的に端末上の挙動（PowerShell、スクリプト、外部通信）に現れやすいのが特徴です。

• EDR/Defenderで PowerShellの不審実行、ショートカット起点、HTML Smuggling由来の動作を重点監視

• Webプロキシ/Firewallで 未知C2への通信、短命ドメイン、異常なリダイレクトチェーンを可視化

• 可能なら、メールのクリック時点ではなく端末上の実行を止める設計にする（攻撃者はリンクやドメインを回転させるため）

個人・現場メンバー向け：迷ったらこれだけ守るチェック

• 「Teams録画」「365リセット」でZIPを落とす導線は一度止まる

• ショートカット（.lnk）を「資料」だと思って開かない

• ブラウザで“ログインのエラー”が出た直後に、別ドメインのダウンロードが始まったら中断する

• 既に開いてしまった場合は、端末をネットワークから切り離してSOC/情シスへ連絡（後追いでC2通信や追加ペイロードが走る可能性があるため）Microsoft

なぜ今この話が重要か：OAuth悪用は「理論」ではなく“運用されている攻撃”になった

OAuthはクラウド業務の前提で、今後も使われ続けます。つまり「OAuthを使うな」では解決しません。重要なのは、

• 正規フローを装ったリンク遷移は“起きるもの”として扱う

• ドメイン遮断に頼り切らず、端末実行・同意・認証の3点で封じる
  この現実的な設計変更です。Microsoftも、OAuth機能の悪用が現実に確認されている点を強調しています。Microsoft+1

まとめ：防御の主戦場を「リンク」から「実行と同意」へ移す

今回のOAuthリダイレクト悪用は、クリック誘導の巧妙さ以上に「従来の防御の得意領域（怪しいURL判定）を外してくる」点が厄介です。
対策の要は、(1) ZIP/LNKなど実行導線の整理、(2) Entraの同意・条件付きアクセスの強化、(3) PowerShellや外部通信といった端末挙動で止める運用、の三本柱。これらを揃えると、攻撃者がドメインを回転させても“最後の一線”で被害を食い止めやすくなります。Microsoft+1