中間者攻撃(AiTM攻撃)とは？多要素認証で防げない理由と対策を解説|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2025年03月20日更新日時: 2026年08月02日

多要素認証を入れているのに、Microsoft 365やGoogle Workspace、Oktaなどのアカウントが乗っ取られる。最近のクラウドアカウント侵害で厄介なのは、この感覚のずれです。

AiTM攻撃は、昔ながらの中間者攻撃を少し言い換えただけの用語ではありません。企業の実務で見るべき本質は、利用者に偽のログイン画面を踏ませ、正規サービスとの認証をリアルタイムに中継し、ログイン後のセッションCookieや認証トークンを奪う点にあります。SMSコードや認証アプリのワンタイムコード、単純なプッシュ承認型MFAでは、利用者が偽サイト上で操作を完了してしまうと、攻撃者側にも認証済みセッションが残ります。

MFAは今でも有効です。ただし、MFAなら何でも同じ、という時期は終わりました。管理者アカウント、メール、VPN、IdP、経理・人事系SaaSのような重要な入口については、FIDO2/WebAuthn、パスキー、セキュリティキーなどのフィッシング耐性MFAを前提に設計し直す必要があります。

AiTM攻撃とは？MFAを突破するセッション窃取の仕組みと企業が取るべき対策のサマリー

AiTM攻撃は、偽ログイン画面を介して正規サービスとの認証を中継し、認証情報だけでなくセッションCookieやトークンを奪う攻撃です。
SMS、メール、TOTP、単純なプッシュ通知型MFAは、リアルタイム中継型のフィッシングでは突破される可能性があります。
Microsoft、Okta、CISA、英国NCSC、NISTはいずれも、重要アカウントではフィッシング耐性MFAやトークン窃取対策を重視しています。
FIDO2/WebAuthn、パスキー、ハードウェアセキュリティキーは、認証を正規ドメインに暗号的に結び付けるため、AiTM攻撃への耐性が高い方式です。
企業はMFAの有無だけでなく、認証方式の強度、端末管理、条件付きアクセス、セッション失効、メールボックスルールの監視まで含めて点検する必要があります。

項目	内容
攻撃名	AiTM攻撃、Adversary-in-the-Middle攻撃
主な標的	Microsoft 365、Google Workspace、Okta、VPN、SaaS、業務メール
狙われる情報	ID、パスワード、MFAコード、セッションCookie、認証トークン
影響	アカウント乗っ取り、メール閲覧、BEC、データ窃取、内部向けフィッシング拡散
従来型MFAの限界	SMS、メール、TOTP、プッシュ承認はリアルタイム中継で突破される可能性があります
有効な対策	FIDO2/WebAuthn、パスキー、セキュリティキー、条件付きアクセス、トークン保護、セッション監視
優先対象	管理者、経理、人事、役員、情シス、外部公開SaaS、メール・IdP・VPN

AiTM攻撃は、MFAを破るのではなく認証済みセッションを奪う攻撃

AiTM攻撃を理解するうえで、MFAが暗号的に破られているわけではない、という点は押さえておきたいところです。攻撃者は認証アプリのアルゴリズムを解読しているわけでも、MicrosoftやGoogleの認証基盤を直接侵害しているわけでもありません。

典型的な流れは、業務連絡や共有ファイル、請求書、社内通知に見せかけたメールから始まります。利用者がリンクを開くと、Microsoft 365やGoogleのログイン画面に似せたページが表示されます。ここまでは従来のフィッシングと似ていますが、AiTMでは偽サイトが単なる入力フォームではなく、正規サイトとの通信を中継するプロキシとして動きます。

利用者がIDとパスワードを入力すると、それは攻撃者側を経由して正規サイトへ送られます。続いて利用者がワンタイムコードを入力したり、認証アプリの承認を押したりすると、その操作もリアルタイムで正規サイトに中継されます。正規サイトから見れば、正しいID、正しいパスワード、正しいMFA応答が届いているため、認証は成立します。

問題はその後です。認証が成功した時点で発行されるセッションCookieやトークンを攻撃者が取得できると、攻撃者は利用者本人としてクラウドサービスに入れます。パスワードを後から変更しても、すでに有効なセッションが残っている場合、影響が続くことがあります。この点が、単純なパスワード漏洩よりもインシデント対応を難しくします。

MicrosoftとOktaの分析が示す、AiTM攻撃の現実味

Microsoftは2022年時点で、AiTMフィッシングサイトを使った大規模キャンペーンが、MFAを有効化している利用者からサインインセッションを奪い、BECに発展した事例を公表していました。2026年にも、Tycoon2FAのようなAiTM型フィッシングキットが、スキルの低い攻撃者でもMFA回避を伴うアカウント侵害を実行できるようにしていると分析しています。

