振込先変更を狙うBECの流れ

経理担当アリスに『取引先の振込先が変わった』というメールが届きました。差出人の表示名は見慣れたものですが、送信ドメインは似た別ドメインです。さらに、別件では取引先の本物のアカウントが侵害され、認証結果が全てpassになる可能性もあります。フィッシング、BEC、なりすまし、ヘッダ、Authentication-Resultsを一つの支払変更業務で読み解きます。以下の人物、ドメイン、時刻、ログは架空です。

読む順序は、攻撃の種類→一通のヘッダと受信ログ→三つのシナリオの差→支払変更の確認と復旧→演習です。送信ドメイン認証の詳細な計算は既存のメール認証記事に譲り、ここでは『認証がpassでも何が未確認か』と、企業の支払業務に結び付けた判断を深めます。

1. フィッシングとBECの攻撃目標を分ける

用語	この事案での意味
フィッシング	人をだましてリンク、添付、認証情報入力などへ誘導する手口。見慣れた表示名や急ぎの依頼だけでは送信者の身元を示さない。
BEC（Business Email Compromise）	企業間のやり取りや担当者を装い、振込先変更や機密情報の送付などを指示する詐欺。偽ドメインだけでなく、実際に侵害した正規メールボックスから送る場合もある。
なりすまし	Header Fromの偽装、表示名の模倣、似たドメイン、正規アカウントの乗っ取りなど、相手に別人だと思わせる行為を含む。この四つは認証結果が異なる。
メールヘッダ解析	From、Reply-To、Return-Path、Received、Message-ID、Authentication-Resultsなどを、受信境界とログに照らして読むこと。文字列の見た目だけを証拠にしない。
Authentication-Results	受信側がSPF・DKIM・DMARCなどの検査結果を伝えるヘッダ。信頼できる受信境界が付けた行だけを判断に用いる。passは検査対象のドメイン等の結果であり、取引の正当性ではない。

正規取引先のドメインはvendor.example、見た目が似た攻撃者管理ドメインはvendor-payments.example、当社受信MXはmx.corp.exampleです。アリスの経理メールボックスはpayables@corp.exampleです。正規の請求書メールであっても、振込先変更には既知の電話番号への折り返し確認と二者承認が必要な業務規則とします。

振込先変更を狙うBECの流れ

1. 送信準備：証跡似たドメインと表示名／防御・対処取引先ドメインを照合
2. メール配送：証跡受信MXのヘッダとログ／防御・対処信頼できる認証結果を確認
3. 支払変更要求：証跡口座変更の本文と添付／防御・対処既知の連絡先へ折返し
4. 振込承認：証跡承認・送金の記録／防御・対処二者承認と差分確認

メール認証に成功する似たドメインでも業務上の確認をすり抜けさせない。

図の二段目でSPF・DKIM・DMARCがpassでも、攻撃者が自分で管理する似たドメインの認証に成功しただけかもしれません。三段目の電話確認は、メール本文に書かれた新しい電話番号ではなく、登録済みの連絡先で行います。四段目の振込実行はメールの配送とは別の証拠で確認します。

2. 一通目：似たドメインで認証がpass

次は09:00に届いた架空のヘッダ抜粋です。`Received`は各ホップで上に追加されるので、信頼できる当社MXが付けた最上段の行と受信ログを起点にします。下段の外部由来の記述は、文字列だけでは真正性を保証しません。

text

Return-Path: <bounce@vendor-payments.example>
Received: from mail.vendor-payments.example
  (mail.vendor-payments.example [203.0.113.77])
  by mx.corp.example with ESMTPS id MX-901; 09:00:00 UTC
Authentication-Results: mx.corp.example;
  spf=pass smtp.mailfrom=vendor-payments.example;
  dkim=pass header.d=vendor-payments.example;
  dmarc=pass header.from=vendor-payments.example
From: "Vendor Accounts" <billing@vendor-payments.example>
Reply-To: billing@vendor-payments.example
To: payables@corp.example
Message-ID: <notice-901@vendor-payments.example>
Subject: 振込先変更のお願い

フィールド	分かること・分からないこと
Received	mx.corp.exampleが203.0.113.77から受けたという記録。外部が書いた下位Received行の経路まで無条件に信用しない。
Authentication-Results	当社MXが付けた行なら、vendor-payments.exampleのSPF・DKIM・DMARCがpass。正規vendor.exampleの認証結果ではない。
Fromと表示名	表示名はVendor Accountsだが、アドレスのドメインはvendor-payments.example。表示名は利用者が設定できる。
Return-Path	配送完了時に記録されたエンベロープ送信者の戻り先。Header Fromと別。これだけで実際の担当者は分からない。
Reply-To	返信先。Fromと違う場合は誘導の手掛かりだが、同じでも安全と証明しない。
Message-ID	メッセージ識別子として検索に役立つ。送信側が作れるため、IDのドメインだけで真正性を判定しない。

