MFAを設定していても安全とは限らない。2026年2月から始まったEvilTokensキャンペーンは、AIで個別化したフィッシングメールと正規のOAuthフローを組み合わせ、多要素認証を事実上無効化する手口を確立した。

セキュリティ企業Huntressが公開した調査レポートによると、このキャンペーンは米国・カナダ・オーストラリア・ニュージーランド・ドイツの340以上の組織に被害を与えた。建設会社から法律事務所まで業種を問わず影響が広がっている。

この記事でわかること:
– EvilTokensがMFAを突破する「デバイスコードフィッシング」の仕組み
– AIで個別化されたフィッシングメールを大量生成する手口
– Railway PaaSをトークンハーベスティングに悪用する方法
– 実際に有効な防御策

EvilTokensとは

https://www.huntress.com/blog/railway-paas-m365-token-replay-campaign

EvilTokensは、2026年2月16日にTelegramチャンネルで初めて公開されたPhaaS（Phishing as a Service：フィッシング代行サービス）プラットフォームだ。Huntressが調査したところ、「B2B Sender」「Office 365 Capture Link」「SMTP Sender」という3種類のプロダクトを販売しており、24時間対応のサポートチームまで備えている。ビジネスとして設計された攻撃インフラだ。

デバイスコードフィッシングとMFAの無効化

EvilTokensが中核に置くのが「デバイスコードフィッシング」だ。Microsoftがスマートテレビやプリンターなど入力手段が限られたデバイス向けに用意したOAuthの認証フローを悪用する。

攻撃の流れはシンプルだ。攻撃者がデバイスコードを生成し、フィッシングメールや偽サイトを通じて被害者に「Microsoftの正規サイト（microsoft.com/devicelogin）でこのコードを入力してください」と誘導する。被害者がコードを入力してMFA認証を完了した時点で、攻撃者のバックエンドに有効なOAuthトークンが渡る。パスワードは不要で、MFAを通過した後にトークンが発行されるため、MFAが防壁として機能しない。

取得したリフレッシュトークンは最大90日間有効なため、パスワードをリセットしても攻撃者はアクセスを維持し続けられる。

AIで個別化されたフィッシングメール

従来のフィッシングは、同一テンプレートを一括送信するキャンペーン型だった。EvilTokensはここに根本的な変化をもたらした。

Huntressの分析では、このキャンペーンで観測されたフィッシングメールに「まったく同じ文面が存在しない」と報告されている。建設業向けには入札提案書、法律事務所向けには契約書の確認依頼、DocuSign風の書類署名通知など、受信者の業種や役職に合わせた内容が都度生成される。

EvilTokensのダッシュボードにはAIワークフロー機能が組み込まれており、メールフィルターの回避、フィッシングルアーの個別化、標的メールボックスからの機密メール探索に使えるとされている。個別化されたメールはスパムフィルターの学習データに引っかかりにくく、受信者の目にも不自然に映らない。

Railway PaaSをトークン窃取基盤として悪用

攻撃インフラの核心にあるのが、開発者向けPaaS「Railway」の悪用だ。RailwayはHerokuに近い環境で、GitHubリポジトリをプッシュするだけで即座にHTTPSエンドポイントが生成される。登録はメールアドレスだけで完了する。

RailwayのIPアドレス（162.220.232.0/22・162.220.234.0/22）は、Microsoftのリスク評価システムに「信頼できるクラウドプロバイダー」として認識されている。このため、Railwayから発生する認証試行のリスクスコアは上がらない。Huntressの観測では、わずか3つのIPアドレスだけで確認されたイベントの84%を占めており、少数のRailwayアプリが大量のトークン窃取を処理していた。

多段リダイレクトで検知を回避

配信経路も精巧だ。CiscoやTrend Micro、MimecastといったセキュリティベンダーのURLリライターを悪用し、フィッシングリンクを信頼済みドメインでラッピングする。ある事例では「SafeLinks → Trend Micro → Cisco Secure Web → フィッシングページ」という4段階のリダイレクトチェーンが確認された。メールセキュリティツールは各ホップの評判しか参照できず、全体のチェーンを見抜けない。

最終ページはCloudflareのworkers.devにホストされることが多く、こちらも信頼済みドメインとして扱われる。さらにMicrosoftのDynamics 365「Customer Voice」フォームを偽のランディングページとして使う手口も観測されている。

防御策

Huntressはいくつかの具体的な対策を推奨している。

デバイスコードフローの制限が最優先だ。 Microsoft Entra ID（旧Azure AD）の条件付きアクセスポリシーで、デバイスコード認証を必要な場合以外はブロックする。これがEvilTokensに対する最も直接的な防御になる。

RailwayのIPをブロックする。 162.220.232.0/22および162.220.234.0/22からの認証イベントを検知・ブロックするルールを設定する。業務上Railwayを使う必要がなければ、このIPレンジを条件付きアクセスの「名前付き場所」として除外設定する。

認証ログを継続的に監視する。 見慣れないクラウドプロバイダーのIPからの認証試行、短時間での複数組織への認証、BAV2ROPCユーザーエージェント（プログラムによる自動トークン更新の痕跡）などを検知ルールとして設定する。

フィッシング耐性の高い認証方式に移行する。 デバイスコードフィッシングはMFA完了後にトークンを取得するため、MFA単体では防げない。FIDO2準拠のパスキーや証明書ベース認証など、フィッシング自体を無効化できる認証方式への移行が根本的な解決策になる。

MFAの前提を問い直す時期

EvilTokensキャンペーンが示すのは、攻撃者がAIとクラウドPaaSを組み合わせてスケーラブルな攻撃工場を構築した現実だ。個別化されたメール生成、信頼済みインフラの悪用、MFAを回避するOAuth攻撃が一体となっており、「MFAを設定すれば安全」という前提が成り立たない攻撃が大規模に展開できる状態になっている。

Huntressは引き続きRailwayからの認証をブロックしており、Microsoftとも連携して対応にあたっている。2026年5月5日にはMicrosoftとの合同ウェビナーも予定されており、より詳細な技術情報が公開される見込みだ。