ビジネスメール詐欺（BEC）とは？手口と防ぎ方

証拠に応じて対策を選ぶ

実際に取るべき対応は、受信者が何を確認できるかで変わります。

• 自社ドメインからの依頼を名乗るのに送信者アドレスが怪しい場合は、ドメインのDMARCレコードと配信されたメールのヘッダーを確認します。直接のドメインなりすましの特定に役立ちますが、誰が送ったかは証明できません。
• 既知の取引先や経営幹部のアドレスから届いた依頼でも、メールボックスが乗っ取られている可能性を前提にします。取引を止め、以前から信頼している電話番号、連絡先名簿、承認経路で依頼を確認します。
• 支払い指示、口座情報、受取人情報が変わった場合は、記録の変更や送金の前に、別の経路での確認を必須にします。
• 認証情報を求めるメールなら、組織で定めた報告とインシデント対応の手順に従います。確認のためにそのメールへ返信してはいけません。
• 公開されているドメインが信頼する取引先のものと似ている場合は、ドメイン名全体を、登録済みの取引先の連絡先情報と照らし合わせます。

送信者名や文面に見覚えがあっても、メールのやり取りだけを根拠に口座情報を変更したり、送金したりしてはいけません。独立して確認した連絡手段で依頼を確かめてください。

BECとフィッシングは重なる部分がありますが、同じものではありません。ビジネスメール詐欺とフィッシングの違いで解説しているとおり、フィッシングは多数の受信者を狙うことがあるのに対し、BECは依頼をもっともらしく見せる取引関係や承認フローを利用するのが一般的です。

BECの確認手順の例

経理担当者が、取引先からと思われるメールを受け取ります。次回の請求書の支払いを新しい口座に送るよう求める内容です。問うべきは「このメールは本物らしいか？」ではありません。「承認済みの取引先の連絡先が、この変更を独立して確認できるか？」です。

メールと承認の判断を切り離す、短く記録に残る確認ルールを使います。

Request: Change supplier payment instructions

Do not approve from the email alone.

Verify through:
- A phone number or portal contact already recorded for the supplier
- A second authorized approver for the payment change
- The supplier's established account-management process

Record:
- Who verified the request
- Which independent contact method was used
- The date and approved change reference

これは説明用の運用フォーマットです。組織の支払い管理、契約上の要件、インシデント対応プロセスの代わりにはなりません。

自社ドメインを名乗るメールなら、技術的な証拠も確認します。配信されたメールのAuthentication-Resultsヘッダーには、受信側による認証の評価が示されます。RFC 8601はAuthentication-Resultsヘッダーフィールドを定義しています。ヘッダーの結果は、その受信側でのそのメールについての証拠です。依頼された取引の正当性を確かめるものではなく、すべての送信経路を示すことも、今後の配信を予測することもできません。

BECが疑われる依頼への対応手順

手元の証拠から、次の順で始めます。

• 支払いやデータの依頼なら、承認手続きを止め、独立した確認ルールを適用します。社内の手順に従い、セキュリティ担当や不正対応チームのためにメールを保存します。
• 受信したメールがあれば、完全なヘッダーを取得し、表示上のFromドメイン、Return-Pathのドメイン、認証結果を比べます。機密情報を伏せないまま、承認された経路の外へ転送してはいけません。
• 自社ドメインをかたるメールなら、DMARCチェックツールで公開DMARCレコードを確認します。公開されているポリシーを、チームが守るべきドメインと比べます。
• レコードがない、またはp=noneの場合でも、その照会結果だけで、すぐに強いポリシーへ移行してはいけません。まず正規の送信元を洗い出し、実際の本番メールでアライメントの取れたSPFまたはDKIMの結果を確認します。
• 依頼が実在する従業員や取引先のメールボックスから来た場合は、アカウントへのアクセス、メールボックスのルール、影響を受けた業務プロセスを調査します。DMARCレコードでは、乗っ取られたメールボックスは修復できません。

管理された手順でDMARCのポリシー強化へ

公開DMARCの照会で、自社ドメインが現在ポリシーを公開しているかは分かります。残る運用上の問いは、どの正規サービスがまだそのドメインでメールを送っているか、そして各経路でアライメントが取れているかです。

Palisadeはエージェント型DMARCソフトウェアです。DMARC集計レポートのデータを分析し、送信元と、認証やアライメントの問題を特定して、優先度付きの修正チケットを作成します。証拠が裏付ければ次のポリシー段階を提案しますが、証拠を確認してDNSの変更を反映するのはチームです。

Palisadeを始める

Palisadeは、個々の支払い依頼の正当性を確認しません。人の操作なしにDMARCポリシーを変更することも、今後のすべてのメールが認証されることや受信トレイへの到達を保証することもありません。