MicrosoftによるEvilTokens妨害作戦、AI主導の詐欺パイプラインを露呈
Microsoftは、世界中の1万を超える組織で1万2,000件以上のメール受信トレイが侵害された後、EvilTokensを妨害した。MicrosoftによるEvilTokens妨害作戦は、フィッシング、アカウントアクセス、メールボックス分析、金融詐欺を一体化したパッケージ型システムを支えるインフラを標的とした。
この作戦が重要なのは、EvilTokensが犯罪者による説得力のあるメッセージ作成を支援するだけにとどまらなかったためだ。同サービスのAIアシスタントは盗まれた受信トレイを調査し、取引関係を整理し、支払い権限を持つ人物を特定し、なりすますべき相手を推奨した。
この機能は、かつて忍耐と専門知識を要した作業を短縮した。しかし、インフラを無効化しても、基盤となる手法そのものがなくなるわけではない。デバイスコードフィッシングは依然として利用可能であり、盗まれたセッションはパスワードリセット後も存続し得る。また、関連サービスがこの運用モデルを模倣する可能性もある。
MicrosoftによるEvilTokens妨害作戦はフルサービス型詐欺プラットフォームを直撃
Microsoftとそのパートナーは、最初のフィッシングと標的型金融詐欺を結ぶインフラを攻撃した。
Microsoftは2026年9月22日、連携した措置を発表した。同社のDigital Crimes Unitは、稼働中のインフラを差し押さえ、同サービスに関連するドメインをリダイレクトするための裁判所の権限を取得した。
この措置にはHealth-ISAC、テクノロジー企業、金融捜査担当者、セキュリティ研究者、法執行機関が関与した。Cloudflareも別途、EvilTokensのキャンペーンを支援していたWorkersプロジェクトとアカウントを無効化した。
court recordsによると、MicrosoftとHealth-ISACはバージニア東部地区で訴訟を提起した。被告としてFelix Utomi、Waidi Segun Adams、および複数の身元不明者が名を連ねている。
Microsoftは、Storm-2992として追跡している脅威アクターにEvilTokensの開発とサポートを帰属させた。この文脈における帰属はMicrosoftの評価であり、刑事有罪判決ではない。
この作戦では、50のWebサイトが差し押さえられ、さらに150を超えるドメインが無効化されたと報じられている。independent reportingによれば、英国警察もEvilTokensに関連して男性2人を逮捕した。
両名は捜査継続中、条件付き保釈で釈放された。逮捕を有罪認定として扱うべきではない。
Cloudflareは、連携したインフラ対策が9月15日に始まったと述べた。同社はEvilTokensの活動に関連する数百の顧客アカウントを特定し、支援プロジェクトを無効化した。
このような法的・技術的アプローチの組み合わせが必要だったのは、EvilTokensが無関係なプロバイダーによって運営されるサービスに依存していたためだ。そのインフラは、ホスティングプラットフォーム、ドメインレジストラ、通信サービス、決済システム、クラウドネットワークにまたがっていた。
EvilTokensは2026年初頭に登場し、金銭的利益を目的とする攻撃者の間で急速に普及した。Microsoftは数カ月以内に、同サービスを1万を超える組織における1万2,000件超の侵害受信トレイと結び付けた。
観測された被害活動が最も集中していたのは、米国、カナダ、英国、オーストラリア、インド、フランスだった。影響を受けた業界には建設、金融、医療、不動産、卸売流通、高等教育が含まれる。
これらの数値は観測された活動を示すものであり、完全な実態調査ではない。侵害されたアカウントの一部は未発見の可能性があり、1つの組織内に複数の影響を受けた受信トレイが存在し得る。
事業領域への集中は異例なほど顕著だった。セキュリティ報道で引用されたSpyCloudのデータでは、特定されたアカウントの約97.5％が企業ドメインに属すると分類されていた。
EvilTokensは多額の収益も生み出していた。Coinbaseは調査支援の過程で、この活動に約110万ドルの収益を追跡したと報じられている。
これらの数字は規模を説明するが、核心的な変化を捉えてはいない。EvilTokensは、以前は分離していた複数の犯罪タスクを単一の管理インターフェースを通じて接続した。
購読者には、キャンペーンツール、フィッシングテンプレート、トークン管理、被害者追跡、メールボックス検索、侵害後のガイダンスが提供された。サポートチャネルと管理ダッシュボードにより、この活動は商用ソフトウェアサービスに似たものとなっていた。
この違いは防御側にとって重要だ。悪意あるドメインを削除すれば1つのキャンペーンを中断できるが、移植可能なサービスモデルを解体できるわけではない。
Microsoftはこの措置を、すべての運営者、購読者、関連システムが消滅した証明ではなく、妨害作戦として説明した。そのためセキュリティチームは、活動の減少は見込めても、恒久的な排除を想定すべきではない。
EvilTokensはいかに正規ログインをアカウントアクセスへ変えたか
EvilTokensは、偽造ログインフォームだけに頼るのではなく、Microsoftの正規認証ページに対するユーザーの信頼を悪用した。
このプラットフォームの中心にあったのはデバイスコードフィッシングだ。この手法は、使いやすいキーボードや完全なブラウザを備えないデバイス向けのOAuth認証フローを悪用する。
スマートテレビ、プリンター、会議機器、一部のTeamsデバイスは、このプロセスを利用できる。デバイスが短いコードを表示し、ユーザーは別の画面で認証を完了する。
悪意あるフローでは、攻撃者がリクエストを開始し、そのコードを標的に送る。欺瞞的なメッセージにより、標的はMicrosoftの正規デバイスログインページでコードを入力するよう誘導される。
被害者には有効なMicrosoftドメインが表示され、通常どおり多要素認証を完了することもある。しかし、その承認は被害者が想定していた行為ではなく、攻撃者が待機させているセッションを認可する。
パスワードが偽造Webサイトを通過する必要はない。この特性により、ドメインの確認や不審なページで認証情報を入力しないことに重点を置く従来の助言は効果が弱まる。
EvilTokensのパネルは、購読者がこのプロセスを現実的な誘い文句に組み込むのを支援した。Microsoftは、請求書、共有ファイル、署名依頼、パスワード通知、福利厚生、提案書、ビジネスパートナーシップを扱う44のテーマを特定した。
キャンペーンでは、リンク、PDF文書、HTML添付ファイル、リダイレクト、模倣された確認ページが使われた。このサービスは、インフラの分類を困難にするため、正規クラウドプラットフォームや侵害済みWebサイトも利用した。
被害者がコードを承認すると、EvilTokensは認証トークンを取得した。トークンとは、パスワードを再入力せずに、認可済みセッションが特定サービスへアクセスできるようにするデジタルな認証情報だ。
盗まれたトークンは、メールおよび関連するMicrosoft 365リソースへのアクセスを可能にし得る。運営者はトークンの更新、管理者権限の調査、Telegram経由でのメールボックスキーワード警告の受信も可能だった。
Microsoftは、攻撃者がメッセージを隠すために悪意ある受信トレイルールを作成した事例を観測した。一部のインシデントでは、初期侵害直後に、より永続的なアクセスを確立するためデバイスが登録されていた。
この持続性はインシデント対応を変える。パスワードをリセットしても、すでに認可されたセッションを終了したり、登録済みデバイスを削除したりできるとは限らない。
防御側は、セッションと更新トークンを無効化し、認証記録を調査し、不正なデバイスを削除し、メールボックスルールを確認しなければならない。そうしなければ、目に見える認証情報が変更された後も攻撃者がアクセスを維持する可能性がある。
technical analysisは、組織が必要としない場合、デバイスコード認証をブロックするよう推奨している。必要な例外は、特定のアカウントと承認済みデバイスに限定すべきだ。
組織は、予期しないデバイスコード要求やリスクの高いサインインも監視する必要がある。ユーザーは、自ら開始していない認証プロセスに関連するコードを拒否すべきだ。
パスキーやFIDO2セキュリティキーを含むフィッシング耐性のある認証は、保護を強化できる。しかし、ユーザーが正当なリクエストを承認するよう欺かれた場合、より強力な認証だけであらゆるソーシャルエンジニアリング経路を防げるわけではない。
この限界こそ、より深いセキュリティ上のトレードオフである。デバイスコード認証はインターフェースが限られたハードウェアを支える一方、承認プロセスが分離されることで、ユーザーの意図とリクエスト元のセッションとの結び付きを弱める。
攻撃者はMicrosoftの暗号化を破ったわけでも、被害者のパスワードを算出したわけでもない。被害者がアクセスを許可するまで、正規の認可メカニズムを操作した。
この教訓は1つのプラットフォームにとどまらない。リクエストと承認を分離するあらゆるセキュリティワークフローには、明確な文脈と厳格なポリシー制御が必要だ。
ユーザーは、自分が何を認可しているのか、どのアプリケーションがアクセスを要求したのか、そして結果として生じるセッションがどこで動作するのかを理解しなければならない。一般的な承認プロンプトは欺瞞の余地を生む。
EvilTokensはこの欺瞞を反復可能にした。その貢献はデバイスコードフィッシングを発明したことではなく、より広範かつ迅速に利用できる形でパッケージ化したことにある。
AIは誘い文句の作成から詐欺標的の選定へ移行した
EvilTokensを特徴づける能力は、アカウント侵害後、AIが未知の受信トレイを実用的な詐欺計画へ変えた段階で現れた。
生成AIは、洗練されたフィッシングメールと結び付けられることが多い。EvilTokensは、アクセス獲得後に被害組織を理解するという、より価値の高い問題にこれを適用した。
侵害されたメールボックスには、何年分もの会話、添付ファイル、請求書、承認記録、氏名、報告関係が含まれている可能性がある。この情報は価値が高いが、手作業での確認には時間と判断力を要する。
EvilTokensは、その作業の多くを自動化した。同サービスのツールは、メッセージの要約・翻訳、財務に関する議論の特定、組織上の役割の整理、信頼された外部関係者の抽出を行えた。
報道によると、プリセット検索は送金に関する会話、請求書、支払い責任、取引を承認できる従業員を特定した。Microsoftは、このアシスタントが攻撃者がなりすますべき人物も推奨できたと述べた。
その後、プラットフォームは盗まれた文脈に合致するメッセージの生成を支援した。詐欺的な要求は、実在するプロジェクト、サプライヤー、管理職、請求書、進行中の会話に言及できる。
このプロセスは、ビジネスメール詐欺、すなわちBECを支える。BEC攻撃では、犯罪者が信頼された関係者になりすまし、支払いの転送や、金銭的価値を持つ別の行動を誘導する。
従来のBECは、経験豊富な実行者に依存することが多い。彼らは通信パターンを研究し、権限を見極め、有用な取引を待ち、もっともらしい介入を構築しなければならない。
EvilTokensはこの調査負担を軽減した。この活動に関する報道によれば、数日を要する可能性があったタスクを数時間に短縮できた。
この圧縮は、文法のわずかな改善よりも重要だ。よく書かれた一般的なフィッシングメールであっても、適切な相手に適切なタイミングで届く必要がある。
メールボックス分析は、攻撃者にタイミング、文脈、組織的な知識を与える。AIは散在する詳細を、有望な機会の優先順位付きリストへ変換できる。
この技術は、経験の浅い購読者も支援した。新規の実行者は、IDシステム、ソーシャルエンジニアリング、メール偵察、決済詐欺にまたがる深い知識を持つ必要がなかった。
EvilTokensはこれらの専門領域を、ガイド付きワークフローへ統合した。そのチャットボットは文章作成支援ツールというより、攻撃者の次の行動を助言するアナリストのように機能した。
Microsoftはまた、プラットフォーム自体の大部分がAI支援コーディングで構築されたことを示す証拠も発見した。この結論は、AIがプラットフォーム開発者と顧客の双方にとって障壁を下げたことを示唆している。
この発見は、AIが自律的にサービスを構築・運営したことを意味するものではない。事業の構築、標的の選定、インフラ管理、システムの推奨に基づく行動は、依然として人間が担っていた。
また、特定の商用モデル1つがすべてのAI機能を提供したことを示すものでもない。Microsoftは、調査担当者が複数のAIモデルの利用を確認したと述べている。
したがって、公開されている証拠が裏付ける結論はより限定的だ。既存のAIツールは、犯罪者がソフトウェアを開発し、窃取した情報をより効率的に解釈することを支援した。
これは犯罪経済における意味のある変化を表している。メールボックスのトリアージが高速化されれば、運用者1人が人員や専門性を比例して増やすことなく、より多くの被害者を調べられる。
規模の拡大は選別も改善する。攻撃者は見込みの薄い機会を早期に見切り、支払い管理、信頼できる取引先、または上級幹部に結び付いたアカウントへ集中できる。
MicrosoftによるEvilTokensの無力化作戦は、不正アクセスと収益化の間にある、この転換レイヤーを標的とした。このレイヤーこそが、同サービスが通常のフィッシング用インフラを超えて注目を集めた理由を説明している。
盗まれた受信トレイは、それ自体で有害だ。その受信トレイをどう悪用するかを迅速に説明するシステムは、侵入の速度と期待収益の両方を高め得る。
このモデルは、アイデンティティチーム、メールセキュリティ提供事業者、AI企業に圧力をかける。それぞれが制御できるのは、複数の独立したサービスをまたぐ攻撃チェーンの一部にすぎない。
AI提供事業者は悪用アカウントを停止できるが、攻撃者はモデルを切り替えられる。ホスティングプラットフォームはインフラを削除できるが、運用者は提供事業者を移り渡れる。
アイデンティティベンダーは不審なセッションを遮断できる一方、正規の認証機能は実際のデバイスにも提供し続けなければならない。防御側は、犯罪者が再構築するより速く、これらの境界を越えて連携する必要がある。
EvilTokensの摘発でもデバイスコード・フィッシングが終わらない理由
この作戦は重要なインフラを排除したが、根本的な認証上の弱点と犯罪需要は依然として残っている。
セキュリティ報道では、APTokenが関連サービスまたは派生サービスとしてすでに特定されている。その出現は、アフィリエイトが成功したフィッシング・アズ・ア・サービスの設計を再現できることを示している。
こうしたクローンとStorm-2992との正確な関係は不明なままだ。類似した機能があっても、共通の所有者や共有インフラを証明するものではない。
それでも、模倣のリスクは明白だ。EvilTokensは、トークン窃取、メールボックス分析、不正行為の準備を組み合わせた統合製品への需要を実証した。
運用者は、顧客サポート、チュートリアル、インターフェース、パートナー関係を通じても知識を配布していた。サーバーを無効化しても、購読者がすでに習得した技能を消し去ることはできない。
このため、「disruption（撹乱・無力化）」という言葉が重要になる。Microsoftとそのパートナーは、現在の運用を妨害し、情報を収集し、運用コストを引き上げ、継続中の調査を支援した。
これらの成果は、直近の攻撃量を減らせる可能性がある。しかし、すべての顧客がアクセスを失ったこと、すべての盗難トークンが失効したこと、すべての被害者が通知を受けたことを保証するものではない。
法的手続きにより、プラットフォームの組織や資金ネットワークについてさらに明らかになる可能性がある。法執行機関の捜査によって、追加の逮捕、起訴、差し押さえにつながる可能性もある。
それまでは、いくつかの中核的な主張は主にMicrosoftと参加企業のテレメトリーに依存する。それらの企業は貴重な可視性を持つが、どの提供事業者も犯罪市場全体を見渡せるわけではない。
被害者数も、パートナー各社が記録を照合するにつれて変化する可能性がある。報告された12,000件の受信トレイは、現時点の観測に結び付いた文書化済みの下限を表している。
直接的な金銭被害を測定することは、さらに難しい問題だ。侵害されたすべての受信トレイが支払い詐欺の成功につながったわけではなく、一部の組織は公表を避ける可能性もある。
AIの役割にも正確さが求められる。EvilTokensは、ソフトウェア開発、誘導文の作成、翻訳、メールボックス分析、標的の推奨にAIを利用した。
しかし、公開報道は、これらの機能がどの程度の頻度で詐欺の成功につながったかを定量化していない。また、AI支援のないキャンペーンとの成功率比較も示していない。
証拠が示しているのは運用上の統合であり、有効性を検証する統制試験ではない。したがって、AIだけがプラットフォームの規模をもたらしたとする主張は、入手可能なデータを超えることになる。
EvilTokensは複数の非AI機能の恩恵も受けていた。これには、トークンの永続化、自動化されたインフラ、再利用可能なテンプレート、検知回避のリダイレクト、正規のクラウドサービスへのアクセスが含まれる。
その人気は、おそらくこの包括的なパッケージに起因していた。AIはワークフローの一部を高速化したが、周辺サービスがそれらの機能を反復可能な運用へと変換した。
防御側は、別のAI製品だけで対応することを避けるべきだ。直近で重要な対策は、アイデンティティポリシー、セッションの可視性、ユーザー検証、インフラ情報、連携したインシデント対応である。
デバイスコード認証を必要としない組織は、これを無効化できる。この機能を必要とする組織は、Conditional Accessと専用リソースアカウントによって制限できる。
セキュリティチームは、想定外のデバイス登録、トークン更新アクティビティ、受信トレイルールの変更、異常なGraphアクセス、不明なアプリケーション承認も調査すべきだ。
Microsoftのデバイスコードに関するガイダンスは、この認証フローを制限するためのポリシーの道筋を提供している。実装には、正規の機器や業務プロセスに対するテストが依然として必要だ。
メール防御では、ユーザーを正規ドメインへ誘導するメッセージを考慮しなければならない。信頼できる宛先であっても、不正な要求や誤解を招く文脈を補うことはできない。
したがって、トレーニングでは開始の経緯と意図を重視すべきだ。ユーザーは、既知のデバイスで対応するサインインを自ら開始した場合にのみ、デバイスコードを入力すべきである。
組織には、トークン窃取が疑われる際の迅速な手順も必要だ。ヘルプデスクは、パスワードのリセットだけでは攻撃者のセッションが有効なまま残る可能性があることを理解しておく必要がある。
こうしたインシデントでは、アイデンティティ、メール、法務、財務、経営幹部の各チームが同じ証拠を必要とすることが多いため、文書化が重要になる。検索可能な技術ナレッジベースは、意思決定、指標、修復の責任分担を保存できる。
こうした運用規律は、EvilTokensが悪用したギャップを埋める助けとなる。犯罪者は自動化を使って自陣を連携させた一方、多くの防御側はいまだに証拠を分断されたシステムに分散させている。
MicrosoftによるEvilTokens無力化の後に何が起こるのか
この作戦が持続的な圧力を生んだのか、それともキャンペーンの一時的な減少にすぎなかったのかは、3つの兆候で判断できる。
第1の兆候は、インフラ措置後の測定可能なEvilTokens活動だ。セキュリティ提供事業者は、デバイスコード・フィッシングの減少、ドメインの変更、他のクラウドサービスへの移行を監視すべきである。
持続的な減少は、ドメインの差し押さえと提供事業者間の連携が、使い捨てのキャンペーン層以上に損害を与えたことを示す。急速な復帰は、運用者が顧客、ツール、代替インフラを維持していたことを示唆する。
Cloudflareの脅威評価は有用な指標を提供し、連携したテイクダウンについて説明している。参加提供事業者による今後の更新は、関連インフラが再出現するかどうかを示し得る。
第2の兆候は、クローンや競合サービスによる採用だ。APTokenや類似サービスは、EvilTokensのブランドを再利用せずとも商業モデルを維持できるため、注目に値する。
研究者は、それらの認証手法、メールボックス分析機能、サポートネットワーク、インフラを比較すべきだ。共有コードや共通の運用者が見つかれば、継続性を示す根拠はより強まる。
独立したサービスが同じ設計を採用するなら、より広範な市場の変化を示すことになる。それは、AIによる侵害後分析の支援が、犯罪製品における標準機能になったことを意味する。
第3の兆候は、法的・捜査上の結果だ。Microsoftの民事訴訟は運用者とされる人物を特定しており、英国当局は別途捜査を継続している。
追加の裁判所提出書類により、所有権、収益の流れ、顧客関係、インフラの支配について明らかになる可能性がある。刑事訴追や資産差し押さえは、運用者とサービス購入者の双方への圧力を高めるだろう。
執行結果が弱いとしても、技術的な無力化の成果が否定されるわけではない。しかし、代替運用者が法的リスクは依然として管理可能だと考えるなら、抑止力は限定される可能性がある。
防御側はMicrosoftの製品対応も注視すべきだ。EvilTokensが悪用したのは、単純なパッチで修正できるソフトウェア脆弱性ではなく、正規のワークフローだった。
Microsoftは、プロンプト、検知、トークン制御、管理者の可視性を改善できる。しかし、サポート対象の機器やアクセシブルなサインインのシナリオでは、デバイスコード認証を維持しなければならない。
この均衡により、ポリシーのデフォルト設定は特に重要になる。安全なデフォルトは、すべての組織が専門的なOAuth悪用手法を理解しなくても、露出を減らせる。
クラウドおよびアイデンティティ提供事業者は、より広い設計上の課題に直面している。承認画面では、どのデバイス、アプリケーション、セッションにアクセスが付与されるのかを伝える必要がある。
また、要求元の文脈が現在のデバイスと異なる場合、ユーザーに明確な警告が必要だ。文脈が改善されれば、正規のログインページは攻撃者にとってソーシャルプルーフとして利用しにくくなる。
AI企業にも別の役割がある。悪用検知は、盗んだ通信内容を繰り返し分析するアカウント、なりすましメッセージを生成するアカウント、既知の犯罪ワークフローを自動化するアカウントを特定できる。
こうした対策は、大手プラットフォーム外で運用されるモデルを止めることはできない。それでも、犯罪者が商用サービスに依存する場合にはコストを引き上げ、証拠の収集に貢献できる。
より大きな対立は、パッケージ化された犯罪自動化と連携した防御との間にある。EvilTokensは、アイデンティティの悪用、クラウドインフラ、AI分析、詐欺の専門知識を結び付けたため成功した。
対応側も同様に接続されたモデルを採用した。Microsoftは裁判所の権限、脅威インテリジェンス、プラットフォーム執行、資金追跡、法執行機関との協力を組み合わせた。
この対称性こそ、MicrosoftによるEvilTokens無力化から得られる中心的な教訓だ。複数の正規システムにまたがって構築された攻撃チェーンに、単一のセキュリティ製品で対処することはできない。
組織は、まずデバイスコード認証が必要かを確認し、その後にポリシー、セッション失効手順、監視範囲を見直すべきだ。また、財務チームが異常な支払い要求をどれほど迅速に検証できるかもテストすべきである。
次の悪意あるサービスは、別の名称、モデル、ホスティング提供事業者を使うかもしれない。重要なのは、盗まれた通信が説得力のある詐欺計画になる前に、防御側がそのワークフローを認識できるかどうかだ。
