多要素認証（MFA）を導入したから安心、と思っていませんか。実は近年、MFAを突破する攻撃手法が現場で急増しています。その中でも特に注意が必要なのが「AiTM（Adversary-in-the-Middle）フィッシング」です。
AiTMフィッシングは、従来の偽サイト型フィッシングとは仕組みが根本的に異なります。攻撃者が”中継役”のプロキシサーバーを挟むことで、被害者が正規サービスへの認証を完了した後のセッション情報まで盗み取れます。ワンタイムパスワード（OTP）やプッシュ通知型のMFAでさえ、この手口の前では無力化されます。
この記事では、AiTMフィッシングの仕組み・攻撃フロー・セッション窃取の原理と、企業が今すぐ取れる防御策を現場目線で解説します。
AiTMフィッシングとは？
AiTM（Adversary-in-the-Middle）フィッシングとは、攻撃者が用意したリバースプロキシサーバーを経由させることで、被害者と正規のWebサービスの間の通信を中継し、セッションクッキーを盗み取る攻撃手法です。
従来の「偽サイトにIDとパスワードを入力させる」フィッシングとは異なり、AiTMでは被害者は本物のサービス（Microsoft 365やGoogle Workspaceなど）に実際にログインします。この”実際のログイン”がポイントで、ログイン完了時にサービスが発行するセッションクッキーもプロキシを経由するため、そのまま攻撃者に窃取されてしまいます。
なぜMFAが突破されるのか
OTPやプッシュ通知型のMFAは、「ログイン時に正しい認証要素が揃っているか」を確認します。ところがAiTMでは、被害者は正規サービスに対して正しく認証を完了します。その結果発行されたセッションクッキーを攻撃者が横取りするため、「MFAで保護されたアカウントでも乗っ取られる」という状況が生まれます。
認証後のセッション管理を狙う点が、AiTMを従来のフィッシング対策と区別して考えなければならない理由です。
攻撃の仕組み（フローを理解する）
AiTMフィッシングの典型的な流れを整理します。
ステップ1：フィッシングメールで誘導
被害者に「ファイルが共有されました」「アカウントを確認してください」といった内容のメールを送り、攻撃者が用意したプロキシサイトへ誘導します。URLは正規ドメインに似せた独自ドメインが使われる傾向があります。
ステップ2：プロキシ経由でリアルタイム中継
プロキシサイトは被害者の入力と操作を本物のサービスへリアルタイムで転送します。被害者の画面には正規サービスのログインページが表示されます。攻撃者のサイトも正規のTLS証明書を取得できるため、ブラウザに鍵マークが表示されることがあります。
ステップ3：MFAを含む認証が完了し、セッションクッキーが盗まれる
被害者がOTPやプッシュ承認などのMFA認証を完了すると、正規サービスはセッションクッキーを発行します。このクッキーはプロキシを通過する際に攻撃者側でコピーされます。
ステップ4：盗んだクッキーでアカウントに侵入
攻撃者は窃取したセッションクッキーをそのまま別のブラウザで使用し、パスワードもMFAも不要で標的のアカウントへアクセスします。メールの盗み読み、ファイルのダウンロード、設定変更によるMFA無効化といった行動につながります。
一般に知られているツールキットとしてはEvilginx・Modlishka・Muraenaなどが公開されており、このような手法を用いた攻撃の報告が増えています。
具体的な防御手順
1. フィッシング耐性のある認証方式（FIDO2/パスキー）に移行する
AiTMフィッシングに対して現時点で最も確実な対策は、FIDO2規格に基づくパスキー（Passkey）またはハードウェアセキュリティキー（YubiKeyなど）の導入です。
FIDO2は「オリジン（アクセス先のURL）」に紐づいた認証情報を使います。攻撃者のプロキシドメインでは正規サービスのオリジンと一致しないため、認証情報の利用が原理的に不可能になります。この特性こそが、AiTMに対する根本的な対抗策となります。
・クラウドサービスのパスキー有効化: Microsoft 365、Google WorkspaceはFIDO2/パスキー対応済み。管理コンソールから有効化できる
・優先ユーザーの設定: IT管理者・経営層・経理担当など高リスクユーザーから先行導入する
・ハードウェアキーの場合: FIDO2対応のUSBセキュリティキーをIT管理者・特権アカウントへ配布する
2. 条件付きアクセス・デバイスコンプライアンスを設定する
FIDO2への全社移行がすぐには難しい場合、「登録済みデバイスからのみログインを許可する」条件付きアクセスポリシーが有効な補完策になります。
・Microsoft Entra ID（旧Azure AD）: 「デバイスコンプライアンス準拠」または「Entra Joinデバイスのみ許可」ポリシーを設定する
・Google Workspace: コンテキストアウェアアクセス（Context-Aware Access）でデバイス証明書を要求する
盗まれたセッションクッキーを未登録の端末（攻撃者のPC）から使おうとしても、デバイス検証でブロックできます。ただし、被害者と同じ登録済みデバイスからの再利用には対応できない点は理解しておく必要があります。
3. セッション監視と異常検知を強化する
侵害後の横移動を早期に発見するため、ログ監視の強化も不可欠です。
・トークンリプレイアラートの有効化: Microsoft Entra ID Protectionの「セッショントークンのリプレイ（Token Replay）」検知を有効化する
・IPアドレスの急変検知: 認証直後に異なる国・地域からのアクセスが発生した場合、セッションを自動失効させるポリシーを検討する
・サインインログのSIEM転送: Entra IDのサインインログをSIEMへ転送し、不審なセッション継続を相関ルールで検知する
なお、AiTMはプッシュ通知を大量送信して誤承認を誘うMFA疲労攻撃と組み合わせて使われることがあります。MFA疲労攻撃への対策もあわせて確認しておくと、より包括的な防御につながります。
中小企業でも今日からできること
FIDO2の全社展開や高度なSIEM環境がすぐに整わない場合でも、以下のステップから着手できます。
・特権アカウントへのFIDO2優先導入: 全社展開前でも、IT管理者・経営層・経理担当などから先行して実施するだけで被害リスクを大幅に下げられる
・セッション有効期間の短縮: Microsoft 365のサインイン頻度（Sign-in frequency）設定でセッション有効期間を絞ることで、盗まれたクッキーの悪用可能時間を減らせる
・プロキシ型フィッシング訓練の実施: 訓練サービスの多くがAiTMプロキシ型URLに対応したメニューを提供している。クリックしてしまうユーザーを把握し、継続的な教育につなげる
・メールセキュリティの設定強化: Microsoft Defender for Office 365やGoogle Workspaceの高度なフィッシング対策を有効化し、AiTM関連インフラを含むURLを含むメールの検知感度を上げる
スピアフィッシング（標的型フィッシングメール）と組み合わせてAiTMを仕掛けてくるケースも報告されています。個人を狙う精度の高いメールへの社内意識を高めることも重要です。
よくある誤解と注意点
「SMS認証でも安全では？」
SMS OTPはAiTMに対しても突破されます。プロキシが中継している間に攻撃者側でOTPを取得・入力するか、リアルタイムで転送することで認証を完了できます。SMS認証はSIMスワップ詐欺とも組み合わせやすく、高リスクアカウントへの利用は推奨されていません。
「HTTPSだから安全では？」
攻撃者のプロキシサイトも正規のTLS証明書を取得でき、ブラウザに鍵マークが表示されます。HTTPS＝サイトの正当性の証明ではありません。URLのドメイン部分（オリジン）を慎重に確認する習慣が重要です。
「MFAを導入すれば十分では？」
OTPやプッシュ通知型のMFAはAiTMに対して無効化されます。「MFAを導入している＝フィッシング対策完了」という認識はリスクです。フィッシング耐性の高い認証方式（FIDO2/パスキー）への移行、または補完的な管理策との組み合わせが必要です。
本記事のまとめ
| 項目 | 内容 |
|---|---|
| AiTMの特徴 | リバースプロキシで認証を中継し、セッションクッキーを窃取 |
| なぜMFAが突破されるか | 被害者が正規サービスへ実際に認証を完了するため、OTP・プッシュ型MFAは無力 |
| 最も効果的な対策 | FIDO2/パスキー・ハードウェアキー（オリジン紐づきのため原理的に防御可能） |
| 補完的な対策 | 条件付きアクセス（登録済みデバイス限定）、セッション有効期限短縮、ログ監視強化 |
| SMS OTPの限界 | リアルタイム中継で突破可能。高リスクアカウントへの利用は推奨されない |
多要素認証を導入しているからと安心するのは禁物です。AiTMフィッシングはMFAという防御の前提を揺さぶる攻撃手法です。まずは特権アカウントへのFIDO2優先導入と、条件付きアクセスポリシーの見直しから着手しましょう。社内のフィッシング訓練もプロキシ型URLへ対応したメニューを選ぶことで、実践的な耐性を養えます。
