Microsoft 365の正規のサインイン画面を利用し、利用者に攻撃者側のアクセスを承認させる「デバイスコードフィッシング」が悪用されています。Microsoftが2026年9月に活動基盤を妨害した「EvilTokens」は、この手口によるアカウント侵害に加え、AIを使って侵害した受信箱を分析し、詐欺の標的やなりすまし相手を選ぶ機能も備えていました。本記事では、EvilTokensの仕組みと、Microsoft 365を利用する企業が確認しておきたい認証設定、監視、侵害後の対応について解説します。
EvilTokensとは
EvilTokensは、デバイスコードフィッシングによるアカウント侵害や、AIを使った侵害後の情報収集などを支援するPhishing-as-a-Service（PhaaS）プラットフォームです。Microsoftは2026年9月22日、同サービスの活動基盤を妨害したと発表しました。同社によると、世界の1万を超える組織で、1万2,000を超える受信箱が侵害されています。この数字はメール侵害の規模を示したものであり、金銭被害が発生した組織数を示すものではありません。
Microsoft 365を利用する企業が見直したいのは、認証画面のURLだけで安全を判断する運用です。EvilTokensは、利用者に正規のMicrosoftの画面で操作させ、攻撃者が開始した認証要求を承認させます。アカウントを守るには、MFAの導入に加え、自社で利用を認める認証方式や、侵害が疑われた場合の対応を確認する必要があります。
正規の認証画面でも侵害につながる理由
デバイスコード認証は、入力操作に制約のある機器などへサインインするための仕組みです。機器側に表示されたコードを、別の端末のブラウザーで入力して認証を完了します。デバイスコードフィッシングでは、この認証要求を攻撃者が開始し、コードを利用者に入力させます。問題は、コードにひも付く認証要求の主体です。画面自体がMicrosoftの正規サイトでも、そこで承認する要求が攻撃者によって開始されたものであれば、攻撃者側にアクセスが与えられます。偽サイトへパスワードを送信していなくても成立する手口です。利用者がMicrosoftにサインインしていない場合には、正規の画面でパスワードやMFAによる認証を求められることがあります。MFAを設定していても、利用者が攻撃者の要求を正規の認証画面で承認すると、侵害につながる場合があります。
図1：EvilTokensによるデバイスコードフィッシングと侵害後の流れ
※図は攻撃の概略を示したものです。AIによる分析後に、必ずなりすましや金銭被害が発生することを示すものではありません。
AIは受信箱から取引関係や送金担当者を探す
EvilTokensのAI機能は、侵害した受信箱を解析し、支払いに関する会話や組織内の役割、信頼関係などを把握するためにも使われていました。Microsoftは、詐欺の標的やなりすまし相手を選び、詐欺の進め方を提案する機能を報告しています。AIが、フィッシングメールの作成だけでなく、侵害した受信箱から詐欺に利用できる情報を探すためにも使われた事例です。このため、ビジネスメール詐欺対策では、振込先の変更や通常と異なる送金依頼について、信頼できる別の連絡経路で確認することが欠かせません。Microsoftも別経路での確認を推奨しています。実務では、受信メールに記載された連絡先をそのまま使わず、社内で管理している既知の連絡先で確認する運用が考えられます。
EvilTokensへの対策
図2：EvilTokensへの防御と対応
※対策の分類は、Microsoftの公表資料を基に弊社が整理したものです。
不要なデバイスコード認証を制限する
予防策の出発点は、自社でデバイスコードフローを使っているかを把握することです。Microsoftは、利用状況を監査して必要性を判断し、可能な限り利用を遮断する方針を推奨しています。業務上必要な用途がある場合は、その理由と保護方法を明確にし、例外を限定します。Microsoft Entra IDの条件付きアクセスでは、認証フローを条件としてデバイスコードフローをブロックできます。変更時は、レポート専用モードで影響を確認してから有効化します。緊急アクセス用アカウントなど必要な除外を設計し、例外が増え続けないよう定期的に点検することも重要です。従業員向けの説明にも、この仕組みを反映することが重要です。「URLを確認する」に加え、「自分が開始していないサインインのコードは入力しない」と具体化すれば、何を判断すべきか伝わりやすくなります。これは、今回の認証手口を踏まえた教育上の対策の一例です。
認証後の不審な操作を監視する
監視では、サインインの成否だけで判断を終えないことが重要です。Microsoftのトークン窃取対応資料では、サインインログ、監査ログ、Officeの操作、関連端末の情報などを調べるよう案内しています。新しい認証方法や端末の登録、メール転送ルールの追加なども確認対象となります。これらの情報は、必要に応じてSIEMなどへ集約し、関連付けて確認できるようにします。たとえば、普段と異なるサインインと、その後の転送設定変更を、同じアカウントの時系列として調べる運用が考えられます。ただし、不審な出来事が一つあっただけでEvilTokensによる侵害と断定することはできません。利用者の操作や業務上の変更だったかを確認し、侵害の有無と範囲を絞り込む必要があります。
侵害が疑われるアカウントを封じ込める
アカウント侵害が疑われる場合、Microsoftは、侵害が疑われるアカウントを調査中は一時的に無効化することを推奨しています。あわせて、アクティブなセッションと更新トークンを失効させ、登録されたMFAの方法や端末、同意済みアプリ、管理者権限などを点検します。不正なメール転送設定や、通常の画面では見落としやすい受信箱ルールも確認対象です。パスワードを変更して利用者が再びログインできたことだけでは、攻撃者が残した設定まで除去できたとは限りません。どのアクセスを止め、どの変更を戻し、どのログで確認したかを記録し、公式手順に沿って復旧することが必要です。
送金や支払情報の変更は別経路で確認する
EvilTokensでは、侵害した受信箱から取引関係や支払いに関する情報が把握され、なりすましや送金詐欺に悪用される可能性があります。振込先の変更や送金依頼など、金銭に関わる重要な依頼については、メールだけで判断せず、既知の電話番号など信頼できる別の連絡手段で確認することが重要です。
EvilTokensへの対策は、認証管理だけでは完結しません。認証フローの制御、不審な操作を追跡できるログの整備、侵害時の対応、送金依頼の確認までを、自社の担当者と手順に落とし込むことが重要です。正規の認証画面を通った操作であっても、誰のアクセスを許可しようとしているのかを確認する視点が求められます。
【参考情報】
- Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」（2026年9月22日公表）（https://blogs.microsoft.com/on-the-issues/2026/09/22/disrupting-eviltokens-the-ai-chatbot-built-for-cybercrime/）
- Microsoft Security Blog「Unmasking EvilTokens: Getting to the root of device code phishing」（2026年9月22日公表）（https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/）
- Microsoft Learn「Block authentication flows with Conditional Access policy」（https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows）
- Microsoft Learn「Token theft playbook」（https://learn.microsoft.com/en-us/security/operations/token-theft-playbook）
- Microsoft Learn「Respond to a compromised cloud email account」（https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account?view=o365-worldwide）
編集責任：木下
アカウント侵害や不正アクセスが疑われる場合は
BBSecでは、セキュリティインシデント発生時の初動対応から、原因・影響範囲の調査、フォレンジック調査、再発防止まで支援しています。
平時の対応体制を見直したい場合
ウェビナー開催のお知らせ
最新情報はこちら
