バックスキャッターとは何か？

バックスキャッターとは何か？

偽装された送信元に返るバウンスと、自社のアドレスが悪用されたときの被害と対策

作成
著者: 竹洞 陽一郎

結論 ― 受け入れた後に返すバウンスが、偽装された第三者に届く現象です

バックスキャッターとは、MAIL FROMを偽装されたメールに対して、受信側が受け入れた後に返したバウンスメールが、メールを送っていない第三者に届く現象です。
自社のアドレスが偽装に使われると、自社名義のメールのバウンスや苦情が自社に集中し、自社が迷惑メールの送信者だと誤解されるおそれがあります。
問い合わせフォームの自動返信も、入力された第三者のアドレスに応答を返すという点で、同じ構造を持っています。

DMARCが保護するのはヘッダーFromのドメインなので、DMARCのp=rejectで防げる被害と、防げない被害があります。
MAIL FROMの偽装にはSPFの-allで、自社に届くバックスキャッターには、添付された元のメッセージのDKIM署名の確認で対処します。
自社が受信サーバーを運用する場合は、受け入れた後にバウンスを返さず、SMTPのやり取りの中で拒否してください。

この記事の要点：

1. バックスキャッターの定義

要点: 受信側が受け入れた後にバウンスを返すと、MAIL FROMを偽装されたメールのバウンスが、無関係な第三者に届きます。これをバックスキャッターと呼びます。

SMTPは、配送不能通知に使うreverse-pathの検証を扱っていません。
（RFC 5321 Section 3.6.2）
そのため、攻撃者がMAIL FROMに他人のアドレスを指定して送ったメールを、受信側が受け入れた後にバウンスすると、そのバウンスメールは、メールを送っていない第三者に届きます。
このような、偽装された送信元に返される配送不能通知を、バックスキャッター（backscatter）と呼びます。

RFC 5321は、悪意のある内容を含むために拒否したメッセージについては、受信側が通知が有用に届くと確信できる場合を除き、拒否の通知を送るべきではない（SHOULD NOT）としています。
（RFC 5321 Section 6.2）
RFC 9989も、DMARCでメッセージを拒否する場合は、DSNを生成するより、SMTPのやり取りの中で拒否するほうが望ましいとしています。
不正なメッセージに対してDSNを生成すると、MAIL FROMのアドレスに迷惑な失敗通知が返されることになるからです。
（RFC 9989 Section 7.2）

バウンスメールが、誰によって作られ、どこに届くのかは、バウンスメールとは何か？で解説しています。

バックスキャッターの語源

backscatter（後方散乱）は、もともと物理学の用語です。
光、電波、粒子などが物体に当たって散らばり、その一部が来た方向へ跳ね返る現象を指し、レーダーやX線検査などで使われる言葉です。
ネットワークセキュリティの分野では、送信元IPアドレスを偽装したDoS攻撃で、標的が偽装されたアドレスに返す応答が、無関係なアドレスに散らばって届く現象を、backscatterと呼んだ研究があります。
（Moore, Voelker, Savage「Inferring Internet Denial-of-Service Activity」USENIX Security Symposium、2001年）
メールのバックスキャッターも、攻撃そのものではなく、攻撃の副作用として跳ね返ってきたバウンスメールが、無関係な第三者に散らばって届くという同じ構造をしています。
メールの用語として、いつ誰が使い始めたのかは確認できていません。

2. バックスキャッターを悪用する手口

要点: 自社のアドレスを偽装して自社を迷惑メールの送信者に見せかけるジョージョブと、第三者のサーバーのバウンスに迷惑メールの本文を載せて自社に届ける反射型の迷惑メールがあります。

バックスキャッターは、受信側の設定の不備による迷惑な副作用であるだけでなく、攻撃にも悪用されます。
いずれの手口も、受信側が「いったん受け入れた後に、バウンスを返す」ことを悪用します。
ここでは、自社のアドレスやサーバーが悪用された場合に、自社にどのような被害が出るかを説明します。

