jp:
日本語
主なポイント
- メールボックスルールは侵害後に攻撃者がよく悪用するものの一つで、使われると高いリスクを伴います。攻撃者は、情報流出、永続化、通信操作のために標準機能のメールボックスルールを悪用します。これにサードパーティサービスやドメインスプーフィングを組み合わせることで、ネットワークレベルでの傍受を行うことなく、スレッドの乗っ取り、被害者のなりすまし、ベンダーとの通信の操作が可能になります。
- メールボックスの悪用は想像以上に広く使われる手法です。2025年第4四半期において、侵害されたアカウントの約10％で初期アクセス直後に悪意のあるメールボックスルールが作成されていました。
- 攻撃者は識別しやすいパターンを使用します。悪意のあるルールは、最小限で意味のない名前（., ..., ;）が圧倒的に多く、メッセージの削除や、アーカイブやRSS Subscriptionsのようなあまり確認されないフォルダへの移動といったアクションを好む傾向があります。攻撃者は検知されないと確信しているために手を抜いており、ルール名にほとんど注意を払わず、即席の簡易な文字を選ぶ傾向があります。
- 永続性はパスワードリセット後も維持されます。転送や抑制のルールは認証情報の変更後も有効なままであり、ルールが存在する限り継続的なデータ漏えいを許してしまいます。
はじめに
最後にメールボックスルールを確認したのはいつですか？
Microsoft 365環境では、攻撃者は通常、認証情報フィッシング、パスワードスプレー攻撃、ブルートフォース攻撃、またはOAuth同意の悪用を通じて初期アクセスを獲得します。
侵入後、攻撃者は即時の破壊活動ではなく、永続化とステルス性の確保に注力します。マルウェアやC2インフラを展開する代わりに、プラットフォームの標準機能を悪用し、侵害されたアイデンティティのもとで検知されることなく活動します。
永続性を維持するための特に効果的な手法の一つが、悪意のあるメールボックスルールの作成です。メールボックスルールは本来、ユーザーがメールを整理するための機能ですが、攻撃者はこれを悪用して、メッセージの削除、非表示化、転送、既読化などを行い、被害者に気付かれることなくメールの流れを静かに制御します。
攻撃者がメールボックスルールを悪用する理由
メールボックスルールは、M365に組み込まれた機能を利用してステルス性、自動化、永続性を提供し、攻撃者にとって以下のような目的の達成を可能にします。
密かに行われるデータの持ち出し：
攻撃者は、転送またはリダイレクトのルールを作成し、メールのコピーを自動的に外部の攻撃者管理下のメールボックスへ送信します。多くの場合、「invoice」「wire」「contract」などの特定のキーワードや送信者を指定し、ノイズを最小限に抑えながら価値の高いデータを収集します。あるいは、メールをArchiveやRSS Feeds、隠しフォルダなど目立たないフォルダに移動させ、転送の兆候を発生させることなく定期的に確認できるようにします。
被害者の欺瞞とメールの抑制：
メッセージの削除、既読化、または移動を行うルールにより、セキュリティアラート、パスワードリセットメール、多要素認証（MFA）の通知、不審な返信、サードパーティサービスへの登録通知など、攻撃者の活動を露見させる可能性のあるメールが隠されます。これにより被害者のメールボックスに対する認識が操作され、攻撃者は足場をさらに強固にしたり、不正な取引を完了したりするための時間を稼ぐことができます。
マルウェアを使わない永続化：
自動転送ルールにより、パスワード変更後であってもメールボックスの内容を把握し続けることができます。ルールが存在する限り情報は漏えいし続け、クラウドネイティブな永続化メカニズムが構築されます。
中間者攻撃のような挙動：
特定のやり取りを隠しフォルダに振り分けることで、攻撃者は通信チャネル内に入り込み、次のようなことを可能にします。
- ベンダー、パートナー、または顧客からのメッセージを、被害者が確認する前に傍受します。
- メールボックス所有者になりすましたり、既存のメッセージスレッドに介入したりします。
- 不正行為を露見させる返信や通知を抑制します。
- メッセージを選択的に表示または非表示にすることで、双方に対する情報の見せ方を操作します。
従来の中間者攻撃のようにネットワーク上の位置取りを必要とせず、正規のプラットフォーム機能を用いて同様の結果を実現します。被害者は通常通り通信を行っていると認識していますが、その裏で重要なやり取りが静かに傍受・操作されており、攻撃者にとっては検知されにくいまま大きな戦術的優位性を得ることになります。
悪意のあるルール作成の統計
侵害されたアカウントの分析から、メールボックスルールの悪用は例外的なケースではなく、頻繁に見られる侵害後の活動であることが一貫して示されています。2025年第4四半期には、侵害されたユーザーアカウントの約10％で、初期アクセス直後に少なくとも1つの悪意のあるメールボックスルールが作成されていました。アカウント乗っ取り（ATO）後、最短で約5秒という非常に短い時間でルールが作成されるケースも確認されています。
最も一般的に観測されたルール名：
攻撃者は、悪意のあるルールに対して説明的で人が理解しやすい名前を付けることはほとんどありません。その代わりに、短く一般的で目立ちにくい文字列を好みます。これは、攻撃者が検知されないと過信しており、手を抜いているためです。
最も頻繁に観測されたルール名は次のとおりです。
- 「.」 （16％）
- 「...」 （8.5％）
- 「..」 （8％）
- 「;」 （6％）
- 「;;;」 （4％）
図1：Microsoft Outlookにおけるルール作成の例
最も一般的なルールのアクション：
メールボックスルール作成時に最もよく観測されるアクションは次のとおりです。
- 特定の送信者からのメッセージ、または特定の単語を含むメッセージを削除する。
- メッセージを「Conversation History」フォルダに移動する。
- メッセージを「Archive」フォルダに移動する。
攻撃者が最小限または意味のないルール名を使用する理由：
低コスト・低リスク： 攻撃者は時間に追われている場合や過信している場合が多く、メールボックスルールは歴史的に検知率が低く、見直されることも少ないため、命名規則にほとんど労力をかけません。
異なる攻撃者間で同様のルール名が使われる理由はいくつか考えられます。公開されている侵害後ツール、フィッシングキット、PhaaSプラットフォームでは、被害者やオペレーターごとにプログラムでルールを作成する際、ハードコードされたデフォルト名や同一テンプレートが使用されることがよくあります。さらに、フォーラムやダークウェブのマーケットプレイスで流通しているBECのガイドやコードスニペットがコピーされ再利用される中で、ルール名もそのまま使われます。共通のツールを使用していない場合でも、最小限の労力で済ませようとする同じ思考により、攻撃者が独立して似たような名前に行き着くこともあります。
シナリオ例
給与詐欺
以下のシナリオは、攻撃者がメールボックスルールの悪用と内部フィッシングを組み合わせ、影響を受けるユーザーにほとんど気付かれないまま、標的型の給与詐欺を実行する方法を示しています。
初期侵害とルール作成
このインシデントでは、最初に侵害されたアカウントは「Accounting Specialist」という役職のユーザーのものでした。アクセスを取得して間もなく、攻撃者は「...」という名前のメールボックスルールを作成しました。そのロジックは単純で、件名に「FW: Payment Receipt」を含むすべてのメールを自動的にArchiveフォルダに移動するというものでした。この件名は後に攻撃者による内部フィッシングキャンペーンで使用され、このルールはそのフィッシングメールに対する警告返信や不審なアクティビティの報告を抑制することを目的として設計されていました。
内部フィッシング：
最初のメールボックスを掌握した攻撃者は、同じ組織内の追加の45人のユーザーを標的に、「FW: Payment Receipt」という件名を使用した内部フィッシングキャンペーンを開始しました。このフィッシングメールは意図的に最小限の内容で構成されていました。
- メール本文は空でした
- 添付ファイルが含まれていました
- 送信者のメール署名がわずかに改変されていました
このメールは正規の社内アカウントから送信され、見慣れた署名が使用されていたため、多くのユーザーの疑念チェックや従来のメールセキュリティ対策をすり抜けました。
二次侵害：
受信者の中には、機密性の高い業務や給与関連の通信にアクセスできる役職であるCEOアシスタントも含まれていました。このユーザーがフィッシングの添付ファイルを開いたことで、2つ目のアカウントも侵害されました。最初のアカウントと同様に、攻撃者は即座に侵害後の制御を確立するため、再び「...」という名前のメールボックスルールを作成しました。このルールは、件名に「Payroll enrollment」を含むすべてのメールをArchiveフォルダに移動し、被害者に対する給与関連の可視性を実質的に遮断しました。
その後、侵害されたCEOアシスタントのアカウントから、会社の給与担当者に対して「Payroll enrollment」という件名のメールが送信されました。このメッセージは、給与に関する不正な手続きを開始させることを狙ったものでした。この段階で、メールボックスルールは攻撃の成功において重要な役割を果たしました。具体的には、次の点が保証されていました。
- 返信や確認のリクエストが隠される
- セキュリティアラートが抑制される
- 被害者が自分のアカウントの不正利用に気付かないままである
この一連の攻撃はすべてMicrosoft 365の正規機能内で実行されており、メールボックスルールを単なる生産性向上機能ではなく、高リスクな侵害後のシグナルとして扱う必要がある理由を示しています。
メールハイジャックとスレッド操作
以下のシナリオは、攻撃者がメールボックスルールとサードパーティのメールサービスを組み合わせて使用し、メール通信の中だけで中間者攻撃のような環境を構築する方法を示しています。これにより、継続的なアカウントアクセスを必要とせずに高度なビジネスメール詐欺（BEC）を実現します。
初期侵害と抑制ルール
最初のユーザーアカウントが侵害された後、攻撃者は「....」という名前の悪意のあるメールボックスルールを作成しました。このルールは特定のメールサービスを対象としており、「From」アドレスに「zoho」という単語を含むすべてのメールを自動的に「RSS Subscriptions」フォルダに移動します。このフォルダは通常、自動フィード更新に使用されるためユーザーに確認されることがほとんどなく、攻撃者が制御する通信を隠すのに理想的な場所となります。
インフラとしてのサードパーティメールサービスの悪用
Zohoは、企業がカスタムメールドメインを登録し、業務用メールアドレスを作成できるサービスを提供しています。攻撃者は侵害したユーザーの業務用メールを利用してこのサービスに登録し、自身が管理するカスタムメールアカウントを作成しました。すでにメールボックスルールが設定されていたため、Zohoからの確認メールや関連するやり取りはすべて自動的に「RSS Subscriptions」フォルダに隠されました。攻撃者は確認コードを取得し、被害者に気付かれることなくアカウント設定を完了させました。
図2：Zohoの確認コード
ホモグリフ登録によるドメインスプーフィング
Zohoプラットフォームを利用して、攻撃者は正規のテナント名に非常に似せたホモグリフ攻撃を用いたドメインを登録しました。その後、「[user_name]@[tenant_name]
図3：アカウントに追加された新しいスプーフィングメールアドレス
スレッドの乗っ取りと不正な通信
攻撃者は、侵害されたテナントとサードパーティベンダーとの間で行われていた既存の支払い依頼スレッドを特定しました。不審に思われる可能性のある新規の会話を開始するのではなく、正規のスレッドを乗っ取りました。Zohoで作成した偽のメールアドレスを使用し、これらのスプーフィングされたアドレスをCC欄に追加することで、通信に見せかけの正当性を持たせました。
攻撃者は取引の状況について問い合わせるメッセージを送信しました。ベンダーは、当該取引は約1週間前にすでに完了していると返信しました。この時点で、当社から顧客へのアラートを受けてアカウントが停止されパスワードが変更されたため、攻撃者は数日後に侵害されたテナントアカウントへのアクセスを失いました。
想定される攻撃の継続と持続的リスク
構築されたインフラと通信パターンに基づくと、攻撃者の主な狙いは、資金が受領されていないと主張し、攻撃者が管理する口座への二重支払いを要求することであったと考えられます。元のメールボックスへのアクセスは失われたものの、Zohoベースの偽メールアドレスは現在も有効である可能性が高いと見られます。これにより持続的なリスクが生じます。すなわち、攻撃者は外部のスプーフィングされたアカウントから独立して詐欺を継続し、乗っ取ったメールスレッドの正当性やベンダーとの過去のやり取りを悪用する可能性があります。
このシナリオは、アプリケーションレイヤー内で完結するメールベースの中間者的な活動の一例を示しています。メールボックスルールが検知を抑制し、サードパーティプラットフォームがインフラを提供し、スレッド乗っ取りが社会的信頼性を構築することで、侵害された環境への継続的なアクセスなしに攻撃が成立します。
大学アカウントの乗っ取りと大規模スパム運用
以下のシナリオは、これまでとは明確に異なる攻撃者の目的と運用パターンを示しています。標的型のビジネスメール詐欺（BEC）ではステルス性と精密さが重視されるのに対し、大学アカウントの侵害では検知をあまり気にせず、巧妙さよりも量とスピードを優先してメールボックス全体を乗っ取るケースが多く見られます。
無条件のメールボックス隔離
大学環境では、侵害されたアカウントに共通して見られる特徴として、無条件のメールボックスルールが挙げられます。これらのルールは特定の送信者、キーワード、件名を対象とするのではなく、すべての受信メールに対して一律のアクションを適用します。最も一般的に観測される設定は次のとおりです。
- すべての受信メッセージを削除する
- すべての受信メッセージを目立たないフォルダ（例：Archive、RSS Subscriptions、Deleted Items）に移動する
- すべての受信メッセージを既読にし、受信トレイから移動する
これらの目的は、セキュリティアラートやベンダーとの通信を選択的に抑制することではありません。むしろ、メールボックスを完全に隔離し、正規ユーザーがメールを一切受信できない状態にすることにあります。
運用目的：大規模スパム配信
特定のベンダーからのメールや特定のフィッシングスレッドへの返信のみを傍受するような限定的なルールを作成するBEC攻撃者とは異なり、大学アカウントを狙う攻撃者は大量のメール配信を優先します。メールボックスが隔離されると、次のような状況が生まれます。
- 攻撃者は送信メールに対して制限のない制御を得る
- 正規ユーザーは警告、バウンスメール、不正利用の報告を受信できず気付かない
- 侵害されたアカウントが大量のスパムやフィッシングキャンペーンの送信に使用され、他の学生、教職員、または外部の連絡先が標的となる
この手法はステルス性を犠牲にする代わりに運用効率を優先しています。攻撃者はアカウントが検知されて無効化される可能性を理解していますが、その短いアクセス期間でも、組織のセキュリティチームが対応する前に数千件の悪意のあるメールを配信するには十分です。
大学コミュニティを狙う一般的な詐欺手法
大学環境は、その特性を悪用した特定の詐欺手法に対して特に脆弱です。攻撃者は、インターンシップやアルバイトを探している学生を狙った偽の求人情報、前払い費用や個人情報を要求する奨学金詐欺、不自然に低価格で電子機器や教科書などを販売する偽のマーケットプレイス出品などを広く配布します。これらの手口は、学生の正当なニーズに合致しているため効果的であり、学期開始時や卒業シーズンといった活動が活発な時期に特に拡散されやすい傾向があります。また、侵害された大学のメールアドレスが使用されることで、受信者は.eduドメインからの通信を信頼しやすくなり、詐欺に対する信頼性が誤って高められてしまいます。
図4：大学における偽求人詐欺の例
休眠アカウントおよび放置アカウントの標的化
アクティブな学生や教職員のアカウントが頻繁に侵害される一方で、攻撃者は休眠アカウント、すなわち元学生、退職した教員、またはすでに組織を離れた職員のアカウントで、適切に無効化されていないものも標的にします。これらのアカウントが魅力的な標的となる理由はいくつかあります。
- セキュリティ態勢の弱さ：休眠アカウントは現行のセキュリティポリシー導入以前に作成されていることが多く、多要素認証（MFA）の適用、最新のパスワード要件、条件付きアクセス保護などが設定されていない場合があります。
- 監視の欠如：セキュリティチームは通常、ユーザー行動をベースライン化できるアクティブなアカウントの監視に重点を置きます。休眠アカウントは正当なアクティビティを生成しないため、認証やメールボックスルールの作成が完全に見逃される可能性があります。
- 検知の遅延：これらのメールボックスを積極的に確認する正規ユーザーが存在しないため、不審なメール、パスワードリセット通知、警告メッセージに気付く人がいません。その結果、攻撃者は発見されるまで数週間から数か月にわたり活動を継続できてしまいます。
大学がこの手法の標的となる理由
大学環境が大規模スパム運用の対象となりやすい理由はいくつかあります。
- 学内および管理ネットワーク全体にわたる信頼関係を伴う大規模な連絡先リストを保有していること。
- 大学のメールアドレスが本質的に信頼性を持つため、フィッシングの成功率が高まること。
- 企業環境と比較して歴史的にセキュリティ態勢が低く、MFAの導入が不十分であったり、メールボックスルールの監視が限定的であったりすること。
- ユーザーの入れ替わりが激しく、IT管理が分散しているため、検知や対応が遅れる可能性があること。
組織は、メールボックスルールの悪用が単一の手法ではないことを認識する必要があります。検知および対応戦略は、巧妙で長期間にわたるBEC攻撃と、大量かつ攻撃的なスパムキャンペーンの両方を考慮する必要があり、それぞれがルールの作成および使用において異なる挙動パターンを示します。
攻撃者の自動化とツール
メールボックスルールの作成には手動の作業が必要ですが、時間のかかるものではありません。実際には、複数の侵害アカウントに対する悪意のあるメールボックスルールの作成は完全に自動化することが可能であり、攻撃者は最小限の労力で個別の標的から企業全体に及ぶキャンペーンへと規模を拡大できます。
大量ルール展開の実態
以前は、攻撃者は侵害した各アカウントごとに手動でルールを作成していました。現在の攻撃フレームワークでは、Microsoft Graph API、Exchange Online PowerShell、直接的なAPIコールを活用し、数十から数百のアカウントに対してメールボックスルールの作成、変更、削除をプログラム的に同時実行できます。攻撃者が有効なセッショントークンや認証情報を取得してしまえば、大規模なルール展開の技術的ハードルは非常に低くなります。
この自動化機能により、メールボックスルールの悪用は標的型で精密な手法から、スケーラブルで再現性のある攻撃パターンへと変化しています。基本的なスクリプト知識を持つ攻撃者であれば、フィッシングによって複数のアカウントを侵害し、数分以内にそれらすべてに対して永続化メカニズムを即座に確立することが可能です。
ATOLS：自動化の容易さを示す例
この自動化機能がいかに容易に利用可能で危険なものとなっているか、そして潜在的なリスクを示すために、プルーフポイントのリサーチャーはATOLS（Account Take Over Live Simulation）という完全に機能するツールを開発しました。このツールは、攻撃者がこれらの操作を大規模に実行できる容易さを実証するものです。
ATOLSは次のワークフローで動作します。
- フィッシングインフラの構築： 匿名性確保のためにVPNを使用し、ATOLSは（外部のフィッシングキットの支援を受けて）正規のMicrosoft 365ログインページを模倣したフィッシングURLを生成します。
- セッショントークンの窃取： フィッシングリンクはメールや侵害されたサードパーティアプリケーション（3PA）を通じて標的ユーザーに送信されます。単にユーザー名とパスワードの組み合わせを取得するのではなく、リバースプロキシが認証成功後に生成されるセッションクッキー／トークンを取得します。ATOLSはこの取得したセッションクッキーを使用します。このクッキーにより、追加のMFA認証を発生させることなく、ユーザーのMicrosoft 365環境へ即座に認証済みアクセスが可能となります。
- 悪意のある操作の自動実行： セッショントークンを取得すると、ATOLSはオペレーターが指定した名前とロジックで悪意のあるメールボックスルールを自動的に作成します。
- 侵害後の活動： ATOLSは、連絡先の列挙、SharePointへのアクセス、他の接続サービスへの横展開など、追加の侵害後活動をオプションで実行することも可能です。
対策
予防的コントロール
強力な予防策により、メールボックスルールの悪用の発生可能性と影響の両方を大幅に低減できます。
- 外部への自動転送の無効化： Exchange Onlineにおいて外部アドレスへの自動転送をデフォルトでブロックし、最も一般的な情報流出および永続化の手法の一つを阻止します。
- 条件付きアクセス ポリシーの適用： MFAの必須化、デバイス準拠状況や場所に基づくアクセス制限、レガシー認証の制限、リスクベースの制御の適用により、フィッシング、パスワードスプレー、トークンリプレイの成功率を低減します。
- OAuth権限付与および同意変更の監視： 新規OAuthアプリの登録、同意付与、権限変更を追跡し、特にMail.Read、Mail.ReadWrite、offline_accessスコープを伴うものについて監視することで、パスワード不要の持続的アクセスを検知します。
インシデント対応手順
悪意のあるメールボックスルールが特定された場合は、封じ込め、排除、アクセスの無効化に重点を置いて対応してください。
- 悪意のあるルールの削除： すべての不正な受信トレイルールを削除し、追加の隠れたルールや条件付きルールが残っていないことを確認します。
- セッションの無効化とトークンのリセット： アクティブなセッションとリフレッシュトークンを無効化し、パスワード変更後も残る持続的なアクセスを排除します。
- サインインアクティビティの確認： Entra IDログを分析し、ルール作成前に発生した不審なIP、未知のユーザーエージェント、異常な場所、またはリスクの高い認証イベントを特定します。
- OAuthアプリケーションの監査： メールボックスへのアクセス権を持つ不明または過剰な権限を持つアプリを削除し、正規のアプリについては同意内容を再確認します。
メールボックスルールが唯一の侵害指標に見える場合であっても、これらの手順は必ず実施すべき対応として扱う必要があります。
［免責事項］
サードパーティの製品名、ロゴ、ブランドは、それぞれの所有者に帰属します。Microsoft 365／OutlookやZoho Mailなどのサードパーティサービスへの言及は識別のためのものであり、推奨や提携関係を示すものではありません。