多要素認証の突破とは？MFA疲労・AiTMの手口、事例と防ぐ方法【2026年】

結論：多要素認証の突破とは？手口と防ぎ方の要点

多要素認証（MFA）は、知識・所持・生体のうち2つ以上を示してログインする仕組みだ。パスワードが漏れても、第2の要素が無ければ侵入できない――そのはずだった。

しかし実際には、「パスワード以外の確認手段」そのものを奪う、あるいは迂回する手口が確立している。多要素認証の突破とは、通知の承認・ワンタイムパスワード・認証後のセッションのいずれかを攻撃者が手に入れ、正規の利用者として入り込む行為を指す。

米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、「すべてのMFAが同じ強さではない」と明示し、一部の方式はフィッシング・プッシュ爆撃（push bombing）・SS7の脆弱性の悪用・SIMスワップに弱いと述べている（CISA「Implementing Phishing-Resistant MFA」2022年10月）。

根本の対策は、FIDO/WebAuthn（パスキーもこの仕組みに基づく）などフィッシングに耐える認証方式への切り替えである。移行できない間は、番号照合付きのアプリ認証に置き換え、AIによる異常検知（ログインの場所・端末・時間・操作の見張り）で補う。方式ごとの強さは本文の表で確認できる。

フィッシングの被害をAIでどこまで防げるかは、フィッシング対策にAIを使う方法で解説しています。

関連記事ラテラルムーブメントの手口とAIで止める方法は？

多要素認証とは：3つの要素の組み合わせ方と、突破される理由

多要素認証（MFA）は、ログインに「記憶（知っていること）」「所持（持っているもの）」「生体（本人の身体的特徴）」のうち、種類の違う要素を2つ以上使う方式だ（IPA「不正ログイン対策特集ページ」、CISA 2022年10月）。パスワードが漏れても、第2の要素が無ければログインできない。ただし、第2の要素に何を選ぶかで、突破されやすさが大きく変わる。

認証アプリ（TOTP）の仕組みと、SMS認証より安全な理由

認証アプリのワンタイムパスワードは、一般にTOTP（時間ベースのワンタイムパスワード）と呼ばれる。サービスと端末が最初に秘密の値を共有しておき、その値と現在時刻から、短時間だけ有効なコードを端末の中で計算する仕組みだ。標準規格のRFC 6238では、コードの切り替え間隔の既定は30秒とされている（IETF RFC 6238）。コードは端末の中で作られ、携帯電話の回線を通らない。

SMSのコードは、携帯電話の回線を通って届く。このため、CISAは、SMS・音声がフィッシング・SS7の脆弱性・SIMスワップのいずれにも弱いと整理している。これに対して認証アプリは、SS7とSIMスワップの対象にならない。ただし、偽サイトにコードを入力させる手口には、どちらも弱い（CISA 2022年10月）。つまり、SMSより安全だが、フィッシングに耐える方式ではない。

「二要素認証」「二段階認証」「多要素認証」の違い

IPAは、「多段階認証」などの多段の認証方式を総称して多要素認証と表記し、記憶・所持・生体のうち2つ以上を用いる方式と説明している（IPA）。二要素認証は要素が2つの場合、二段階認証は認証の回数が2回の場合を指す言葉で、見る観点が違う。パスワードを2回入れる方式は二段階だが、種類が同じなので多要素認証ではない。本記事では、違う種類の要素を重ねる方式を多要素認証として扱う。

パスワード側の攻撃（総当たりや、漏えいしたIDとパスワードの投入）は、多要素認証で止まる。その手口はブルートフォース攻撃の解説で扱っている。本記事は、その先にある、第2の要素を破る手口を扱う。

MFAが突破される3つの理由

• 要素そのものを渡してしまう：偽サイトにパスワードとコードを入力する、電話でコードを聞き出される。
• 承認操作を誤らせる：プッシュ通知を連打して、利用者に「承認」を押させる（MFA疲労攻撃）。
• 認証の後ろや手続きを狙う：MFA通過後のセッションCookieを盗む、ヘルプデスクに電話して認証方式を付け替えさせる。