自社のアドレスが悪用された場合の、ジョージョブと反射型の迷惑メールの流れを示した図。どちらも、第三者の受信サーバーが受け入れた後に返すバウンスが、自社に届く。
バックスキャッターを悪用する2つの手口（自社のアドレスが悪用された場合のジョージョブと反射型の迷惑メール）
ジョージョブ（Joe job）― 自社を迷惑メールの送信者に見せかける
攻撃者が、自社のアドレスをMAIL FROMやFromに偽装し、自社を装った宣伝などの迷惑メールを大量に送る手口です。
本来の目的は、自社を迷惑メールの送信者に見せかけて、自社の信用を落とすことです。
受け取った人は自社が送ったと思い込むため、自社に苦情が届き、自社が契約しているプロバイダーやホスティング事業者に通報されたり、自社のドメインがブロックリストに登録されたりするおそれがあります。
その副作用として、受け入れた後にバウンスを返す第三者の受信サーバーから、自社名義のメールのバウンスが、自社のメールボックスに大量に届きます。
メールボックスの容量が圧迫され、正規のバウンスや業務のメールが埋もれます。
報復、嫌がらせ、競合の妨害が、典型的な動機とされています。
名前は、1997年にJoe's Cyberpost（joes.com）というサイトが、利用を断った迷惑メール業者からこの手口で報復されたことに由来するとされていますが、一次資料では確認できていません。
また、迷惑メール業者が、自分でバウンスや苦情を受けないように、実在する他人のアドレスをMAIL FROMに使うこともあります。
この場合、自社は狙われたわけではありませんが、巻き添えで自社名義のメールのバウンスを受け取ります。
反射型の迷惑メール ― 第三者のサーバーのバウンスに載せて、自社に迷惑メールを届ける
攻撃者が、MAIL FROMを自社のアドレスにし、宛先を存在しないアドレスにして、迷惑メールやフィッシングの本文を、受け入れた後にバウンスを返す第三者の受信サーバーに送る手口です。
第三者の受信サーバーは、元のメッセージを添付したバウンスを自社に返すので、攻撃者の本文が、第三者の正規のサーバーからのバウンスとして自社に届きます。
バウンスは第三者のサーバー自身のドメインとIPアドレスから送られるため、自社の迷惑メールフィルターの、送信元の評判による判定をすり抜けやすくなります。
自社の社員が、配送できなかったことを知らせる通知だと思って開封し、添付された本文のリンクを開いてしまうおそれがあります。
正規のシステムに攻撃者の内容を運ばせるという点で、入力エコー攻撃と似た構造です。
不在通知などの自動応答や、送信者に確認を求めるチャレンジ・レスポンス型の迷惑メール対策も、同じように悪用されることがあります。
自社の受信サーバーが中継に使われた場合の評判の低下
自社の受信サーバーが、受け入れた後にバウンスを返す設定になっていると、自社のサーバーが図の「第三者の受信サーバー」として悪用されます。
バックスキャッターを大量に返したサーバーは、迷惑メールを送っているのと同じように扱われ、ブロックリストに登録されることがあります。
その結果、自社の正規のメールまで、取引先に届きにくくなるおそれがあります。
自社の有効なアドレスの探索（関連する手口）
自社の受信サーバーで、宛先が存在するかどうかによって、受け入れた後にバウンスが返るかどうかが変わる場合、攻撃者はその差を観測して、自社の有効なアドレスを推定できます。
推定されたアドレスは、自社の社員を狙った標的型メールの宛先に使われるおそれがあります。
RFC 5321も、メッセージを受け入れることが、アドレスの確認になって望ましくない通信を招く場合があると指摘しています。
（RFC 5321 Section 6.2）

3. DMARCから見たジョージョブと反射型の迷惑メール

要点: ヘッダーFromに自社のドメインが使われるジョージョブは、自社のp=rejectで防げます。MAIL FROMだけの偽装にはSPFの-allが効きます。反射型の迷惑メールで自社に届くバウンスはDMARCに合格するため、DMARCでは止められません。

DMARCが保護するのは、ヘッダーFromのドメインです。
そのため、攻撃者がヘッダーFromにも自社のドメインを使うか、MAIL FROMだけに自社のアドレスを使うかで、DMARCの効果が変わります。

ジョージョブ ― ヘッダーFromに自社のドメインが使われた場合

ジョージョブで自社を迷惑メールの送信者に見せかけるには、受け取った人に自社が送ったと思わせる必要があるため、攻撃者はヘッダーFromに自社のドメインを使います。
このメールは、SPFもDKIMも自社のドメインとアラインしないため、DMARCで不合格になります。
自社のDMARCのポリシーによって、被害は次のように変わります。

