MicrosoftがAI駆動のデバイスコード型フィッシング「EvilTokens」をテイクダウン——ID基盤を狙う量産型BECの潮流に待ったをかける動きです

今日の深掘りポイント

• デバイスコード（OAuth 2.0 Device Authorization Grant）を悪用した「正規ページでのサインイン」を武器に、MFAを含む従来対策の“安心感”を逆手に取る攻撃が量産段階に入った事実が重いです。
• サービスとして提供されるフィッシング基盤がAIで全工程を自動化し、侵害後はメールボックスを機械的に解析してBEC（ビジネスメール詐欺）を最適化する。攻撃の「習熟要件」を大幅に下げる犯行インフラの再現性が課題です。
• 連邦地裁の許可と民間複数社の連携で50サイトを押収した点は、越境型犯罪への官民協調の実効性を示します。ただし、プロトコル自体（デバイスコードフロー）は正規用途で広く使われるため、テイクダウンは重要な一手に過ぎず、設計・運用両面の恒常対策が要ります。
• 直近の運用では、ユーザー同意制御の強化、デバイスコードフローの許可範囲見直し、OAuthトークン/セッションの強制失効、Exchangeの悪性ルール狩り込み、そしてサインインログからの「grant_type=device_code」ハンティングを優先度高で回すべきです。

はじめに

Microsoftが「EvilTokens」と名付けられたデバイスコード型フィッシング・サービスのテイクダウンを発表し、12,000件超のメールボックス侵害に関与していたと報じられています。攻撃基盤はAIでオペレーションを自動化し、メールボックスの内容解析から詐欺実行までを“犯罪SaaS”として誰でも利用できる形に磨き上げていました。今回の摘発は、ID基盤を起点にしたBECや不正送金といった実害の連鎖を止める上で象徴的な一歩です。
一方で、被害規模・再現性・当面の可用性（残存する模倣サービスや再建の容易さ）を総合すると、足元の運用改善をすぐに差し込む必要があります。特に、条件付きアクセスの見直しやユーザー同意のガバナンス、トークン/セッションの強制失効と継続ハンティングは待ったなしです。

参考情報は、現時点で以下の公開記事に基づき要点を整理しています（一次情報の追加確認は今後の課題です）。

• Microsoft Takes Down ‘EvilTokens’ Device Code Phishing Service Linked to 12,000 Email Hacks（The Hacker News）

深掘り詳細

事実整理（確認できる範囲）

• Microsoftは、AIを用いたデバイスコード型フィッシング「EvilTokens」の運用基盤に対し、連邦地裁の許可と民間複数社の連携でテイクダウンを実施し、関連する約50サイトを押収したと報じられています。
• 「EvilTokens」は全世界で1万超の組織にまたがる12,000件以上のメールボックス侵害に関与し、金融詐欺等の計画・実行に資する機能を提供していたとされます。
• Microsoftは本件の脅威アクターを「Storm-2992」として追跡しているとされています。
• 攻撃はOAuth 2.0のデバイス認可フローを用い、被害者に正規のMicrosoftサインインページでコードを入力させることで、攻撃者側デバイス/アプリで利用可能なアクセストークン/リフレッシュトークンを取得し、パスワードを把握せずにメールボックスへアクセスする手口です。
• 侵害後は、メール内容の自動解析や会話ハイジャック、取引先を狙う継続的詐欺実行の最適化が組み込まれていたと報じられています。

以上は提供情報と公開記事に依拠した整理で、一次情報の精査・差分確認は今後も続けるべきです。

分析・インサイト（編集部視点）

• MFA依存の限界があらためて露呈しています。ユーザーが「正規ドメインでコードを入力しMFAにも応答する」ため、利用者体験としては“安全に見える”のが曲者です。ユーザー教育の範囲だけで食い止めるのは難しく、フローそのものの許容/不許容、アプリ同意の境界、トークンの扱い（継続セッション/リフレッシュトークン）といった設計・ガバナンスの手当てが中核になります。
• サービス化×AIの組み合わせにより、BECの“習熟曲線”がほぼフラットになっています。侵害数の広がりから見ても、特定の高度犯罪者だけでなく幅広い犯罪者に攻撃機能を供与する産業化が一段階進んだと見るべきです。
• テイクダウンの効果は即効性がありますが、根本的な脅威は「プロトコルの悪用」と「ユーザー同意/セッション設計の盲点」にあります。攻撃インフラは可搬性が高く、別名義での再構築も容易です。よって今回の措置を契機に、自社テナントのOAuthフロー・同意ポリシー・セッション管理・サインイン監視の“ベースライン”を見直し、再発前提の態勢に引き上げるのが本筋です。
• メトリクスの観点でいえば、即応の必要性と再発確率の高さ、そして現場で差し込み可能な対策メニューが十分にある、という三点が同時に立っています。すなわち“重大だが打ち手もある”タイプのインシデントで、運用改善の好機でもあります。

脅威シナリオと影響

以下は公開情報に基づく仮説シナリオで、MITRE ATT&CKに沿って整理します（実環境での観測に応じて更新が必要です）。

