All
SaaS管理
デバイス管理
セキュリティ対策
脅威・インシデント
IT基盤・インフラ
情シス業務・組織形成
AI / テクノロジー
プロダクト
イベントレポート
その他
ガバナンス

新着記事

もっと見る

>

>

中間者攻撃(MitM)とは?仕組み・手法やAiTMとの違いを解説

中間者攻撃(MitM)とは?仕組み・手法やAiTMとの違いを解説

中間者攻撃(MitM)とは?仕組み・手法やAiTMとの違いを解説

中間者攻撃(MitM)とは?仕組み・手法やAiTMとの違いを解説

公開日

最終更新日

AiTMは正規サイトとの通信を中継しMFA後のセッションクッキーを窃取する中間者攻撃の一種です。

MitMは「Man-in-the-Middle attack」の略で、読み方は「エム・アイ・ティー・エム」です。従来は同一ネットワーク内で通信を奪う手口が中心でしたが、現在はフィッシングサイトを中継点にして認証を突破するAiTMも、企業アカウントを狙う脅威になっています。

情シス部門では、Wi-FiやVPNだけの対策では不十分です。認証方式、端末証明書、DNS、Webサイト設定、ログ監視をつなげて設計する必要があります。本記事では、攻撃が成立する技術的な前提と対策の優先順位を整理します。

中間者攻撃(MitM)とAiTMの仕組みや手法の違い、ならびにパスキー導入やログ統合といった対策アプローチを概念的に表現したインフォグラフィック。

MitM(中間者攻撃)とは

MitM(Man-in-the-Middle attack、中間者攻撃)とは、利用者と正規サービスの間に攻撃者が不正に入り込み、通信の盗聴、改ざん、なりすましを行う攻撃です。

本記事のポイント

  • HTTPSが正常に証明書を検証していれば、第三者が正規サイト通信を単純に復号・改ざんすることは困難です。

  • AiTMはパスワードだけでなく、MFA完了後のセッションクッキーを狙います。

  • SMSやワンタイムコードだけのMFAでは、リアルタイム中継型フィッシングを防ぎ切れない場合があります。

  • 情シスはフィッシング耐性MFA、端末管理、ネットワーク分離、監視を組み合わせます。

攻撃者は、利用者には正規サーバー、正規サーバーには利用者であるかのように振る舞います。成功すると、認証情報の窃取だけでなく、送金先口座の書き換え、マルウェア配布、業務SaaSへの不正ログインにつながります。IPAは「2024年度中小企業における情報セキュリティ対策に関する実態調査」において、サイバー攻撃の手口として「脆弱性を突かれた」が48.0%、「取引先やグループ会社等を経由して侵入」が19.8%と報告しています。IPAの中小企業向け情報セキュリティ対策調査は、通信経路だけでなく取引先・委託先を含めた対策の必要性も示しています。

なお、企業が管理下の端末通信を一時復号して検査するSSL復号は、攻撃者によるMitMとは目的と権限が異なります。前者は組織が配布したルート証明書、利用規程、検査ポリシーに基づくセキュリティ運用であり、後者は無権限の介入です。

中間者攻撃(MitM)における利用者・攻撃者・正規サーバー間の通信構造

▲ 中間者攻撃(MitM)における利用者・攻撃者・正規サーバー間の通信構造

HTTPS環境での攻撃成立条件

HTTPSはMitMへの有効な防御ですが、証明書検証を無効化する条件やフィッシング中継があると攻撃が成立します。

証明書認証の突破条件

ブラウザは、接続先ドメインと証明書の有効性を検証します。そのため、攻撃者が別ドメイン用の正規証明書を持つだけでは、正規ドメインの通信を中間者として復号できません。攻撃には、端末への不正ルート証明書の導入、証明書警告の無視、端末やネットワーク機器の侵害などが追加で必要になります。鍵マークや「https://」は通信暗号化の表示であり、ログイン先の正当性そのものを保証するものではありません。

SSLストリッピングの成立条件

