パスワードだけでなく、スマートフォンの認証も済ませた。それなのに、他人が自分のアカウントに入ってしまう。多要素認証（MFA）の突破は、追加の認証を計算で解読するような攻撃だけを意味するわけではありません。
偽サイトが本人の認証を本物へ中継する、通知を繰り返して承認させる、認証後のログイン状態を盗む。攻撃者は、本人しか通れない確認を壊す代わりに、本人が通った結果を利用することがあります。
本記事では、MFAが突破される主な仕組みを、どの段階が狙われるかに沿って説明します。その理解を土台に、パスキーとの違いや、被害時にパスワード変更だけで終われない理由を整理します。
多要素認証とは？パスワードを盗まれただけでは入れない仕組み
多要素認証は、知っている情報、持っているもの、身体の特徴といった異なる種類の要素を組み合わせ、本人を確認する仕組みです。パスワードに加えて、認証アプリやセキュリティキーなどを使います。パスワードと秘密の質問のように、知識だけを二回尋ねる方式とは区別されます。
追加確認があれば、パスワードだけを入手した攻撃者は、そのままログインしにくくなります。しかし、確認を本人に実行させたり、確認が終わった後を狙ったりする攻撃まですべて止めるとは限りません。
MFAをどのシステムに適用するかは、SCSと多要素認証の解説で扱っています。本記事の焦点は、適用範囲とは別の、突破の仕組みです。
手口1：偽サイトが認証を中継するAiTMフィッシング
AiTM（Adversary-in-the-Middle）は、利用者と正規サービスの間に攻撃者が入り込む手口です。ここでは、偽ログインサイトが正規サービスとの通信を中継する場面を考えます。
利用者が偽サイトへパスワードを入力すると、攻撃者側がその情報を本物のサービスへ渡します。本物が認証コードを求めると、その画面を利用者に見せ、入力されたコードもすぐ本物へ渡します。
有効期限の短いワンタイムコードでも、間に合ってしまう理由
ワンタイムコードは、古いコードの再利用を防ぐうえで役立ちます。ただし、中継型の攻撃は、本人が入力した有効なコードを、その有効時間内に使います。コードを後で解読する必要がない点が、直感と異なるところです。
正規サービスから見ると、正しいパスワードと追加確認が届いています。利用者も実際に認証を済ませます。その途中で、攻撃者が認証済みの状態を手に入れることがあります。
認証後のセッション情報が盗まれると何が起きるのか
ログインするたびにパスワードを入れずに済むのは、サービスが認証済みの状態を識別しているためです。ブラウザーのセッションCookieなどが、その状態を示す情報になります。
Microsoftが2022年に公表した分析では、中継型フィッシングでセッションCookieを盗み、メールボックスへアクセスして、後続の送金詐欺へ進む攻撃が説明されています。
盗まれた情報が有効で、サービス側の追加制御に止められなければ、攻撃者は認証後の状態を悪用できます。すべてのCookieがログインに使えるわけではなく、端末との結び付けや有効期限などによっても条件は変わります。
手口2：承認通知を繰り返すMFA疲労攻撃
スマートフォンに「ログインを承認しますか」という通知を送る方式では、攻撃者が取得したパスワードでログインを繰り返し、通知を大量に発生させることがあります。
本人が一度も承認しなければ、追加認証は防御として働きます。しかし、通知を止めようとして承認したり、社内サポートを名乗る相手の説明に応じたりすると、攻撃者のログインを許可してしまいます。これは暗号を解く攻撃ではなく、承認操作を誘う攻撃です。
Uberの事例：追加認証は最初は侵入を止めていた
Uberは2022年9月19日の更新で、外部契約者のアカウントに攻撃者が繰り返しログインを試み、本人に二要素認証の承認要求が届いたと説明しました。最初はアクセスを止めていたものの、最終的に一度承認され、侵入に至ったとしています。
同社はパスワードの入手経路について、マルウェア感染後にダークウェブで購入された可能性を挙げています。これは同社の当時の推定です。また、公表文だけから本人が承認した心理的理由までは分かりません。
通知に数字の照合を加える方式は、承認ボタンだけを押す方式より誤承認を減らす助けになります。ただ、それを偽サイトの中継に強い方式と同一視はできません。防ぐ操作が違うためです。
手口3：端末や復旧経路から、認証の外側を狙う
セッション情報は、偽サイトの中継だけでなく、端末に入り込んだマルウェアから盗まれることもあります。認証が強くても、ログイン後の端末を操作されたり、有効な情報を持ち出されたりすれば、別の防御が問われます。
また、電話番号を不正に移すSIMスワップでは、SMSの受信先が攻撃者側へ変わる場合があります。本人確認が弱いサポート窓口や復旧手順も、通常の認証とは別の入口になります。いずれも、すべてのサービスで同じ条件で成功するわけではありません。
見慣れた画面から利用者に不正な操作を実行させる手口は、ClickFixと偽の人間認証でも説明しています。MFAの導入と、端末で何を実行するかの防御は、両方が関係します。
パスキーは何が違う？偽サイトへ渡せるコードを使わない
パスキーは、公開鍵暗号を使う認証の仕組みです。秘密鍵そのものをログイン先へ送らず、利用するサイトと結び付いた認証を行います。そのため、別ドメインの偽サイトへ認証コードを渡し、そのまま本物へ中継する手口への耐性があります。
顔や指紋、端末のPINは、手元のパスキーを使う確認に利用されます。「顔認証だからフィッシングに強い」というより、正規のサイトとの結び付きがある点に違いがあります。
| 認証・攻撃の場面 | 狙われるもの | 強化を考える方向 |
|---|---|---|
| コード入力の中継 | 本人が入力する有効なコード | サイトに結び付いた耐フィッシング認証 |
| 通知の大量送信 | 本人による承認 | 数字照合、通知異常の検知、強い認証方式 |
| ログイン後の情報盗難 | セッション、端末内の情報 | 端末防御、セッション管理、アクセス条件 |
| 復旧経路の悪用 | 再設定の本人確認 | 代替方式・復旧手続きの確認 |
パスキーを導入しても、端末の侵害や弱い代替ログイン方法まで自動的に解消されるわけではありません。パスキーによる認証が強くても、同じアカウントへSMSなど別の方法で入れるなら、そちらが狙われる余地があります。
MFA突破の対策は、認証の前・最中・後を分けて考える
仕組みを理解すると、社員に「認証コードを教えないように」と伝えるだけでは届かない部分が見えてきます。本人は本物のログインだと思ってコードを入力している場合もあるためです。
企業で検討するなら、メールや管理者アカウントなど影響の大きい場所から、耐フィッシング認証への移行を考える方法があります。その際、端末やサービスの対応、紛失時の復旧も合わせて確認すると、通常時だけ強い仕組みに偏りにくくなります。
身に覚えのない承認通知は、誰かがパスワードを使っている兆候として扱えます。本人が拒否して終わるだけでなく、社内の相談先へ伝われば、アカウントの確認につながります。
すでに不正アクセスが疑われる場合、パスワード変更に加えて、有効なセッションの取り消し、登録済み認証方法や不審なメール転送設定の確認なども検討対象になります。実行できる機能はサービスごとに異なります。事故の初動対応と合わせ、管理者や専門担当者が確認する範囲を整理できます。
多要素認証の突破についてのFAQ
MFAが突破されるなら、導入しても意味がありませんか？
パスワードだけを盗む攻撃に対しては、追加の確認が防御になります。突破手口があることと、導入の意味がないことは別です。どの方式を使い、端末やログイン後をどう守るかで、防御を重ねられます。
認証アプリを使えば、SMSより必ず安全ですか？
認証アプリにも、コードを表示する方式、通知を承認する方式、パスキーを使う方式などがあります。アプリという名称だけでは攻撃への耐性を判断できません。実際にどんな操作で認証するかが比較の材料になります。
パスワード変更だけで、盗まれたログイン状態も無効になりますか？
サービスの設定やセッション管理によって異なります。変更だけですべて無効になるとは限らないため、不正アクセス時はセッションの取り消しなどを含め、管理者が確認することになります。
「本人が認証した」後に、誰が使っているかまで考える
MFAの突破には、本人の認証を中継する、承認を誘う、認証後の状態を盗むといった異なる経路があります。追加確認の回数だけを増やしても、同じ経路に情報を渡すなら解決しない場面があります。
自社の方式を考える際には、どの攻撃のどの段階を止められるのかが判断の軸になります。認証の仕組みを理解することは、「MFAあり」という表示の先にある、実際の防御を確かめる手がかりになります。
参考資料
- Microsoft：多要素認証の概要：認証要素の基本。
- Microsoft：AiTMから送金詐欺への分析：2022年7月12日。認証中継とセッションCookie盗難。
- Microsoft：クラウドのトークン盗難：2022年11月16日。認証後のアクセスと対応。
- Uber：Security update：2022年9月19日更新部分。承認要求と侵入の経過。
- FIDO Alliance：パスキー：サイトに結び付いた公開鍵認証とフィッシング耐性。
- Microsoft：フィッシングに強いMFA：認証方式の強化と復旧・導入時の条件。
本記事の文章・表・図解・グラフは、Skill Business Architecture Labが独自に編集・作成しています。引用・紹介する場合は、引用箇所が分かる形で、記事名・サイト名・記事URLをご記載ください。
コメント