• 初期侵入
  • ユーザーに「microsoft.com/devicelogin」でのコード入力を促すフィッシング（メール/メッセージ/電話併用）。
  • MITRE: T1566（Phishing）, T1566.002（Spearphishing Link）
• 認証悪用・権限取得
  • 攻撃者が発行したデバイスコードとアプリIDに対して、被害者が正規ページで認証・MFAを実施。結果として攻撃者側環境でアクセストークン/リフレッシュトークンが取得可能に。
  • MITRE: T1550（Use Alternate Authentication Material）, T1078（Valid Accounts：クラウドID/トークンの実質的な流用）
• 発見・横展開の準備
  • メールボックス/組織情報の自動探索、取引先や役職者の抽出、決裁フローの把握。
  • MITRE: T1087（Account Discovery）, T1069（Permission Group Discovery）
• 収集・持続化
  • リモートからのメール収集、Outlookルール/転送設定の改変による痕跡隠蔽・持続化。
  • MITRE: T1114.002（Remote Email Collection）, T1114.003（Email Forwarding Rule）
• コミュニケーション・詐欺実行
  • 取引先との会話ハイジャック、請求書改ざん、振込先変更の誘導。
  • MITRE: T1656（Impersonation／なりすまし, 関連テクニックとしての社会工学的操作）
• 影響
  • 金銭的被害、信用失墜、対外的通知・法執行対応コストの増大。準リアルタイムに複数組織へ連鎖するリスク。

注意点として、デバイスコードフローは正規用途（CLIツールやヘッドレス端末認証）でも使われます。よって「全面遮断」には業務影響が伴い得る一方、「許容のまま無警戒」だと再発可能性が高い——このトレードオフを前提に、精緻な許可・監視・検知体制を敷くことが肝要です。

セキュリティ担当者のアクション

優先度の高い順に、CISO/SOC/ID運用（Entra ID/Exchange Online）で実施したい具体策を整理します。

• テナント方針と同意ガバナンスの即時見直し
  • ユーザーの自己同意を原則禁止または低リスク権限のみに制限し、管理者同意ワークフローを有効化します（Mail.Read/ReadWrite、offline_accessなど高リスク権限は管理者審査を必須化します）。
  • 既存のエンタープライズアプリ/サービスプリンシパルを棚卸しし、不要なアプリ同意を剝がします（特にGraphのメール系スコープ）。
• デバイスコードフローの取り扱い方針
  • 正当な利用要件を洗い出し、許可対象アプリを極小化します。可能なら当面ブロックし、業務要件に基づく例外承認制に移行します。
  • 代替フロー（Authorization Code + PKCE、デバイス登録済みのPoPトークンなど）への移行計画を検討します。
• トークン・セッションの強制失効と継続監視
  • ハイリスクユーザー（役員、財務、購買、営業）のサインインセッションを一斉失効し、リフレッシュトークンを無効化します（パスワード変更だけでは不十分です）。
  • サインインログ/監査ログで「grant_type=device_code」「不審なアプリID」「不自然な地理/ASN」を条件にハンティングを常設化します。検知した場合は当該アプリの同意を取り消し、該当ユーザーのセッション失効と合わせて是正します。
• Exchange Onlineの事後痕跡狩り
  • 受信トレイルール（自動削除/移動、外部転送）、フォワーディング設定、委任アクセス権の異常を網羅的に確認・除去します。特に「特定の送信者・件名を隠す」ルールはBEC隠蔽の常套手段です。
  • 送信メールにおける会話ハイジャックの痕跡（過去スレッドへの唐突な振込先変更指示など）をサンプリング監査します。
• 条件付きアクセス（CA）と強固認証
  • 高リスクロール/アプリに「フィッシング耐性MFA（FIDO2/WebAuthn）」を段階的に強制します。
  • 高価値アプリには「デバイス準拠/ハイブリッド参加」の必須化や、サインイン頻度・セッション制御の引き締めを適用します。
  • サインインリスク/ユーザーリスクに応じた自動ブロック/再認証を有効活用します。
• ユーザー教育は“コード入力行為”に的を絞る
  • 「自分が開始していないのに“デバイスコードの入力”を求められたら中止・通報」という一点突破の行動指針を、短時間のマイクロドリルで徹底します。正規ドメイン表示に惑わされない“相関確認”（自分が今まさに開始したワークフローと一致しているか）を教え込みます。
• インシデント準備と外部連携
  • 金流遮断（振込留保・SWIFT連絡）を含むBEC即応プレイブックを最新化し、法務・財務・広報・保険の連絡線を即時起動できるよう整備します。
  • 法執行・業界ISAC・クラウドベンダとIOA/IOCの交換を強化し、同種サービスの再出現に備えます。

最後に強調したいのは、「テイクダウン＝安全化」ではないことです。攻撃は“正規フローの社会工学的転用”という構造上の強みを持ち、再現も容易です。今回の件は、IDを中核とする防御の見直しを一気に進めるための、またとない合図になります。現場の皆さんの迅速な差し込みと、運用ベースラインの再定義を強くお勧めします。

参考情報

• https://thehackernews.com/2026/09/microsoft-takes-down-eviltokens-device.html