フィッシング被害に遭ったら — 48 時間以内にやるべき 7 ステップ

「会社のブランドを名乗るフィッシングサイトが発見されました」——この一報が情シスや広報担当に入った瞬間から、対応の質はその後 48 時間で決まります。

実際にフィッシング被害の報告を受けた企業が直面する最大の問題は、「何を・どの順序で・誰が」やるべきか、社内に整理された手順がないことです。多くの場合、見つけてから担当者が個別に registrar へメールを書き、広報が独自にアナウンスを準備し、法務が別ルートで対応を検討——その間にもフィッシングサイトは稼働し続け、被害は拡大します。

この記事は 「発見直後から 48 時間以内にやるべき 7 ステップ」 を、実際に OpenBait の運用チームで回している手順に基づいて順序化したものです。社内ドキュメントに落とし込んで使えるよう、各ステップの責任者と成果物も明示しました。

Step 1（発見後 1 時間以内）— 被害の範囲を特定する

責任者：情シス / セキュリティ担当 成果物：「被害サマリ」1 ページ

最初の 1 時間でやるべきは以下の事実確定：

• 偽サイトの完全 URL（リダイレクト先を含め、できれば複数経路で確認）
• WHOIS / RDAP 情報（登録日、registrar、nameserver、公開されている contact）
• 該当する自社ドメインとブランド要素（ロゴ / カラー / 文言 / UI 構造をどこまでコピーしているか）
• 推定される被害ユーザー数（既に CS に通報が来ているか、SNS で言及されているか、referrer ログで検知できるか）
• 偽サイトの目的（credential 収集 / 偽決済 / 偽配送通知 / 偽キャンペーンなど）

使うツール：WHOIS / RDAP lookup、urlscan.io、ブラウザのシークレットモードで直接アクセス（この段階で社用ネットワーク経由でアクセスしない——ログが攻撃者に通知される可能性）。

自社で継続監視を入れていれば、この Step 1 の大半は自動で埋まります。継続監視がなく手動確認している段階の企業は、まず類似ドメイン検知のベースライン整備を並行して検討すべきです。

Step 2（発見後 2 時間以内）— 社内ステークホルダーへの即時共有

責任者：情シス部長 or CSIRT リード 成果物：Slack / Teams / メールでの初報（1 つの宛先リスト）

48 時間対応で一番よく失敗するのは 「共有が遅いこと」 です。次のメンバーに最初の 2 時間以内に同期してください：

避けるべきパターン：情シス内だけで抱え込む。「広報に出すかまだ決めかねる」という状態でも、「広報に入れるかどうかも含めて判断したいので状況共有します」 という形で早期に引き込むのが鉄則です。

Step 3（発見後 4 時間以内）— 証拠を保全する

責任者：セキュリティ担当 or SOC 成果物：incident-{日付}-{ブランド名}/ フォルダに収めた証拠パッケージ

後で registrar 通報、UDRP 申請、PR 対応、社内監査いずれの場面でも参照することになる証拠を、削除される前に確保します。

必ず取得するもの：

1. スクリーンショット（ヘッドレスブラウザ推奨、PC + モバイルの両方）
2. HTML ソース全文（curl -L -A "Mozilla/..." {URL} > page.html）
3. HTTP レスポンスヘッダ（curl -I）
4. TLS 証明書情報（openssl s_client -connect {host}:443 -servername {host}）
5. WHOIS / RDAP 出力（JSON 形式で保存）
6. ドメインの DNS レコード全種（A / AAAA / MX / NS / TXT）
7. リダイレクトチェーン（curl の -v で履歴を残す）
8. pHash / SSIM による正規サイトとの視覚類似度（定量証拠）

これらを社内ストレージ（タイムスタンプ付き）に保存。後述の registrar 通報の添付に直接使えます。

Step 4（発見後 6〜12 時間以内）— ユーザーへの警告アナウンス

責任者：広報 + カスタマーサポート + 情シス 共同 成果物：自社サイト告知 + メール + SNS 投稿（3 媒体最低）

「アナウンスするかどうか」を迷う時間は短く。被害が確認された時点でユーザーに事実を伝える義務があります（個人情報保護法の観点でも、消費者保護の観点でも）。

告知する内容：

• 発見した偽サイトの URL ドメイン名（自社ブランド名 + "似ていないが関連しそうな表記" を例示）
• 正規サイトの URL（正しい URL を明示してそれ以外を踏まないよう誘導）
• パスワードや決済情報を入力してしまった可能性がある場合の対応方法（パスワード変更、クレジットカード停止、CS 問い合わせ先）
• 企業側で進めている対応（「現在、当該サイトの停止を関係事業者に要請しています」）
• 今後の最新情報をどこで確認できるか

注意：告知に偽サイトの URL を完全な形で載せる場合は、クリック可能にしない（https:// を取り除く or 画像埋め込み）。読者が誤ってクリックする二次被害を防ぐため。

この段階でブラウザ blocklist への並行提出を始めておくと、告知と同時に Safe Browsing 警告が表示され始める ことで被害拡大を抑えられます（Step 6 と重なる）。

Step 5（発見後 12〜24 時間以内）— レジストラ / ホスティング事業者への abuse 通報

責任者：情シス / 法務共同 成果物：registrar と hosting 事業者への通報メール（チケット ID 取得）

Step 3 の証拠パッケージを使って abuse 通報を送ります。詳しい書き方は通るレジストラ abuse 通報の書き方を参照。要点だけ再掲：

