本物のログイン画面でも要注意。デバイスコード・フィッシングとMFAの限界

こんにちは、Ryohei（@ityryohei）です！

多要素認証（MFA）を有効にしていても、利用者が攻撃者の要求を正規の手続きだと思って承認してしまうと、不正なアクセスにつながる場合があります。重要なのは、認証方法の強さだけでなく「どのアプリ・端末へのアクセスを許可しているか」まで確認することです。

Microsoftは2026年9月22日、フィッシング基盤「EvilTokens」の分析を公表しました。同社は、誘導メールの個別化や侵害したメールボックスの分析にAIを利用する機能と、デバイスコード認証を悪用する活動を報告しています。

本記事では、この報告を入口に、認証コード、トークン、パスキーの役割を整理します。新しい被害の速報ではなく、2026年10月13日に一次資料を確認した運用向けの解説です。以下の確認例は、特定のWordPressサイトが侵害されたことを示すものではありません。

デバイスコード認証は、もともと正規の便利な機能

Microsoftの技術資料によると、デバイスコード認証は、テレビやプリンターなど文字入力しにくい端末のためのOAuth認証フローです。対象端末に短いコードと確認用URLを表示し、利用者が別の端末のブラウザーで認証します。認証が完了すると、要求を開始したクライアントがトークンを取得します。

ここで押さえたいのは、コードを入力しているブラウザーと、アクセスを得るクライアントが同じとは限らない点です。自分の会議端末を接続しているつもりでも、コードの出どころを確認しなければ、別の要求を承認する可能性があります。「正規のログインページで認証した」という事実だけでは、接続先まで確認したことにはなりません。

この問題はAIが登場して初めて生まれたものではありません。2019年8月公開のRFC 8628のセキュリティ上の考慮事項でも、攻撃者が利用者にコードを渡し、別の端末への認可を誘導するリモート・フィッシングが扱われています。新しい報告と、従来からあるプロトコルの注意点を分けて理解することが必要です。

「本物のサイトにログインしたのに危険」が起きる理由

EvilTokensの報告では、攻撃者が始めたデバイスコード認証のコードを、利用者に入力させる手口が説明されています。利用者が本物のMicrosoftのページで操作しても、そのコードに対応する要求は攻撃者側で始まったものです。利用者の認証が成功することと、承認してよい要求であることは別の判断になります。

このため、確認はURLだけで終わらせないようにします。「自分が直前に接続操作を始めたか」「どのアプリや端末のための操作か」「表示されたアカウントは想定どおりか」が確認対象です。届いたメールにあるコードを、ファイル閲覧や本人確認のためだという説明だけで入力することは避けましょう。

たとえば、取引先から共有ファイルの案内を受けた場面を考えます。内容が自然で、業務に関係する用語が含まれていても、それだけで承認依頼の正当性は判断できません。心当たりのない端末接続を要求されたら、その場で続行せず、既知の連絡先や普段使うサービス画面から依頼を確認するのが実務上の提案です。

Microsoftの報告が示すAIの用途は、誘導の個別化や侵害後の分析などです。本記事は、AIが認証の暗号を破ったことや、攻撃全体を無人で実行したことを主張していません。どの工程にAIが使われたのかを区別することで、必要な対策も絞りやすくなります。

MFA・パスキー・トークンは、守る場所が異なる

MFAは本人確認に複数の要素を使う仕組みですが、すべての方式が同じ性質を持つわけではありません。認証コードを利用者が入力する方式と、接続先に結びついた公開鍵認証では、偽サイトへの耐性が異なります。また、認証後に発行されたトークンが不正利用される問題は、ログイン時の本人確認だけで完結しません。

FIDO Allianceの説明では、パスキーは公開鍵暗号に基づく、フィッシング耐性のある認証方式です。対応するサイトに結びついた認証情報を使うため、偽サイトで同じ秘密を入力させるパスワード型フィッシングに強い性質があります。同期されるパスキーと、特定の端末やセキュリティキーに保持される方式もあります。

ただし、パスキーを導入すれば、あらゆる承認の誤りや侵害が防げるとは考えないでください。本人が正規の認証を行った後に、別のクライアントへのアクセスを許可する場面では、要求の意味を確認する必要が残ります。パスキーへの移行と、不要な認証フローの制限は、異なる点を守る対策として検討します。

さらにOWASPのパスキー実装ガイドは、アカウント復旧の不備、認証済みセッションの侵害、端末や同期アカウントの侵害などを、パスキーだけでは防げない問題として挙げています。強い認証を採用しても、復旧手順や認証後のセッション管理まで確認する必要があります。

Microsoft 365を使う運営者が最初に確認したいこと

Microsoftの条件付きアクセスの資料は、デバイスコード認証の利用状況を調べ、必要な用途だけに限定する方針を示しています。利用しない環境ではブロックし、まずReport-onlyで影響を確認してから有効化する手順が記載されています。