次の章で、それぞれの手口を方式との相性とあわせて整理する。

多要素認証の突破：攻撃の流れと主な手口

多要素認証の突破は、侵入の段階によって手口が異なる。下の図は、攻撃者が認証の各段階でどう動くかと、各段階に対応するAI防御の層を示したものだ。

主な手口を以下の表に整理する。

多要素認証の突破手口と弱点となるMFA方式（CISA 2022年10月・Microsoft 2023年6月）

手口	攻撃の概要	特に弱いMFA方式
MFA疲労攻撃（プッシュ爆撃）	承認するまでプッシュ通知を浴びせ続け、利用者に押させる	番号照合なしのプッシュ通知
フィッシング（偽サイトでの入力取得）	偽ログインページでパスワードに加えOTPまで入力させる	アプリOTP・SMS・音声
中継型フィッシング（AiTM）	利用者と正規サービスの間に入り、MFA通過後のセッションCookieを盗む	すべての方式（セッション奪取のため）
SIMスワップ	携帯会社を説得して電話番号を攻撃者のSIMに移し、SMSコードを受け取る	SMS・音声
SS7の脆弱性悪用	通信基盤SS7の弱点を突き、SMSコードを取得する	SMS・音声
ワンタイムパスワードの聞き出し	IT担当者を装い、従業員にOTPを共有させる	すべての方式
ヘルプデスクへのなりすまし	従業員を装ってヘルプデスクに電話し、パスワードリセットやMFA移行を求める	方式に依存しない（手続きの悪用）
マルウェアによるCookieの窃取	端末に入り込んだ情報窃取型のマルウェアが、MFA通過後のCookieを抜き取り、別の端末で再利用する	すべての方式（セッション奪取のため）
認証方式の追加（居座り）	侵入後、攻撃者が自分の電話番号などをMFA方式として追加し、パスワードを変えられても入り続ける	方式に依存しない（追加時に再認証が要らない設定の盲点）

CISAは、SMS・音声によるMFAを「最後の手段」と位置づけている。番号照合のないプッシュ通知も、プッシュ爆撃に対して脆弱だ。一方、FIDO/WebAuthnに基づくフィッシング耐性MFAは、偽サイトでは動作しない仕組み上、フィッシング・AiTM・SIMスワップの大半を構造的に無効化する（CISA「Implementing Phishing-Resistant MFA」2022年10月）。

中継型フィッシング（AiTM）の流れ

AiTMでは、攻撃者の偽サイトが利用者と本物のサービスの間に入り、入力された内容を中継する。利用者は本物と同じ画面でMFAを済ませるため、異変に気づきにくい。攻撃者が手に入れるのはパスワードやコードそのものより、MFAを通過した後に発行されるセッションCookieだ。盗んだCookieは「すでに認証を済ませた証明」として使えるため、再度のMFAを求められない（Microsoft Security Blog、2023年6月8日）。

マルウェア（情報窃取型）によるCookieの窃取

偽サイトを使わず、端末に入り込んだマルウェアでCookieを抜き取る手口もある。Microsoftは、ブラウザでサインインするとセッションごとにCookieが保存され、端末を侵害した攻撃者がそれを別の端末のブラウザへ渡す「pass-the-cookie」で認証の確認を回避できると説明している。マルウェアの中にはブラウザのCookieを抜き取って外部へ送る機能を持つものがあり、私用端末は管理が弱く特に危険だとしている（Microsoft Security Blog「Token tactics」、2022年11月16日）。前述のUberの事例でも、攻撃の起点は委託先の端末のマルウェア感染だったとUberは説明している。

この手口は、MFAの方式を強くしただけでは止まらない。Microsoftは、許可した端末だけにアクセスを限る、継続的アクセス評価を使う、FIDO2のようなフィッシングに強い認証に切り替える、といった対策を挙げている（Microsoft Security Blog 2022年11月16日）。

