Microsoft 365などで不審なメール転送ルールや受信トレイルールを見つけた時、アカウント侵害・BECの可能性、ログ保全、セッション失効、MFA、OAuth確認、影響範囲、削除前の判断基準、報告までをSaaS管理者向けの実務手順として整理します。
冒頭要約
Microsoft 365、Google Workspace、社内メール基盤で、心当たりのないメール転送ルールや受信トレイルールを見つけた場合、単なる設定ミスとは限りません。アカウント侵害後に、メールを外部へ転送したり、重要な通知を別フォルダへ移動したり、本人に気づかれにくくする目的で使われることがあります。
まず行うべきことは、ルールをすぐ消して終わりにすることではありません。対象ユーザー、作成時刻、転送先、条件、ログ、本人の操作有無、関連するサインインやMFAイベントを記録し、アカウント侵害やビジネスメール詐欺（BEC）につながる可能性を判断します。
この記事では、攻撃再現や探索ではなく、情シス・SaaS管理者・CSIRTが実務で使える初動確認、やってはいけないこと、エスカレーション条件を整理します。
この記事は防御・確認・報告を目的としています。悪用手順、探索クエリ、攻撃再現、具体的な検出クエリや管理コマンド列は掲載しません。調査は自社の正規管理画面、監査ログ、公式ドキュメント、承認された管理手順に限定してください。
不審なメール転送ルールとは
メール転送ルールとは、受信したメールを別のアドレスへ転送する、特定の条件に合うメールを別フォルダへ移動する、既読化する、削除する、といった自動処理です。正しく使えば、共有メールボックス、チケット起票、業務委託先との連携に役立ちます。
一方で、本人が作成していないルール、所有者不明の外部転送、請求・支払い・パスワードリセット・MFA通知などを隠すルールは、アカウント侵害後の兆候として扱う必要があります。Microsoft Defender XDRの公式プレイブックでも、疑わしい受信トレイ転送ルールやメール転送活動は、正当な運用か不正かを分類して調査する対象として扱われています。
ポイントは「転送ルールがあること」自体を一律に悪としないことです。正当な業務ルールか、不審な継続アクセスかを、作成者、時刻、転送先、条件、対象ユーザー、関連ログで判断します。
読者別の影響
| 読者 | 影響しやすい範囲 | まず見るもの |
|---|---|---|
| 個人・社員 | メール内容、取引先連絡、パスワードリセット通知、MFA通知が外部へ流れる可能性 | 自分で作ったルールか、見覚えのない転送先がないか |
| 情シス | アカウント侵害、退職者・委託先アクセス、共有メールボックス運用 | 対象ユーザー、転送先、作成時刻、管理者操作ログ |
| SaaS管理者 | Microsoft 365、Google Workspace、IdP、OAuthアプリ、外部共有 | サインインログ、MFA、セッション、OAuth 2.0同意 |
| CSIRT・SOC | BEC、情報流出、隠蔽、横展開、証跡保全 | 監査ログ、転送ルール、メールフロー、報告時系列 |
| 開発者・業務アプリ担当 | メール連携、チケット化、自動処理、通知基盤 | 正当な業務転送か、システム連携停止の影響 |
特に、経理、人事、役員、法務、ヘルプデスク、SaaS管理者のメールボックスで見つかった場合は優先度を上げます。請求書、振込先変更、アカウント回復、MFAリセット、取引先連絡が絡むためです。
まず確認すること：不審なメール転送ルールのチェックリスト
削除や無効化の前に、確認結果を時刻付きで残します。証跡を残さず削除すると、転送期間、影響範囲、正当性の説明が難しくなります。
| 確認項目 | 見るポイント | 記録すること |
|---|---|---|
| 対象ユーザー | 誰のメールボックスか。管理者、経理、人事、共有メールボックスか | ユーザー、所属、権限、業務影響 |
| ルール種別 | 外部転送、内部転送、フォルダ移動、削除、既読化、通知抑制 | ルール名、条件、転送先、動作 |
| 作成・変更時刻 | いつ作られ、いつ変更されたか | タイムゾーン、確認画面、監査ログ上の時刻 |
| 作成者・操作元 | 本人操作、管理者操作、API、同期、委託先操作か | 操作主体、端末、IP、管理者名 |
| 転送先 | 社内、委託先、個人アドレス、外部ドメイン、所有者不明か | 転送先ドメイン、正当な業務理由 |
| 関連ログ | サインイン、MFA、パスワード変更、OAuth同意、セッション | 同じ時間帯の不審イベント |
| 影響期間 | いつから有効だったか。どのメールが対象か | 開始日、終了日、対象件名の範囲 |
| 例外運用 | 正当な転送、共有メールボックス、チケット連携か | 承認者、期限、台帳、再確認日 |
転送ルールは、アカウント侵害の後に追加されることがあります。パスワード変更だけで終えず、セッション失効、MFA再登録、OAuth同意、端末、共有リンク、外部転送、代理アクセスを同じ時系列で見ます。
初動対応：やること
1. 証跡を残してから止める
不審なルールを見つけたら、まず画面情報、監査ログ、作成・更新時刻、転送先、条件、対象ユーザーを記録します。正当な業務ルールでないと判断できる場合は、組織の手順に従って無効化または削除します。
ただし、調査目的で不審メールを転送先へ送ったり、第三者ドメインへ到達確認したりする必要はありません。自社ログと管理画面で確認します。
2. アカウント侵害の有無を確認する
対象ユーザーのサインインログ、MFAイベント、パスワード変更、端末登録、セッション、メールボックス操作を確認します。本人が作成していない場合、または同時間帯に不審なログインやMFA承認がある場合は、アカウント侵害の初動として扱います。
必要に応じて、セッション失効、パスワード変更、MFA再登録、リカバリー情報の確認、委託先アクセスの停止を行います。心当たりのないパスワードリセットメールの確認方法 や MFA疲労攻撃の初動対応 と同じく、本人の申告とログを突き合わせることが重要です。
3. OAuth同意とSaaS連携を確認する
メール転送ルールが見つかった場合、同じアカウントに不審なOAuthアプリ同意、メール閲覧権限、外部共有、代理アクセスが追加されていないかも確認します。パスワードを変更しても、セッションや同意済みアプリが残る場合があります。
SaaS権限棚卸しチェックリスト と OAuth同意フィッシングの初動対応 を併用すると、メールボックスだけでなくSaaS全体の継続アクセスを確認できます。
4. 影響範囲を切り分ける
転送されていた可能性のある期間、件名、差出人、受信者、添付の有無、機密区分を確認します。取引先、請求、個人情報、人事、法務、認証通知が含まれる場合は、漏えい疑いとして扱い、漏えい疑い初動テンプレート に沿って記録します。
正当なメール転送であっても、外部自動転送が恒常化している場合は、CISAのMicrosoft Exchange Online向けベースラインにあるように、外部自動転送を制御する方針を検討します。
やってはいけないこと
- 証跡を残さず、ルールを削除して完了にする。
- 本人に「覚えがないなら消してよい」とだけ伝える。
- パスワード変更だけで、セッション、MFA、OAuth同意、代理アクセス、共有リンクを確認しない。
- 不審な転送先へ確認メールを送る。
- 調査内容をチャットに断片的に書き、誰がいつ何を判断したか分からない状態にする。
- 例外運用の正当な転送と、不審な転送を同じ扱いにする。
重要なのは、早く消すことよりも、再発防止と説明可能性です。特に金銭取引や個人情報に関係するメールボックスでは、削除前後の記録が後の報告に必要になります。
判断基準：危険度とエスカレーション条件
| 危険度 | 条件 | 推奨対応 |
|---|---|---|
| 高 | 外部アドレスへ自動転送されていた、本人が作成していない、サインインログにも異常がある | アカウント侵害疑いとしてCSIRTへ上げ、証跡保全、セッション失効、影響範囲確認を行う |
| 高 | 経理、人事、役員、管理者、共有メールボックスで発見 | BECや情報流出の可能性を含め、関係部門と時系列を共有する |
| 中 | ルールは正当か不明だが、作成者や承認記録がない | 一時停止または所有者確認、例外期限、再確認日を設定する |
| 中 | 社内転送だが、退職者、委託先、個人端末運用と関係する | 退職者アカウント初動対応 と合わせて確認する |
| 低 | 正当な業務転送で、承認者、期限、台帳、監査ログが揃っている | 例外台帳に登録し、定期棚卸し対象にする |
「外部転送があるか」だけでなく、「誰のメールか」「何を転送していたか」「いつからか」「本人や管理者が説明できるか」で優先度を決めます。
よくある誤解
「転送ルールを削除すれば解決」
削除は必要な場合がありますが、原因確認ではありません。侵害されたセッション、MFA登録、OAuth同意、代理アクセス、共有リンクが残っていれば、同じ問題が再発します。
「外部転送はすべて禁止すればよい」
外部転送は強いリスクになりますが、チケットシステム、委託先連携、監査用メールなど正当な運用もあります。禁止・許可の二択ではなく、承認、期限、対象、監査ログ、例外台帳で管理します。
「本人が覚えていないなら誤操作」
本人が覚えていない設定は、誤操作だけでなく、過去の委託先設定、退職者の残存アクセス、アカウント侵害、OAuth同意の結果かもしれません。本人確認だけでなく、ログで裏付けます。
「MFAが有効ならメール転送は心配ない」
MFAは重要ですが、すでに成立したセッション、承認済みOAuthアプリ、代理アクセス、古い例外設定を自動で消すものではありません。MFA有効でも、継続アクセスの確認は必要です。
記録テンプレート
発見日時:
発見者:
対象ユーザー:
対象メールボックス:
ルール名:
ルール種別:
転送先または移動先:
作成・更新時刻:
本人の作成有無:
正当な業務理由:
関連サインインログ:
関連MFAイベント:
関連OAuth同意:
転送され得る期間:
影響があり得るメール種別:
実施した対応:
残リスク:
次回確認日:
報告先:このテンプレートは、フィッシング報告テンプレート や 漏えい疑い初動テンプレート に転記できます。判断が分かれる場合は、記録を先に揃えることで、セキュリティ担当、法務、業務部門との会話が進めやすくなります。
関連用語・関連ページ
- 用語: フィッシング / メールヘッダー / MFA / OAuth 2.0 / DMARC
- 実務: フィッシング確認チェックリスト / SaaS権限棚卸しチェックリスト / 退職者アカウント確認チェックリスト
- プレイブック: フィッシング報告テンプレート / 漏えい疑い初動テンプレート
- 関連記事: 心当たりのないパスワードリセットメールの確認方法 / MFA疲労攻撃の初動対応 / OAuth同意フィッシングの初動対応 / セキュリティログの読み方
- 学習: インシデントレスポンス入門 / メールヘッダー分析入門
- 演習: フィッシングメール判定ミニCTF / パスワードリセットメール判定ミニCTF
公式情報・参考情報
- Microsoft Learn: Responding to a compromised email account
- Microsoft Learn: Alert classification for suspicious inbox forwarding rules
- Microsoft Learn: Alert classification for suspicious email forwarding activity
- Microsoft Learn: Detect and remediate Outlook rules and custom forms injections attacks
- CISA: Microsoft Exchange Online Secure Configuration Baseline
- CISA: Recognize and Report Phishing
まとめ
不審なメール転送ルールは、単なるメール設定の問題ではなく、アカウント侵害、BEC、情報流出、証跡隠しの兆候である可能性があります。ルールを削除する前に、対象、時刻、転送先、本人の操作有無、サインインログ、MFA、OAuth同意、影響期間を記録してください。
実務では、転送ルールの確認をメール管理だけに閉じず、SaaS権限棚卸し、フィッシング報告、漏えい疑い初動、インシデントレスポンスへ自然につなげることが重要です。