`dmarc=pass`はvendor-payments.exampleのHeader Fromに対して、整合するSPFまたはDKIMの少なくとも一方がpassした結果です。vendor.exampleの正規社員が送ったという判定ではありません。似た文字列の比較は人の目にも難しいため、登録済み取引先ドメインと支払先変更手続きを別に用います。

3. 三つの攻撃型で認証結果はどう変わるか

シナリオ	認証の典型例と未確認点
直接のHeader From偽装	攻撃者が`From: billing@vendor.example`と書き、vendor.exampleの許可されないIPから送る。SPF fail、DKIMなし、DMARC failとなり得る。ただし転送や正規経路の例外もあるのでログで確認する。
似たドメイン	攻撃者がvendor-payments.exampleを管理して送れば、自分のドメインでSPF・DKIM・DMARC passになり得る。認証passでも正規vendor.exampleとの同一性は示さない。
正規アカウント侵害	攻撃者がvendor.exampleの実アカウントで正規の送信経路を使えば、SPF・DKIM・DMARCが全てpassし得る。アカウントの利用者と業務指示の正当性を別に調べる。
表示名のみ模倣	`From: Vendor Accounts <attacker@unrelated.example>`なら、UIが名前を強調すると見落としやすい。ドメイン認証がpassしてもunrelated.exampleの結果である。

DMARC failは調査の強い手掛かりですが、転送、メーリングリスト、DNS障害、設定ミスなどで正当メールにも失敗や一時エラーが出ます。判定結果と受信側の隔離・拒否は別です。逆にpassは悪意なしを保証しません。認証方式の働く主体と、攻撃者が管理する主体を区別します。

4. 信頼できるAuthentication-Resultsを選ぶ

攻撃者はメール本文の先頭に`Authentication-Results: mx.corp.example; dmarc=pass`という偽行を挿入できます。受信境界は自ドメインを名乗る外部由来の行を除去し、自分で評価した結果を追加する必要があります。調査ではMX-901の受信ログと境界設定で、どの行を当社が付けたか確認します。

authserv-idが当社の検証基盤のものかを確認する。ただし同じ文字列を攻撃者が書けるため、名前だけで信頼しない。
最も外側の信頼できるReceived行で、接続元IP、受信時刻、キューIDを確認する。MXログと一致するか見る。
spfの`smtp.mailfrom`、dkimの`header.d`、dmarcの`header.from`を読み分ける。passという単語だけを数えない。
複数のAuthentication-Results行があれば、当社境界と信頼した内部MTAの行を分け、外部由来や偽行を除外する。
転送経路ではARCなどの補助情報を参照しても、現在の受信側の検査結果と、転送前の主張を同一視しない。

外部からの偽Authentication-Results行を境界が除去していれば、実際の受信メールにはその行が残りません。残っていた場合は境界設定上の問題も調べます。ヘッダ表示画面の切り詰めや折返しで情報を見落とさないよう、原本を保全して確認します。

5. メール以外の証拠でBECを判断する

調査対象	確認する事実と限界
メール基盤	受信キューMX-901、宛先、隔離判定、同報先、添付・URL、開封やクリックの記録が取得できるか確認する。配信成功だけで開封を断定しない。
取引先との連絡	登録済みの電話番号へ折り返し、振込先変更の有無、依頼者、承認者を確認する。メール内の番号へかけると攻撃者へつながり得る。
社内支払業務	取引先台帳の変更履歴、二者承認、振込依頼と実行記録を確認する。メール受信だけで金銭被害は確定しない。
正規アカウントの監査	正規vendor.exampleから届いた場合は、不審なサインイン、MFA変更、転送ルール、送信済みメール、OAuth委任を相手組織と確認する。相手の監査証拠が得られない限界を明記する。
端末・ブラウザ	リンクの実URL、アクセス時刻、入力した情報、添付の実行結果を調べる。URLを見たことと認証情報を送ったことは別。

振込先変更の依頼を受けた経理担当は、メールで返信して確認しただけでは同じ侵害された会話に戻る可能性があります。登録済みの別経路で確認し、変更前後の口座と取引先名を照合します。急ぎの依頼、秘密保持の要求、担当者の不在を理由に承認を一人へ集中させない運用にします。

5-1. スレッド内の本物らしさとリンクの検査

