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

2026年7月、2つの並行した調査により、多要素認証（MFA）をすり抜ける高度なMicrosoft 365フィッシング攻撃が、根本的に異なる2つの方法——「Adversary-in-the-Middle（AiTM）プロキシ攻撃」と「デバイスコード認証の悪用」——で急増していることが明らかになりました。最初の発見は、攻撃者の単純なミス、すなわち設定を誤ったPython Webサーバーが3つの進行中のキャンペーンを露呈したことから始まりました。2つ目の発見は、研究者が新たな商用フィッシングプラットフォーム「Forg365」を追跡したことによるものです。各攻撃の仕組みを理解することが、適切な防御を講じるための第一歩です。なぜなら、一方への対策が他方には通用しないからです。

設定ミスのサーバーが暴露した3つのEvilginx作戦

2026年7月13日、フランスのセキュリティ企業Lexfoは、攻撃者がPython Webサーバーをパブリックポートで公開し、ディレクトリリスティングを有効にしたままにしていたミスを突き、3つの進行中のEvilginxベースのMicrosoft 365フィッシング作戦を暴露しました。サーバーの.bash_historyには、python3 -m http.server 8080というコマンドがそのまま残っていました。この公開ディレクトリから、Lexfoは攻撃者のツールキット全体、ログ、窃取した被害者データを入手し、さらに別の2つのフィッシングオペレーターが運営する別々のキャンペーンを特定しました。

3つのキャンペーンはすべて、EvilginxベースのAiTMフィッシングであり、Microsoft 365のログインページをプロキシして、ユーザーがMFAを完了した後に発行されるセッショントークンを窃取するものでした。そのうちの1つのキャンペーンでは、12カ国にわたる218のアカウントが記録されており、その94%は企業のメールボックスでした。これらの作戦は2つの異なる攻撃経路を使用していました。すなわち、Evilginxによるセッショントークン窃取（AiTMプロキシ経由）と、デバイスコードフィッシングです。後者のキットは被害者を正規のMicrosoftデバイスログインページに誘導し、そこで被害者自身がアクセスを許可し、攻撃者のバックエンドがそのトークンをポーリングして取得するというものでした。

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テナントに当てはまります。