改ざんされたコンテンツ:広告主ではなくサイト自体が侵害されたとき、実際に何が起きるのか

最初の兆候が公式な通知から来ることはまずない。チームの誰も作った覚えのない見慣れないURLがSearch Consoleに並んでいたり、いつものダッシュボードでは原因が見当たらないまま自然検索トラフィックが落ち込んだり、ある広告主から「自分の掲載ページがサイトと無関係な場所にリダイレクトされるのはなぜか」という問い合わせが来たりする。ブラウザがページを開くのを拒否したと訪問者から報告されることもある。これらはいずれも広告主による不正とは違うし、サイト自身のコードには一切非がないのにサイトがフラグを立てられる、悪意ある広告配信のケースとも違う。

これはそれとは別のケースであり、問題の性質も解決策も異なる。この場合、チームの誰も置いた覚えのないものが、実際にサイトのファイルやデータベースに追加されている。このカテゴリーのディレクトリサイトは、一週間であっても信頼できないように見えることを許容できない。Googleに対しても、この業界をすでに平均より高リスクと扱っている決済代行会社に対しても、通報一件でアカウント停止に至りかねないホスティング事業者に対しても同じことが言える。何が起きたのかを正確に把握し、Googleが実際に何を確認しているのかを理解し、解決策が本当にどういう順序で機能するのかを知ることは、ごく普通の中小企業のブログにとってよりも、ここではずっと価値が高い。順序を間違えたときの代償が大きいからだ。

攻撃者が実際にどう侵入するのか、たいていは劇的ではない

この段階で、成人向け分類広告ディレクトリを名指しで狙う攻撃者はほとんどいない。よくあるパターンは、既知で未修正の脆弱性を持つ特定のソフトウェアを動かしているサイトをオープンなウェブ上で探し回るボットで、レストランのサイトや法律事務所のブログを探すのとまったく同じやり方だ。サイトが被害に遭うのは、百万もの他のサイトと同じCMS、同じプラグイン、同じ古いライブラリをたまたま使っていたからであって、誰かがそのサイトを観察して「手間をかける価値がある」と判断したからではない。

古いソフトウェアは実在する、ありふれた要因だが、それがすべてではない。それがすべてだと考えてしまうと、実際の侵入経路の半分が無防備なまま残ってしまう。Sucuriのハッキングされたウェブサイトに関するレポートは、2023年に同社が復旧させたサイトを対象にしたもので、侵害されたCMSインストールの39.1%が感染時点で古いソフトウェアを動かしていたとしており、これは前年の50.58%から低下している。同じレポートは、Sucuriが復旧作業を詳しく調べた時点で、既知の脆弱なプラグインやテーマが特定できたサイトはおよそ14%にすぎなかったとも報告している。つまり、同社が復旧させたサイトの大半は、運営者が真っ先に修正すべきと考えるようなソフトウェアの欠陥から実際に侵入されたわけではなかったということだ。

もう半分の要因は認証情報にある。Verizonの2025年版データ漏洩調査報告書は、ウェブサイトに限らず同社が追跡するあらゆる業界を対象にしたもので、攻撃者が最初の足がかりを得る手段として、盗まれた、あるいは推測された認証情報が、悪用された脆弱性をわずかに上回ったとしている。侵害の22%対20%という数字だ。これは分類広告サイトだけから導かれた数字ではないが、SucuriがCMSプラットフォームに特化した復旧作業で観察している内容と一致している。何年も前に無関係な漏洩事件で流出した個人のメールアカウントから使い回された管理者パスワードは、実際のところ、未修正のプラグインとほぼ同程度に侵入経路になり得るということだ。

実務上の結論は、サイトを守る作業は重みがほぼ等しい二つの戦線であって、一つではないということだ。パッチ適用のスケジュールはソフトウェア側の穴の半分を塞ぐ。誰がアクセス権を持っているか、そのパスワードが実際どうなっているか、他で使い回されていないかという、別建ての規律がもう半分を塞ぐ。プラグインの更新だけを続けている運営者は仕事の半分しか終えておらず、しかもそのことに永遠に気づかないかもしれない。どちらの半分を怠っても、警告画面はまったく同じに見えるからだ。