攻撃者が過去の請求メールを引用し、`References`や`In-Reply-To`を合わせると、メーラー上では既存の会話に見える場合があります。これらのヘッダは会話整理に役立ちますが、引用文やIDを知る攻撃者も作れます。正規アカウント侵害なら本物のスレッドから送られるため、スレッドの連続性だけを本人確認に使いません。

表示されたリンク文字列と実際の遷移先URLも分けます。HTMLメールでは`https://vendor.example`という表示文字のリンク先を別のホストへ設定できます。短縮URLやリダイレクトがあれば最終到達先まで、認証情報を入力したかどうかはブラウザとIdPログで調べます。URLが怪しいことと情報漏えいが起きたことは別の判断です。

5-2. passした正規アカウントの異常をどう絞るか

追加証拠	判断できること
送信済みと送信ログ	本物のメールボックスや投稿APIから送ったかを調べる。送信済みフォルダが消されていてもサーバ側監査が残る場合がある。
サインインとMFA	新しい端末・地域・認証方式、セッション発行の変化を調べる。旅行やVPNの可能性もあるのでIPだけで侵害確定にしない。
受信箱の転送ルール	攻撃者が請求書のやり取りを監視した形跡を探す。ルールがなくても別のAPI権限や端末上の閲覧は残る。
業務確認	取引先の登録済み担当者と電話等で変更の正当性を照合する。技術的なpassよりも支払変更の承認を優先して判断する。

6. 封じ込め・調査・復旧

対象メールの原本、ヘッダ、MX-901ログ、添付、URL、受信時刻を保全する。生のリンクを不用意に開かず、安全な解析環境を使う。
同じ送信元・似たドメイン・件名・Message-ID・本文特徴で同報先を探し、必要に応じて隔離・削除する。Message-ID単独の一致だけで全件と決めない。
振込先変更を一時停止し、既知の連絡先で取引先と事実を確認する。既に振り込んだ場合は社内責任者と金融機関へ速やかに連絡し、実行記録を保全する。
受信者がリンクを開き認証情報を入力した可能性があれば、関連セッション・資格情報を失効し、端末、サインイン、MFA、メール転送ルールを調査する。
正規アカウント侵害なら取引先と連携し、侵害経路、送信済みメール、転送設定、残存セッションを確認する。認証結果がpassだったことを理由に調査を終えない。
再開時は登録済みドメインと連絡先、二者承認、メール基盤の境界処理、受信側の検査・隔離方針を確認し、正規の取引連絡が届くことも試験する。

ドメインをブロックしても、既に振込先台帳が改ざんされていたら被害は止まりません。逆に支払手続きを停止しても、偽メールを受け取った他部署の認証情報が漏れる可能性があります。メール、アカウント、端末、支払の四つを独立に確認し、対象範囲と未確認事項を記録します。

7. 科目B（午後）の判断と演習

演習1：DMARC pass

条件：vendor-payments.exampleのDMARCがpass。質問：vendor.exampleの取引先本人と判断できるか。解答：できない。passしたのは似た別ドメイン。誤答『passなら正規』は認証対象のドメインを見ていない。

演習2：偽Authentication-Results

条件：メール原本に当社MXを名乗る二つの結果行がある。質問：どちらを信じるか。解答：境界設定とMX受信ログ、Receivedを照合して当社が付けた行を特定する。誤答『上の行だけ』は偽行の混入を無視する。

演習3：正規アカウント侵害

条件：vendor.exampleのSPF・DKIM・DMARCがpassし、口座変更依頼が届いた。質問：支払を変更してよいか。解答：別経路の確認と二者承認が必要。誤答『全passで安全』はアカウント乗っ取りを無視する。

演習4：Reply-To

条件：Fromはvendor.example、Reply-Toはunrelated.example。質問：何を調べるか。解答：返信先の変更理由と原本・MXログを調べ、既知の取引先連絡先へ確認する。誤答『Reply-Toが違えば必ず攻撃』は正規の代理返信も考慮していない。

演習5：配信と被害

条件：MX-901はメールを受理した。質問：送金被害は確定か。解答：確定しない。台帳変更、承認、金融機関への振込実行記録を確認する。誤答は配送と業務実行を混同する。

演習6：確認先

条件：メール本文に『新しい電話番号に確認してほしい』とある。質問：その番号へ電話してよいか。解答：既知の台帳登録番号へ折り返す。誤答『メール記載の番号で確認』は攻撃者が確認先を支配できる点を見落とす。

8. 一次資料

RFC 8601：Authentication-Resultsと信頼境界

RFC 5322：From、Reply-To、Message-IDなどのヘッダ

RFC 9989：DMARCの認証対象と整合

IC3：Business Email Compromise

フィッシング・BECとメールヘッダ解析