ここで重要なのは、AiTMが一部の高度な攻撃者だけの手口ではなくなっている点です。フィッシングキット化、PhaaS化により、攻撃者はテンプレート、管理画面、回避機能、セッション窃取の仕組みを借りるだけで、企業向けSaaSを狙えます。セキュリティ対策Labでも、過去に多要素認証を回避しMicrosoft 365へ不正アクセスするフィッシングサービス Rockstar 2FAや、中国語圏PhaaSが日本を標的にしたサイバー攻撃を取り上げてきましたが、いずれも認証情報だけではなく、認証プロセスそのものを悪用する方向に攻撃が進んでいます。

Oktaも、VoidProxyというPhaaSについて、MicrosoftアカウントやGoogleアカウントを標的に、認証フローをリアルタイムで傍受し、認証情報、MFAコード、セッションTokenを取得するサービスとして分析しています。一方で、Oktaは同じ分析の中で、フィッシング耐性のある認証器を使っている利用者は、VoidProxyのインフラ上で認証情報を共有したりサインインしたりできなかったと説明しています。

この差は大きいです。MFAを入れているかどうかではなく、どのMFAを、どのアプリに、どの条件で要求しているかが問われる段階に入っています。

従来型MFAは不要ではないが、重要アカウントでは足りない

SMS認証やTOTP認証アプリは、パスワードだけの状態に比べれば明らかに安全です。パスワードリスト攻撃、パスワードスプレー、単純な認証情報の使い回しには今でも効きます。Googleの過去の研究でも、復旧用電話番号を追加するだけで自動ボットや大規模フィッシングに対する防御効果が大きいことが示されており、セキュリティキー利用者では調査対象の標的型フィッシング被害が確認されなかったとされています。

ただし、AiTM攻撃の相手には、ワンタイムコードを人間が偽サイトへ入力してしまう限り、コードの寿命が短いことは決定的な防御になりません。攻撃者はその場で正規サイトへ中継するためです。プッシュ通知型MFAも、単純な承認ボタンだけでは危険が残ります。番号照合や位置情報表示は改善策になりますが、NISTやCISA、NCSCが重視するフィッシング耐性MFAとは別物として考えた方が安全です。

英国NCSCは2026年のパスキーに関する資料で、SMSコード、メールコード、TOTP、プッシュ承認を含む従来型MFAは本質的にフィッシング可能であり、FIDO2認証情報やパスキーは一般的な認証攻撃に対して従来型MFA以上に安全だと整理しています。米CISAも、ゼロトラストの一部としてフィッシング耐性MFAの導入を強く推奨しています。

FIDO2、WebAuthn、パスキーがAiTMに強い理由

FIDO2/WebAuthnやパスキーがAiTM攻撃に強いのは、利用者が覚えた秘密やワンタイムコードを入力する方式ではないからです。認証器は、正規サービスのドメイン情報を含めた形で認証処理を行います。偽サイトが見た目だけを似せても、認証器から見ると別のドメインです。そのため、攻撃者のプロキシサイト上では、正規サービス向けの有効な認証応答を作りにくくなります。

ハードウェアセキュリティキー、PCやスマートフォン内蔵の生体認証、管理されたパスキーは、利用者にとっても運用しやすくなっています。以前はセキュリティキーを全社員に配る負担が大きく、紛失対応も悩みどころでした。現在は端末内蔵の認証器や同期型パスキーも選択肢に入るため、管理者、経理、人事、役員、情シス、開発者の特権アカウントから段階的に導入する現実的な道筋を作れます。

とはいえ、パスキーならすべて解決、という話でもありません。同期先アカウントの保護、端末紛失時の回復、共有端末での利用、退職時の回収、管理外ブラウザや拡張機能のリスクは残ります。フィッシング耐性MFAはゴールではなく、ID基盤の設計を見直す入口と考えるべきです。

AiTM対策はメール対策だけでは終わらない

AiTM攻撃はフィッシングメールを入口にすることが多いため、メールセキュリティや訓練に話が寄りがちです。もちろん、SPF、DKIM、DMARC、添付ファイル・URL検査、ブランド偽装検知、フィッシング報告フローは必要です。ただ、実務上はメール対策だけで止め切る前提にしない方がよいです。

攻撃者は、侵害済みの取引先メールアカウント、正規のファイル共有通知、OAuthリダイレクト、短縮URL、クラウドストレージ、チャットツールを使います。セキュリティ対策Labでも、国内ISPの認証情報を悪用したフィッシングメール多発や、株式会社スペースの社員メールアカウント不正アクセスなど、メールアカウント侵害が次のフィッシング配信基盤になる事例を取り上げています。正規アカウントから届くメールは、利用者教育だけでは見抜きにくいのが現実です。

そのため、重要なのは侵入前対策と侵入後対策の両方です。フィッシング耐性MFAで最初の認証を固め、条件付きアクセスで端末・場所・リスクを見て、セッションやトークンの再利用を監視し、侵害時にはセッション失効まで含めて対応する必要があります。