Googleが実際にこれを何と呼ぶのか、そしてなぜ悪意ある広告とは別の問題なのか

Chromeの別種の警告については、すでにここで扱っている。それは契約先の広告ネットワークがサイト自体の広告枠を通じて欺瞞的あるいは悪意あるクリエイティブを配信し、サイトが一度も触れていないコンテンツのせいでGoogleにフラグを立てられるケースだ。今回はそのケースではない。ここでは、運営者の知らないうちにサイトのページやデータベースに何かが追加されている。これはまさにGoogleのスパムポリシーが「改ざんされたコンテンツ」と定義しているものだ。すなわち、サイト自体のセキュリティ上の弱点が原因で、所有者の許可なくサイトに置かれたコンテンツである。

Googleのドキュメントは三つの具体的なパターンを区別している。コードインジェクションは、通常JavaScriptの悪意あるコードが、既存のページやiframeに直接挿入されるものだ。ページインジェクションは、検索順位の操作やフィッシングの実行を目的として、以前は存在しなかった新しいページがサイトに追加されるもので、訪問者がすでに知っているページの方には異常の目に見える兆候がないことが多い。コンテンツインジェクションはさらに巧妙で、CSSやHTMLのトリックを使って既存のページに隠しテキストや隠しリンクを追加するもので、検索エンジンのクローラーには見えるが、ブラウザで同じページを見ている人間には見えない。

ページインジェクションは運営者が最後に気づくパターンであることが多く、攻撃者がなぜ自前の使い捨てサイトを作るのではなくわざわざこの手間をかけるのかを理解しておく価値がある。すでに履歴があり、既存の被リンクがあり、検索結果での地位が確立しているドメインは、まったく新しいドメインよりもはるかに速くスパムコンテンツを検索順位へと洗浄してしまう。だからこそ攻撃者は自分でゼロから評判を築くより、既存サイトの評判を借用することを選ぶ。これは別の記事で扱った外部からのリンク攻撃とは異なる仕組みだ。あちらは外部の他サイトからのリンクをターゲットに向ける攻撃だが、こちらはスパムページがターゲット自身のドメイン上に、その独自のファイル構造の内側に存在するよう作られている。

そうしたコンテンツがサイト上に存在するようになると、影響は積み重なっていく。Search Consoleのセキュリティの問題レポートがそのプロパティに直接フラグを立て、一部のページが検索結果から除外されたり、一覧で警告表示に置き換えられたりすることがあり、Chromeのセーフブラウジングは広告ネットワークのケースですでに説明した赤い中間画面を訪問者に表示し始めることがある。今回はそれが、不具合のあるクリエイティブが通過したからではなく、サイトが実際に悪意あるまたは欺瞞的なコンテンツをホストしているから引き起こされる点が違う。

警告を解除させる:実際に機能する順序

Googleのガイダンス自体が順序について具体的であり、実務で失われる時間の大半は、これらの手順を順不同で行うことから生まれている。最初の作業は、注入されたコンテンツのすべてのインスタンスを見つけて削除することであり、Search Consoleが問題の例として挙げたサンプルページだけではない。そのURLはサンプルであって一覧ではなく、それを修正した時点で止まってしまう復旧作業は、通常、実際のインジェクションの大半をそのまま残してしまう。

二つ目の作業は、攻撃者がどのように侵入したのかを突き止め、その具体的な穴、未修正のプラグインであれ、流出した認証情報であれ、誤って設定された権限であれ、をふさぐことだ。侵入経路を修正せずにスパムページだけを削除しても、同じ攻撃者、あるいは同じ自動スキャンが同じ扉から戻ってくるまで、時計をリセットするだけに終わる。Googleのドキュメントは、修正がホームページや訪問者が通報したページだけでなく、サイト全体をカバーしなければならないと明確に述べており、同じガイドの関連部分では、管理者アクセス権を持つアカウントに紐づくすべてのパスワードを変更することを推奨している。CMSのログイン、ホスティングのコントロールパネル、FTPまたはSFTP、そしてデータベースだ。まさに侵入経路が、症状が現れたページそのものではなく、これらのいずれかであることが多いからである。

