フィッシングキット「Tycoon2FA」が、Microsoft 365のOAuthデバイス認証フローを悪用した新たな攻撃手法を展開していることが、セキュリティ企業eSentireの調査で明らかになった。多要素認証（MFA）を有効にしていても被害を受ける可能性があるため、Microsoft 365を使う組織は早急な対策が求められる。

Tycoon2FAとは——摘発後も素早く復活したフィッシングキット

Tycoon2FAは、サイバー犯罪者がサービスとして購入・利用できる「フィッシング・アズ・ア・サービス（PhaaS）」プラットフォームの一つだ。2026年3月に国際的な法執行機関による摘発を受けたにもかかわらず、新たなインフラ上にわずかな期間で再構築され、通常の活動水準に戻ったとAbnormal Securityが確認している。それだけでなく、研究者による検知を回避するための難読化レイヤーも強化されている。

今回の調査では、4月末にTycoon2FAがOAuth 2.0のデバイス認可グラントフローを悪用するキャンペーンを展開していることが観測された。Push Securityによれば、このデバイスコードフィッシング攻撃は2026年に入ってから37倍に増加しており、少なくとも10の異なるPhAaSプラットフォームが同手法に対応済みだという。

デバイスコードフィッシングの仕組み——なぜMFAが突破されるのか

デバイスコードフィッシングは、テレビやゲーム機など「ブラウザでのログインが困難なデバイス」向けに設計されたOAuth 2.0の正規フローを悪用する。攻撃の流れを整理すると次のようになる。

  • 攻撃者がデバイス認可リクエストを発行: 攻撃者自身がMicrosoftに対してデバイスコードを取得する
  • フィッシングメールでコードを被害者に届ける: Trustifiのクリックトラッキング URLを含む請求書を装ったメールを送付する
  • 多重リダイレクトで本物そっくりのページへ誘導: TrustifiのURL → Cloudflare Workers → 複数の難読化されたJavaScriptレイヤーを経て、偽のMicrosoftのCAPTCHAページにたどり着く
  • 被害者が microsoft.com/devicelogin にコードを入力: ページ上に表示された「デバイスコードを入力してください」との指示に従い、被害者は本物のMicrosoftの認証ページでコードを入力してMFAを完了する
  • OAuthトークンが攻撃者に発行される: Microsoftはトークンを攻撃者の管理するデバイスに発行し、メール・カレンダー・クラウドストレージへの無制限アクセスが成立する

ポイントは、被害者が正規のMicrosoftドメイン（microsoft.com）上でMFAを完了している点だ。フィッシングページを疑って確認しても、最後の認証ステップは本物のMicrosoftのページで行われるため、違和感を覚えにくい。

Trustifiのクリックトラッキング悪用とアンチ解析機能

Trustifiは正規のメールセキュリティプラットフォームだが、今回の攻撃ではそのクリックトラッキング機能がリダイレクト中継として悪用されている。eSentireは攻撃者がどのようにTrustifiを利用しているかは特定できていないとしているが、正規サービスのURLを経由させることでメールセキュリティ製品のURLフィルタリングをかいくぐっている可能性がある。

また、Tycoon2FAのキットは研究者・自動スキャナーへの対策が徹底されている。Selenium・Puppeteer・Playwright・Burp Suiteの検出、セキュリティベンダーやVPN・サンドボックス・AIクローラー・クラウドプロバイダーからのアクセス遮断に加え、デバッガータイミングトラップも搭載。ブロックリストには現在230以上のベンダー名が登録されており、随時更新されている。分析環境と判断されたリクエストは、本物のMicrosoftページに自動リダイレクトされるため、解析自体が困難になっている。

実務への影響——日本のIT管理者がいま取るべき対策

MFAを設定済みだからといって安心できないのが今回の攻撃の厄介な点だ。eSentireは以下の対策を推奨している。

すぐに実施できる設定変更

  • OAuthデバイスコードフローを無効化する: 組織内でデバイスコードフローが必要なシナリオ（テレビ会議端末、ゲーム機など）がなければ、条件付きアクセスポリシーで urn:ietf:params:oauth:grant-type:device_code を明示的に制限する
  • OAuthのコンセント権限を制限する: エンドユーザーが勝手にサードパーティアプリに広範なアクセスを許可できないよう、管理者承認を必須にする
  • 継続的アクセス評価（CAE）を有効化する: トークンが盗まれた後のセッション継続を困難にする
  • 準拠デバイスからのアクセスのみ許可する: Intune管理デバイス以外からのアクセスをブロックする条件付きアクセスポリシーを設定する

検出・監視の強化

Azure AD（Entra ID）のサインインログで device_code フローからの認証を監視する。通常業務では発生しないはずの端末からこのフローが使われていれば、侵害の可能性が高い。Microsoft Sentinel を使用している場合は、デバイスコードフローに関するKQLクエリを検出ルールとして追加することを検討したい。

筆者の見解

「MFAを設定しているから安全」という認識が多くの組織でまだ根強いが、今回の攻撃はその前提を真正面から崩しにきている。MFAはパスワード単体認証よりはるかに強固だが、「認証の仕組み自体を正規フローとして利用する」攻撃には無力だ。

筆者がゼロトラストを推進する立場から言えば、「デバイスを信頼するのではなく、デバイスの健全性を継続的に評価する」仕組みが本質的な防御になる。準拠デバイスポリシーとCAEの組み合わせは、まさにこの考え方の実装だ。設定にある程度の手間はかかるが、「とりあえずMFAだけ」よりはるかに実効性がある。

Microsoft 365はこうした高度な条件付きアクセス機能を提供しており、正しく使えば強力な防御基盤になる。Tycoon2FAのような攻撃が37倍に急増しているいま、その機能を「設定が面倒だから」と放置しておくのはもったいない。プラットフォームの実力を引き出す設定を積み重ねることが、現時点での最善策だ。

「禁止ではなく安全に使える仕組みを」というアプローチで言えば、デバイスコードフローを一律禁止するのではなく、必要な用途だけを明示的に許可する構成が理想だ。ゼロトラストの基本に立ち返り、アクセスの文脈（デバイス・場所・リスクレベル）を組み合わせた判断ができる環境を整えていきたい。

出典: この記事は Tycoon2FA hijacks Microsoft 365 accounts via device-code phishing の内容をもとに、筆者の見解を加えて独自に執筆したものです。