実際に起きた多要素認証の突破事例

Uber（2022年9月）――MFA疲労攻撃

Uberは2022年9月、委託先担当者のアカウントを通じた侵害を公表した。Uberの説明では、攻撃者は委託先端末のマルウェア感染によってダークウェブに流出した社内パスワードを購入し、ログイン試行を繰り返したとみている。ログインのたびに二要素の承認要求が委託先に届き、最初はアクセスを防いだが、「最終的に委託先が1件を承認し、攻撃者はログインに成功した」（Uber Security Update、2022年9月15日〜19日）。攻撃者はその後、他の従業員アカウントに侵入し、G-SuiteやSlackの権限を昇格させ、内部のSlackメッセージの一部と経理ツールの情報をダウンロードした。アプリを動かす本番系システムや機微なユーザー情報DBへのアクセスは確認されなかったとUberは述べている。Uberは攻撃者がLapsus$と関係するとみている（2022年9月19日の更新）。

MFA疲労攻撃への直接の対策は番号照合（number matching）だ。承認時に認証基盤側に表示された数字をアプリに入力させる方式で、無差別な承認を防ぐ（CISA 2022年10月）。

Microsoftが公表したAiTMフィッシング事例（2023年6月）

Microsoftは2023年6月8日、多段のAiTMフィッシングとBEC（ビジネスメール詐欺）の事例を公表した。取引先を装ったメールのリンクから、偽のOneDriveプレビュー、さらにMicrosoftサインインを模した偽ページへ誘導し、認証セッションの途中でセッションCookieを盗む構造だ。盗んだCookieは数時間後、別のIPアドレス（米国）から再利用され、パスワードとMFAを迂回してログインした。攻撃者はその後、被害者の連絡先に16,000通を超えるフィッシングメールを送信した（Microsoft Security Blog、2023年6月8日）。

AiTMが特に危険なのは、盗んだCookieが「すでに正規の認証を通過したセッション」として機能するためだ。MFAの設定に問題があるわけではなく、セッション自体が奪われている。Microsoftは対応として、セッションCookieの失効と、攻撃者が追加したMFA方式の削除を推奨している。パスワードの変更だけでは不十分だ。

また、攻撃者は電話番号ベースのOTPサービスをMFA方式として追加して居座っていた。「新しいMFA方式の追加は、既定では再認証を必要としない」という設定上の盲点を突いた手口だ（Microsoft Security Blog、2023年6月8日）。

Cloudflare（2022年7月）――ワンタイムコードまで盗む偽サイトが、セキュリティキーで止まった

Cloudflareは2022年7月20日、従業員への大規模なSMSフィッシングを受けたと公表した。同社によれば、1分足らずの間に少なくとも76人の従業員の私用・業務用の電話にメッセージが届いた。リンク先はOktaのログイン画面を模した偽サイトで、ユーザー名とパスワードに続いて、時間制限付きのワンタイムコード（TOTP）まで入力させ、攻撃者が本物のログイン画面へ即座に使う仕組みだった。3人の従業員が認証情報を入力した。

それでも侵入は成立しなかった。同社は全従業員にFIDO2のセキュリティキーを配っており、TOTPを使っていなかったためだ。キーはサイトの正規ドメインに結び付く（origin binding）ので、偽サイトを経由した認証は完了しない。攻撃者のログイン試行は、正しいパスワードを持っていても、ハードウェアキーの確認で止まった（Cloudflare Blog、2022年）。ワンタイムコードを盗む偽サイトには、アプリやSMSのコードでは耐えられず、FIDO2のような方式が耐えるという実例だ。

Cisco（2022年5月）――個人アカウント経由の情報取得、電話とMFA疲労で承認させた

