ビジネスメール詐欺インシデントへの対応に関するIT管理者のチェックリスト

ビジネスメール詐欺 （BEC）は、単なるメールフィルタリングの問題ではありません。攻撃者が正規のメールボックスへのアクセス権を取得すると、BEC攻撃は組織内部から展開される可能性があります。攻撃者は、既存のやり取り、連絡先、支払い情報、カレンダー、ファイル、および内部プロセスを悪用し、不正行為を日常業務のように見せかけることができます。

これにより、IT管理者の業務内容も変化します。ビジネスメール詐欺への効果的な対応には、侵害されたID、メールボックス、関連するエンドポイント、メールインフラ、財務プロセス、そして何が起きたかを把握するために必要な証拠を網羅する必要があります。第一の目的は被害の封じ込めです。第二の目的は、攻撃者がどこまで侵入したかを特定することです。

BECインシデント対応を一元管理する

中央集約型のIT運用レイヤーがあれば、対応の調整が容易になります。 IT管理ソフトウェアは は、管理者が共通の運用ビューから、影響を受けたデバイス、ユーザー、ソフトウェア、設定変更、および是正措置を追跡するのに役立ちます。これは電子メールのセキュリティ対策を置き換えるものではありませんが、インシデントが単一のメールボックスを超えて拡大した場合に、有用な背景情報を提供します。

BECの疑いがある場合は、直ちにインシデント記録を作成し、技術的な対応を担当する責任者を1名指定してください。その後、最初の不審なメッセージ、アカウントへの不正アクセスが疑われる事象、パスワードや多要素認証（MFA）の変更、メールボックスルールの変更、送信メッセージ、および金融取引の有無などを網羅したタイムラインを作成してください。

初期調査の結果が記録されるまでは、有用な証拠を破壊するような変更を行わないようにしてください。同時に、証拠の保全を重視するあまり、攻撃者に引き続きアクセス権限を残してしまってはなりません。対応にあたっては、この両者のバランスをとらなければなりません。

1. 侵害されたメールアカウントの拡散を防ぐ

技術的な優先事項の第一は、攻撃者がそのアカウントを操作し続けるのを阻止することです。直ちに行うべきチェックリストには、以下の項目を含める必要があります：

• インシデント対応手順に従い、侵害されたアカウントを無効化または利用制限を適用してください。
• パスワードのリセットだけに頼るのではなく、アクティブなセッションを無効化し、トークンを更新してください。
• 封じ込め措置の後、パスワードをリセットしてください。
• 見慣れないMFA（多要素認証）の手法を確認し、削除してください。
• 不審なアプリの権限やOAuthの同意を取り消してください。
• 外部への転送先アドレスや悪意のある受信トレイのルールがないか確認してください。
• 最近送信したメッセージ、削除したメッセージ、復元したメッセージを確認します。

メールボックスのルールには特に注意を払う必要があります。 攻撃者は、特定のメッセージを自動的に転送したり、セキュリティアラートを目につかない場所に移動させたり、侵入を露見させる恐れのある通信を削除したりするルールを作成する可能性があります。

2. メールボックスが複数の目的で使用されていたと仮定する

侵害されたメールボックスは、単なる認証情報の問題として扱うべきではありません。

攻撃者は、過去のメッセージの中から、請求書、仕入先情報、役員名、支払い情報、契約内容、顧客データ、認証リンクなどを探し出す可能性があります。また、詐欺的な要求を送る前に会話を監視し、メッセージが既存の取引関係に自然に溶け込むようにすることもあります。

メールボックスを点検し、偵察の兆候や明らかな不正行為がないか確認してください。不審なログイン履歴、新しい転送ルール、削除された会話、不審な送信メッセージ、およびアカウント設定の変更がないか確認してください。

可能であれば、時系列を整理してください。不審なログインはいつ発生しましたか？最初の詐欺メッセージはいつ送信されましたか？その出来事の前後にメールボックスの設定に変更はありましたか？こうした詳細情報は、最初のアクセスとそれ以降の活動を区別するのに役立ちます。

3. 電子メール以外の侵害範囲を把握する

BECへの対応において最も重要な区別のひとつは、 メールボックスの乗っ取り と 身元の乗っ取りです。

攻撃者が有効な認証情報を入手した場合、他のシステムも侵害されている可能性があります。そのアカウントを通じて、クラウドストレージ、コラボレーションプラットフォーム、リモート管理システム、財務アプリケーション、CRMプラットフォーム、パスワードマネージャー、または社内文書へのアクセスが可能かどうかを確認してください。

