レジストラの返事を待たずに phishing を止める — ブラウザブロックリスト通報の実務

前回のレジストラ abuse 通報の書き方で最後に触れた エスカレーションパス——その中で最も強力なのが「ブラウザ側で phishing サイトを止める」アプローチです。

ブラウザブロックリストの何が強力なのかというと、レジストラが何もしなくてもエンドユーザーが守られる という点です。レジストラへの abuse 通報は結局のところ相手の処理速度と意思決定に依存しますが、ブラウザブロックリストはユーザー側のクライアント で警告を出すため、サイト自体は生きていても被害発生を大幅に抑え込めます。

この記事では、実運用で使える 3 つのブラウザ側ブロック経路——Google Safe Browsing、Microsoft SmartScreen、DNS レベルブロックリスト——それぞれの通報手順と反映タイムラインを整理します。

全体像：ブラウザ側の防御レイヤーは 3 つある

フィッシングサイトが生存している間に、エンドユーザーの手元で警告を出せる経路は次の 3 つに分かれます。

この 3 つは並行で送ってよい ものです。どれも被害ブランドや reporter への報酬 / 制裁は発生しないので、レジストラへの abuse 通報とセットで同時進行 させるのが実務上の基本戦略になります。

1. Google Safe Browsing への通報

フロー

通報エンドポイントは公開されています： https://safebrowsing.google.com/safebrowsing/report_phish/

フォームに入力する主な項目：

• URL：フィッシング完全 URL（クエリパラメータ含む）
• Comments：任意だが、phishing credential-theft page impersonating {brand} などと明記すると担当のレビュー優先度が上がる傾向
• Captcha：reCAPTCHA v2 を通す

反映タイムライン

経験則：

• 24 時間以内：Chrome / Android で Deceptive site ahead の全画面警告が出るケースが多い
• 数時間：既に他の通報源（PhishTank、複数のユーザー通報など）と一致した場合
• 48 時間以上：Google 側の再検証で live 判定が取れないと警告表示されない

Safe Browsing の判定は API でも確認できます：

curl "https://safebrowsing.googleapis.com/v4/threatMatches:find?key=$API_KEY" \
  -d '{
    "threatInfo": {
      "threatTypes": ["SOCIAL_ENGINEERING"],
      "platformTypes": ["ANY_PLATFORM"],
      "threatEntryTypes": ["URL"],
      "threatEntries": [{"url": "https://example-phish.com/login"}]
    }
  }'

レスポンスに該当 URL が含まれれば、既にブラックリスト入り済み ——エンドユーザーには警告が出ています。

落とし穴

• URL 単位であってドメイン単位ではない：サイトの path を変えられると再通報が必要
• 誤検知 appeal：正規サイトが巻き添えで誤検知された場合、Google Safe Browsing の reconsideration request を通せば数時間で解除される
• Private フィッシング（非公開 URL）には効かない：QR コード経由で拡散される URL shortener 先など、Google が crawl できない URL には警告が出ない

2. Microsoft SmartScreen への通報

フロー

通報エンドポイント： https://feedback.smartscreen.microsoft.com/feedback.aspx?t=0

入力項目：

• URL
• Threat type：Phishing / Malware / Unwanted software から選択
• Evidence：スクリーンショット 1 枚を必ず添付する——SmartScreen は GSB 以上に証拠ベースで動く チームなので、スクリーンショットなしの通報は遅延する

ステータスサイクル

SmartScreen は通報後、次の 3 段階でステータスが変化します：

1. Submitted：通報受付完了
2. Under review：担当が検証中（担当者が URL にアクセス）
3. Effective / Not effective：判定確定。Effective になれば Edge / Outlook / Teams などマイクロソフト製品上で警告表示

SmartScreen は ステータス遷移の通知メール を送ってくれるので、reporter 側で tracking しやすい仕様です（ただしスパム判定されやすいのでメールフィルタ設定に注意）。

落とし穴

• 証拠スクリーンショットが低解像度だと再提出要求：fullsize 1280x800 以上推奨
• Edge 以外のブラウザでは警告が出ない：Firefox / Chrome ユーザーには効かない
• 反映タイムラインが読みにくい：12 時間で effective になることもあれば、72 時間かかることも

3. DNS レベルブロックリスト

Quad9（9.9.9.9）

Quad9 は IBM X-Force、Anycast ネットワーク、複数の脅威インテリフィードをバックエンドにした 無料のフィルタリング DNS リゾルバ です。Quad9 を使っているエンドユーザーは、フィッシングドメインに対して NXDOMAIN 応答（= 名前解決失敗）を返してもらえます。

通報先： https://quad9.net/report/

Quad9 は フィードパートナー経由の通報を優先 するため、個別 URL 通報より PhishTank など upstream への通報が回り回って効く、という挙動を覚えておくと良いです。

Cloudflare 1.1.1.1 for Families

Cloudflare Gateway の家庭向け DNS（1.1.1.3 = malware block、1.1.1.2 = malware + adult block）。Cloudflare Gateway を使っている企業ネットワークでは、dashboard.cloudflare.com から category-level で phishing をブロックできます。

個別 URL / ドメインの通報経路： https://cloudflare.com/report-abuse/phishing

Cloudflare のフォームは短く、レジストラ以上に処理が速いです（24 時間以内にフィード反映されるケースが多数）。

OpenDNS（Cisco Umbrella）

B2B 寄りの DNS フィルタ。通報経路は： https://phish.opendns.com/

大手企業の従業員ネットワークで広く使われているため、被害ブランドの従業員や顧客が corporate network から被害に遭うリスク を抑える意味で投入すると効果的です。

通報後の効果検証

通報しただけでは「本当に警告が出ているか」がわかりません。次の 3 つで検証できます：

Google 側の反映確認

chrome://safe-browsing-diagnostic?site=https://example-phish.com

Chrome のアドレスバーに貼ると、Google 側の最新判定が表示されます。

第三者による検証

• VirusTotal に URL を投げると、GSB / Opera / PhishTank / その他ベンダーの判定が並んで見られる
• urlscan.io は解析のたびに新しい verdict を付けてくれるので、通報前後で diff を取れる

SmartScreen の専用確認 URL

https://www.microsoft.com/en-us/wdsi/filesubmission/detail?id={ticket_id}

通報時に発行される ticket ID でステータスを追えます。

OpenBait での自動化

OpenBait では、類似ドメイン検知の実務ガイド で紹介した candidate のうち live 判定が付いたものに対して、

1. スクリーンショット自動取得（ヘッドレス Chromium）
2. GSB / SmartScreen / Cloudflare それぞれへの通報送信（各 API / フォーム経由）
3. ステータス tracking（Submitted → Under review → Effective の遷移）
4. 失効（Effective になったら stale evidence として ticket close）

までを一連で実行します。人手で 20 分かかる作業が、1 candidate あたり 30 秒で完了する計算です。

レジストラ abuse 通報とこのブラウザブロックリスト通報を並列で走らせることで、エンドユーザー保護のタイムラインをレジストラの対応速度から独立させる ことができます。

類似ドメインや phishing を見つけた時、次の選択肢は「レジストラに通報する」だけではありません。ブラウザブロックリスト通報 は、reporter の信頼積み上げも不要、返答待ちのエスカレーションも不要、エンドユーザーを守るまでの時間が最短 の経路です。

自動化に興味があれば無料枠で試してみてください。候補検知から通報、ステータス管理までが一つのダッシュボードで完結します。