SSLストリッピングは、利用者をHTTPへ誘導し、HTTPSへの切り替えを妨げて平文通信を傍受する手口です。サイトがHTTPを受け付け、ブラウザが初回アクセスでHTTPSを強制されない場合にリスクが高まります。Web管理側はHTTPSへの恒久リダイレクトに加え、HSTSを設定してブラウザにHTTPS接続を強制します。

公衆無線LANにおける影響範囲

暗号化されていないWi-Fiでも、HTTPS通信の本文やパスワードが常に読めるわけではありません。一方で、接続先に関する情報の一部、HTTP通信、証明書警告を無視した通信は危険です。社外勤務時のルールでは、業務SaaSへのログインや管理操作は会社管理のVPNまたはモバイル回線経由に限定し、店舗掲示などでSSIDの正当性が確認できないネットワークは業務利用対象外とします。VPNは端末からVPN終端までの経路を保護しますが、フィッシングサイトへの入力や端末感染には効果が及びません。VPN接続中のDNSフィルタリング・Webアクセス制御・EDRの適用については、「企業の多層防御」節で設計の考え方を整理しています。Wi-Fiセキュリティの基礎も、従業員教育の補助資料として利用できます。

中間者攻撃の主な手口

MitM攻撃は、通信を自分に流す手口と、正規サービスになりすます手口を組み合わせて実行されます。

ARPスプーフィング

ARPスプーフィングは、同一LAN内でIPアドレスとMACアドレスの対応情報を偽り、端末の通信を攻撃者端末へ転送させる手口です。同じセグメントに攻撃者が存在し、ARPを保護・監視していない環境で成立します。対策は、業務端末と来訪者用Wi-FiのVLAN分離、動的ARP検査、不審なARP応答の監視です。

DNSスプーフィング

DNSスプーフィングは、名前解決結果を偽装して利用者を攻撃者のサーバーへ誘導する手口です。偽サイト側でHTTPSを使っていても、正規ドメインとは異なるURLであればフィッシングです。社内DNSの変更ログを取得し、DNSフィルタリングで既知の悪性ドメインを遮断すると、誘導段階の対策になります。

悪魔の双子攻撃

悪魔の双子攻撃は、正規APに似たSSIDを持つ偽アクセスポイントへ端末を接続させる手口です。例えば正規SSIDが「Cafe-Office-WiFi」の場合、「Cafe_Office_WiFi」のような似た名称を使います。SSIDだけでなく、接続先の正当性を確認し、業務端末の自動接続を管理対象ネットワークに限定します。

フィッシング中継

現在の企業アカウント侵害で警戒すべきなのが、偽ログイン画面を入口に正規サービスとの通信を中継する手口です。利用者が入力したパスワードや認証コードをリアルタイムで正規サイトへ転送するため、従来型MFAでも突破される場合があります。IPAは情報処理安全確保支援士試験のシラバスで、中間者攻撃とMan-in-the-Browser攻撃を関連する攻撃用語として扱っています。IPAのシラバス追補版を、教育資料の用語統一に利用できます。

AiTM・MitBとMitMの違い

AiTMとMitBはMitMの考え方を発展させた攻撃であり、対策の中心は通信保護から認証・端末保護へ広がります。

種類

介入する場所

主な窃取対象

情シスの防御軸

MitM

ネットワーク経路

通信内容、認証情報

ネットワーク分離、証明書検証、DNS保護

AiTM

フィッシングサイトによる通信中継

認証情報、MFA後のセッションクッキー

FIDO2・パスキー、条件付きアクセス、セッション監視

MitB

感染端末上のブラウザ

入力内容、送金先、画面表示

EDR、ブラウザ更新、拡張機能管理、取引の再確認

AiTMの仕組み

AiTMはAdversary-in-the-Middleの略です。IPAは、フィッシングサイトが被害者と正規サイト間の通信を中継し、多要素認証の完了後に正規サイトが返すセッションクッキーを窃取する手口と説明しています。IPAのAiTM型フィッシングに関する注意喚起にある通り、窃取されたクッキーが有効な間は、攻撃者がパスワードを再入力せずにセッションを悪用するおそれがあります。