被害に遭った従業員の端末についても調査してください。フィッシングページによって、エンドポイントが侵害されることなく認証情報が盗み出された可能性もありますが、マルウェアや情報窃取型マルウェアが検出された場合は、より広範な問題が存在することを示唆しています。

ここで、エンドポイントおよびIT管理データが重要になってきます。重要なのは、「このメールボックスは侵害されたのか？」というだけでなく、「このIDを使って他にどこにアクセスできたのか？」という点です。

4. 不正な支払いが行われていないか確認する

BECには多くの場合、金銭的な目的があるため、財務部門とIT部門は、このインシデントを純粋に技術的な問題として扱うのではなく、連携して対応すべきである。

直近の支払請求書を、通常の仕入先記録と照合してください。特に以下の点に注意してください：

• 銀行口座情報の変更。
• 通常の承認手続きを省略する緊急の依頼。
• 新規の受取人、または見慣れない振込先。
• 経営陣や経理担当者が不在のときに送信される依頼。
• 正規のメールのやり取りの中に含まれているものの、支払い情報が改ざんされている請求書。

最も安全な確認方法は、別途用意された信頼できる通信経路を利用することです。新しい銀行口座番号の確認は、あらかじめ登録済みの連絡先情報を通じて行ってください。変更を依頼してきたメールに返信して確認することは絶対に避けてください。

5. 攻撃者が送信した内容を確認する

封じ込め措置を講じた後、侵害されたアカウントが顧客、取引先、従業員、または経営陣への連絡に使用されていたかどうかを確認してください。

送信済みメールの記録や、入手可能な場合はメッセージの追跡記録を確認してください。支払い指示、パスワード再設定リンク、悪意のある添付ファイル、機密情報の提供要請、または既定のプロセスからの変更が含まれるメッセージを特定してください。

特に、攻撃者が操作する指示に従ってしまう可能性がある場合は、受信者に速やかに警告してください。正規の企業のメールボックスから送信されたメッセージは、従来のフィッシングメールよりもはるかに信頼性が高く見えます。特に、既存のやり取りの続きとして送られてきた場合はなおさらです。

送信者のメールボックスから詐欺メールを削除したからといって、この件が解決したとは考えないでください。受信者がすでにそのメールを開封したり、転送したり、あるいはその内容に基づいて行動を起こしている可能性があります。

6. ドメインレベルの制御機能を確認する：DMARC、SPF、DKIM

DMARC、SPF、DKIMはBEC対策において重要な手段ですが、IT管理者はそれぞれで何が可能で、何が不可能かを理解しておく必要があります。

DMARC は、認証に失敗したメッセージを処理するためのポリシーフレームワークを提供しており、それらを監視、隔離、または拒否するオプションが用意されています。あなたの DMARCポリシー は、したがって、ドメインをなりすましから保護する上で重要な役割を果たします。

ただし、実際に乗っ取られたメールボックスから送信を行っている攻撃者を自動的に阻止できるわけではありません。犯罪者が正規のアカウントにログインし、正規のメールサービスを通じてメッセージを送信した場合、そのメッセージは依然として通常通り認証される可能性があります。

インシデント発生後は、SPF、DKIM、DMARCの設定を見直し、すべての正当な送信サービスが正しく登録されていることを確認してください。その目的は、ドメインのなりすましを削減すると同時に、アカウント乗っ取りの問題にも別途対処することにあります。

7. メールのレピュテーションに変化がないか確認する

攻撃者が侵害されたアカウントを利用して、悪意のあるメールや迷惑メールを大量に送信した場合、さらなる問題が生じる可能性があります。

レビュー ブロックリスト、バウンス率、スパム苦情、およびその他の送信者レピュテーション指標。モニタリングを行うことで、そのインシデントが正当なメールの配信能力に影響を与えたかどうかを判断するのに役立ちます。専用の メールレピュテーションサービス を利用すれば、その過程においてドメインやIPのレピュテーションに関するさらなる可視性を得ることができます。

これが重要なのは、メールボックスの管理権限を取り戻したからといって、攻撃によるすべての影響が必ずしも解消されるわけではないからです。他のメールシステムは、侵害中に発生したトラフィックに対して、すでに何らかの対応を講じている可能性があります。

8. AIを活用したBEC攻撃も、対応上の問題として捉える

BECの基本的な目的は変わっていませんが、なりすましの質は変化しています。

