AiTMフィッシングとは？MFA後の乗っ取りを防ぐ確認と初動
「追加認証も通したのに、不審な操作が残っている」。
そんなときは、パスワードだけでなく、ログイン後の状態が悪用されていないかも確認します。
AiTMフィッシングは、偽サイトが利用者と正規サービスの間に入り、認証のやり取りを中継する手口です。
この記事では、MFAが役立つ範囲とセッション窃取の違い、管理者へ伝える記録、遮断を確認する順番を整理します。
この記事は以下のような人におすすめ！
- MFAを使っているのに業務アカウントの不正利用が心配な人
- 偽サイトへ認証情報を入れた後に何を伝えればよいか迷う人
- 認証の対策とログイン後の対策を分けて考えたい人
AiTMでは「認証した後」の状態も狙われる
1-1. パスワードとセッションは、使われる場面が違う
まず分けたいのは、本人を確認する場面と、確認後にサービスを使い続ける場面です。
パスワードや追加認証は、ログイン時に本人かどうかを確かめるために使われます。
一方、ログイン後は、ブラウザーに保存されたCookieなどを使って、その利用者の操作として扱う仕組みがあります。
ここでのセッションは、サービスが管理するログイン状態のことです。
Cookieとセッションは同じ言葉ではありませんが、セッションを識別する値をCookieに保存する実装は一般的です。
その値が盗まれ、サービス側の制約も満たされると、攻撃者がログイン済みの状態を悪用できる場合があります。
追加認証を終えているから、その後の操作がすべて安全になる、とは言い切れないのです。
1-2. MFAを外すのではなく、守る範囲を広げる
AiTMはAdversary-in-the-Middleの略で、ここでは認証のやり取りを中継するフィッシングを指します。
狙われるのは、パスワードだけではありません。
利用者が追加認証を完了した際のセッションCookieも奪われる可能性があります。
Microsoftの調査資料でも、AiTMに関連するセッションCookieの窃取と、その後の不審な操作を合わせて確認しています。
（参考1）
この説明から「MFAは無意味だ」と判断するのは早計です。
パスワードの流出だけで不正ログインされるリスクを抑える対策と、認証を中継された場合や認証後の状態を守る対策は、分けて考える必要があります。
MFAをやめる理由ではありません。
認証方式の選択と、認証後のセッション・端末・操作の監視を組み合わせる話です。
偽サイトの中継では、画面だけで判断しにくい
2-1. いつもの画面に見えても、アクセス先は別かもしれない
偽サイトが正規サービスとのやり取りを中継すると、利用者には見慣れた画面が表示される場合があります。
たとえば、普段と同じサービス名や追加認証の案内が見えたとしても、それだけではアクセス先の正しさを確認できません。
図では、説明用に正規の認証先をlogin.example.com、偽の入口をsignin-check.example.netとしています。
いずれも説明用の名前で、実際のログイン先や攻撃サイトではありません。
確認するのは、画面の雰囲気ではなく、組織が案内した正規の入口と一致しているかです。
メールのリンクをたどる代わりに、保存した正規の入口や組織の案内から開き直す方法を、普段から決めておくと迷いにくくなります。
ただし、URLを見たという利用者の記憶だけで、被害の有無を確定することはできません。
2-2. 通信の暗号化と、相手の正しさは別の確認
HTTPSで接続されていても、その相手が目的の組織のサービスかどうかは別問題です。
利用者と偽サイトの区間が暗号化されていることは、偽サイト自体が正しいことの保証にはなりません。
また、Cookieに関する保護設定だけですべての窃取経路を防げる、とも言えません。
XSSへの備え、通信経路の保護、偽サイトの中継への備えは、想定する経路が異なります。
一つの設定を「セッション窃取の万能策」にしないことが大切です。
（参考1）
MFAは回数より、方式と適用条件を確認する
3-1. 追加のコードがあっても、中継に強いとは限らない
MFAを導入済みかどうかに加え、どの認証方法を使っているかを確認します。
入力したコードが正規サービスへ中継されるような場面では、「コードを一つ追加したから安心」とは言い切れません。
通知を承認する方法も、その承認がどのアクセスに対応するのかを利用者が判断できる運用になっているかが重要です。
とはいえ、この記事を読んで、利用者が会社の認証設定を勝手に変更する必要はありません。
現在の方式と適用範囲を管理者へ確認するための材料にしてください。
3-2. フィッシング耐性と、端末そのものの保護を分ける
FIDO2のパスキーなどでは、認証を利用先に結び付ける仕組みが使われます。
単にコードを入力する方法と比べ、偽の利用先へ認証情報を渡さないための性質が異なります。
図のRPは認証を受けるサービス側を指します。
originはページの出所を表す情報で、一般に方式、ホスト名、ポートの組み合わせです。
FIDO2では、利用先に結び付いた認証を検証します。
単にログイン画面の表示名を比較している、という意味ではありません。
Microsoft Entraには、許可する認証方法の組み合わせを指定する認証強度という仕組みもあります。
ただし、適用には製品の対応状況、ライセンス、管理者のポリシーなどの条件があります。
すべての利用者が同じ画面から無料で切り替えられる、と案内するのは適切ではありません。
（参考3）
また、フィッシング耐性がある認証方式でも、端末の侵害や、アカウント復旧の経路まで含めたすべての問題を解決するわけではありません。
パスキーの対応条件を確認すると同時に、端末の保護や復旧時の確認手順も整理します。
（参考4）
被害の疑いは、認証と後続の操作をつないで調べる
4-1. 知らない場所からのアクセスだけで断定しない
不審なサインインがあったとしても、表示された場所やIPアドレスだけで、攻撃者や原因を特定できるわけではありません。
利用者の接続環境や中継サービスの影響など、別の説明もあり得ます。
逆に、見慣れた地域だから安全、と決めるのも避けたいところです。
管理者は、認証の時刻と、その後に何が行われたかを合わせて確認します。
たとえば、メールの転送設定、不審な送信、アプリへのアクセスなどです。
実際に確認できる項目は、利用している製品やログの保持期間、契約、権限によって異なります。
図の10:00、10:03、10:08は、調べ方を示す架空の時刻です。
短い間隔で操作が続くこと自体が、不正の証明になるわけではありません。
本人に心当たりがあるか、操作の対象は何か、ほかの記録と矛盾しないかを確認するための並べ方です。
4-2. 利用者は「確認できたこと」と「分からないこと」を分ける
偽サイトかもしれない画面へ入力した場合は、気づいた時刻、どの経路から開いたか、入力や承認をしたかを、分かる範囲で管理者へ伝えます。
正確なURLを覚えていなければ、「覚えていない」で構いません。
推測で埋めるより、記憶と記録のどちらに基づく情報かが分かるほうが、調査に使いやすくなります。
一方、パスワード、追加認証コード、Cookieの実値を相談票や公開の質問欄へ貼り付けないでください。
調査に必要な証拠の取り扱いは、組織の担当者と安全な経路を決めます。
（参考1）
パスワード変更と、セッションの遮断を分けて確認する
5-1. 認証基盤とアプリには、それぞれの管理範囲がある
業務アカウントが悪用された疑いがある場合、パスワードだけを変えて完了とするのではなく、既存のログイン状態がどう扱われるかも管理者へ確認します。
ここで、認証基盤のセッションと、アプリが独自に発行したセッションを分けることが重要です。
たとえばMicrosoft Entraで認証した後、アプリ側が独自のCookieを発行する場合があります。
Microsoftの資料では、Entraからアプリ独自のセッションCookieを直接失効できないことが説明されています。
認証基盤側の対応だけで、すべてのアプリをその瞬間に遮断できたと判断しないようにします。
5-2. 遮断したという操作と、遮断できたという確認は別
セッションの失効を指示しても、実際のアクセスへ反映されるまでに時間差が生じる場合があります。
アプリ側の仕組みやトークンの扱いにも左右されるため、「この操作で必ず即時停止する」と一律には説明できません。
管理者は、対象アカウントだけでなく、影響が疑われるアプリや端末を整理し、製品ごとの正式な手順に沿って対応します。
その後、再び不審な操作が発生していないかを確かめます。
利用者が自分の判断で設定を次々に変えるより、担当者へ状況を渡し、必要な遮断と記録保全を一緒に進めることが大切です。
（参考2）
この章は管理者の確認範囲を整理する説明です。
特定の管理コマンドを実行したり、実環境で失効を検証したりした結果ではありません。
初動で迷ったら、分かる記録をそろえて相談する
6-1. 相談で知りたいのは、犯人の断定より被害の範囲
不正利用の疑いがあると、「誰がやったのか」を早く知りたくなるかもしれません。
まず整理したいのは、どのアカウントや情報へ影響が及んだ可能性があるか、いま何を止め、何を残す必要があるかです。
組織の担当者がいる場合は、社内の連絡経路を優先します。
外部の調査を検討する場合も、対応する対象、調べられる記録、費用、報告書の範囲、機密情報の取り扱いを先に確認します。
調査サービスを使えば必ず侵入経路や人物が特定できる、と期待を膨らませないことも大切です。
6-2. よくある疑問と、覚えておきたいこと
Q1：MFAを使っていれば、AiTMは気にしなくてよいですか？
いいえ。
認証方式と、認証後のセッションが悪用される経路を分けて確認します。
MFAを外すという意味ではありません。
Q2：HTTPSなら、正しいログイン画面だと判断できますか？
通信が暗号化されていることと、接続先が目的のサービスであることは別です。
組織が案内する正規の入口と照合します。
Q3：パスワードを変えれば、それだけで終わりですか？
既存のセッションやアプリ側のログイン状態までどう扱われるか、管理者へ確認します。
変更だけで全アプリの即時遮断を保証しません。
Q4：知らないIPアドレスがあれば、不正アクセスですか？
IPや位置だけでは断定できません。
本人の利用状況、認証時刻、後続操作などの記録を合わせます。
Q5：自分で分からない項目が多くても、相談できますか？
分かる時刻や行った操作を整理し、未確認は未確認として伝えます。
認証情報やCookieの実値を貼る必要はありません。
AiTMで押さえたいのは、認証を済ませた後にも守る対象があるという点です。
正規の入口、認証方式、端末、セッション、操作の記録を別々に確認すると、MFAを導入した先に何が必要なのかが見えてきます。
疑わしい操作があれば、一人で原因を決めず、分かる記録を持って担当者へつなげてください。
参考資料
- 参考1：Microsoft Learn — AiTMの中継、セッション窃取、サインインと後続操作の調査
- 参考2：Microsoft Learn — Entraとアプリ独自のセッションの区別、失効の反映時間差
- 参考3：Microsoft Learn — 認証強度と製品ライセンス/適用条件
- 参考4：Microsoft Learn — FIDO2パスキーの利用先との結び付きと認証方式
- 参考5：NCSC — 固定的で頻繁な再認証だけに頼らない