1. 件名に Phishing Abuse Report — {偽ドメイン} impersonating {正規ブランド} と明記（分類ミスで別チームに回される事故を防ぐ）
2. 証拠を後で検証可能な形で添付（スクリーンショット URL、pHash 距離、動作証拠）
3. 「これは abuse であり DMCA / UDRP ではない」 ことを明示
4. 被害ブランドからの授権を明示（被害企業自身が書くなら不要）
5. 固定の reporter アドレスから送る（継続的な信頼積み上げ）
6. 72 時間後に follow up できる準備（chain リスト化）

ホスティング事業者（Cloudflare、AWS、OVH など）にも並行して通報。レジストラより速く対応するケースが多いので、レジストラ一択で待たないのが現実的。

Step 6（発見後 12〜24 時間以内・Step 5 と並行）— ブラウザブロックリストへの通報

責任者：セキュリティ担当 成果物：Google Safe Browsing、Microsoft SmartScreen、Cloudflare 1.1.1.1 3 系統への提出完了

レジストラの応答を待つ間にエンドユーザー保護を走らせる最速経路です。3 系統全て並行で送ります：

• Google Safe Browsing：https://safebrowsing.google.com/safebrowsing/report_phish/ — Chrome / Safari / Firefox / Android をカバー、24 時間以内で警告表示されるケースが多い
• Microsoft SmartScreen：https://feedback.smartscreen.microsoft.com/feedback.aspx?t=0 — Edge / Outlook / Teams / Windows Defender をカバー、必ずスクリーンショット添付（ないと処理遅延）
• Cloudflare 1.1.1.1 for Families：https://cloudflare.com/report-abuse/phishing — 公開通報チャネルで最速、24 時間以内の feed 反映が多い

詳細はブラウザ blocklist 通報の実務参照。

提出後の反映検証も必ず実施。chrome://safe-browsing-diagnostic?site={URL} または VirusTotal で確認し、社内 incident ticket に記録を残します。

Step 7（発見後 24〜48 時間以内）— 再発防止（継続監視の自動化）

責任者：情シス + CISO 成果物：監視インフラの設計書 + 次回発見時の自動通知ルート

今回のインシデント対応が終わる前に、次の偽サイトが登録された瞬間に気付く仕組みを整えます。これがなければ同じ 48 時間対応を毎回手動で繰り返すことになります。

最低限必要な監視レイヤー：

1. Certificate Transparency（CT）ログ監視 — 自社ブランド関連の TLS 証明書発行を日次で監視
2. Newly Registered Domains（NRD）feed — 高リスク TLD（.top / .shop / .xyz 等）で自社ブランド関連ドメインの新規登録を検知
3. dnstwist 系の候補列挙 — ブランド名バリエーションを週次スキャン
4. ソーシャル監視 — X / Instagram / TikTok / YouTube / LINE で自社ブランドの悪用投稿をキーワード検知

これらを全部自前で組むのは中堅企業には重すぎるので、継続監視はプラットフォームに委ねるのが現実的。OpenBait はこの 4 レイヤーを統合しており、新規偽サイト検知→証拠採取→abuse 通報生成→ブラウザ blocklist 提出まで自動で走らせます。

48 時間チェックリスト（社内配布用）

現場で印刷・共有して使える形：

発見後 1 時間以内:
  □ 偽 URL 完全確定
  □ WHOIS / RDAP 取得
  □ 被害サマリ 1 ページ作成

発見後 2 時間以内:
  □ 情シス部長・広報・法務・CS・事業責任者・CISO に共有

発見後 4 時間以内:
  □ スクリーンショット保存
  □ HTML / HTTP ヘッダ / TLS 証明書保存
  □ DNS / WHOIS / リダイレクトチェーン保存
  □ pHash / SSIM 計算

発見後 6-12 時間以内:
  □ 自社サイトに告知
  □ ユーザーへメール送信
  □ SNS で公式発信

発見後 12-24 時間以内（並行実行）:
  □ レジストラ abuse 通報
  □ ホスティング事業者 abuse 通報
  □ Google Safe Browsing 提出
  □ Microsoft SmartScreen 提出
  □ Cloudflare 1.1.1.1 提出

発見後 24-48 時間以内:
  □ ブロック反映の検証
  □ ユーザー向け追加情報の発信
  □ 継続監視インフラの設計 or 導入判断
  □ 事後レビュー（次回の手順改善）

OpenBait がどこを自動化するか

上記 7 ステップのうち、OpenBait プラットフォームが自動化する範囲：

• Step 1（範囲特定）：CT ログ + NRD + dnstwist の継続監視で、発見を人手から引き剥がす
• Step 3（証拠保全）：ヘッドレスブラウザでのスクリーンショット・pHash・WHOIS を自動取得
• Step 5（レジストラ通報）：テンプレート自動生成 + 固定 reporter アドレス + 送信状態トラッキング
• Step 6（ブラウザ blocklist）：Google Safe Browsing / SmartScreen / Cloudflare 3 系統への並行自動提出
• Step 7（再発防止）：ここを自動化するのが本来のプロダクト価値

OpenBait が自動化しない範囲（こちらは引き続き人が判断すべき）：

• Step 2（社内共有）—— 誰をどう巻き込むかは組織固有
• Step 4（ユーザー告知文）—— トーン・用語・法務レビューは企業判断
• Step 5 の法務判断（UDRP に進むかなど）

発見から対応開始までの時間を最短にすること が、ブランド毀損と被害拡大を抑える最大のレバーです。継続監視を組んでいれば、発見自体が Step 1 ではなく Step 0（自動通知）になります。無料枠で試してみることから始められます。

関連記事：

• 類似ドメイン検知の実務ガイド — 5 つの手法
• 通るレジストラ abuse 通報の書き方 — 6 つの設計
• ブラウザブロックリスト通報の実務
• 反フィッシング予算を経営層に通す — 被害試算と ROI