フォーブスの最近の分析によると、攻撃者は、収集した組織情報を、AIによって生成された通信、音声クローン、ディープフェイク技術と組み合わせることで、詐欺的な要求をより説得力のあるものにしているという。また、同記事では、2021年から2025年にかけて、米国におけるBEC（ビジネスメール詐欺）による被害額の報告が大幅に増加していると報じられている。 AIを活用した詐欺 により、従来の警告サインの信頼性が低下しつつある。

文法の誤りや、明らかに定型的なメッセージは、もはや詐欺の主な指標とは見なせなくなっています。メッセージ自体が説得力のあるものである場合、認証管理、取引ルール、および独立した検証の重要性が高まります。

9. 自動化が導入されている箇所を確認する

より巧妙なBEC攻撃に直面しているこれらの組織は、IT運用においても自動化をさらに進めている。

最近の英国の企業動向に関する報道によると、日常的なサービスやインフラのタスクの自動化を含め、IT管理におけるAIの活用が拡大していることが示唆されています。 IT分野におけるAI また、自動化システムがより多くの責任を担うようになるにつれ、組織はどの程度の制御権を保持すべきかという問題も浮上している。

これはインシデント対応において重要な点です。自動化システムは、不審な活動を検知したり、ログを収集したり、アカウントを無効化したり、ワークフローを迅速に起動したりすることができますが、その権限は厳格に管理する必要があります。

に関するセキュリティ研究 AI駆動型ワークフロー に関するAIを活用したワークフローのセキュリティ研究もまた、自律型システムが企業インフラへの特権アクセス権限を取得した際に生じるリスクを浮き彫りにしている。インシデント対応環境も例外ではない。

侵害されたIDへの常時アクセス権限を持つ自動化システムを監査し、その権限の範囲が十分に限定されており、影響範囲が最小限に抑えられることを確認する。

10. 問題を解決しながらその経緯を記録する

この手順は、見落とされがちです。証拠が残っているうちに、何が起きたかを記録しておきましょう。

初期の兆候、影響を受けたアカウント、不審なIPアドレス、メールボックスのルール変更、認証イベント、不正なメッセージ、支払い試行、封じ込め措置、認証情報のリセット、確認されたシステム、および送信された通知を記録します。これにより、将来の調査のための技術的な記録が作成され、どの制御措置が機能しなかったかを特定するのに役立ちます。

最終レビューでは、いくつかの実務上の疑問に答える必要があります：

• 攻撃者はどのように侵入したのでしょうか？
• どの制御機能が侵害を防ぐことができなかったのか？
• 攻撃者が活動を続けられたのはなぜでしょうか？
• その不正な要求について、誰かが独自に確認した人はいますか？
• 財務チームとITチームは迅速に連携することができたのでしょうか？

まとめ

BECへの対応は、これを「アイデンティティ」「インフラ」「財務」「通信」の各インシデントとして同時に扱う場合に最も効果的です。アカウントの拡散を封じ込め、持続的な侵入を阻止し、アクセス範囲を限定し、財務プロセスを保護し、ドメインの統制を再確認し、証拠を保全するとともに、侵害されたメールボックスが制御できない経路を通じて重要な指示を確認してください。

よくあるご質問

ビジネスメール詐欺への対応において、最初のステップは何ですか？

侵害されたアカウントの拡散を食い止めましょう。そのアカウントへのアクセスを制限し、アクティブなセッションとリフレッシュトークンを無効にした上で、パスワードをリセットし、不審な多要素認証（MFA）方式、OAuth グラント、および受信トレイのルールをすべて削除してください。

DMARCはBEC攻撃を防ぐことができますか？

DMARCは、攻撃者によるドメインのなりすましを防ぐことができますが、実際に侵害されたメールボックスから送信されたメッセージを阻止することはできません。なぜなら、そうしたメッセージは認証を通過してしまうからです。アカウントの乗っ取りを防ぐには、IDレベルでの制御も必要です。

メールアカウントが乗っ取られた後、パスワードの再設定だけで十分なのでしょうか？

いいえ。攻撃者は、アクティブなセッション、リフレッシュトークン、OAuthアプリの同意、追加されたMFA（多要素認証）方式、および転送ルールを通じて引き続きアクセス権を維持することができます。パスワードのリセットと併せて、これらすべてを無効にしてください。

• について
• 最新記事

Ahona Rudra

ドメインおよびメールセキュリティの専門家（所属： PowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

• ビジネスメール詐欺インシデントへの対応：IT管理者のチェックリスト - 2026年10月2日
• Exchange メールボックスの復元：Exchange Server で削除されたメールボックスを復元する方法 - 2026年9月22日
• DMARC MSP 事例研究：Presis社がPowerDMARCを活用して顧客のメール配信率を向上させた方法 - 2026年9月17日