テック技報最新号へ →
セキュリティ

自社の通知メールに攻撃者の電話番号を載せさせない(正規の注文通知の悪用)

攻撃者は注文の配送先・請求先欄に「Helpline」と自分の電話番号を入れ、正規の注文通知メールにそれを載せさせる。送信元は本物なので DKIM・DMARC は通る。サービス側はメールに差し込む入力を検証し、受信側は「認証を通った=中身が安全」とみなさない。

@MalwareBibleJP · 2026-10-27
#email#phishing#dmarc#input-validation#callback-phishing

何が起きたか(Talos の報告)

  • Staples と Dell の注文通知に攻撃者の電話番号が混入し、2 つのキャンペーンで計約 1,400 通を観測。身に覚えのない高額注文を装い、電話で問い合わせさせるコールバック型の詐欺。
  • 解析したメールはどちらも DKIM と DMARC を通過していた。送信元を偽るのではなく、本物のメールのひな形に利用者の入力を取り込む処理を悪用している。
  • 過去 1 年で悪用が確認された正規プラットフォームは 25 超。公開フォームに入れた誘い文句が登録確認メールに反映される例や、配信不能通知の返送本文に誘い文句が入る例もあった。

サービス提供側の対策

  1. メールに差し込む入力は、保存前と差し込み前の両方で検証する(Talos の提言)。
  2. 名前・住所・会社名など「電話番号や URL が入るはずのない欄」に、電話番号・URL・「サポート」「至急」などの案内文があれば拒否するか警告する。
  3. 通知メールでは、利用者が入力した自由記述を目立つ位置や本文の案内文として表示しない。表示するなら「お客様の入力内容」と明示し、公式の問い合わせ先は固定の文言で別に載せる。
  4. 登録確認や招待メールのように、他人のアドレス宛てに送れて自由入力が載る機能は、レート制限と内容チェックをかける。

受信・ゲートウェイ側の対策

  • DMARC 通過は「送信ドメインが本物」という意味だけで、本文の連絡先や取引の安全性は保証しない。
  • 表示される本文だけでなく、メール内の別メールや添付を含む MIME 構造全体を検査する。
  • 注文通知に、不審な問い合わせ番号・キャンセルの指示・強い急かしが含まれていないかをルール化する。利用者には「メール内の電話番号ではなく、公式サイトに載っている連絡先にかける」と案内する。

関連

出典

X の元の投稿を開く