MitBの仕組みと対策

MitBはMan-in-the-Browserの略で、端末に侵入したマルウェアや悪性拡張機能がブラウザ内部で入力値や画面表示を書き換える攻撃です。MitB攻撃対策では、EDRで不審なプロセスやブラウザ操作を検知し、拡張機能を許可リスト方式で管理します。振込や権限変更を扱うシステムでは、別経路で宛先・変更内容を照合する承認フローを設けると、画面改ざんによる誤操作を抑えられます。

 MitM・AiTM・MitBの介入ポイントと脅威の比較

▲ MitM・AiTM・MitBの介入ポイントと脅威の比較

企業の多層防御

企業のMitM対策は、フィッシング耐性認証を最優先にし、ネットワーク・端末・Web設定・監視を重ねて実装します。

フィッシング耐性MFA

SMSや認証アプリのワンタイムコードは、リアルタイムで中継されるAiTMに対して単独では不十分な場合があります。業務SaaSがFIDO2セキュリティキーまたはパスキーに対応し、端末の管理状態を認証条件に使えるなら、管理者・特権IDからフィッシング耐性MFAへ移行します。デジタル庁の当人認証ガイドライン(DS-511)は、保証レベル3において公開鍵暗号に基づく認証器を含む多要素認証を要件として定めています。フィッシング耐性認証の適用対象や必須範囲は保証レベルの区分によって異なるため、自組織のシステムが求める保証レベルをガイドライン本文で確認したうえで要件を判断します。デジタル庁の当人認証ガイドライン資料は認証要件を検討する基準になります。

無線LANとリモートアクセス

社内無線LANは、共有パスワード方式ではなくWPA3-Enterpriseと802.1X/EAPによる利用者・端末認証を採用し、来訪者用ネットワークを業務ネットワークから分離します。VPNは端末からVPN終端までの経路を保護しますが、フィッシングサイトへの入力、端末感染、VPN終端以降の通信までは防げません。VPN接続中にも、認証・端末・Webアクセス制御を適用します。VPNの仕組みと利用時の注意点もあわせて参照できます。

Webサイトとログ監視

自社Webサイトは常時HTTPS化に加え、HSTS、HTTPからHTTPSへのリダイレクト、CookieのSecure属性・HttpOnly属性を設定します。ただし、Secure属性はHTTP経由のCookie送信を防ぐもの、HttpOnly属性はJavaScriptからのCookie読み取りを防ぐものであり、いずれもAiTMのようにHTTPS通信を正規サイトとして中継してセッションクッキーを取得する手口には効果が及びません。AiTMへの対処は、条件付きアクセスによるセッション有効期限の短縮と、フィッシング耐性MFAの適用が中心になります。認証基盤、DNS、プロキシ、EDRのログをSIEMへ集約し、「国外からの新規ログイン直後にMFA設定が変更された」「同一アカウントで短時間に異なる端末識別子が出現した」といった相関ルールを設けます。通信暗号化の基礎はSSL/TLSの解説で確認できます。

実装チェックリスト

次の順序で確認すると、対策漏れを減らせます。

  1. 管理者IDと高権限SaaSで、パスキーまたはFIDO2を利用できるか確認します。利用できれば先行適用し、利用できなければ条件付きアクセスと異常ログイン検知を先に強化します。

  2. 社内Wi-Fi、来訪者Wi-Fi、IoT機器を分離し、DNS・ARPの異常を記録します。

  3. 自社ドメインでHSTSとHTTPSリダイレクトが有効かを検証し、不足があればWeb運用の変更計画に組み込みます。

  4. 証明書警告を無視して接続しない運用を教育し、警告発生時は端末・ネットワーク・証明書配布履歴を調査します。

正当なSSL復号の運用判断

SSL復号は暗号化通信に潜むマルウェアや情報漏えいを検査できますが、対象範囲と証明書管理を誤ると業務影響を招きます。

