多要素認証（MFA）を有効にしているのに、なぜアカウントが乗っ取られるのか——。その答えの多くはインフォスティーラー（情報窃取マルウェア）によるセッションCookieの窃取にあります。攻撃者はMFAを「突破」しているのではありません。すでに認証済みのセッションをまるごと盗んで、MFAを“迂回”しているのです。
被害規模は桁違いです。2024年だけで4.3百万台の端末から39億件の認証情報が窃取され、1回の感染あたり平均1,861個のCookieが抜かれたと報告されています。2025年には窃取ログ（スティーラーログ）の流通が前年比72%増の5,170万件に達しました。本記事は、この「パスワードもMFAも要らない」侵入が成立する仕組みと、最新の防御（ChromeのDBSCなど）を実務目線で整理します。
インフォスティーラーとは
インフォスティーラーは、感染した端末から認証情報を根こそぎ抜き取る情報窃取マルウェアです。2026年現在、LummaC2・StealC・RedLine・ACRStealer・Vidar といった系統が主流で、上位3種だけで感染の約75%を占めるとされます。多くはMaaS（Malware-as-a-Service）として月額250ドル前後で販売され、技術力の低い攻撃者でも使えます。
動作はおそろしく速く、静かです。典型的にはこう動きます。
- 端末で実行されると、30秒ほどで全ブラウザのセッションCookie・保存パスワード・オートフィル情報・暗号資産ウォレットを収集する。
- 集めたデータ（スティーラーログ）をC2サーバへ送信する。
- 痕跡を消すため自身を削除する。被害者は感染に気づかない。
盗まれたログはTelegramやダークウェブのマーケットで売買され、別の攻撃者が侵入の足場として使います。個人端末の感染から企業侵害までの平均日数は、わずか7日と報告されています。
なぜMFAが効かないのか：pass-the-cookie
ここが本記事の核心です。Webサービスにログインすると、サーバは「この人は認証済み」という印としてセッションCookie（セッショントークン）をブラウザに発行します。セッション認証やトークン認証の仕組みそのものです。以降のリクエストは、このCookieを提示するだけで通る——パスワードもMFAも再度問われません。
インフォスティーラーが狙うのは、まさにこの「認証後のCookie」です。攻撃者は盗んだCookieを自分のブラウザに読み込ませる（Cookieエディタ等で注入する）だけで、本人としてログイン済みの画面にそのまま入れます。これを pass-the-cookie（セッションリプレイ）と呼びます。
【正規のログイン】
ユーザー → ID/PW + MFA(OTP/Passkey) → サーバ → セッションCookie発行
│
【pass-the-cookie】 ▼
攻撃者 ── 盗んだCookieを注入 ──▶ サーバは「認証済み」と判断
（IDもPWもMFAも不要。Cookieが“通行証”として機能）OTPやSMSはもちろん、多くの実装ではPasskeyすら無関係です。なぜなら認証はとっくに完了しており、攻撃者が手にしているのは「認証の結果」だからです。MFAは“ログインの瞬間”を守りますが、その後に発行されたCookieはMFAの保護範囲の外——ここが盲点です。
もう一つの経路：AitMフィッシング
Cookieを盗むのはマルウェアだけではありません。AitM（Adversary-in-the-Middle）フィッシングも同じ獲物を狙います。Evilginx・Tycoon 2FA・Mamba 2FA といったフィッシングキットは、本物のログイン画面をリバースプロキシで中継し、被害者が入力したID・パスワード・MFAコードを正規サーバへ転送。そして正規に発行されたセッションCookieを横取りします。
被害者は本物そっくりの画面でログインに成功し、違和感がありません。しかし攻撃者の手元には有効なセッションCookieが残る——マルウェア感染が不要なぶん、こちらも広く使われています。入口は違っても、ゴールは同じ「認証済みセッションの奪取」です。
感染経路：ClickFixや偽ソフトから
インフォスティーラーは、近年急増した ClickFix（偽CAPTCHAで自分でコマンドを実行させる手口） の主要な配布物の一つです。ほかにも、海賊版・クラック版ソフト、偽のアップデート、不正広告（マルバタイジング）、ゲームのチートなどが定番の入口です。
重要なのは、感染するのは私物端末でも構わないという点。在宅勤務や BYOD で、私物PCのブラウザに業務SaaSのセッションが残っていれば、そこから企業侵害に直結します。「個人の問題」では済みません。
クラウドでの悪用：Cookie-Bite
この攻撃はクラウド環境でとくに厄介です。Varonis が報告した Cookie-Bite では、Microsoft Entra ID／Microsoft 365 のセッションCookie（ESTSAUTH 等）を盗んでリプレイし、MFAを回避したまま長期間クラウドにアクセスし続ける手口が示されました。SaaS全盛のいま、1枚のCookieが組織全体への通行証になり得ます。
図解案：MFAの「守備範囲」と盗まれるポイント
時間 ──────────────────────────────────────────▶
[ログイン] ←MFAが守る区間→ [認証完了] ── 以降はCookieで通過 ──
│
▼ ★インフォスティーラー/AitMが狙うのはココ
セッションCookie
│ 窃取 → pass-the-cookie
▼
攻撃者が本人として侵入
（IDもPWもMFAも問われない）
要点：MFAは「入口の瞬間」だけを守る。発行後のCookieは別途守る必要がある。防御策
1. セッションを「端末に縛る」：DBSC とトークンバインディング
最も本質的な対策が、Cookieを盗んでも他の端末では使えなくすることです。Google は2026年4月、Chrome 146（Windows）で DBSC（Device Bound Session Credentials） を一般提供しました。DBSCはTPM などハードウェアに紐づく鍵でセッションを端末に暗号学的にバインドし、Cookieが流出しても別端末では無効にします。「盗まれてから検知する」発想から「盗まれても使えない」発想への転換です。
ただし万能ではありません。攻撃者が感染端末そのもの上で操作する場合や、サイト側がDBSCに対応していない場合は守れません。サーバ・ブラウザ双方の実装が広がるまでは過渡期が続きます。
2. ログインを強くする：FIDO2/Passkey
AitMフィッシングに対しては、フィッシング耐性のある FIDO2/Passkeyが有効です。Passkeyはオリジンに束縛されるため、中継プロキシ経由ではそもそも認証が成立しません。ただし前述のとおり、認証後のCookie窃取（pass-the-cookie）まで防ぐにはトークンバインディング/DBSCの併用が必要です。
3. セッションの寿命と再認証
- セッションを短命にし、重要操作では再認証（step-up認証）を求める。盗まれたCookieの有効時間を縮める。
- 条件付きアクセス：管理対象端末・コンプライアンス準拠端末からのみアクセスを許可し、未知の端末を弾く。
- 侵害が疑われたら全セッションを即時失効（サインアウト・トークン無効化）。パスワード変更だけでは生きているCookieは切れない。
4. 異常検知と端末防御
- セッション異常の監視：不可能な移動（impossible travel）、見慣れないUser-Agent・IP・デバイスフィンガープリントの変化を検知してセッションを止める。
- EDRと配布元対策：海賊版ソフト・不正広告・ClickFixを入口で断つ。私物端末（BYOD）にも最低限の保護と、業務アクセスの分離を。
- スティーラーログの監視：自組織のドメイン・従業員の認証情報がダークウェブ／Telegramに出回っていないかを監視し、出たら即リセット。
まとめ
インフォスティーラーとAitMフィッシングは、「MFAを突破する」のではなく「MFAの後にできるCookieをかすめ取る」ことで認証を迂回します。だからこそ、MFAを入れただけで安心するのは危険です。守りの軸は3つ——セッションを端末に縛る（DBSC/トークンバインディング）、ログインをフィッシング耐性化する（FIDO2/Passkey）、寿命を短くして異常を検知し即失効する。
入口を断つ観点では ClickFix や AIブラウザの乗っ取り も同じ「認証情報・セッション窃取」に行き着きます。認証方式そのものの比較は MFA・TOTP・FIDO2・Passkeyの違い 、セッション設計は セッション認証とJWT認証の違い も合わせてご覧ください。
※ 本記事の統計値・マルウェア名・手法は、各セキュリティベンダーの公表内容および報道に基づきます。攻撃・防御とも変化が速いため、対策時は最新の公式情報をご確認ください。