実際の変更前には、会議端末、運用ツール、既存の業務アプリなどで使われていないかを確認します。正当な利用がある場合は、利用者、用途、責任者、見直し日を記録して例外を管理します。「動かないので全員を例外にする」という対応では、制限の目的が失われます。機能の利用条件や必要な権限も、契約と環境に合わせて確認してください。

ここからは本記事の運用提案です。小規模なWeb制作チームでも、メールの管理者、クラウドの管理者、サイトの管理者が誰かを一覧にすると、変更の担当が曖昧になりにくくなります。全員に設定を変えてもらう前に、重要アカウントと影響範囲を限定した検証を行い、その結果から展開範囲を広げます。

利用者への説明も、単に「怪しいメールに注意」では不十分です。「自分で接続を始めていないコード入力は止める」「アプリ名が想定と違う承認はしない」「正規ページでも依頼そのものを確認する」という、操作時に使える判断基準にします。業務で使う正当な接続手順を用意しておくと、迷ったときの比較対象にもなります。

WordPressのMFA設定だけでは、運営全体を守れない

WordPress管理画面のログインを保護していても、復旧用メール、ドメイン管理、サーバーパネル、クラウドストレージが別の認証方式で動いている場合があります。これは、そのWordPressサイトにデバイスコード認証の欠陥があるという意味ではありません。サイトを取り戻したり、設定を変更したりできる周辺サービスまで、運営上の管理対象に含めるという話です。

確認の起点は「このサービスを失ったら、何ができなくなるか」です。メールアカウントを失うと、問い合わせ対応に加え、ほかのサービスのパスワード再設定に影響する場合があります。ドメイン管理の侵害はDNS変更につながる可能性があります。それぞれの影響を分け、認証・復旧・通知の設定を確認しましょう。

AIによる記事投稿を導入している場合も、人の管理画面ログインと、外部連携の認証情報を分けて扱います。MFAが有効な管理者アカウントを使っているというだけで、API連携や保存済みトークンまで同じ確認を毎回受けるとは限りません。連携先で何が実行でき、どこから停止できるかを把握しておくことが重要です。

チェック表を作るなら、サービス名、管理者、認証方式、復旧手段、セッションの停止方法、ログの確認先を1行ずつ記録します。秘密情報そのものを一覧表に書く必要はありません。設定変更の日時と担当者を残すことで、正常な変更と見覚えのない変更を区別しやすくなります。

侵害が疑われたときは、パスワード変更だけで終わらせない

Microsoftのアクセス失効の資料は、アクセストークン、更新トークン、アプリケーションが発行するセッションを区別しています。Entra IDは、アプリが独自に発行したセッションを直接失効できません。アクセスが止まるまでの時間も、アプリやトークンの扱いに依存します。

この区別から、対応時には「パスワードを変えたか」と「既存のアクセスを止めたか」を別々に確認します。組織の手順に沿って、新しいログインの制限、該当セッションやトークンの失効、アプリ側の停止などを担当者が判断します。すべてのサービスで同じ操作が使えるとは限らないため、提供元の案内に沿った確認が必要です。

本記事の点検例としては、見覚えのない端末や認証方法、連携アプリ、メールの転送設定、権限変更などを挙げられます。認証後に設定を追加されていた場合、入口のパスワードを変えるだけでは、その変更の取り消しを確認したことになりません。いつから何が変わったかを調べ、業務上必要な設定と区別します。

調査に使う日時、通知、ログは可能な範囲で保全し、操作した担当者と内容も記録します。証拠を消してしまうような一括削除は避け、組織の対応責任者やサービス提供元と相談しながら、封じ込めと調査を並行して進めます。利用者全員を停止するなど業務影響の大きい操作は、対象と影響を確認して判断してください。

パスキー導入時に、開発者が見落としやすい周辺処理

ログイン画面にパスキーのボタンを置くことと、安全に実装できていることは同じではありません。OWASPは、RP IDや許可するオリジン、チャレンジ、署名、アカウントとの対応を検証し、保守されているWebAuthnライブラリを使うよう説明しています。認証が成功した場合だけアプリのセッションを作る、という境界も重要です。

登録・削除・復旧の設計も確認します。ログイン済みであるという理由だけで、新しい認証方法を無制限に登録できる設計は避けます。強いログイン方式を導入しても、弱い復旧手順で簡単に置き換えられるなら、アカウント全体の安全性は改善しにくくなります。

以下は導入確認の提案です。既存の認証方式との併用期間、端末紛失時の手順、利用者への通知、管理者が取り消す方法を、リリース前に確認します。正常な登録・ログインだけでなく、期限切れや想定外のアカウントでの操作が拒否されるかも点検します。独自実装で暗号処理を増やすより、利用するライブラリと周辺処理の責任範囲を明確にしましょう。