1台の露出サーバーが暴露した3つのMicrosoft 365フィッシング作戦——その仕組みと、2種類の攻撃をそれぞれ止める防御策

Forg365：商用フィッシング・アズ・ア・サービス・プラットフォーム

これとは別に、ZeroBECの研究者（2026年7月9日～13日報告）によって、Forg365というフィッシング・アズ・ア・サービス（PhaaS）プラットフォームが特定されました。これはTelegramで配布される商用キットで、価格は月額400ドル（年間3,800ドル）です。露出サーバーで見つかったカスタムEvilginxフォークとは異なり、Forg365は複数の攻撃手法とツールを1つのオペレーターダッシュボードにバンドルしています。

Forg365は3つの中核的な機能を組み合わせています：

• AiTMプロキシ — ユーザーがMFAを完了した後にセッショントークンをキャプチャする透過的リバースプロキシ
• デバイスコードフィッシング — 正規のMicrosoft OAuthデバイスコードフローを悪用。被害者は正規のMicrosoftページで認証を完了するため、攻撃者がパスワードを直接見ることはありません
• AI支援による偽装メール・ランディングページ生成 — AIを使って、SharePoint、OneDrive、DocuSign、Adobe Acrobat Signを装った説得力のあるフィッシングメールとランディングページを作成します

このプラットフォームには、アンチボット回避機能（サンドボックスやセキュリティクローラーの検出）、侵害後のメールボックスアクセス（オペレーターがパネル内からメールの閲覧や外部送信が可能）、SMTPローテーション、キャンペーンスケジューリングも含まれています。

一方はMFA後のトークンを窃取し、他方は正規プロトコルを悪用

これら2つの発見は、AiTMプロキシ攻撃とデバイスコード悪用の間の決定的な違いを示しています。この違いを理解することは不可欠です。なぜなら、同じ防御策が両方に対して機能するわけではないからです：

• AiTMプロキシ攻撃（Evilginxタイプ）： 攻撃者は、正規のMicrosoftログインページへのトラフィックをプロキシする偽のログインページをセットアップします。ユーザーは攻撃者のプロキシ上でパスワードを入力し、MFAを完了します。認証成功後、Microsoftは正規ユーザーのブラウザと思われるものにセッションクッキーを発行しますが、そのクッキーは実際にはユーザーのブラウザではなく攻撃者のプロキシに届きます。攻撃者はそのクッキーを再生して被害者のMicrosoft 365アカウントにアクセスできます。

• デバイスコードフィッシング： 攻撃者は正規のMicrosoftデバイスコード（スマートテレビなどキーボードのないデバイスでサインインするための短いコード）を生成し、フィッシングメールで被害者に送信します。被害者は正規のMicrosoftログインページにアクセスし、コードを入力してMFAを完了し、攻撃者のアプリケーションを承認します。「回避」されるものは何もありません。被害者が自らアクセスを許可したのです。攻撃者のバックエンドはその後、Microsoftに対してトークンをポーリングします。

推奨防御策：各攻撃を止めるためのコントロール

Adversary-in-the-Middle（AiTM）プロキシ攻撃（Evilginxタイプ）に対する防御策

AiTMプロキシ攻撃に対する最も効果的な単一の防御策は、フィッシング耐性MFA、特にFIDO2/WebAuthnとパスキーです。これらは認証情報を正規のドメイン名にバインドするため、ユーザーのブラウザが攻撃者のプロキシサイト（異なるドメインを持つ）に接続すると、認証プロトコルがドメインミスマッチを検出し、自動的に認証情報の交換をブロックします。

その他の防御策：

• Conditional Accessポリシー（Entra ID）： デバイスの準拠状況や信頼できる場所の要件を適用し、信頼できないプロキシからのトークン発行をブロックします
• Continuous Access Evaluation（CAE）： リスクのある状態が検出された場合に、ほぼリアルタイムでトークンを失効させることができます
• 異常なトークン使用の監視： トークンが発行されたIPや国とは異なるIPや国から使用されている場合、ありえない移動、そして「見慣れないサインインのプロパティ」を監視します
• 新しく登録されたフィッシングドメインのブロック： 過去30日以内に登録され、フィッシングインフラに使用される既知のホスティングIP範囲に解決されるドメインを監視します

デバイスコード認証悪用に対する防御策

デバイスコードフィッシングでは、攻撃者がユーザーを偽のページで認証情報入力に誘導する必要はありません。ユーザーは正規のMicrosoftログインページとやり取りします。つまり、FIDO2/パスキーだけではこの攻撃を完全には防げません。正規のOAuthフローが使用されているからです。

主要な防御策は、デバイスコードOAuth許可を必要としないユーザーに対してブロックすることです。Microsoft Entra IDのConditional Accessを使用します：

• 「認証フロー」条件を使用して、ドキュメント化された例外グループを除くすべてのユーザーに対してデバイスコードフローをブロックするポリシーを作成します
• ブロックする前に、レポート専用モードで実行するか、過去のサインインログを確認して、正当なデバイスコード使用（例：スマートTV、会議室デバイス）を特定します
• デバイス登録サービス（DRS）の例外を計画します。デバイスコードフローのブロックは、AutopilotやWindowsデバイスの登録に干渉する可能性があるためです

追加の防御策：

• アプリの同意とOAuth許可スコープの制限： デバイスコード許可を使用できるアプリを制限し、同意されたアプリケーションを定期的に監査します
• デバイスコードフローに対してもフィッシング耐性MFAを導入： 完全な解決策ではありませんが、FIDO2ハードウェアキーや証明書ベースの認証は攻撃対象領域を減らします

結論

FBIは2026年5月のKali365 PhaaSプラットフォームに関する注意喚起で、デバイスコードフローのブロックを主な防御策として推奨しました。Forg365のようなフィッシングプラットフォームがこれらの攻撃手法を商品化し続ける中、防御側にとっての運用上の緊急性は明らかです。すなわち、すべての特権アカウントにFIDO2/パスキーを導入してAiTMプロキシ攻撃を阻止し、Conditional Accessを使用して不要なユーザーに対してデバイスコード許可を無効化することです。1つの公開ディレクトリが3つのキャンペーンを暴露したかもしれませんが、その教訓はすべてのMicrosoft 365テナントに当てはまります。