「多要素認証（MFA）を導入しているから安全」―そう考えている方は多いのではないでしょうか。しかし2026年4月、Microsoftが公開したレポートは、その安心感を根本から揺るがす内容でした。
報告されたのは、AIを活用した大規模なフィッシング攻撃の実態です。この攻撃の厄介なところは、MFAのパスワードを「盗む」のではなく、認証の仕組みそのものを「すり抜ける」設計になっていること。しかも攻撃ツールが「サービス」として流通しており、高度な技術を持たない攻撃者でも実行できる状況が生まれています。
Microsoftによると、この攻撃は2025年2月に確認された類似のキャンペーンからさらに進化しており、手動スクリプトに依存していた従来型と異なり、AIを活用したエンドツーエンドの自動化が実現されています。攻撃の成功率とスケールにおいて「重大なエスカレーション」と位置づけられました。
この記事では、何が起きているのかをできるだけ平易に整理し、企業として何を見直すべきかを考えます。
1. いま何が起きているのか―「本人が正規の画面で認証してしまう」攻撃
MFAをすり抜ける仕組み
今回の攻撃で悪用されたのは、「デバイスコード認証」と呼ばれる正規のログイン方式です。これはスマートTVやプリンタなど、キーボードのないデバイスからログインするために用意された仕組みで、画面に表示されたコードを別のPCやスマホで入力して認証を完了します。
ポイントは、「コードを発行した側」と「コードを入力する側」が別のデバイスであることです。攻撃者はこの構造を悪用し、自分が発行したコードを、フィッシングメール経由で被害者に入力させます。
被害者はMicrosoftの正規のログイン画面でコードを入力し、いつも通りMFAの認証も完了します。URLも本物、画面も本物。しかしその裏で、認証の「成果」―つまりアカウントへのアクセス権―は攻撃者の手に渡っている。パスワードは一切盗まれていないのに、アカウントが乗っ取られるのです。
たとえるなら、「鍵を盗む」のではなく「本人に鍵を開けさせて、そのまま入る」ようなもの。鍵の複雑さ（MFAの強度）をいくら上げても、本人が正規の手順で開けてしまう以上、防ぎようがありません。
「怪しいURLに注意しましょう」という従来のセキュリティ教育が、この攻撃にはほぼ通用しないという点が、特に深刻です。
AIで「あなた専用」のフィッシングメールが届く
従来のフィッシングメールは、「パスワードの有効期限が切れます」のような汎用的な文面が中心でした。しかし今回の攻撃では、AIがターゲットの役職や業務内容に合わせたメールを自動生成しています。経理担当者には請求書、営業担当者には提案依頼、製造部門にはワークフロー通知―日常業務の延長として自然に受け取れる内容が届くため、警戒心が働きにくい設計です。
さらに技術面でも巧妙な工夫がありました。デバイスコードには15分の有効期限がありますが、従来の攻撃ではメール送信前にコードを発行していたため、受信者がメールを開くまでに期限切れになることが多かったのです。今回の攻撃では、被害者がリンクをクリックした瞬間にコードを発行する仕組みに進化しており、この時間制限を実質的に無効化しています。
生成されたコードは被害者のクリップボードに自動コピーされ、正規のMicrosoftログインページに遷移後、ペーストするだけで認証が完了します。攻撃の「使いやすさ」は、もはや正規のWebサービスと変わらない水準です。
加えて、フィッシングページ自体もよく作り込まれています。ドキュメントのプレビュー画面をぼかし表示にして「本人確認」ボタンを配置するパターンや、ブラウザの中に偽のブラウザ画面を表示してMicrosoftのログイン画面を再現するパターンが確認されています。電子署名や音声メール通知など複数のテーマが使い分けられており、「このパターンに注意」と一律に伝えること自体が難しい状況です。
攻撃が「サービス化」している現実
今回のキャンペーンでは「EvilToken」と呼ばれる攻撃ツールキットの関与が確認されています。これはPhaaS（フィッシング・アズ・ア・サービス）―フィッシング攻撃のインフラをサービスとして提供するビジネスモデルです。
攻撃の裏側では、Railway.comやCloudflare、AWSといった正規のクラウドサービス上に攻撃基盤が構築されていました。一般企業が業務で使うのと同じプラットフォーム上で攻撃が動いているため、「怪しい通信先をブロックする」というアプローチでは、正規の業務通信まで止めてしまうリスクがあります。
いまやサイバー攻撃もクラウド上で自動運用される時代。防御側が年に1回のセキュリティ監査で対抗しようとするのは、馬車で新幹線を追いかけるようなものかもしれません。
2. 「MFAを入れているから安全」はもう通用しない
MFAは万能ではない――残り10%の脅威
誤解のないように補足すると、MFA自体は依然として有効な防御策です。米国の安全保障当局によれば、MFAはサイバー攻撃の約90%を防いでいるとされています。
問題は残りの10%です。MFAの普及が進んだことで、攻撃者の関心は「MFAで守られていないアカウント」から「MFAをすり抜ける方法の開発」へと移っています。Microsoftによれば、同社が過去1年間でブロックしたパスワード攻撃は毎秒7,000件、前年比75%増。MFAの壁に阻まれた攻撃者が、より高度な迂回策に投資するのは必然的な流れです。
現在確認されているMFAをすり抜ける主な手法は3つあります。正規サイトとの通信に割り込んで認証情報を横取りする「中間者攻撃」、承認リクエストを大量に送りつけてうっかり許可させる「MFA疲労攻撃」、そして今回レポートされた「デバイスコードフィッシング」です。
前の2つがMFAの「運用上の隙」を突くのに対し、デバイスコードフィッシングは認証の仕組みそのものの「設計上の特性」を利用しているため、より根本的な対策が求められます。しかも、これらの手法は単独ではなく組み合わせて使われるのが実態です。今回のキャンペーンでも、メール配信には乗っ取り済みの正規ドメインが使われ、リダイレクトにはクラウドサービスが活用されるなど、複数の攻撃手法が何層にも重ねられていました。
「MFAを入れているか」ではなく、「どんな仕組みのMFAを、どこに適用しているか」が問われる時代に入りました。
乗っ取り後、10分で何が起きるか
今回のレポートで特に深刻なのは、アカウント乗っ取り後の行動の速さです。
Microsoftの観察によると、攻撃者はアクセス権を取得してから最短10分以内に、乗っ取ったアカウントに新しいデバイスを登録して長期的なアクセス手段を確保し、社内の組織図や権限情報を自動スキャンしてCFOや経理担当者など「お金を動かせる人」を特定していました。
最終的には、ターゲットのメールに不正な転送ルールを仕込み、本人に気づかれないまま送金情報や請求書データを抜き取り続けます。しかも攻撃者は大量に乗っ取ったアカウントの全てを攻撃するのではなく、「高価値なターゲット」を選別して集中投資する、まさにビジネス化された攻撃オペレーションを展開しています。
検知の難しさも深刻です。攻撃インフラは一般企業も利用する正規のクラウドサービス上に構築されており、通信パターンも正規の認証トラフィックと見分けがつきにくい。「怪しい通信を止める」という従来のアプローチでは、正規の業務通信まで止めてしまうリスクがあり、セキュリティチームにとって極めて対応が難しい状況です。
3. いま企業が見直すべきこと――認証の「設計思想」を変える
Microsoftの推奨策と、現場のハードル
Microsoftはレポートの中で、デバイスコード認証を必要な場面以外で無効化すること、そしてパスキーやFIDO2セキュリティキーといった「フィッシングに強い認証方式」への移行を推奨しています。
しかし、「来月からパスキーに全面移行」は現実的ではありません。セキュリティキーの配布コスト、既存システムとの互換性、全従業員への教育―ハードルは決して低くないのが実情です。
では、完全移行を待つ間に何ができるのでしょうか。
「電話番号の一意性」で認証の土台を強くする
今回の攻撃が示したのは、「認証手段を1つ足せば安全」という発想の限界です。認証の仕組み全体を迂回されてしまう以上、どこかに「なりすましが構造的に難しい要素」を組み込む必要があります。
そこで注目されるのが、電話番号が持つ「物理的な一意性」です。携帯電話番号は通信キャリアとの契約に基づいて1人1回線が割り当てられ、メールアドレスのように無限に作ることはできません。この特性を認証に活用することで、「そもそも不正なアカウント作成やログインを許さない」という、攻撃の入口を塞ぐ防御が可能になります。
先ほどの「鍵の比喩」で言えば、鍵の複雑さを上げるのではなく、「そもそも鍵を使おうとしている人が本人かどうか」を、偽造が難しい身分証で確認する層を追加するようなイメージです。
SMS認証（ワンタイムパスワードをSMSで送る方式）と混同されがちですが、ISの電話番号認証はSMS送信に依存しない仕組みのため、SMSの傍受リスクとは異なる設計です。
Infront Security（IS）が提供する電話番号認証には、3つの導入しやすさがあります。
まず、実装の軽さ。1つのAPIを連携するだけで最短数日で本番稼働でき、既存のセキュリティ構成を入れ替える必要がありません。
次に、コストの低さ。従量課金モデルのため、まず小さくPoC（概念実証）を試してから広げるアプローチが取りやすい設計です。
そして、不正アカウント対策との両立。ログイン認証だけでなく、アカウント登録時の「1人1アカウント」の担保にも使えるため、不正アカウント対策と本人確認を同時に実現できます。弊社導入クライアント様での多重アカウント対策や、D2C不正対策といった事例で、その効果が確認されています。
4. まとめ
Microsoftのレポートは、「MFAを入れているから安全」という前提がもはや通用しないことを、具体的な攻撃の手口とともに示しました。
AIによるフィッシングメールの自動生成、クリックした瞬間に発行されるデバイスコード、クラウド上で自動運用される攻撃基盤―攻撃側の進化は、防御側の想定を超えています。そして攻撃ツールの「サービス化」により、こうした高度な手法が一部の高スキル攻撃者だけのものではなくなっているという事実も見過ごせません。
いま求められているのは、認証手段を「もう1つ足す」ことではなく、認証の土台そのものを見直すことです。パスキーへの長期的な移行を視野に入れつつ、いま実装できる防御層として、電話番号の一意性に基づく認証を組み込む。ISの電話番号認証は、その第一歩として最も導入しやすい選択肢のひとつです。
まずは自社の認証フローに「デバイスコード認証が有効になっていないか」を確認することから始めてみてください。それだけでも、今日の攻撃への備えは一段変わります。
「馬車で新幹線を追いかけない」ために―認証の見直しは、来月ではなく今月始めるテーマです。
