多要素認証（MFA）の導入は、セキュリティ対策として非常に有効です。
実際、
Microsoft の調査では MFA を有効にすることで 99.9%以上のアカウント侵害の試みを防止できる と報告されています。
しかしここに、大きな落とし穴があります。
MFA の普及が進むにつれて、攻撃者は MFA を突破する新たな手口を開発しました。
それが「AiTM（Adversary-in-the-Middle）フィッシング攻撃」です。
スマートフォンの認証アプリで生成した 6 桁のコードも、この攻撃の前では無力化されてしまう可能性があります。
本記事では、AiTM 攻撃の仕組みを解説し、本当に強固な「フィッシング耐性のある認証」とは何かを紹介します。
AiTM 攻撃とは何か？— MFA コードを”リアルタイム”で盗む手口
通常の MFA が突破されるメカニズム
AiTM（中間者）攻撃の流れは以下の通りです。
[被害者] → [偽のログイン画面 (攻撃者のプロキシサーバー)] → [本物のサービス]
- 攻撃者は、本物そっくりの偽ログインサイトを用意する
- フィッシングメールなどで被害者をその偽サイトに誘導する
- 被害者が ID・パスワードを入力すると、攻撃者のプロキシがリアルタイムで本物のサービスに転送する
- 本物のサービスが MFA を要求すると、偽サイトが同様に MFA 入力画面を表示する
- 被害者が認証アプリの 6 桁コードを入力すると、攻撃者がそれを即座に本物のサービスへ転送して認証を完了させる
- 攻撃者は認証済みのセッショントークン（Cookie）を入手し、以後はパスワードも MFA も不要で被害者のアカウントにアクセスできる
ポイントは、攻撃者は認証情報を「保存」するのではなく「中継」しているという点です。
TOTP（時間ベースのワンタイムパスワード）は有効期限が 30 秒程度しかありませんが、リアルタイムの中継であれば十分間に合います。
AiTM 攻撃耐性と MFA の種類
以下は、認証方式と AiTM 攻撃耐性です。
| 認証方式 | AiTM への耐性 | 理由 |
|---|---|---|
| SMS ワンタイムパスワード | ❌ 脆弱 | コードをリアルタイムで中継可能 |
| 認証アプリの TOTP（6 桁コード） | ❌ 脆弱 | コードをリアルタイムで中継可能 |
| プッシュ通知（承認ボタン） | △ 限定的 | Number Matching などの追加情報によりユーザーが不審に気付きやすい |
| FIDO2 / パスキー | ✅ 耐性あり | オリジン（ドメイン）にバインドされた暗号認証 |
| 証明書ベース認証（CBA） | ✅ 耐性あり | 公開鍵証明書による暗号認証 |
| Windows Hello for Business | ✅ 耐性あり | デバイスにバインドされた暗号認証 |
被害事例：「0ktapus」
2022年、「0ktapus」と呼ばれる大規模 AiTM フィッシングキャンペーンが複数の著名企業を標的にしました。
偽の SMS でフィッシングサイトに誘導し、ID・パスワードと MFA コードをリアルタイムで盗み取る手口が使われました。
この事件では、採用していた MFA の種類によって被害の明暗が分かれました。
物理的な FIDO2 セキュリティキーをすべての従業員に義務付けていた組織では、攻撃が成功しなかった一方、従来型 MFA のみを使用していた組織では認証が突破されました。
Microsoft もこの種の攻撃を継続的に観測・分析しております。
本当に強固な認証とは — 「フィッシング耐性のある MFA」
Microsoft Entra ID では、認証方式をフィッシング耐性の有無で明確に区別しています。
なぜ FIDO2 / パスキーはフィッシングに強いのか？
FIDO2 / パスキーが AiTM 攻撃を防げる理由は、認証がオリジン（ドメイン名）に暗号的にバインドされているからです。
通常の TOTP コードは「どのサイトへのログインか」に関係なく使える汎用的な数値です。
しかし FIDO2 認証では、秘密鍵を使った署名に接続先のドメイン情報が含まれます。
- 本物のサイト login.microsoftonline.com で認証 → ✅ 正しいオリジン、認証成功
- 偽サイト login.attacker.com 経由で中継 → ❌ オリジンが一致しない、認証拒否
攻撃者が認証プロセスをプロキシしようとしても、偽サイトのドメインが本物のサービスに登録されたドメインと一致しないため、認証が失敗します。
攻撃者が入手できるのは無効な署名だけです。
証明書ベース認証（CBA）とは
証明書ベース認証（Certificate-Based Authentication: CBA）は、スマートカードや端末に格納された X.509 クライアント証明書を使用して認証する方式です。
PKI（公開鍵基盤）による 公開鍵暗号認証を利用するため、パスワードやワンタイムコードのような共有秘密情報が存在せず、中継型のフィッシング攻撃に対して強い耐性を持ちます。
特に、緊急アクセス（Break Glass）アカウントなど、パスキーの運用が難しいケースでも CBA は有力な選択肢です。
参考：Azure ポータル (および Azure CLI 等) の MFA 義務付けに関する更新情報 (2024/6/27)
Microsoft Entra ID で実践する「認証強度」の設定
Microsoft Entra ID の条件付きアクセスでは、「認証強度（Authentication Strengths）」という機能を使って、特定のリソースへのアクセスにフィッシング耐性のある MFA のみを許可するポリシーを設定できます。
組み込みの認証強度レベル
| 強度レベル | 対象の認証方式 |
|---|---|
| Multifactor authentication | すべての MFA 方式（TOTP 含む） |
| Passwordless MFA | パスワードレス認証（パスキー、Windows Hello for Business 等） |
| Phishing-resistant MFA | パスキー（FIDO2）、CBA、Windows Hello for Business のみ |
管理者は、重要なシステムやデータへのアクセス条件に「Phishing-resistant MFA」を指定することで、たとえ SMS や TOTP のみを登録しているユーザーがいても、そのアクセスを自動的にブロックできます。
段階的な移行戦略
すべてのユーザーを即日 FIDO2 に移行するのは現実的ではありません。
以下の優先順位で段階的に取り組むことを推奨します。
ステップ 1：まず「フィッシングに気づける」MFA へ
FIDO2 の導入前でも、Microsoft Authenticator アプリの数値一致（Number Matching）機能を活用することで、AiTM 攻撃を困難にできます。
- 認証要求元のアプリ名・場所・IP アドレスが画面に表示される
- ユーザーが「自分がログインしていない」と気づきやすくなる
- 不審な通知に「No, it’s not me」を押すと Entra ID Protection にリスクシグナルが送られる
ステップ 2：特権アカウントから FIDO2 / CBA を適用
管理者アカウントや重要システムへのアクセス権を持つユーザーから、フィッシング耐性のある認証方式へ移行します。
Microsoft も 2025 年 2 月より Azure Portal へのサインイン時に MFA を義務付けており、緊急アクセスアカウントには FIDO2 または CBA の利用を強く推奨しています。
ステップ 3：一般ユーザーへの Microsoft Authenticator パスキーの展開
Microsoft Authenticator アプリは、iOS および Android でデバイスにバインドされたパスキーをサポートしています。ユーザーが既にアプリを使っていれば、ハードウェアキーを別途購入する必要なく、フィッシング耐性のある認証へ移行できます。
また、組織が管理者側でセキュリティキーの登録をユーザーに代わって行える FIDO2 プロビジョニング API も提供されており、大規模展開を支援します。
参考：パブリック プレビュー: Microsoft Entra ID FIDO2 のプロビジョニング API
ステップ 4：条件付きアクセスで「Phishing-resistant MFA」を強制
段階的に移行が完了したユーザーから、条件付きアクセスポリシーで「Phishing-resistant MFA」を要求する設定に切り替えます。
これにより、フィッシング耐性のない認証方式は自動的にブロックされます。
まとめ
| 観点 | 従来の MFA（TOTP/SMS） | フィッシング耐性のある MFA（FIDO2/CBA） |
|---|---|---|
| パスワード漏洩 | ✅ 防御 | ✅ 防御 |
| AiTM フィッシング | ❌ 突破可能 | ✅ 高い耐性 |
| セッショントークン盗取 | ❌ 可能 | △ 完全防御ではないが 攻撃難易度が高い |
| ユーザーの利便性 | 〇 普及済み | ◎ パスキーは生体認証で簡単 |
| 導入コスト | 低い | 中〜高（ハードウェアキーの場合） |
MFA の導入は今や最低限の対策です。攻撃者はすでに MFA を前提とした攻撃手法を持っています。
これからは 「MFA を入れているか」ではなく、「どの MFA を使っているか」 が問われる時代です。
FIDO2 / パスキーと証明書ベース認証を中心としたフィッシング耐性のある認証方式への移行を、ぜひ計画的に進めてください。
免責事項：Microsoft 365の機能や仕様は変更される可能性がありますので、実施前には最新の公式ドキュメントをご確認ください。