Ciscoは2022年5月24日に侵害の可能性を把握した。同社のTalosの報告では、攻撃者はまず従業員の個人のGoogleアカウントに入り込んだ。そのアカウントにはブラウザの同期機能で会社の認証情報が保存されていた。攻撃者は、信頼できるサポート組織を名乗る電話（ボイスフィッシング）とMFA疲労攻撃を重ね、最終的にMFAのプッシュ通知が承認されてVPNへのアクセスを得た。持ち出されたのは、侵害された従業員のBoxフォルダの中身と、Active Directoryの従業員の認証データだった。Talosは、Boxのデータは機微なものではなく、重要な内部システムに到達した証拠は確認していないと述べている（Cisco Talos、2022年8月10日）。電話での働きかけと通知の連打を組み合わせる点が、Uberの事例と共通する。

Twilio（2022年8月）――従業員への偽ログイン画面で認証情報を盗まれた

Twilioは、2022年7月中旬に、現職・元従業員へSMSが送られたと公表した。パスワードの期限切れなどを装い、TwilioやOktaを模した偽のログイン画面へ誘導する内容だった。同社は2022年8月4日に不正アクセスに気づき、一部の従業員が認証情報を入力したとしている。影響を受けたのは顧客209社（顧客全体は27万社超）と、Authyの利用者93人だった。同社は、コンソールの認証情報・認証トークン・APIキーへのアクセスの証拠は無いと述べ、事後にFIDO2のトークンを配布した（Twilio、2022年10月27日に調査完了）。

国内インターネットバンキングの不正送金

警察庁・金融庁は2023年12月25日の注意喚起で、2023年11月末時点の国内インターネットバンキング不正送金被害が5,147件・約80.1億円に達し、いずれも過去最多だと公表した。銀行を装った偽サイトへIDやワンタイムパスワードを入力させる手口が多数確認されている（警察庁・金融庁、2023年12月25日）。警察白書令和7年版によれば、2024年は4,369件・約86億8,900万円で、件数は減少したものの被害額は依然として高水準にある。2025年（令和7年）の被害額は約103億9,700万円で過去最悪となり、法人の被害額は前年の4倍を超えた。手口の約9割はフィッシングとされる（共同通信、2026年3月12日）。

国内のフィッシング・ハッキング被害の全体像については、AIハッキングと情報漏洩の被害一覧も参照されたい。

パスキー（FIDO/WebAuthn）が中間者攻撃に強い理由と、導入の手順

AiTMのように偽サイトを中継する攻撃に対して、CISAが「広く使えるフィッシング耐性の認証はFIDO/WebAuthnのみ」とするのは、仕組みが違うためだ。

パスキーは、暗号の鍵のペアでログインする方式だ。秘密鍵は利用者の端末やセキュリティキーに残り、サービスには公開鍵だけを渡す。ログインのたびに、サービスが送る使い捨ての乱数（チャレンジ）へ秘密鍵で署名して返す（FIDO Alliance「Passkeys」）。WebAuthnの仕様は、公開鍵の資格情報は、登録したサービスのオリジンからしか使えず、この制限をブラウザと認証器が一緒に守ると定めている（W3C「Web Authentication」第1章）。

この結果、偽サイトの画面で何を入力させても、ブラウザは本物とは別のドメインだと判断して、署名を作らない。入力する文字列も、転送できるコードも無いので、中継役の偽サイトは盗むものを持てない。2022年のCloudflareの事例（前掲）は、ワンタイムコードまで盗む偽サイトに対して、FIDO2のセキュリティキーが実際に侵入を止めた例だ。

パスキー導入の手順

導入は、管理者アカウントとメール・クラウドなどの重要なサービスから始め、全体へ広げる（CISA 2022年10月）。

パスキーにしても残る手口

