改ざんが確認できたら、次は復旧です。ただし手順を間違えると、復旧したつもりでも数日で再発します。実際、復旧のご相談のうち一定数は「一度自分で戻したが、また同じ状態になった」というものです。この記事では、正しい順序と、自力対応と業者依頼を分ける判断基準を整理します。
この記事でわかること
- 復旧作業の正しい順序（いきなりバックアップに戻してはいけない理由）
- 侵入経路を特定する具体的な方法
- ファイル・データベースそれぞれの除去手順
- 再発を防ぐために必ず変えるべき認証情報
- 業者に依頼した方がよいケースの判断基準
目次
- 復旧の全体像と正しい順序
- 手順1：現状を保全する
- 手順2：侵入経路を特定する
- 手順3：不正コードを除去する
- 手順4：認証情報をすべて変更する
- 手順5：穴を塞いで再発を防ぐ
- バックアップから戻すだけで済むのか
- 業者に依頼した方がよいケース
- まとめ
復旧の全体像と正しい順序
正しい順序は次のとおりです。多くの方が最初にやってしまう「きれいなバックアップに戻す」は、実は最後の方の工程です。
- 現状の保全（改ざんされた状態のままバックアップを取る）
- 公開停止またはメンテナンスモードへの切り替え
- 侵入経路の特定
- 不正ファイル・不正コードの除去
- パスワードと認証情報の全変更
- 穴を塞ぐ（更新・設定変更）
- 再発監視
順序が重要な理由は単純で、3番の侵入経路の特定を飛ばすと、6番で塞ぐべき穴が分からないからです。塞がないまま復旧すれば、同じ手口で再び入られます。
手順1：現状を保全する
改ざんされたファイルは、原因を突き止めるための証拠です。消してしまうと侵入経路が永久に分からなくなります。
確保すべきものは次の3点です。
- ファイル一式（改ざんされた状態のまま）
- データベースのダンプ
- サーバーのアクセスログ（最低でも過去1か月分）
特に3番目は急いでください。ログの保存期間は数週間程度のサーバーが大半で、後から取得することはできません。「まずログを保存する」を最初の作業にしてください。
また、取引先や顧客への説明が必要になる場合、この記録の有無が説明の質を大きく左右します。個人情報を扱うサイトでは、後の報告義務にも関わります。
手順2：侵入経路を特定する
WordPress の改ざんで多い侵入経路は、次の4つです。
プラグイン・テーマの脆弱性
最も多い経路です。更新を止めていたもの、開発が終了して長期間更新されていないものが狙われます。停止中のプラグインもファイルが残っていれば対象になります。
管理画面へのパスワード総当たり
ログインURLが標準のままで、パスワードが単純な場合に成立します。ログに wp-login.php への大量のPOSTリクエストが記録されていれば、この経路が疑われます。
FTP・サーバー管理画面の認証情報の流出
制作会社や社内のPCがウイルスに感染し、保存されていたFTPパスワードが盗まれるケースです。WordPress 自体に問題がなくても侵入されます。この場合、サイト側をいくら直しても、認証情報を変えなければ再発します。
同一サーバー内の別サイトからの横移動
1つのサーバー契約で複数サイトを運用している場合、別のサイトが侵害され、そこから移動してくることがあります。「このサイトには心当たりがないのに改ざんされた」という場合、この経路を疑ってください。
ログの読み方
不正ファイルが作られた日時が分かれば、その前後のアクセスログに注目します。手がかりになるのは次の点です。
- 同一IPアドレスからの
POSTリクエストの集中 - 見慣れないパスへのアクセスが成功（ステータス200）している記録
- 通常アクセスのない時間帯の集中的なリクエスト
手順3：不正コードを除去する
本体・プラグイン・テーマは「入れ替える」
WordPress 本体とプラグイン・テーマは、公式の同バージョンで上書きではなく入れ替えてください。上書きでは、公式に存在しない追加ファイル（バックドア）が残ってしまいます。いったん削除してから、公式のものを設置し直すのが確実です。
個別に確認すべき場所
入れ替えでは対処できない箇所を、個別に確認します。
wp-content/uploads内の.phpファイル（正常なら存在しません）wp-config.phpの冒頭・末尾に追記されたコード.htaccessのリダイレクト記述mu-pluginsフォルダ（通常は使われないことが多く、置かれていれば要確認）
データベース内の除去
最も見落とされやすい箇所です。ファイルだけをきれいにしても、記事本文に埋め込まれたスクリプトが残っていれば改ざんは続きます。
確認すべきは、投稿本文、オプション設定、ウィジェットの3箇所です。記事本文のテーブルを script や iframe といった文字列で検索し、該当箇所を1件ずつ確認してください。
手順4：認証情報をすべて変更する
不正コードを除去しても、認証情報が盗まれていれば再侵入されます。次をすべて変更してください。
- WordPress の管理者パスワード（全アカウント）
- FTP／SFTP のパスワード
- データベースのパスワード（
wp-config.phpの書き換えも必要） - サーバー管理画面のパスワード
あわせて、wp-config.php の認証キー（SALT）を再生成してください。これを変えないと、盗まれたログインセッションが有効なままになります。公式サイトで新しいキーを生成し、該当箇所を差し替えます。
手順5：穴を塞いで再発を防ぐ
特定した侵入経路に応じて対処します。
- プラグインの脆弱性だった場合 → 最新版へ更新。開発が止まっているものは代替へ乗り換え
- パスワード総当たりだった場合 → ログインURLの変更、試行回数の制限、IP制限
- 認証情報の流出だった場合 → 変更に加え、流出元のPCのウイルスチェック
- 別サイトからの横移動だった場合 → 同一サーバー内の全サイトを点検
復旧後は、しばらく監視期間を設けてください。ファイルの改ざん検知を有効にし、数週間は再発がないかを確認します。
バックアップから戻すだけで済むのか
「改ざん前のバックアップに戻せば終わり」と考えがちですが、これが有効なのは侵入経路がすでに塞がっている場合だけです。
脆弱性が残ったまま戻せば、同じ手口で再び侵入されます。しかも、改ざんに気づくまで時間がかかっていた場合、「戻した先のバックアップにも、すでにバックドアが仕込まれている」ということが起こります。
バックアップから戻す場合は、次を確認してください。
- 戻す先の世代が、確実に侵害前のものか（改ざんの開始時期が特定できているか）
- 戻したあと、すぐに本体・プラグインを最新へ更新できるか
- 認証情報の変更を同時に行えるか
業者に依頼した方がよいケース
- 侵入経路が特定できない、ログが残っていない
- 復旧後に再発した
- ECサイトや会員サイトで、個人情報の流出が疑われる
- Google 広告や Search Console で警告が出ており、早期の解除が必要
- 同一サーバー内の複数サイトに影響が及んでいる
- 侵害前のバックアップが残っていない
最後の項目は特に難易度が上がります。戻す先がない状態からの復旧は、不正コードを1つずつ取り除く作業になり、取りこぼしのリスクが高くなります。
まとめ
- 復旧は保全 → 経路特定 → 除去 → 認証情報変更 → 穴を塞ぐの順で行う
- ログは数週間で消える。最初に保存する
- 本体・プラグインは上書きではなく入れ替える
- データベース内の不正コードを忘れない
- 認証キー（SALT）の再生成まで行う
WordPressレスキューでは、調査・除去・再発防止・Google への再審査申請までを一括で対応しています。復旧作業と並行して、何が原因だったかを報告書としてお渡ししています。まずは現状をお聞かせください。
