フィッシング対策の実装ガイド — 検知・テイクダウン・顧客防御を一つの運用に束ねる
フィッシング攻撃は技術的に派手な話ではない。攻撃者の側からみれば、ドメインを 1,000 円程度で取得し、ログインページを HTML として複製し、配信代行に数万通単位で投げるだけ。クリック率が 0.1 % でも、配信 10 万通で 100 人がパスワードを入力する。コストパフォーマンスが圧倒的によいから止まらない。
防御側にとってこれが厄介なのは、社内で起きるインシデントは「人がミスをした」ことに帰着するからだ。Verizon の DBIR では複数年連続で、検知済みインシデントの 6〜7 割に人的要因が関与していると報告されている。つまりシステムをいくら堅牢にしても、判断疲れの瞬間に通報メールを開いて URL をクリックする確率はゼロにならない。
そこで多くの企業は研修と模擬攻撃で「人を訓練する」方針に向かうのだが、それだけでは足りない。研修で識別率は上がっても、忙しい時期の朝一に届く「業務システム緊急メンテナンス」のメールに引っかかる確率は残る。訓練を補完する技術側の防御を、検知・対応・顧客保護の 3 層で組み立てる必要がある。本稿はその実装の話だ。
検知レイヤ — フィッシングサイトを公開と同時に見つける
攻撃者が偽サイトを立ち上げてから、社内の誰かがフィッシングメールを受け取って気付くまでの時間がそのまま被害ウィンドウになる。この差を縮めるには、攻撃側が必ず通る「観測点」を押さえる必要がある。
Certificate Transparency ログは最も効率がよい観測点になる。HTTPS が前提となった現在、フィッシングサイトもほぼすべて Let's Encrypt や ZeroSSL で証明書を発行する。CT ログにはこの発行履歴が秒単位で書き込まれるため、自社ドメイン名と類似したホスト名（example-login.com、secure-example.jp、example.help など）を継続クエリしておくと、攻撃者が証明書を取った瞬間に通知が出せる。crt.sh の API を 1 分間隔で叩く程度の実装で十分間に合う。
新規登録ドメインの監視は CT ログより一段早い段階を捕える。dnstwist で生成したタイポスクワッティング候補（同形字置換、TLD 差し替え、文字挿入など）を、新規登録ドメインフィード（Whoisxmlapi の NRD feed や ICANN Centralized Zone Data Service）と毎日突き合わせると、攻撃者が証明書を発行する前——多くの場合はパーキングや在庫期間のうちに——リストアップできる。実装と運用上の注意は タイポスクワッティング検知の実務ガイド でまとめた。
検索エンジンのブランドキーワード監視は補完的だが効果がある。攻撃者が広告枠を買って自社ブランド名で上位表示するケースや、SEO で自然検索上位を取りにくるケースは、CT ログでも NRD でも捕まらない。Google・Bing・Yahoo! Japan で 自社ブランド名 ログイン 自社ブランド名 公式 のような典型的な被害者検索クエリを毎日実行し、上位 10 件に未知ドメインが入っていればフラグを立てる。
これら 3 系統で発見した候補は、そのまま triage キューに流す。月数件の中堅企業なら自社内で運用、月数十件規模なら自動化されたプラットフォームに任せたほうが TCO は下がる。
対応レイヤ — テイクダウンを並行で走らせる
候補を見つけてから実際にサイトを停止できるまでが第二のリードタイムだ。フィッシングサイトの平均存続期間は APWG の四半期レポートで 30〜80 時間程度を行き来している。この時間内にどれだけアクセスを止められるかで被害件数が決まる。
最も基礎的な経路が registrar への abuse 通報だ。GoDaddy・Namecheap・Porkbun・お名前.com など、対象ドメインを登録した registrar に対して abuse 通報を送る。ここで重要なのが通報の品質で、件名と本文の書き方を間違えると abuse キューで後回しにされる。詳細は 通る registrar abuse 通報の書き方 で扱ったが、要点は「件名で Phishing Abuse Report であることを明示」「再検証可能な証拠（スクリーンショット URL、pHash、WHOIS、証明書チェーン）を添付」「DMCA・UDRP との混同を避ける明示」「固定 reporter アドレスからの送信」の 4 点。
ブラウザブロックリストへの並行提出を忘れがちだが、これが効く。registrar が応答するまで数日かかる間、ブラウザ側でユーザーに警告を出せれば被害は実質ゼロに近づく。Google Safe Browsing、Microsoft SmartScreen、Cloudflare Phishing URL Scanner の 3 系統に同時に提出する。SmartScreen はスクリーンショット必須、Safe Browsing は phishing カテゴリの明示が必要——細かい注意点は ブラウザブロックリスト通報の実務 にまとめた。
ホスティングプロバイダーへの通報は registrar より反応が遅いことが多いが、Cloudflare 経由のホスティングや AWS S3 バケット直 hosting のような場合は registrar より先に止まる。Cloudflare はブランド保護プログラムで abuse 通報窓口があり、Cloudflare Pages や Workers にデプロイされた偽サイトに対して比較的早く反応する。
これら 3 経路を同時並行で走らせるのが正解で、どこか 1 系統が失敗しても他の経路で結果が出る確率が上がる。手で並行運用するなら最低限、registrar・blocklist 同時提出のスクリプトと通報履歴の社内チケット管理は欲しい。
顧客側保護 — ブラウザ層で最後の砦を作る
ここまでで攻撃者の証明書発行を観測し、registrar とブロックリストで停止依頼を出した。それでもユーザーが偽サイトに着地する経路は残る。SMS で送られたフィッシングリンクに反応した瞬間や、QR コードからのアクセスでは、メールゲートウェイも社内訓練も介在しない。最後にユーザーをブラウザ層で守る仕組みが必要になる。
Canary トークンは仕掛け側の検知としてシンプルで強力だ。正規サイトの HTML 内に 1 ピクセルのビーコンや特定のクラス名を埋め込み、攻撃者が wget --recursive や Cypress 系のページコピーツールでサイトを丸ごとコピーした際に、攻撃者の偽サイト上でそのビーコンが発火するように仕込む。発火イベントには referrer（攻撃者の偽サイト URL）と訪問者の IP が含まれるため、登録から数分で偽サイトを特定できる。Canary 単独で防げるわけではないが、CT ログ監視や NRD と組み合わせると検知の網が二重になる。
JavaScript SDK によるユーザー警告は、攻撃者が SDK ごとサイトをコピーした場合に効く。SDK 自身が動作中の URL と正規 URL を比較し、不一致であれば「このサイトは公式ではありません」とフルスクリーンの警告を出す。攻撃者は SDK を取り除くこともできるが、ヘッドレスブラウザでサイト全体をコピーするツールではよくこのまま含まれてしまう。Memcyco が金融機関向けに提供しているのが代表例で、OpenBait は同等の技術を中堅企業価格帯で提供している。詳細は OpenBait Canary SDK のアーキテクチャ で扱った。
ブランド識別の一貫性は最後の地味だが効く一手だ。公式メール・SMS・アプリ通知でいつも同じ送信ドメイン、同じテンプレート、同じトーンを使う。顧客に「これは見慣れた形だ」という認知パターンを作っておくと、攻撃者がパターンを完全に再現するハードルが上がる。送信ドメインの DMARC ポリシーを p=reject で運用し、SPF と DKIM を全配信経路で揃えるのがその技術側の最低ラインになる。
運用上の注意点
ここまで仕組みの話だったが、実際に走らせるとよく踏む地雷がいくつかある。
ツール一つで全部解決しようとしない。市場には「フィッシング対策ワンストップ」を謳う製品が多いが、CT ログ監視に強いベンダーがテイクダウンに弱かったり、メールゲートウェイ会社が顧客側保護をカバーしていなかったりする。3 層それぞれで信頼できるツールを選び、API でつなぐ。
メール以外のチャネルを見落とさない。スミッシング（SMS フィッシング）、LINE の偽公式アカウント、Instagram の DM、QR コード経由のフィッシングは、メールゲートウェイの守備範囲外。広報・カスタマーサポート・セキュリティチームの 3 部門で月次で連携会議を持ち、別経路で来た被害情報を吸い上げる。
事業部門との情報伝達線を作る。フィッシング被害が大規模化したとき、顧客サポートには「公式から SMS でパスワードを聞くことはありません」「不審な URL を開いてしまった場合は…」というトークスクリプトが要る。インシデント発生から数分以内に発出できる準備が、信頼回復の速さに直結する。
インシデント後のレビューを必ずやる。完了報告で終わらせない。攻撃者の手口、検知から停止までのタイムライン、見落としたチャネル、自動化できる工程をすべて記録し、次の四半期の優先度に反映する。被害がなかったケースも記録対象に含める——「危なかったが防げた」事例こそ、現場の改善ヒントになる。
OpenBait の位置付け
OpenBait は 3 層すべてを 1 つのワークスペースで運用できる中堅企業向けプラットフォームとして設計している。CT ログと NRD feed を 24 時間連続で監視し、Canary token と JavaScript SDK で顧客側を保護し、registrar abuse 通報と ブラウザブロックリスト 3 系統への並行提出を自動化する。月額 $79 から、Business 以上で年契約・銀行振込・請求書払い対応。実装の判断材料として 無料枠 で自社ドメインに対して試せる。
関連記事
関連記事
`.cn` フィッシングサイトを Tencent 経由で数時間で停止 — Google には 3 日反応されなかった件
顧客対応で実際に起きた事例。同じフィッシング URL を同じタイミングで Google Safe Browsing と Tencent abuse 通報の両方に出した結果。Tencent 側は 24 時間以内に停止、Google 側は 3 日経っても無反応。中国系インフラを跨ぐ可能性のあるブランドを守っている人が、テイクダウンスタックを設計し直すべき理由を整理する。
フィッシング被害に遭ったら — 48 時間以内にやるべき 7 ステップ
自社ブランドがフィッシングに悪用されたと判明した直後の 48 時間で何をすべきか。被害範囲の特定、証拠保全、ユーザー警告、レジストラ通報、ブラウザブロックリスト並行提出、再発防止まで、順序化された playbook。
Phishing Takedown Services Compared — In-House, Agency, or SaaS?
An honest 2026 comparison across the takedown landscape: enterprise platforms (Memcyco, Bolster, ZeroFox, Axur, PhishLabs), agency-style retainers, and self-serve SaaS. Where each model wins, how prices actually shake out, and what mid-market security teams should buy when budgets land under $50K/year.