• ヘルプデスクへのなりすまし：認証方式ではなく、本人確認の手続きを突く手口は残る。CISAは、電話でのパスワードリセットやMFAの付け替えへの本人確認の強化を求めている（CISA AA23-320A）。
• サインイン後のCookieの窃取：サインインの後に発行されるセッションCookieが端末から盗まれる手口は、サインイン方式とは別の問題だ（本記事の整理。Microsoft 2022年11月の説明に基づく）。許可した端末への限定と、継続的アクセス評価で備える。
• 認証器の選び方：パスキーは、クラウドを通じて端末間で同期できるものと、特定の端末に固定されるもの（セキュリティキーなど）がある（FIDO Alliance）。管理者のような重要なアカウントでは、端末に固定する型も選べる。

自社の多要素認証は大丈夫か：方式別の強さと確認の手順

ここまでの手口を、「どの方式のMFAに通用するか」で見直すと、点検すべき順番が決まる。CISAは、MFAの方式を突破への強さで次のように並べている（CISA「Implementing Phishing-Resistant MFA」2022年10月）。

CISAは、フィッシング耐性MFAを「ゴールドスタンダード」とする一方、「どの形のMFAでも、無いよりは良い」とも述べている。SMS・音声は最後の手段であり、強い方式へ移るまでの一時的な措置として使える、という位置づけだ（CISA 2022年10月）。

自社の状況を確かめる手順は、次の3つに絞れる。

1. 管理者アカウントと、メール・クラウドなど重要なサービスが、どの方式を使っているかを一覧にする。
2. 表の下の行にあたる方式（番号照合なしのプッシュ、SMS・音声）から、番号照合付きのアプリ認証へ置き換える。
3. 管理者権限と重要なシステムから順に、FIDO/WebAuthnへ移す計画を立てる。MFAに対応していないシステムは洗い出し、経営層へ報告する（CISA 2022年10月）。

具体的な導入の順序と、AiTMやヘルプデスクへの備えは、次の「対策」の章で説明する。

多要素認証の突破を防ぐ対策：導入の優先順位

多要素認証の突破を防ぐための対策は、以下の優先順で進めるのが現実的だ。

1. フィッシング耐性MFAへの移行。CISAは、広く使えるフィッシング耐性認証はFIDO/WebAuthn（パスキーはこの仕組みに基づく資格情報）のみだとし、「MFAのゴールドスタンダード」と呼ぶ。物理トークン（USB・NFC）と、PCやスマートフォンに内蔵されたプラットフォーム認証器がある。偽サイトでは動作しない設計上、フィッシング・AiTMを無効化できる。まず管理者権限や重要なシステムから段階的に導入する（CISA 2022年10月）。

2. 移行できない間の次善策。番号照合付きのアプリ認証に置き換える。CISAは中小企業の次善策としてこれを挙げる。SMS・音声は最後の手段と位置づける。

3. MFA非対応システムの棚卸し。MFAに対応していないシステムを洗い出し、対応またはMFA対応システムへの移行を計画する。残存リスクは経営層にエスカレーションする（CISA 2022年10月）。

4. ヘルプデスクの本人確認強化。CISAは、パスワードのリセットやMFA移行を求める電話の手口を挙げ、本人確認手順の強化とフィッシング耐性MFAの導入を推奨している（CISA AA23-320A、2023年11月16日公開・2025年7月29日更新）。

5. リスクベースの条件付きアクセスとログ監視の整備。リスクの高いログインの検知と、EDR・ネットワーク監視のログ確認体制を整える（Microsoft Security Blog 2023年6月8日・CISA AA23-320A）。

6. 侵害後の対処手順の確立。パスワードの変更だけでは不十分だ。セッションCookieの失効と、攻撃者が追加したMFA方式の削除まで行う。MFAの更新時に再認証を求める設定も推奨されている（Microsoft Security Blog 2023年6月8日）。

導入のコストと使い勝手：SSO・IDaaSとMFAをどう組み合わせるか

MFAは、強い方式ほど利用者の手間と運用の負担が増える。ここで現実的な選択肢を整理する。

