ホスティング業者のabuse@アドレスを見つける方法は？

更新日：2026年9月26日

正しいサーバーが特定されたら、それを停止させるために誰に連絡すればよいかを知る必要があります。良い知らせは：アドレスはほぼ常に存在し、まさにそのために用意されています。あまり良くない知らせは：一度で見つけるのは必ずしも簡単ではないということです。以下がステップバイステップの方法です。

なぜabuse@アドレスが存在するのか

1997年、RFC 2142は今日でもほぼすべてのホスティング業者とネットワーク運営者によって使用されている慣例を定めました：インターネットに接続されたマシンを管理する各組織は、不正利用の通報（スパム、ハッキング、フィッシングなど）を受け取るためのabuse@ボックスを、postmaster@やwebmaster@のような他の標準ボックスに加えて公開しなければなりません。これは単なる習慣ではありません：規格です。だからこそ、小規模なホスティング業者から最大手の世界的な運営者まで、これほど広く機能しているのです。

運営者の特定：IPからASNまで

すべてはIPアドレスから始まります：フィッシングページをホストするサーバーのアドレス、またはメールのReceived行に見つかるアドレスです（ヘッダーでそれを見つける方法を参照）。そこから、方法は常に同じ経路をたどります：

IPのWHOISまたはRDAP：単純なwhois 203.0.113.45コマンド、またはオンラインのRDAPサイトが、どの組織がこのアドレスブロックを登録したかを示します。回答には非常に多くの場合、直接abuse-mailboxやOrgAbuseEmailフィールドが含まれています：存在すればこれが最も早い答えです。
IPのWHOISが不十分な場合のASN：各IPアドレスブロックはASN（自律システム番号）に紐づいています。これはそれを運営するネットワーク運営者の一種の身元番号です。bgp.he.netのようなツールを使えば、IPからASNを見つけ、次にそれに紐づく組織を見つけることができます。
連絡先の確認：組織が特定されたら、「組織名 + abuse」で検索するか、そのサポートページを参照します：ほとんどの大手ホスティング業者は自社の通報手順を文書化しています。

4ステップの図：フィッシングサイトのヘッダーまたはURLで見つかった疑わしいIPアドレス。誰がこのブロックを登録したかを示すIPのWHOISまたはRDAPの照会で、応答にはしばしばすでにabuse-mailboxフィールドが含まれている。これが不十分な場合、ASNで特定されるネットワーク運営者がこのIPブロックを運用する企業を指し示す。最後にabuse@アドレス、これは1997年からRFC 2142によってこのような通報のために設けられたボックスで、例はabuse@hebergeur.example。キャプション：本当の責任者が見つかるまで遡る、IPだけでは不十分で、それを運用し対処できる組織が必要。 — 図1：IPアドレスからabuse@アドレスまで、答えがすぐに得られない場合に遡るべきチェーン。

連絡先が正しいものであることを確認する

フィッシングサイトのドメイン名だけからabuse@アドレスを推測することはよくある間違いです：abuse@secure-login.exampleはおそらく存在しません。なぜならこのドメインは詐欺師自身のものであり、ホスティング業者のものではないからです。正しいabuse@アドレスはサーバーを所有する組織のものです（IPから見つかったもので、罠サイトのドメイン名からではありません）。停止すべきサーバーではなく停止すべきドメインの場合、探すべきは別のアドレスです、それはレジストラのものです（レジストラ、ホスティング業者、CDNの間で誰が何を制御するかを参照）。

abuse@アドレスが明白でない場合

WHOISは必ずしも明確に答えてくれるわけではありません。3つの状況がよく起こります：

大手クラウドホスティング業者（AWS、OVH、Azure、Google Cloudなど）は、メールアドレスの代わりに専用のウェブフォームを使用することが多く、時には通報を迅速に処理するために必須とされることさえあります。
ドメインのレジストラは、時にはRDAPを通じて、従来のメールアドレスではなく直接の「report abuse」リンクを公開します。
沈黙、または拒否：一部の運営者、特に海外の運営者は、対応が遅い、あるいは全く対応しないことがあります。この場合、国のCERTやその国の公式プラットフォームが手段として残ります：例えばフランスではPHAROSがあります。

質問から始まる3つの分岐の図：可視で応答するabuse@アドレスがない？第一の分岐、AWS、OVH、Azureのような大手クラウドホスティング業者で、ウェブフォームがメールに取って代わる。第二の分岐、ドメインのレジストラで、RDAPがそのフォームへの直接の「report abuse」リンクを提供する。第三の分岐、完全な沈黙または拒否で、その国の国のCERTまたは公式プラットフォーム、例えばPHAROSが手段として残る。キャプション：代替の連絡先、決してゼロではない、フォーム、チケット、または国のプラットフォームなど、ほぼ常に入口が存在する。日付、使用したチャネル、チケット番号を記録し、後で催促またはエスカレーションするのに役立てる。 — 図2：従来のabuse@アドレスが明白でない場合、ほぼ常に別の入口が残っています。

各試みの記録を保持します：日付、使用したチャネル（メール、フォーム、チケット）、そしてもしあれば参照番号。これによって有効に催促したり、ゼロから始めることなく次のレベルに進んだりすることができます。

通報の準備

正しいアドレスが見つかったら、通報自体は受け取る人が処理しやすいようにシンプルに保ちます：

関係する具体的な要素：ホスティング業者にはIPアドレス、レジストラにはドメイン名；
フィッシングページの正確なURL、または通報がメールから来ている場合は完全なヘッダー；
確認の日時、タイムゾーンを添えて；
hxxps://secure-login[.]exampleのような無害化されたリンク。読んでいる際に誤ってクリックしないようにするためです。

要点

1997年（RFC 2142）以来、abuse@ボックスはあらゆるネットワーク運営者に期待される規格です。
従来の経路はIP → WHOIS/RDAP → （必要ならASN）→ abuse@アドレスです。
有効な連絡先はサーバーを所有する組織のもの（IP経由で見つかった）であり、罠サイトのドメイン名から推測されたものではありません。
大手クラウドホスティング業者はメールアドレスよりもウェブフォームを使うことが多いです。
回答がない場合、国のCERTや公式プラットフォームが手段として残ります。

これはまさにBaitbackが自動化することです：メールやリンクから、ツールは関連するサーバー、その運営者、その正確な通報アドレスを見つけ、送信準備が整ったメッセージを作成します。

さらに詳しく知るには：レジストラ、ホスティング業者、CDN：誰が実際に対処できるか、または効果的な通報の完全な構成。