自社のDMARCのポリシーとジョージョブの被害（DMARCを評価する受信側の場合）
自社のポリシー受信側での扱い自社が受ける被害
DMARCなし、p=noneDMARCのポリシーは適用されず、ほかのフィルターを通れば受信箱に届く受け取った人が自社が送ったと思い込み、苦情や通報が自社に届く。受け入れた後のバウンスも自社に届く。
p=quarantine隔離、または迷惑メールフォルダーに振り分け受信箱には届きにくくなるが、迷惑メールフォルダーで目にした人が、自社が送ったと思い込むおそれは残る。
p=rejectSMTPのやり取りの中で拒否受信者の目に触れないため、自社が送信者に見せかけられる被害を防げる。受信側は受け入れていないので、受信側からのバックスキャッターも発生しない。

p=rejectで拒否された場合、バウンスを作るのは、攻撃者が使った送信側のサーバーです。
攻撃者が受信側のMXへ直接送る仕組みを使っていればバウンスは作られませんが、中継サーバーを経由していれば、そのサーバーから自社のアドレス（MAIL FROM）にバウンスが届くことがあります。
また、受信側がp=rejectのポリシーだけを理由に拒否するとは限らず、DMARCを評価しない受信側もあるため、p=rejectで被害がなくなるわけではありません。
（RFC 9989 Section 8）

DMARCの集計レポートには、自社のドメインをヘッダーFromに使ったメールが、どの送信元のIPアドレスから、どれだけ送られ、受信側でどう扱われたかが報告されます。
ジョージョブを受けたときは、集計レポートで攻撃の規模を把握でき、自社が送ったメールではないことを、プロバイダーや取引先に説明する材料にもなります。

MAIL FROMだけに自社のアドレスが使われた場合

攻撃者が、ヘッダーFromには別のドメインを使い、MAIL FROMだけを自社のアドレスにした場合、受信側が評価するDMARCは、ヘッダーFromのドメインのものです。
自社のDMARCのポリシーは適用されず、自社のDMARCの集計レポートにも、このメールは現れません。
この場合に効くのは、自社のドメインのSPFです。
SPFレコードの末尾を-allにしておくと、SPFのfailをMAIL FROMの段階で拒否する受信側では、受け入れる前に拒否されるため、受け入れた後のバックスキャッターが発生しません。
-allについては、SPFは-allにすべき理由 ― ~allとの違いとDMARC運用での注意点で解説しています。

反射型の迷惑メール ― 自社に届くバウンスはDMARCに合格する

反射型の迷惑メールで自社に届くバウンスメールは、第三者の受信サーバーが、自分のドメインで、自分のサーバーから送ったものです。
バウンスメールのMAIL FROMは空なので、SPFは第三者のサーバーのHELOのドメインで評価されます。
（RFC 7208 Section 2.4）
ヘッダーFromも第三者のドメイン（例：MAILER-DAEMON@第三者のドメイン）なので、第三者がSPFやDKIMを正しく設定していれば、自社の受信サーバーでのDMARCの評価は合格になります。
攻撃者の本文は、添付された元のメッセージの中にあり、その中のFromはDMARCの評価の対象になりません。
つまり、自社がDMARCで受信したメールを検証していても、反射型の迷惑メールは止められません。
認証に合格した正規のメールに攻撃者の内容が載るという点も、入力エコー攻撃と同じです。

一方で、攻撃者が第三者の受信サーバーに送るメールのヘッダーFromに自社のドメインを使い、そのサーバーがSMTPのやり取りの中でDMARCを評価している場合は、自社のp=rejectによって、受け入れる前に拒否されます。
MAIL FROMに自社のアドレスが使われている場合は、自社のSPFの-allも、受け入れる前の拒否につながります。
ただし、受け入れた後にバウンスを返すサーバーは、受信時の検証が十分でないことが多いと考えられるため、DMARCやSPFの評価で拒否されるとは限りません。

4. 関連する手口 ― 問い合わせフォームの自動返信の悪用

要点: 問い合わせフォームの自動返信は、入力された第三者のアドレスに送られるため、バックスキャッターと同じ構造で悪用されます。自社の正規のメールなので、DKIMやBIMIの有無にかかわらず悪用され、DMARCでは止められません。