• まず「全員にMFA」を優先する：CISAは「どの形のMFAでも、無いよりは良い」とし、フィッシング耐性MFAへの移行を優先度の高い取り組みとして位置づけている（CISA 2022年10月）。
• すぐに移行できない中小企業には、番号照合付きのアプリ認証：CISAは、アプリのOTP、トークンのOTP、番号照合付きのプッシュを、フィッシング耐性MFAをすぐに導入できない中小企業の最善の選択肢の一つとしている。
• MFAに対応していないシステムは、SSOにまとめる：CISAは、MFA対応のシステムへの追加は、企業のID管理とシングルサインオン（SSO）の仕組みとの連携で可能なことが多いとしている。ログインを一か所に集約すれば、そこにフィッシング耐性MFAをまとめてかけられる（CISA 2022年10月）。
• 配るコストと復旧の運用を見積もる：Cloudflareは全従業員にセキュリティキーを配って防いだ（前掲）。キーを配る場合は、配布・紛失時の再発行・ヘルプデスクでの本人確認の費用が要る。

MFA導入のデメリットと、その抑え方

AIによる突破の検知（リスクベース認証・行動分析）：補助として何ができ、何ができないか

AIを使った防御は、多要素認証の突破が起きる3つの段階それぞれに有効なアプローチがある。

攻撃段階別のAI防御手段（Microsoft Security Blog 2023年6月・CISA 2022年10月を基に整理）

段階	攻撃の内容	AIを使った防御の仕組み	代表的な検知シグナル
①フィッシング前	偽メール・偽サイトへの誘導	AIメールフィルタによる不審メールの検出、悪意あるサイトを遮断するWebフィルタ・ブラウザ保護	送信元ドメインの偽装、リンク先のレピュテーション低下
②ログイン時（認証の異常）	OTP取得・プッシュ爆撃・SIMスワップ後のログイン	リスクベースの条件付きアクセス（不審な場所・ISP・端末・匿名化サービスの利用を検知し、追加認証または遮断）、ありえない移動（impossible travel）の検知	普段と異なるISP・ユーザーエージェント、地理的に不自然な移動
③ログイン後（セッション・居座り）	盗んだCookieの再利用・MFA方式の追加・転送ルール設置	セッション異常検知（別のIPからの再利用、受信トレイ転送ルールの作成、リスクの高いサインインをフラグ）、連続アクセス評価（Continuous Access Evaluation）の実装	新しいMFA方式の追加、受信トレイ転送ルールの作成、短時間での不審なメール削除

ログイン時の対策として特に実効性が高いのは、リスクベースの条件付きアクセスだ。Microsoftは、信頼できるIPアドレスや準拠した端末の使用を条件とし、ありえない移動や普段と異なるISP・ユーザーエージェントの利用を継続的に監視・ハンティングすることを推奨している（Microsoft Security Blog、2023年6月8日）。

ログイン後のセッション監視では、受信トレイの転送ルール作成や新しいMFA方式の追加が重要な検知シグナルとなる。連続アクセス評価を実装することで、盗んだセッションの有効期限内での悪用を抑止しやすくなる。

AIセキュリティ対策の全体像については、AIセキュリティ対策の解説を参照されたい。

Microsoftが示す具体策：番号照合・トークン保護・継続的アクセス評価

Microsoft Entra IDの公式ドキュメントには、多要素認証の突破に対応する仕組みが具体的に示されている。

• 番号照合（number matching）：Authenticatorアプリのプッシュ通知では、サインイン画面に表示された数字をアプリに入力しないと承認できない。利用者がこの機能を無効にすることはできず、通知の連打で誤って承認させるMFA疲労攻撃への対策になる（Microsoft Learn）。
• トークン保護（Token Protection）：条件付きアクセスの設定で、端末に暗号的に結び付いたサインインのトークンだけを受け付ける。中継型フィッシングでトークンを盗まれても、別の端末からは使えなくなる。Microsoftは、試験運用、記録だけのモード、強制の順で導入することを勧め、トークン窃取への多層防御の一部として使うよう明記している（Microsoft Learn）。
• 継続的アクセス評価（CAE）：アカウントの無効化、パスワードの変更、高リスクの検知などが起きると、Exchange Online・SharePoint Online・Teamsのセッションを短時間で失効させる。盗まれたセッションが長く使われ続けるのを防ぐ（Microsoft Learn）。

