- AiTM攻撃とは、偽サイトで通信をリアルタイムに中継し、認証を通った後のセッションCookieを盗み取る攻撃のことだ。
- 厄介なのは、パスワードにコードを足す多要素認証を入れていても突破されてしまう点にある。認証そのものではなく、認証済みの「通行証」を横取りする発想だからだ。
- これを知らないと、対策済みのつもりで盗まれる。逆に仕組みを押さえれば、どの認証方式に移るべきかが見えてくると覚えておけばいい。
この4コマは、AiTM攻撃で実際に起きている侵害の構造をそのまま日常に置き換えたものです。コマ①②の合鍵の横流しが示すのは、攻撃者が正規サイトと利用者の間に割り込むリバースプロキシ型フィッシングの動きにほかなりません。利用者は本物そっくりの画面を見ているため、偽サイトだと気づく手がかりがほとんど残らないのです。
コマ③の通行証こそが、この攻撃の核心にあたります。攻撃者が本当に欲しいのはパスワードやワンタイムコードそのものではなく、認証を通した結果として発行されるセッションCookieです。これを握られると、以降は再認証を求められないまま正規ユーザーになりすまし続けられます。経営面では、業務停止や顧客補償に加え、個人情報保護法上の報告義務まで発生しかねません。
回避策はコマ④の一言に集約されます。鍵が特定のドメインにしか反応しない仕組み、すなわちフィッシング耐性のある認証へ移すことが本質的な防御です。従業員教育も無駄ではありませんが、見破りが困難な以上、技術で通信のすり替え自体を成立させないほうが確実だと言えるでしょう。
なぜAiTM攻撃は多要素認証を突破できるのか？
AiTM攻撃が多要素認証を突破できる理由は、狙う対象が「認証情報」ではなく「認証済みの状態」だからです。攻撃者は正規サイトそっくりの偽サイトを用意し、利用者が入力したIDやパスワード、さらにはワンタイムコードまでを、リアルタイムで本物のサイトへ中継します。本物のサイトから見れば正しい情報が順番に届くため、認証は問題なく成立してしまうのです。
そして認証が通った瞬間、正規サイトは「この人はログイン済み」という証明書としてセッションCookieを発行します。攻撃者はこれを盗み、自分のブラウザに読み込ませることで、パスワードもコードも入力せずに正規ユーザーとして振る舞えます。マイクロソフトのデジタル防御レポート2025では、2025年上半期にIDを狙った攻撃が前年比で32%増加したと報告されており、この種の認証を狙う手口が広がっている実態がうかがえます。
この手口が急速に広がった背景には、攻撃の「商品化」があります。かつては相応の技術力を要した中間者型のフィッシングが、いまや月額課金のサービスとして流通しているのが実情です。実際、2025年初頭には国内の複数のネット証券で口座乗っ取りが多発し、多要素認証を有効にしていたにもかかわらず被害に遭ったケースも確認されました。この事態を受け、金融庁は監督指針を改正し、重要操作にフィッシング耐性のある認証を求める方向へ動いています。
AiTM攻撃のよくある誤解
多要素認証さえ入れれば安全という思い込み
多要素認証は今も有効なセキュリティ対策ですが、万能ではありません。SMSやアプリで受け取るワンタイムコードは、リアルタイムで中継されると通過してしまうため、AiTM攻撃の前では時間稼ぎ程度の効果しか持たない場合があります。安全なのは「導入した事実」ではなく「どの方式を選んだか」だと理解しておく必要があります。
パスワードを盗む攻撃だと考えてしまうケース
本当に盗まれているのはパスワードではなく、認証後のセッションCookieです。では、なぜパスワードも入力させるのでしょうか。それは本物のサイトで正規のログインを完了させ、正規のCookieを発行させるための手順にすぎません。攻撃の主目的は最初から「認証済みの状態」の窃取にあります。
怪しいサイトは見た目でわかるという過信
AiTM攻撃の偽サイトは、本物のサイトの表示をそのまま中継しています。デザインの粗さや不自然な日本語といった従来の見分け方はほぼ通用しません。URLの微妙な違いに気づけるかどうかが分かれ目になりますが、それを人間の注意力だけに頼るのは現実的ではないでしょう。
会話での使われ方
先週の不正ログイン、MFA通ってるんですよね。たぶんAiTM攻撃でセッション持っていかれてます。パスワード変更だけじゃ止まりません。
社内のセキュリティ担当者が、インシデント対応の緊急ミーティングで情報システム部長に状況を報告している場面。原因の切り分けを共有する報告のトーン。
御社のログイン、AiTM攻撃への耐性はいかがですか。SMS認証のみですと、正直なところ心もとないですよ。
セキュリティ製品を扱うベンダーの営業担当が、商談の場でクライアント企業の担当者に対し、現状の認証方式の課題をやんわり指摘している場面。提案につなげる会話。
AiTMってつまり、合鍵を渡した瞬間に横で本物のドア開けられてる感じ？こわ。
勉強会後のランチで、新人エンジニアが同期に向けて、学んだばかりの攻撃手法を自分なりの例えで確認している場面。くだけた雑談のトーン。
AiTM攻撃とMITM攻撃の違い
AiTM攻撃はMITM（中間者）攻撃の一種ですが、狙いと手口に明確な差があります。両者は名前が似ているため混同されがちで、対策の方向性も変わってくるため整理しておきましょう。
| 比較観点 | AiTM攻撃 | MITM攻撃 |
|---|---|---|
| 主な目的 | 認証済みセッションCookieの窃取 | 通信内容の盗聴・改ざん全般 |
| 手口 | 偽サイトでログインを中継するリバースプロキシ型フィッシング | 公衆Wi-Fiなど通信経路への割り込み |
| 狙う対象 | クラウドサービスやオンラインバンキングの利用者 | 暗号化が弱い通信を使う不特定の相手 |
| MFAへの影響 | 多要素認証を回避してなりすまし可能 | 認証情報を盗んでもセッション乗っ取りには至りにくい |
【まとめ】AiTM攻撃の3つのポイント
- 盗まれるのは通行証：AiTM攻撃の正体は、認証そのものではなく認証後のセッションCookieを横取りする手口である
- フィッシング耐性認証へ移す：FIDO2やパスキーを導入し、偽ドメインでは認証が成立しない仕組みで防ぐ
- 「MFA済み」で油断しない：SMSやアプリのコードだけでは突破される前提で、認証方式を今すぐ棚卸しする
よくある質問
-
QAiTM攻撃はパスキーでも防げませんか？
-
A
パスキーはAiTM攻撃に対して非常に高い耐性を持ちます。パスキーの認証はアクセス先のドメインに暗号的に紐付いており、偽サイト上では正規サイトと判定されず署名が行われないため、通信を中継されても認証が完結しないのです。マイクロソフトもパスキーを最善のソリューションとして推奨しています。
-
QAiTM攻撃の被害に遭ったらどう対処すればよいですか？
-
A
まず盗まれたセッションを無効化することが最優先です。対象アカウントの全セッションを強制ログアウトさせ、パスワードを変更した上で、不審なアプリ連携やメール転送ルールが追加されていないかを確認します。パスワード変更だけでは、すでに盗まれたCookieによる不正アクセスは止まらない点に注意してください。
-
QどんなサービスがAiTM攻撃に狙われやすいですか？
-
A
Microsoft 365などのクラウドサービスとオンラインバンキング、証券口座が主な標的です。これらは業務や資産に直結し、乗っ取れば金銭やさらなる詐欺の起点として悪用しやすいため狙われます。実際に2025年には国内のネット証券で乗っ取り被害が相次ぎました。
-
QAiTM攻撃とフィッシングとの違いは何ですか？
-
A
AiTM攻撃は、フィッシングの中でも「通信をリアルタイム中継してセッションを奪う」進化型と位置づけられます。従来のフィッシングは偽サイトで入力されたIDとパスワードを盗むだけで、多要素認証があれば多くは防げました。一方でAiTM攻撃は認証後のセッションCookieまで奪うため、多要素認証を設定していても突破されてしまう点が決定的な違いです。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| フィッシング | AiTM攻撃はフィッシングの進化型であり、その基本を理解する土台になる |
| 多要素認証（MFA） | AiTM攻撃が突破対象とする認証方式で、その仕組みと限界が対策の前提になる |
| パスキー | AiTM攻撃に対する最有力の防御手段であり、フィッシング耐性認証の代表格 |
| Cookie | AiTM攻撃で盗まれるセッションCookieの正体を知るために欠かせない |
| マン・イン・ザ・ミドル攻撃 | AiTMの上位概念にあたる中間者攻撃で、両者の違いが理解を深める |
【出典】参考URL
https://www.microsoft.com/security（マイクロソフト デジタル防御レポート2025：2025年上半期のID狙い攻撃32%増の根拠）
https://eset-info.canon-its.jp/malware_info/malware_topics/detail/malware2512.html（AiTM攻撃の仕組み・国内証券口座乗っ取り・金融庁の監督指針改正の根拠）
https://www.trendmicro.com/ja_jp/jp-security/25/j/securitytrend-20251003-01.html（パスキー／FIDO2によるドメイン検証がAiTMを防ぐ仕組みの根拠）
https://www.cybertrust.co.jp/blog/certificate-authority/client-authentication/aitm-phishing-and-mfa.html（MicrosoftによるAiTM発表とFIDO・証明書ベース認証の有効性の根拠）
コメント