このサイトをいつも読んでくださっている方に、まずお詫びとご報告があります。
当サイトは一時、第三者による改ざん被害を受けてしまいました。
改ざんされた状態にあったのは、時間にして数時間かと思います。
しかし、その後始末には約1か月かかりました。
現在は復旧・対策済みで、閲覧に問題はありません。
なお、当サイトでは会員情報や決済情報を保管していないため、読者の皆様への被害はありません。
ご安心ください。
今回はその実体験をもとに、WEBサイト改ざんの原因、検知の方法、そして乗っ取られたときの対処を包み隠さずお話しします。
同じようにサイトを運営している方、そして「自分が見ているサイトは大丈夫か」と不安な読者の方、どちらにも役立つ内容にしたつもりです。
WEBサイト改ざんは、削除しても終わらない
まず、今回の件について結論から言うと、WEBサイト改ざんへの対処は、不正なファイルを削除しただけでは終わりません。
本当に終わるのは、次の状態がそろったときであるということです。
- 攻撃者が残したプログラムを除去できた
- 侵入口を塞いだ
- 不審なアクセスをサーバーの手前で遮断した
- Googleに登録された不正URLを正常に処理した
- 再発していないことをログで確認できた
私も当初は、「怪しいファイルを消してWordPressが表示されれば復旧」と考えていました。
しかし、実際にはそう簡単ではありませんでした。
見た目が元に戻っても、Googleは過去に取得した不正ページを覚えています。
不正URLを狙うボットも、一度成功したサイトとしてその後しばらく訪問を続けます。
実際、今回は改ざんを修正した後も、1か月くらい毎日数十万単位で不正アクセスが続きました……
WAFでブロックしたアクセスだけで100万を超える日なんてのもありましたね。
攻撃者が別の場所にバックドアを残していれば、削除したファイルが再生成される恐れもあります。
警察庁も、改ざんの確認項目として、不審なJavaScript、通常と異なるURL、Webサーバー・FTP・SSHなどのアクセスログを挙げています。
画面を目視するだけでは不十分ということです。
Google Search Consoleには、Googleがサイトのハッキングや訪問者に害を与える可能性を検知した際に知らせる「セキュリティの問題」レポートがあります。
ただし、Search Consoleに警告が出ていないことと、サイトが完全に安全であることは同じではありません。
今回の経験から得た、この記事の核となる考え方はこれです。
改ざんは、直して終わりではない。信用を戻して終わる。
ここでいう信用とは、読者からの信用だけではありません。
Googleなどの検索エンジン、レンタルサーバー、外部サービス、そして自分自身が、「このサイトは再び正常に運営できている」と判断できる状態を指します。
見た目は正常なのに、Googleには別サイトに見えていた
それでは今回どのようなことが起こったのかを見ていきましょう。
検索順位の大幅落下と管理画面に入れない
異変に気付いたきっかけは、検索順位の大幅な下落の連絡です。
さらに確認しようとサイトの管理画面に行っても入れなくなっていたのです。
サイト自体は普通に表示されています。
トップページを開いても、ブログ記事を見ても不審な広告や外国語の文章が見えるわけではありません。
ですから順位の連絡がなければなかなか気づけなかったでしょう。
うちのWEBサイトの場合は、自動で検索順位を定期チェックしていたことで、被害にすぐ気づけたのは不幸中の幸いでした。
不審なファイルが大量に
管理画面にいくとログインは出来ず、『サーバー会社に連絡してください』という表示が出ていました。
連絡すると、乗っ取りの可能性が高いため、サーバー会社側で管理画面にガード(アクセス制限)を掛けているとのことでした。
調査を依頼したところWordPressの複数箇所から不審なPHPファイルが見つかったそうです。
不正ファイルは一つだけではありません。
こうした場所に分散して置かれていました。
- サイトのルートディレクトリ直下
- WordPress本体のシステムフォルダの中
- 使用中のテーマのフォルダの中
- wp-content配下（アップロード用フォルダやプラグインフォルダの中）
- ランダムな名称の謎フォルダ
さらに、一部の正常なWordPressファイルも書き換えられていました。
つまり、玄関の鍵を交換するだけでは不十分です。
屋根裏や床下に、別の出入口が作られているような状態でした。
WEBサイト改ざんは「表示が変わるだけ」の事故ではありません。
知らないページがGoogleに認識されている
さらにSearch ConsoleやGoogleが取得した情報を確認すると、私が作った覚えのない外国語のページが大量に認識されていました。
海外の通販サイトやShopify系サイトを模したような情報です。
Googleから見ると、私のサイトはいつの間にか「別の商品を販売する通販サイト」のようになっていたのです。
これは、アクセスする相手によって異なるページを返すクローキング型のSEOスパムとみられます。
通常の読者には正規サイトを表示し、検索エンジンや特定のボットには不正な商品ページを見せる。
こうなると、サイト運営者が自分のブラウザで確認しても、なかなか気付けません。
Googleのスパムポリシーでは、検索順位を操作するためのクローキングや、不正に生成されたコンテンツが検索結果からの順位低下や除外につながる可能性を示しています。
サーバー会社の復旧機能で不正ファイルを無効化
サーバー会社からの提案いただいた復旧機能で不正ファイルを無効化し、正常なWordPressへ戻しました。
その後、セキュリティプラグインで、サイト全体をスキャン。
不正に変更されたファイルや、WordPressに本来存在しないファイルを一つずつ確認しました。
これで基本的に元の状況に戻っています。
ただし、この時点でも作業は半分です。
削除後も、不正商品ページのURLをGooglebotやClaudeBotなどが大量に訪問してきました。
勝手に生成されたURLのリストが、インターネット上に残っていたためです。
見た目が正常になった瞬間と、被害が収束する瞬間には、大きな時間差がありました。
WEBサイト改ざんの原因はプラグイン？
今回、改ざんの侵入口を完全には特定できていません。
サーバー会社の調査では、不審なFTPアクセスは確認されませんでした。
そのため、考えられる経路は、主に次の二つです。
- 何らかの方法で盗まれたログイン情報による不正アクセス
- WordPressのプラグインやテーマなどの脆弱性を悪用された
管理画面の認証は二段階になっていますし、不正アクセスの痕跡は見つかりませんでした。
ですから私としては、使用していたプラグインのいずれかが侵入口になった可能性を疑っています。
一つ疑っているプラグインがありますが、決定的な証拠はなく、現時点では断定できないので書きません。（そのプラグインは削除しております）
WordPressだから危険ではないが・・・
ここで注意したいのは、「WordPressだから危険」と単純化しないことです。
WordPress本体、テーマ、プラグイン、サーバー、管理端末、パスワード。WEBサイトは複数の部品でできています。
一つでも脆弱性がある古い部品が残っていれば、そこが攻撃面になります。
ただし、数字を見ると弱点の偏りは明らかです。
WordPressのセキュリティ企業Patchstackの調査によると、2025年にWordPress関連で報告された脆弱性11,334件のうち、91%がプラグイン由来でした。
テーマ由来が9%で、WordPress本体（コア）由来はわずか6件です（出典：Patchstack「State of WordPress Security in 2026」）。
日本でも同じ傾向が確認できます。
IPAが公開している脆弱性対策情報データベースの2025年第2四半期レポートでは、アクセスランキングの上位3件がいずれもWordPress用プラグインの脆弱性でした（出典：IPA「JVN iPediaの登録状況 2025年第2四半期」）。
WordPressのプラグインが実際に継続して調査・警戒されていることが分かります。
WordPress公式のセキュリティ文書でも、信頼できない提供元からプラグインやテーマを入れないこと、定期的にバックアップを取得し、復旧計画を持つことを勧めています。
使っていないプラグインを「停止」にするだけでは、サーバー上にプログラムが残ります。
・今後使わないものは削除する。
・更新が止まったプラグインは代替品を探す。
・運営を終えたWordPressサイトは、放置せず閉鎖または静的化する。
この地味な整理が、派手なセキュリティ製品より先に必要です。
機械的に脆弱性を探していた
攻撃者が私や私のWEBサイトを狙っていたのかは分かりません。
ただし、アクセスログを見る限り、改ざん前の数時間で大量のアクセスがあり、機械的に既知のファイル名や脆弱性を探していました。
実際、こうした被害は急増しています。
JPCERT/CCへのWebサイト改ざんの報告は、2025年4〜6月期に231件と、前四半期の95件から143%増加しました（出典：JPCERT/CC 四半期レポート、2025年7月）。
自動スキャンにとっては、企業規模も知名度も関係ないのです。
穴があるサイトを自動で探しているのです。
WEBサイト乗っ取りの対処でChatGPTは何をしてくれたのか
ここまで読むと、「ChatGPTが不正ファイルを削除してくれた」と思うかもしれません。
そうではありません。
実際にサイトを復旧したのは、サーバーの復旧機能、セキュリティプラグイン、WAF等の設定変更、そして私自身の操作です。
ChatGPTが役立ったのは、散らばった情報を整理し、次の一手を判断する場面でした。
アクセスログの危険度を分ける
アクセスログには、毎日大量の通信が記録されます。
たとえば、次のようなステータスコードです。
| コード | 意味 | 見るべき点 |
|---|---|---|
| 200 | 正常に応答した | 怪しいPHPが200なら要注意 |
| 301・302 | 転送した | 最終的な転送先を確認 |
| 403 | アクセス拒否 | 防御が機能している可能性 |
| 404 | 対象が存在しない | 不正URLなら正常な応答 |
| 500 | サーバー内部エラー | 攻撃が処理系まで届いた可能性 |
何千行、何万行ものログを人間が目視すると、怪しいURLを見落とします。
ChatGPTにログを渡し、「怪しいPHPが200になっていないか」「500エラーは何件か」「改ざん由来URLは何を返しているか」と問いかけることで、確認する範囲を絞れました。
ただし、200が出たから即感染、404だから絶対安全という話ではありません。
URL、レスポンス容量、HTTPメソッド、User-Agent、時刻、前後のアクセスを組み合わせて判断します。
なお、ログには訪問者のIPアドレスなどが含まれます。
AIに渡す際は、必要な範囲に絞り、機密にあたる部分を伏せる配慮も忘れないでください。
ブロックルールを調整する
攻撃元IPを一つずつブロックしても、相手は別のIPからやってきます。
そこで、WAFを使い、IPだけでなくアクセス先のパターンをブロックしました。
たとえば、次のような通信です。
- 改ざん時に生成された不正URLのパターンへの大量アクセス
- 存在しないはずのPHPファイルを直接実行しようとするアクセス
- ログインページや設定ファイルを狙った機械的な連続アクセス
ただし、防御は強ければ強いほどよいわけではありません。
Googlebotを止めれば、不正URLが削除されたことをGoogleが確認できません。
セキュリティプラグインの同期通信を止めれば、セキュリティ機能に支障が出ます。
RSS取得Botを止めれば、外部サービスとの連携が切れます。
攻撃を止めながら、正規通信を通す。
ここが最も難しい部分でした。
ChatGPTの回答をそのまま採用しない
ChatGPTは、セキュリティソフトでもデジタルフォレンジック業者でもありません。
次のことは保証できません。
- 感染がすべて除去されたかどうかの断定
- 侵入経路の特定
- そのアクセスが正規のBotか攻撃Botかの正確な判定
- ブロックルールに副作用がないこと
- 個人情報の漏えいしていないこと
正規のGooglebotなど検索エンジンのbotを攻撃Botと誤認すれば、SEO復旧の邪魔になります。
そのため、私はChatGPTの回答を「正解」ではなく、「確認項目の候補」として扱いました。
ChatGPTは除菌剤ではありません。
ログと状況を整理し、判断を早める参謀です。
改ざん復旧の「5層モデル」
今回の経験を、再利用できる形に整理したのが「改ざん復旧の5層モデル」です。
一つのセキュリティ製品に頼るのではなく、検知から監視までを五つに分けます。
| 層 | やること | 私が実施したこと | 完了の目安 |
|---|---|---|---|
| 第1層：検知 | 異変を発見する | 検索順位、Search Console、ログを確認 | 改ざんの範囲が見える |
| 第2層：遮断 | 被害拡大を止める | パスワード変更、WAF、アクセス制限 | 不正通信が手前で止まる |
| 第3層：除去 | 不正ファイルを消す | サーバー復旧、コア交換、スキャン | 怪しいPHPが検出されない |
| 第4層：再認識 | 検索の信用を戻す | 不正URLを404・410にし再取得を促す | Googleが正常状態を認識する |
| 第5層：監視 | 再発を検知する | アクセスログ、WAF、更新状況を確認 | 怪しい200や500が出ない |
第1層：検知
最初に確認するのは、サイトの見た目だけではありません。
Googleで自分のドメインを「site:ドメイン名」の形で検索し、身に覚えのないタイトルがないかを見る。
Search Consoleのページ、構造化データ、セキュリティ関連レポートも確認します。
さらに、サーバー上で最近更新されたPHPファイルや、不自然なフォルダを探します。
第2層：遮断
復旧作業中も攻撃は続きます。
WordPress管理者、FTP、サーバー、データベースのパスワードを変更し、不要なアカウントを削除。
WAFで明確な攻撃パターンを止めます。
WAFは攻撃を遮断し、根本的な脆弱性を修正するまでの時間を確保する役割もあります。
ただし、WAFを入れただけで脆弱性そのものが消えるわけではありません。
第3層：除去
不正ファイルを見つけるたびに削除する方法では、取り残しが起こりやすくなります。
正常なバックアップやWordPress公式ファイルを基準にして、コアファイルを入れ直す。
テーマやプラグインも、信頼できる配布元のものへ置き換えます。
ログなどの証拠は、削除する前に保存しておきます。
警察庁は、改ざん被害を相談する場合、アクセスログなどの資料を持参するよう案内しています。
第4層：再認識
不正URLをすべてトップページへ転送してはいけません。
存在しないページは、HTTPステータスの404または410を返します。
画面に「見つかりません」と書いてあっても、実際のHTTPレスポンスが200なら、検索エンジンには存在するページとして扱われる可能性があります。
Googleも、削除済みで代替ページがないURLには、404または410を返すよう案内しています。
Search Consoleの削除ツールは、検索結果から一時的に隠す目的には使えます。
しかし、恒久的な処理には、ページ側で404・410・noindexなどを維持する必要があります。
第5層：監視
最後は、何も起きていないことを確認する作業です。
私が主に見ているのは次の三つです。
- アクセスログ（不正URLへのアクセスが何を返しているか）
- Search Console（不正ページのインデックスが減っているか、警告が出ていないか）
- ファイル変更の通知（セキュリティプラグインからの検知メール）
403や404が大量に記録されていると、不安になるかもしれません。
しかし、不正なアクセスに403や404を返しているなら、防御が機能している可能性があります。
見るべきはアクセス件数そのものではありません。
「何が、どこまで到達し、何を返したか」です。
よくある質問
- 改ざんされたらまずなにをするべきか？
-
まずサーバー会社に連絡し、状況を共有してください。
次にアクセスログや不審ファイルを削除せずに保全します。
その後、全パスワードの変更と脆弱性の修正に進みます。
慌てて証拠を消すと侵入経路が特定できず、再侵入を許す原因になります。
- WEBサイト改ざんの原因で最も多いのは何ですか？
-
WordPressなどのCMSのプラグインの脆弱性です。
Patchstackの調査では2025年にWordPress関連で報告された脆弱性11,334件のうち91%がプラグイン由来でした。
使っていないプラグインの削除と、更新が止まったプラグインの入れ替えが最も効果的な対策になります。
- WEBサイトの改ざんを無料で検知する方法はありますか？
-
あります。Googleで「site:自分のドメイン」と検索し、身に覚えのないページがないか確認する方法は警察庁も紹介しています。
加えてGoogle Search Consoleの通知を有効にし、ファイル変更を監視するセキュリティプラグインを併用すると検知の精度が上がります。
- 小さな個人サイトでも狙われますか？
-
狙われます。攻撃の多くは人間ではなく自動プログラムによるもので、規模や知名度に関係なく、脆弱性のあるサイトを機械的に探しています。
実際に当サイトも、改ざん前の数時間に機械的なスキャンを受けていました。
- ChatGPTだけでWEBサイトの改ざんに対処できますか？
-
ChatGPTはログ整理、怪しいURLの抽出、WAF条件の検討には役立ちます。
ただし、感染の完全除去や情報漏えいの有無は保証できません。
復旧機能、セキュリティ製品、専門家との併用が前提です。
まとめ
WEBサイト改ざんを100％防ぐ方法はありません。
情報セキュリティなど専門部署がある大手企業でも改ざんされるくらいですからね。
新しい脆弱性は今後も発見されます。
攻撃Botも止まりません。
攻撃する側のAIはどんどん賢くなっています。
だからこそ、「絶対に侵入させない」だけでなく、「侵入されても早く発見し、被害を小さくする」設計が必要です。
警察庁も、脆弱性情報を継続的に収集し、OSやソフトウェアを最新状態に保つよう案内しています。
一度対策しても、新たな脆弱性が発見される可能性があるためです
最低限、次を実施してください。
- WordPress本体、テーマ、プラグインを最新の状態に保つ
- 使っていないプラグインとテーマを削除する
- 管理画面とサーバーのパスワードを別々にする
- 管理画面のログインに二要素認証を設定する
- サーバー外にもバックアップを保存する
- Search Consoleを定期的に確認する
- セキュリティプラグインなどでファイル改変をスキャンする
- WAFを有効にする
- アクセスログを保存する
- 更新しないWordPressサイトを放置しない
ただし、決済情報、会員情報、問い合わせ情報などを保存しているサイトは、自力復旧だけで済ませない方が安全です。
個人情報漏えいの可能性がある、管理者権限を奪われた、何度削除しても再感染する、複数サイトが同時に書き換わった。
このようなケースでは、サーバー会社、セキュリティ専門会社、警察のサイバー犯罪相談窓口へ早めに相談してください。
今回、私が救われたのは、ChatGPTが何でも直してくれたからではありません。
分からないログを一つずつ読み、仮説を立て、サーバー会社や公式情報と照合しながら進められたからです。
WEBサイトは、作った日よりも、その後どう保守するかで安全性が決まります。
まずは3分だけ、自分のドメインをGoogleで検索してください。
見覚えのないページが一つもないか。
それが、今日できる最初の「WEBサイト 改ざん 検知」です。
にほんブログ村
