「サイトが改ざんされているかもしれない」と気づいた瞬間は、慌てて操作を重ねやすい。しかし順番を誤ると、原因を調べる手がかりが消えたり、同じ入口から再び入られたりする。この記事では、WordPress サイトで侵害が疑われたときの初動を、隔離 → 証跡の保全 → クリーンなバックアップからの復旧 → 認証情報の入れ替えの順に整理する。特定の攻撃手順には触れず、落ち着いて進めるための考え方に絞る。環境や状況によって最適な手順は変わるため、迷うときはホスティング事業者や専門家への相談を前提に読んでほしい。
最初に決めておく：慌てて消さない
疑わしいファイルを見つけると、すぐ削除したくなる。気持ちは自然だが、消す前に「何が起きたか」を残すことが先になる。削除してしまうと、いつ・どこから入られたかを後から調べられなくなり、復旧後も同じ穴が残る可能性がある。
また、「ひとつ見つけて消したから終わり」とも言い切れない。見つかったものは一部で、他にも置かれている場合がある。だから初動は、被害を広げない → 記録を残す → きれいな状態へ戻す → 入口を閉じ直す、という順で考える。
1. 隔離する：被害を広げない
最初の目的は、訪問者や他のサイトへ影響を広げないことだ。
- 公開を一時的に止める: メンテナンス表示にする、アクセスを制限する、など。方法はサーバーの管理画面や事業者の案内に従う
- 同じサーバーに他のサイトがある場合は、そちらにも影響がないか確認する。同じアカウントを共有していると、片方の侵害がもう一方に及ぶことがある
- 事業者に連絡する: レンタルサーバーなら、状況を伝えると事業者側で見える情報（ログや遮断の状況）を教えてもらえることがある
この段階では、まだファイルの削除や上書きをしない。
2. 証跡を保全する：消す前に残す
原因調査と再発防止のために、現状をそのまま保存する。
- サイト全体のコピーを取る: ファイルとデータベースを、変更を加える前の状態でダウンロードして別の場所に保管する。復旧用のバックアップとは別物として扱う
- アクセスログ・エラーログを取得する: ログは一定期間で古いものが消える（ローテーション）ため、早めに取る。見方はアクセスログの読み方の記事を参照
- 気づいた経緯をメモする: 何を見て、いつ気づいたか。画面の記録も有効
確認作業は読み取りだけで進められる。たとえば WP-CLI では、WordPress 本体のファイルがチェックサムと一致しているかを調べられる。
wp core verify-checksums
wp user list --role=administrator
これらは変更を加えずに状況を見るためのコマンドだ。点検の考え方は侵害されていないかを確かめる3つの点検にまとめている。ただし、結果が正常でも侵害がないことの証明にはならない。見つかった項目は手がかりのひとつとして扱う。
3. クリーンなバックアップから復旧する
一般に、疑わしいファイルを一つずつ手作業で取り除くより、侵害される前の状態と分かっているバックアップへ戻すほうが、取りこぼしのリスクを下げやすい。ここで重要なのは次の点だ。
- 「いつの時点のバックアップが安全か」を判断する: 侵害の時期が分からなければ、複数の世代を比べる。最新のバックアップに入り込んだものが含まれている可能性がある
- 復旧先を新しい環境にする選択肢: 可能なら、既存の環境を上書きせず、新しい領域に復旧して検証してから切り替えると、証跡も残せる
- WordPress 本体・プラグイン・テーマは公式の配布元から入れ直す: 復旧後に最新版へ更新し、使っていないものは削除する
- バックアップが「取れた」だけでなく「戻せる」ことが前提: 復元できるバックアップの取り方はmysqldump と整合性のあるバックアップの記事で扱った。復旧が必要になってから初めて試すのは避けたい
バックアップがない、または信頼できる世代がない場合は、独力で進めず、事業者や専門家への相談を優先したい。
4. 認証情報を入れ替える：入口を閉じ直す
きれいな状態に戻しても、盗まれた認証情報が残っていれば、同じ人が再び入れる。復旧後に、関わりうるものを入れ替える。
- WordPress の管理者パスワード: 全管理者アカウントについて変更する。見覚えのない管理者アカウントがあれば、調査のうえ扱いを決める
- データベースのパスワード: 変更後は
wp-config.phpの設定も合わせる - SSH 鍵・FTP/SFTP のパスワード・サーバー管理画面のパスワード: 流出の可能性があるものは更新する。古い鍵は無効にする
- ソルト（認証用の秘密鍵）:
wp config shuffle-saltsでwp-config.phpのソルトを再生成できる。実行すると既存のログインセッションがすべて無効になるため、全員が再ログインになる。意図した動作として行う - 外部サービスの API キーなど: サイトに保存していたものがあれば、提供元で再発行する
入れ替えは、きれいな環境に戻してから行う。侵害が残ったまま変更すると、新しい認証情報もまた読み取られてしまう。
5. 再発防止と、公開再開の判断
復旧後は、入口になりえた部分を見直す。更新が止まっていたプラグイン、放置していた管理者アカウント、不要なプラグインやテーマ、ファイル権限などだ。点検の観点は攻撃面を狭めるチェックリストも参考になる。
公開を再開したあとも、しばらくはログと管理者アカウント、ファイルの変更を普段より注意して見る。再開の時期は、原因の見当がついているか、入口を閉じ直せたかで判断する。
限界と、知っておきたいこと
- 手順どおりに進めても、原因が特定できないことがある。その場合は、可能性のある入口を広めに閉じる運用になる
- 個人情報を扱うサイトでは、状況によって関係者や監督機関への連絡が必要になる場合がある。社内の担当者や専門家に相談する
- 侵害の有無や範囲の判定は、ツールだけでは断定できない。「問題が見つからなかった」ことは安全の保証ではない
まとめ
- 慌てて消さず、隔離 → 証跡の保全 → クリーンな状態への復旧 → 認証情報の入れ替えの順で進める
- 復旧は「戻せる」バックアップがあってこそ。日ごろのバックアップの検証が初動の質を左右する
- 認証情報の入れ替えは、きれいな環境に戻してから行う
- 迷うときは、事業者や専門家に相談する
初動の手順は、事が起きてから考えると判断を誤りやすい。落ち着いているときに一度書き出しておくと、いざというときの助けになる。