企業のWebサイトの問い合わせフォームも、バックスキャッターと同じ構造で悪用されます。
攻撃者やボットが、フォームの「メールアドレス」欄に第三者のアドレスを入力すると、フォームの自動返信は、入力された第三者のアドレスに送られます。
偽装されたアドレスに応答を返すという点で、受け入れた後に返すバウンスと同じです。
ここでは、自社のフォームが悪用された場合の被害を説明します。

問い合わせフォームの自動返信が、入力された第三者のアドレスに送られ、宛先不明や拒否のバウンスが自社に集中する流れを示した図。
問い合わせフォームの自動返信の悪用（自社のフォームが悪用された場合）

DKIMやBIMIを設定していなくても悪用される

お名前や本文の入力欄にフィッシングの文面やURLを入れ、自動返信に転記させて送らせる手口は、Spelldataが名付けた入力エコー攻撃です。
DKIMやBIMIで信用されやすいメールは、入力エコー攻撃の踏み台として狙われやすくなります。
しかし、DKIMもBIMIも設定していない企業のフォームでも、自動返信が大量に送られる被害は起きています。
フォームの悪用の目的は、信用されやすいメールを送ることだけではないからです。
攻撃者の目的は外から確認できないため、次の目的は手口の構造からの推測です。

また、DKIMを設定していなくても、自動返信を送るサーバーのIPアドレスが自社のSPFレコードに登録されていて、MAIL FROMが自社のドメインであれば、SPFのアライメントでDMARCに合格します。
（RFC 9989 Section 5.3.5）
DKIMを設定していないことは、悪用されにくい理由にはなりません。

自社が受ける被害

自社のドメインから迷惑メールが届き、評判が下がる
第三者には、自社のドメインと自社のサーバーから、迷惑メールが届きます。
苦情や通報が自社に届き、ブロックリストに登録されると、自社の正規のメールまで届きにくくなるおそれがあります。
結果はジョージョブと似ていますが、実際に送っているのが自社自身である点が異なります。
バウンスが自社に集中する
存在しないアドレスへの自動返信や、受信側に拒否された自動返信のバウンスは、自動返信のMAIL FROM、つまり自社のアドレスに返ってきます。
SMTPのやり取りの中で拒否された場合は自社の送信サーバーが、受け入れた後に配送できなかった場合は第三者の受信サーバーが、バウンスを作ります。
メール配信サービスのアカウントの停止や、料金の増加
自動返信をメール配信サービスから送っている場合、サービスによっては、バウンス率や苦情率が高くなるとアカウントが停止されることがあります。
送信量に応じた料金のサービスでは、料金も増えます。

DMARCの視点

自動返信は、自社が本当に送った正規のメールで、偽装は起きていません。
そのため、自動返信がSPFやDKIMでアラインしていれば、DMARCに合格し、DMARCでは止められません。
一方で、DMARCの集計レポートには、自社のドメインをヘッダーFromに使ったメールの送信量が、送信元のIPアドレスごとに報告されます。
Webサーバーやメール配信サービスからの送信量が急に増えたことに気付けば、フォームの悪用を早く見つけられます。
また、自動返信を送るサーバーがSPFに登録されておらず、DKIMの署名もない場合は、自動返信がDMARCに不合格になります。
自社がp=rejectであれば、受信側に拒否された自動返信のバウンスも、自社に返ってきます。
このような送信元は、集計レポートで見つけて、SPFとDKIMで認証してください。

5. バックスキャッターへの対策

要点: 自社の受信サーバー、自社のドメインのDMARCとSPF、問い合わせフォーム、自社に届いたバウンスの検証の、それぞれで対策します。

自社のアドレス宛てに、送った覚えのないメールのバウンスメールが大量に届く場合は、自社のアドレスが偽装されて送信されている可能性があります。
ヘッダーFromに自社のドメインが使われていれば、DMARCの集計レポートで送信元と量を確認できます。
MAIL FROMだけが偽装されている場合は、集計レポートには現れないので、届いたバウンスに添付された元のメッセージのヘッダーで、送信元を確認してください。
大量のなりすましメールへの対処は、なりすましメール大量発生時の対応ガイドで解説しています。

6. まとめ ― 確認チェックリスト

参考資料