多要素認証を突破する中間者型フィッシング（AiTM攻撃）を防ぐ｜Microsoft Entra IDでフィッシングに強い認証と準拠端末を必須にする
中間者型のフィッシング（AiTM 攻撃）は、フィッシングに強い多要素認証と、準拠した端末の必須化で、大きく防げます。
AiTM 攻撃では、偽のサイトが本物の Microsoft のサインインを中継し、利用者が多要素認証を済ませたあとのセッションの Cookie を横取りします。攻撃者はその Cookie で入るため、多要素認証を求められません。Microsoft は「多要素認証の脆弱性ではない」とし、多要素認証は引き続き欠かせないと説明しています。
Microsoft は2022年に、この手口で1万を超える組織が狙われたと公表しました。多要素認証を全員に設定した組織でも、次の点は見落とされがちです。
- SMS・ワンタイムコード・プッシュ通知は、偽のサイトにそのまま中継されてしまう
- 強い方式を配っても、弱い方式でもサインインできる設定のままだと、攻撃者は弱い方を通す
- 被害に気づいてパスワードを変えるだけでは、奪われたセッションと、攻撃者が足した認証方法が残る
この記事では、攻撃の流れと、多要素認証を入れても突破される理由から始めて、認証強度での入口の塞ぎ方、準拠した端末と場所の条件、Microsoft Entra ID Protection と Microsoft Defender XDR での検知、乗っ取られたあとの対処までを、Microsoft Learn と Microsoft Security ブログの公開情報をもとに解説します。
株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。
AiTM 攻撃で奪われるもの｜パスワードと、サインインしたあとの Cookie
AiTM（Adversary-in-the-Middle）攻撃では、攻撃者が利用者と本物のサイトの間に、中継する偽のサイトを置きます。偽のサイトは本物の画面をそのまま映すので、見た目は本物と同じで、URL だけが違います。流れは次の4段階です。
- 誘い出す：請求書や共有ファイルの通知を装ったメールのリンクで、偽のサイトを開かせる
- 中継する：利用者が入力したパスワードと多要素認証を、偽のサイトが本物のサイトへそのまま渡す
- 横取りする：本物のサイトが発行したセッションの Cookie を、偽のサイトが手元に残す。利用者には本物の画面が返るので、気づきにくい
- 入り込む：攻撃者は奪った Cookie を自分のブラウザーで使い、利用者としてメールやファイルにアクセスする
入り込んだあとに起きること
Microsoft Security ブログは、入り込んだ攻撃者がメールボックスを足がかりに、取引先への請求書詐欺（ビジネスメール詐欺）へ進んだ例を報告しています。2023年の記事で取り上げた攻撃では、攻撃者は次のことをしていました。
- 電話番号によるワンタイムコードを、自分の認証方法として追加した（当時、認証方法の追加には既定で再認証が求められなかった）
- 受信トレイのルールで、届くメールをアーカイブへ移し、利用者に気づかれないようにした
- 乗っ取ったメールボックスから、取引先や社内へ1万6千通を超えるフィッシングメールを送った
一人の乗っ取りが、取引先を巻き込んだ次の被害の入口になります。防ぐ設定と、乗っ取られたあとの対処の両方を用意しておく必要があります。
（2026年11月更新）
補足：2026年3月、Microsoft は欧州刑事警察機構などと連携し、多要素認証を中継する仕組みを売っていた大手のフィッシング サービスの基盤を停止したと公表しました。このサービスは毎月50万を超える組織にメールを届けていたとされます。基盤が止まっても手口は残るため、この記事の対策の考え方は変わりません。
なぜ多要素認証を入れても突破されるのか
AiTM 攻撃は、多要素認証を「破る」のではなく、利用者に本物の多要素認証を済ませてもらい、その結果だけを奪います。Microsoft は、これは多要素認証の脆弱性ではないと明記したうえで、多要素認証は ID を守る欠かせない柱だと説明しています。多要素認証が要らなくなるわけではありません。
突破されるかどうかは、多要素認証の方式で分かれます。利用者が画面の表示を見て入力したり承認したりする方式は、偽のサイトがその画面を中継できるため、攻撃者に通されてしまいます。
| 多要素認証の方式 | AiTM 攻撃 | 理由 |
|---|---|---|
| SMS・音声通話 | ✕ 中継される | 届いたコードを、利用者が偽のサイトに入力する |
| 認証アプリのワンタイムコード | ✕ 中継される | 同じく、利用者が偽のサイトに入力する |
| 認証アプリのプッシュ通知（番号の一致を含む） | ✕ 中継される | 偽のサイトが本物の画面を映すので、利用者は本物と同じ通知を承認してしまう |
| パスキー（FIDO2）・Windows Hello for Business・証明書ベース認証 | ◎ 成り立たない | 認証のときにサインインする先を確かめるため、偽のドメインでは認証が成り立たない |
なお、本物の Microsoft のページでサインインさせ、その結果のトークンを奪う「デバイスコードフィッシング」という手口もあります。偽のサイトを使わないため、効く対策が異なります。
（2026年11月更新）
補足：Microsoft は、SMS と音声通話による多要素認証を2027年2月から順に廃止すると発表しました。移行の手順はMicrosoft 365の多要素認証を見直すで、デバイスコードフィッシングは多要素認証をすり抜けるデバイスコードフィッシングを防ぐで解説しています。
入口を塞ぐ｜認証強度で「フィッシングに強い多要素認証」を必須にする
パスキーなどを配るだけでは足りません。利用者が SMS などほかの方式も使える設定のままだと、偽のサイトはそちらを選ばせます。条件付きアクセスの「認証強度」で、使ってよい方式そのものを絞ります。条件付きアクセスには Microsoft Entra ID P1 が要り、Microsoft 365 E3 と Business Premium に含まれます。
認証強度には、Microsoft があらかじめ用意した「フィッシングに強い MFA」（Phishing-resistant MFA）があります。許可されるのは次の3つです。
- Windows Hello for Business
- パスキー（FIDO2 セキュリティ キー）
- 証明書ベース認証（多要素）
ポリシーは、許可の「認証強度が必要」でこの強度を選びます。同じポリシーの中で「多要素認証を要求する」と一緒には使えません。
管理者から始め、登録を済ませてから広げる
乗っ取られたときの被害が大きい管理者のアカウントから始めます。利用者全体に広げるのは、対象の人がパスキーなどを登録し終えてからです。登録していない人にこのポリシーが効くと、サインインできなくなります。
ポリシーはまず「レポート専用」で作り、サインイン ログで、まだ弱い方式でサインインしている人を洗い出します。緊急用のアカウントは除外しておきます。
認証方法の登録も守る
前の章の例のとおり、入り込んだ攻撃者は自分の認証方法を足して居座ろうとします。条件付きアクセスのユーザー操作「セキュリティ情報の登録」を対象にしたポリシーで、認証方法を登録するときにも、強い認証や社内のネットワークからの操作を求めておきます。
（2026年11月更新）
補足：認証強度のポリシーを、ほかのポリシーと矛盾なく、除外の漏れなく組み立てる方法は条件付きアクセスをポリシープランで整理するで解説しています。
奪われても使わせない｜準拠した端末と、場所を条件にする
フィッシングに強い多要素認証を全員に行き渡らせるには時間がかかります。その間の備えとして、Microsoft は、準拠した端末や信頼できる IP アドレスを条件にする条件付きアクセスで補うよう勧めています。攻撃者は奪った Cookie を自分の端末で使うので、組織が管理する端末や社内のネットワークからしか通さない設定が効きます。
- 準拠した端末を必須にする：Intune に登録し、コンプライアンス ポリシーを満たした端末からだけアクセスを許す。Intune Plan 1 は Microsoft 365 E3 と Business Premium に含まれる
- 場所を条件にする：社内や VPN の出口の IP アドレスを「ネームド ロケーション」に登録し、それ以外からのアクセスを止める
場所の条件は、継続的アクセス評価（CAE）に対応した Exchange Online・SharePoint Online・Teams では、サインインのあとも続けて確かめられます。許可していない場所から使われると、ほぼ即時にアクセスが止まります。そのためには、国や地域ではなく IP アドレスの範囲で場所を定義し、IPv4 と IPv6 の両方の出口を登録します。
私物の端末とゲストは、別に扱いを決める
準拠した端末を必須にすると、Intune に登録していない私物の端末や、取引先のゲストのアカウントは使えなくなります。誰をどの条件で通すかを先に決め、レポート専用で影響を確かめてから有効にします。
トークン保護は、ブラウザーの Cookie を守る機能ではない
条件付きアクセスには、端末に結び付いたトークンだけを受け付ける「トークン保護」という設定もあります。名前から AiTM 攻撃に効きそうに見えますが、対象は Windows などで動くネイティブ アプリです。Microsoft 365 をブラウザーで使うときの Cookie は対象にならないため、AiTM 攻撃への備えの中心にはなりません。
（2026年11月更新）
補足：トークン保護は現在、Windows・iOS/iPadOS・macOS のネイティブ アプリで一般提供と表記されています。ブラウザーでの利用はプレビューで、対象は Azure Resource Manager を使う一部の Web アプリに限られます。Microsoft 365 をブラウザーで使うときの Cookie は、引き続き対象外です。
見つけて止める｜ID Protection と Defender XDR の検知
入口を塞いでも、すべての利用者と端末が揃うまでは抜け道が残ります。奪われた Cookie が使われたことに、早く気づける仕組みを用意します。検知する製品と、必要なライセンスは次のとおりです。
| 製品 | AiTM 攻撃に関わる検知 | ライセンス（Learn の表記） |
|---|---|---|
| Microsoft Entra ID Protection | 「Attacker in the Middle」：悪意のあるリバース プロキシにつながったセッションを見つけ、ユーザーのリスクを「高」にする。精度の高い検出で、オフラインで計算される | Microsoft 365 E5 と Enterprise Mobility + Security E5 |
| Microsoft Entra ID Protection | 「Anomalous Token」：見慣れない場所から使われたトークンなど、トークンの再利用の兆候 | Microsoft Entra ID P2 |
| Microsoft Defender XDR | 「Stolen session cookie was used」「Possible AiTM phishing attempt」などのアラート。Defender for Cloud Apps の Microsoft 365 のコネクタを使う | Defender for Cloud Apps などを含む契約（Microsoft 365 E5 など） |
ID Protection のユーザーのリスクを使った条件付きアクセスのポリシーもあわせて設定します。ただし、Microsoft は「Attacker in the Middle」が出たときは管理者が調べることを勧めており、リスクの解消にはパスワードの安全なリセットか、セッションの取り消しが要ることがあるとしています。
自動攻撃中断で、検知したときに止める
Microsoft Defender XDR の「自動攻撃中断」は、AiTM 攻撃を対象のシナリオに含みます。確度の高いインシデントを見つけると、アカウントの無効化やセッションの取り消しを自動で行い、攻撃者の動きを早い段階で止めます。止めた操作は、セキュリティの担当者が元に戻せます。
働かせるには、Defender for Identity・Defender for Office 365・Defender for Cloud Apps を展開しておく必要があります。Defender for Cloud Apps の Microsoft 365 のコネクタは、Microsoft Entra ID のアプリを含めてすべての項目を有効にします。項目が欠けると、中断が正しく働かないことがあります。
入口のメールそのものを止める設定は、Microsoft Defender for Office 365 で行います。Microsoft Edge を使う組織では、Microsoft Defender SmartScreen を有効にして、フィッシング サイトを開く前に警告させます。
（2026年11月更新）
補足：2026年7月から、Microsoft 365 E3 と Office 365 E3 に Microsoft Defender for Office 365 Plan 1 が含まれています。メールで届く誘い出しへの備えはMicrosoft 365のメールセキュリティ対策（Defender for Office 365編）で解説しています。
乗っ取られたあとの対処｜パスワードを変えるだけでは終わらない
Microsoft は、AiTM 攻撃ではパスワードのリセットは有効な対処にならないと説明しています。奪われたセッションの Cookie を無効にし、攻撃者が変えた多要素認証の設定を元に戻す必要があります。対処は次の順で進めます。
- セッションを取り消す：Microsoft Entra 管理センターの利用者のページで「セッションの取り消し」を行い、パスワードもリセットする
- 認証方法を確かめる：利用者に覚えの無い電話番号や認証アプリが追加されていないかを見て、あれば削除する
- メールボックスを確かめる：攻撃者が作った受信トレイのルール（転送・移動・削除）が無いかを見る
- 送られたメールを確かめる：乗っ取られた間に送られたメールを調べ、請求書詐欺やフィッシングのメールが出ていれば、相手に連絡する
- リスクを確かめて解除する：ID Protection で利用者のリスクの履歴を確かめ、対処を終えてから解除する
Exchange Online・SharePoint Online・Teams は継続的アクセス評価に対応しているため、パスワードのリセットやセッションの取り消しを受けて、数分のうちにアクセスを止めます。対応していないアプリでは、発行済みのトークンが期限まで使えることがあります。
AiTM 攻撃への備えを進める順番
- 管理者のアカウントに、認証強度「フィッシングに強い MFA」を必須にする
- 認証方法の登録に、強い認証か社内のネットワークを求める
- 準拠した端末か、社内の IP アドレスを条件にするポリシーをレポート専用で作り、私物の端末とゲストの扱いを決めてから有効にする
- 利用者にパスキーなどを登録してもらい、認証強度の対象を全員に広げる
- ライセンスに応じて、ID Protection のリスクのポリシーと、Defender XDR の自動攻撃中断を設定する
- 乗っ取られたときの手順（セッションの取り消し、認証方法とメールボックスの確認）を決めておく
弊社の支援
弊社は、Microsoft 365 と Azure の導入とセキュリティ設定を支援しています。AiTM 攻撃への備えは、設定そのものより、利用者の認証方法の登録を進め、私物の端末やゲストの扱いを決める作業に時間がかかります。
サインイン ログの確認から、認証強度と端末の条件を組み合わせた条件付きアクセスの設計、パスキーの展開、乗っ取られたときの手順づくりまでをご一緒に進めます。メールのなりすまし対策はMicrosoft 365のメールセキュリティ対策（DMARC編）で、セキュリティ対策の全体像はゼロトラストとはで解説しています。
資料のご案内
Microsoft 365 セキュリティ対策ガイド【ID・アクセス編】
フィッシングに強い多要素認証と準拠した端末を条件にする、条件付きアクセスの土台となるポリシーと、段階的な適用の進め方をまとめています。
よくあるご質問
こちらをクリックして「よくある質問」を表示
パスキーを配れば、AiTM 攻撃は防げますか？
パスキーは偽のドメインでは認証が成り立たないため、AiTM 攻撃に強い方式です。ただ、SMS などほかの方式でもサインインできる設定のままだと、攻撃者はそちらを使わせます。条件付きアクセスの認証強度で、フィッシングに強い方式を必須にします。
番号の一致を使ったプッシュ通知なら安全ですか？
AiTM 攻撃では、偽のサイトが本物の画面を映すため、利用者は本物と同じ番号を見て承認してしまいます。番号の一致は、身に覚えの無い通知を承認させる攻撃には効きますが、AiTM 攻撃は防げません。
Microsoft 365 E3 や Business Premium でできる対策はありますか？
あります。条件付きアクセスの認証強度、準拠した端末と場所の条件は、Microsoft Entra ID P1 と Intune Plan 1 で使えます。ID Protection の「Attacker in the Middle」の検知や自動攻撃中断には、Microsoft 365 E5 などの契約が要ります。
トークン保護を有効にすれば、Cookie を奪われても大丈夫ですか？
トークン保護の対象はネイティブ アプリで、Microsoft 365 をブラウザーで使うときの Cookie は対象になりません。AiTM 攻撃には、フィッシングに強い多要素認証と、準拠した端末や場所の条件で備えます。
偽のサイトに入力してしまったら、パスワードを変えれば大丈夫ですか？
パスワードの変更だけでは足りません。セッションを取り消し、攻撃者が追加した認証方法と受信トレイのルールが無いかを確かめます。乗っ取られた間に送られたメールも調べ、取引先に届いていれば連絡します。
URL を確かめるよう教育すれば防げますか？
偽のサイトは本物の画面をそのまま映すため、見た目では見分けられず、違いは URL だけです。教育は続けつつ、見落としても認証が成り立たない仕組み（フィッシングに強い多要素認証）と、端末や場所の条件を重ねます。
AiTM 攻撃は、利用者が本物の多要素認証を済ませたあとの結果を奪うため、多要素認証を入れただけでは止まりません。中継できない認証方式に絞り、奪われた Cookie を組織の外で使わせない設定を重ねれば、この入口は閉じられます。お使いの環境の認証方法の登録状況をお聞かせいただければ、進め方をご提案します。お問い合わせよりお気軽にご相談ください。
関連サービス・関連コラム
- セキュリティ強化支援（ゼロトラスト）
- クラウド導入支援（Microsoft 365）｜安全で生産性の高い働き方の基盤を構築
- Microsoft 365のメールセキュリティ対策（DMARC編）｜SPF・DKIMを整えてp=rejectまで段階的に強める
- ゼロトラストとは｜中小企業がMicrosoft 365で始めるセキュリティ
まずは無料トライアルで、効果をご確認ください
「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。