いずれも、AIによるリスク判定と組み合わせて使う仕組みであり、フィッシングに強い認証方式への移行と並行して設定する。

AIによる防御の限界と注意点

AIを使った検知には、構造的な限界がある。整理しておくことが、現実的な対策設計につながる。

AiTMはMFAの「欠陥」ではない。盗まれたセッションCookieは、すでに正規の認証を通過したセッションを表す。トークンの有効期限前であれば、攻撃者はMFAなしで利用者として操作できる（Microsoft Security Blog、2023年6月8日）。MFAの設定を強化しても、セッション奪取後の再利用を直接防ぐことはできない。必要なのは、連続アクセス評価とセッションの失効設定だ。

誤検知と見落としのトレードオフ。条件付きアクセスは、出張中の社員やVPN利用を誤検知しうる。逆に、攻撃者が利用者に近い場所・端末の特徴でアクセスすれば、検知をすり抜ける可能性がある。AIによる異常検知はリスクの低減であり、完全な排除ではない。

方式ごとの強さの差。CISAの整理では、SMS・音声はフィッシング・SS7・SIMスワップに弱く「最後の手段」、番号照合なしのプッシュ通知はプッシュ爆撃に弱い。アプリのOTPや番号照合付きプッシュはフィッシングには依然として弱い。AIによる検知を整備しても、MFA方式自体が弱ければ突破のリスクは残る（CISA「Implementing Phishing-Resistant MFA」2022年10月）。

ほかの侵入の手口と対策

多要素認証の突破は、ほかの手口と組み合わせて使われることが多い。関係する手口の仕組みと対策は、それぞれの解説ページにまとめている。

手口全体の見取り図と、AIを使った対策の優先順位はAIセキュリティ対策の解説で扱っている。

よくある質問

多要素認証を導入していれば安全か

導入しないよりは確実に安全だが、方式によって強さが異なる。CISAは、SMS・音声、番号照合のないプッシュ通知は、フィッシング・SIMスワップ・プッシュ爆撃に弱いとしている。最も強いのはFIDO/WebAuthnなどのフィッシング耐性MFAだ（CISA 2022年10月）。

MFA疲労攻撃とは何か

承認するまでプッシュ通知を送り続ける手口だ。2022年9月のUberの事例では、委託先が最終的に1件を承認してログインされた（Uber Security Update 2022年9月）。対策は番号照合の有効化と、フィッシング耐性MFAへの移行だ。

中継型フィッシング（AiTM）はなぜMFAを突破できるのか

正規サービスとの間に入り、MFA通過後のセッションCookieを盗んで再利用するためだ。盗んだCookieはすでに認証済みのセッションを表すため、再度のMFA入力を求められない。Microsoftの2023年6月の公表事例では、数時間後に別のIPアドレスから使われた。

ヘルプデスクへのなりすましにどう備えるか

CISA AA23-320Aは、パスワードのリセットやMFAの移行を求める電話の手口を取り上げている。本人確認手順の強化と、フィッシング耐性MFAの導入が推奨されている（2025年7月29日更新）。

侵害されたらパスワードを変えれば十分か

不十分だ。セッションCookieの失効と、攻撃者が追加したMFA方式の削除が必要だ（Microsoft Security Blog 2023年6月8日）。侵害後の対処手順として、これをあらかじめ定めておく必要がある。

SMSの多要素認証は使い続けてよいか

無いよりは良いが、最後の手段だ。CISAは、SMS・音声がフィッシング・SS7の脆弱性・SIMスワップに弱いとし、強い方式へ移るまでの一時的な措置として使うものと位置づけている（CISA 2022年10月）。重要なアカウントから、番号照合付きのアプリ認証、さらにFIDO/WebAuthnへ置き換えるのが順序だ。