企業のSSL Inspectionでは、端末とプロキシ間、プロキシとWebサイト間にそれぞれTLS通信を構築して検査します。このため、組織管理のルートCA証明書を端末へ安全に配布し、失効・更新を管理する仕組みが必要です。クライアント証明書認証を利用するサービス、金融・医療など高い秘匿性を持つサイト、ソフトウェア更新通信は、業務要件とリスクを確認して復号除外リストを設計します。

全通信を一律に復号する設計は、性能低下、証明書エラー、プライバシー上の問題につながります。プロキシログを取得でき、証明書をMDMや端末管理基盤から配布できるなら、まず少数の管理端末で検査対象と除外対象を検証します。ログが取得できない、または証明書配布の統制が取れない場合は、復号範囲を広げず、DNSフィルタリングやEDRの検知を優先します。

総務省は令和7年版「情報通信白書」(第2部第1章第1節、URL: https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd21a100.html)で、2023年の国内情報セキュリティ製品市場の売上高を前年比12.0%増の5,574億400万円と報告しており、そのうちセキュリティソフトウェア市場は4,965億1,100万円でした。同白書はネットワーク防御とクラウド型セキュリティへの投資が市場拡大を牽引していると分析しており、SSL復号やEDR導入の予算根拠を社内説明する際の参照データとして活用できます。

社内ネットワークにおけるSSL復号(SSL Inspection)の運用適用判断フロー

▲ 社内ネットワークにおけるSSL復号(SSL Inspection)の運用適用判断フロー

導入時の失敗パターン

MitM対策は製品を導入しただけでは機能せず、例外管理と監視運用を設計しないことが典型的な失敗です。

SMS認証への過信

「MFAを有効にしたからAiTMは防げる」と判断すると、認証コードを中継するフィッシングを見逃します。管理者IDにFIDO2やパスキーを適用できるかを確認し、対応していないサービスではログイン元・端末状態・セッション異常を監視する補完策を設定します。

証明書警告の例外運用

SSL復号導入後に発生した証明書警告を、利用者へ「続行」を案内して解消する運用は危険です。正規のルートCA配布漏れなら配布基盤を修正し、想定外のサイトやアプリなら復号対象の妥当性を再評価します。警告を無視する習慣は、攻撃者の不正証明書を見分ける最後の防壁を弱めます。

ログの未統合

EDR、認証基盤、DNS、プロキシのログが別々では、AiTM後の不審なセッション利用を追跡しにくくなります。IPAの2024年調査では、中小企業でOSやソフトウェアを常に最新化している割合は73.0%、ウイルス対策ソフトの導入・定義ファイル更新は71.4%でした。IPAの中小企業向け情報セキュリティ対策調査が示す基本対策を土台に、認証・通信ログの突合まで運用範囲を広げます。まずは特権IDのログを1か所へ集約し、検知時の無効化手順を定めると着手しやすくなります。

まとめ

MitM攻撃はネットワーク経路への介入だけでなく、AiTMによる認証中継、MitBによるブラウザ改ざんへと形を変えています。HTTPS、VPN、MFAはいずれも必要ですが、単独では十分ではありません。

情シス部門では、まず管理者IDと高権限SaaSの認証方式を棚卸しし、FIDO2またはパスキーを適用できる対象を特定します。次に、無線LAN分離、HSTS、認証・EDR・DNSログの統合を進めます。証明書警告を無視させない運用を定着させることが、明日から着手できる最初の防御策です。AiTMによるセッション窃取が疑われる場合の初動としては、①該当アカウントの既存セッションを強制失効、②発行済みアクセストークンの無効化、③登録済みMFA方式に不審な追加がないかの確認(Microsoft Entra IDであれば「セキュリティ情報」画面、Google Workspaceであれば「2段階認証プロセス」設定画面で確認可能)、④メール転送ルールと外部OAuthアプリの同意状況の確認、の順に対応すると、被害の横断を抑えやすくなります。


本記事の内容に誤り等がございましたら、こちらからご連絡ください。

監修

Admina Team

情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。