企業が優先すべき対策

最初に取り組むべきは、全アカウントにMFAが入っているかどうかの確認ではありません。どの認証方式がどの権限に使われているかを棚卸しすることです。管理者アカウントにSMSやTOTPしか使っていない、外部公開SaaSにプッシュ承認だけで入れる、MFA登録変更時に強い再認証を求めていない、といった状態は優先的に見直すべきです。

管理者、特権ユーザー、情シス、経理、人事、役員、開発者、外部委託先の高権限アカウントには、FIDO2/WebAuthn、パスキー、セキュリティキーなどのフィッシング耐性MFAを要求します。全社員に一気に展開できない場合でも、重要アプリと重要ユーザーから段階的に始める価値があります。

次に、条件付きアクセスを使い、管理外端末、未知の場所、匿名化サービス、通常と異なる国・地域、リスクの高いサインインを制限します。Microsoft Entra IDでは、トークン保護や継続的アクセス評価のように、盗まれたトークンの再利用を抑えるための考え方も出てきています。すべての環境で同じ機能が使えるわけではありませんが、IdPやSaaS側でどこまでセッション制御ができるかは確認しておくべきです。

侵害時の初動も見直しが必要です。AiTMではパスワードリセットだけで終わらせると危険です。該当ユーザーのセッション失効、リフレッシュトークンの無効化、MFA登録情報の確認、追加された認証方法の削除、メール転送・受信トレイルールの確認、OAuthアプリ同意の点検、外部共有リンクの確認までを手順化しておく必要があります。BECにつながる場合は、経理部門や取引先への注意喚起も含めた対応が必要になります。

AiTM攻撃を前提にしたログ監視の観点

AiTM攻撃の検知では、ログイン成功そのものを異常として扱いにくい点が厄介です。正しいID、正しいパスワード、正しいMFA応答でログインしているためです。

見るべきなのは、ログイン前後の連続性です。普段と異なるIPアドレス、国・地域、ASN、端末、ブラウザ、ユーザーエージェント、短時間の不可能移動、MFA直後の大量メール閲覧、受信トレイルールの追加、外部転送設定、OAuth同意、ファイル大量ダウンロード、共有リンク作成などを組み合わせて検知します。

MITRE ATT&CKでは、AiTMはT1557、WebセッションCookieの窃取はT1539、MFAインターセプトやMFA要求生成はT1111やT1621の文脈で整理できます。SOCや情シスがアラートルールを作る場合、単体のログインイベントだけでなく、認証、メール、クラウドストレージ、IdP、EDRのログを横断して見る設計が必要です。

利用者教育は必要だが、最後の砦にしてはいけない

AiTM攻撃の画面は、よくできています。攻撃者は正規のロゴ、言語、ログインフロー、場合によってはCAPTCHAやクラウドサービスの見た目まで流用します。取引先の侵害済みアカウントから送られてきたメールであれば、差出人だけで違和感に気づくのは難しいです。

利用者教育は必要です。普段と違うログイン画面、再認証の頻発、共有ファイルの不自然な誘導、短縮URL、外部チャットへの誘導を報告できる文化は大切です。ただし、教育を最後の砦にしてはいけません。NCSCが過去に指摘しているように、悪いリンクをクリックしないように求めるだけでは限界があります。組織側が、クリックされても認証情報やセッションを奪われにくい構造を作る必要があります。

情報システム部門への示唆

情報システム部門がまず実施すべきなのは、自社のMFAを方式別に棚卸しすることです。MFA有効率だけを見ていると、SMS、TOTP、プッシュ承認、FIDO2、パスキーが同じ数字に混ざってしまいます。管理者と一般利用者で同じ基準になっていないか、MFA登録変更や端末追加時に弱い認証へ逃げられないかを確認してください。

次に、重要アカウントからフィッシング耐性MFAへ移行します。対象は、全社管理者、メール管理者、IdP管理者、VPN管理者、経理・人事、役員、開発基盤やクラウド管理者、外部委託先の管理者です。全員一斉ではなくても、ここを優先するだけで被害の広がり方は変わります。

あわせて、AiTMを前提にしたインシデント対応手順を作るべきです。パスワードリセット、MFA再登録だけでなく、セッション失効、トークン無効化、メール転送・受信トレイルール確認、OAuth同意確認、外部共有リンク確認、取引先への注意喚起までをチェックリスト化します。

最後に、条件付きアクセスとログ監視を見直します。管理外端末からの重要SaaS利用を制限し、異常な国・地域、匿名化サービス、通常と異なる端末、MFA直後のメール操作やファイル操作を検知できるようにします。AiTM攻撃は、利用者の注意力だけに任せるには完成度が上がりすぎています。MFAを入れて終わりではなく、認証方式、端末、セッション、ログ、初動対応まで含めて、ID防御の設計を一段引き上げる時期です。