パスキー（FIDO/WebAuthn）にすれば突破されないか

偽サイトでは動作しない設計のため、フィッシングやAiTMには耐える（CISA 2022年10月）。ただし、ヘルプデスクへのなりすましのように、方式ではなく手続きを悪用する手口は残る。本人確認手順の強化も合わせて進める必要がある（CISA AA23-320A）。

マルウェアに感染していたら、MFAは意味がないのか

無意味ではないが、サインイン後のCookieを抜かれると突破される。Microsoftは、許可した端末への限定、継続的アクセス評価、FIDO2など強い認証への切り替えを挙げている（Microsoft Security Blog 2022年11月16日）。端末の感染対策と、セッションの失効を合わせて行う。

認証アプリはSMSより安全か

SS7の脆弱性やSIMスワップの対象にならない分、SMSより安全だ。ただし偽サイトにコードを入力させる手口には、どちらも弱い（CISA 2022年10月）。

MFAの方式を強くすると、使いにくくならないか

番号照合付きの認証アプリは、番号を1回入力する手間が増えるだけだ。パスキーは、パスワードの入力が要らなくなる。まず管理者と重要なサービスから適用し、利用者の負担を確認しながら広げる（CISA 2022年10月）。

参考文献

• 警察庁の数値（神奈川県警察の資料）
  https://www.police.pref.kanagawa.jp/assets/entry/d7034_09.txt
• 共同通信（秋田魁新報、2026年3月12日）ネットバンキング不正送金の被害額
  https://www.sakigake.jp/news/article/20260312CO0052/
• Microsoft Learn「How number matching works in MFA push notifications」
  https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match
• Microsoft Learn「Token protection in Microsoft Entra Conditional Access」
  https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
• Microsoft Learn「Continuous access evaluation」
  https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
• CISA「Implementing Phishing-Resistant MFA」（2022年10月）
  https://cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• CISA Cybersecurity Advisory AA23-320A（2023年11月16日公開・2025年7月29日更新）
  https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
• Microsoft Security Blog「Detecting and mitigating a multi-stage AiTM phishing and BEC campaign」（2023年6月8日）
  https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/
• Uber Security Update（2022年9月15日〜19日）
  https://www.uber.com/en-US/newsroom/security-update/
• 警察庁・金融庁「インターネットバンキングに係る不正送金被害の急増について」（2023年12月25日）
  https://www.npa.go.jp/bureau/cyber/pdf/20231225_press.pdf
• 警察白書 令和7年版（2026年、インターネットバンキング不正送金統計）
  https://www.npa.go.jp/hakusyo/r07/honbun/html/bb3312000.html
• Cloudflare Blog「The mechanics of a sophisticated phishing scam and how we stopped it」（2022年）
  https://blog.cloudflare.com/2022-07-sms-phishing-attacks/
• Cisco Talos「Cisco Talos shares insights related to recent cyber attack on Cisco」（2022年8月10日）
  https://blog.talosintelligence.com/recent-cyber-attack/
• Twilio「Incident Report: Threat Actors Gain Access to Twilio’s Systems」
  https://www.twilio.com/en-us/blog/august-2022-social-engineering-attack
• Microsoft Security Blog「Token tactics: How to prevent, detect, and respond to cloud token theft」（2022年11月16日）
  https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/
• FIDO Alliance「Passkeys」
  https://fidoalliance.org/passkeys/
• W3C「Web Authentication: An API for accessing Public Key Credentials」
  https://www.w3.org/TR/webauthn-3/
• IETF RFC 6238「TOTP: Time-Based One-Time Password Algorithm」
  https://www.rfc-editor.org/rfc/rfc6238
• IPA「不正ログイン対策特集ページ」
  https://www.ipa.go.jp/security/anshin/measures/account_security.html
• MGM Resorts SEC Form 8-K（2023年10月5日）
  https://www.sec.gov/Archives/edgar/data/789570/000119312523251667/d461062d8k.htm