運営者が最もよく取り違える部分は、いつGoogleに再審査を依頼するかというタイミングだ。上記の復旧作業が実際に完了する前に審査をリクエストしても、何も早くはならない。Googleは、問題がまだ存在している間に審査をリクエストしても、サイトがフラグを立てられたままになる期間を延ばすだけだと明言している。審査にかかる時間はカテゴリーによって異なる。単純なマルウェアの審査は通常数日、フィッシングの審査はおよそ一日だが、注入されたスパムページを含む改ざんコンテンツの審査には数週間かかることがある。Googleがこのカテゴリーを、自動の再チェックではなく、実際に人の手による確認が必要になり得るものとして扱っているためだ。

審査に一度合格した後に同じ警告が再発するのは、たいてい、侵入経路がそもそも一度目に実際には塞がれておらず、取り除かれたのは症状だけだったことを示している。目に見えるスパムページを削除すると作業が終わったように感じられるが、脆弱なプラグインがまだそこにあるか、流出したパスワードがまだ有効であれば、同じ穴が再び使われる。警告が解除されてから数日のうちに再発することもある。

この事業が負担できる予算で、実際に何が予防になるのか

ここまでの話に、専任のセキュリティチームを雇う必要はまったくない。基本を省く運営者は、たいていリストが実際よりも長く感じられるからそうしてしまう。CMS本体、そのテーマ、インストール済みのすべてのプラグインには、「時間ができたら」ではなく毎週確認する固定の更新スケジュールが必要であり、一度インストールしてもう使っていないものは、休眠させたままにせず完全に削除すべきだ。無効化されたプラグインも、鍵をかけ忘れたままのドアであることに変わりはないからである。

上で挙げたSucuriとVerizonの数字が実際に示していることを踏まえれば、認証情報に関する規律はパッチ適用と同じだけの重みを持つ。それは、サイトに触れられるすべてのアカウントに対して一意のパスワードを用意し、記憶に頼らずパスワードマネージャーで生成・保管すること、提供されているあらゆるログインで二要素認証を有効にすること、そしてスタッフやモデレーターの間でログイン情報を使い回さないことを意味する。共有ログインは、何か問題が起きたときに特定の個人まで追跡できないアクセス手段でもあるからだ。

バックアップは予防策と同じくらい重要だ。それは、数週間かかることもあるGoogleの審査を待つのではなく、数時間でサイトをオンラインに戻すための手段だからである。保護対象のサイトと同じホスティングアカウント上に置かれたバックアップは、たいしたバックアップとは言えない。管理者権限を持つ攻撃者は通常そこにも手が届くからだ。別の場所に保管され、検証されないまま放置されるのではなく、少なくとも一度は実際に復元して検証されたコピーこそが、悪い一週間と悪い一ヶ月の違いを生む。

最後の要素は、単純に早く気づくことだ。Search Console自体のメール通知は、セキュリティの問題レポートを、実際に誰かが読む受信箱に届けてくれる。訪問者からの苦情や、何日も何週間も経ってからの自然検索トラフィックのじわじわとした減少によって運営者が問題に気づくのとは違う。これらの手順のどれも、時間以上のコストはかからず、警告画面がすでに一週間分のトラフィックを奪い、復旧作業がようやく片付きつつあるという段階になってから行うより、今すぐ行うほうがすべて安上がりだ。

警告がすでに出てしまっている場合の順序は、まずすべてを徹底的に清掃し、それを可能にした具体的な穴をふさぎ、そこで初めてGoogleに再審査を依頼する、であって、決してその逆ではない。まだ何も起きていない場合の順序は、それでも今週中に同じ四つのことをスケジュールに組み込んで行うことだ。インストール済みのものにパッチを当て、管理者アクセス権を持つすべてのパスワードを変更し、提供されているあらゆる場所で二要素認証を有効にし、バックアップからの実際の復元を一度テストする。いずれにせよ、解決策が問われてきたのは、証明書の法域でも契約している弁護士事務所の規模でもなく、誰がログインできるか、ソフトウェアがどれだけ最新に保たれているか、そして誰かが間に合ううちに気づけるかどうかだった。