WordPressが突然改ざんされ、検索結果に見覚えのない日本語ページが表示されたり、管理画面に入れなくなったりする相談は本当に多いです。
私が現場で対応してきた中でも、「気づいた時にはかなり進行していた」というケースが目立ちます。
ある案件では、最初は表示崩れだと思われていましたが、調査するとコアファイルに不正コードが埋め込まれていました。
私はその時、まず見た目の復旧よりも侵入経路の特定を優先する判断をしました。
結果として再発を防げましたが、今振り返ると、初動の優先順位を誤れば長期化していた可能性が高いと感じています。
この記事では、私が実務で行っている確認手順と復旧方法を、一次情報の確認ポイントとあわせて具体的に解説します。
最初にやるべき被害状況の整理と証拠保全
経験者として最初に強調したいのは、すぐに削除や上書きをせず、現状を記録することが重要だという点です。
事実として、ハッキング直後の状態には侵入経路を特定する手がかりが多く残っています。
一次情報として確認するのは、サーバーのアクセスログ、エラーログ、最終更新日時が不自然なファイルです。
例えばログには次のような痕跡が残ることがあります。
/wp-login.php への短時間大量アクセス
xmlrpc.php への連続POST
存在しないURLへのスキャン痕跡
私は以前、早く復旧させたい気持ちから先にファイルを上書きしようと考えたことがありました。
その時は「まず表示を戻す方が安心だろう」と判断しました。しかし証拠が消えると侵入口の特定が難しくなると気づき、作業を止めてログ保存を優先しました。
今振り返ると、この判断変更が再発防止につながったと感じています。
改ざんファイルの特定と安全な確認方法
経験上、ハッカーは目立つファイルよりも見落とされやすい場所にコードを仕込みます。
事実として多いのは、wp-content/uploads 内に設置されたPHPファイルや、テーマファイル末尾への追記です。
一次情報として有効なのは、公式WordPressの配布ファイルとの比較です。
改ざん確認では、サーバー上のwp-adminやwp-includesと公式パッケージの差分を確認します。
また、次のような記述は典型的な不正コードの特徴です。
eval(base64_decode(
gzinflate(base64_decode(
preg_replace(“/.*/e”
私は以前、functions.phpだけを確認して安心しかけたことがあります。
その時は「テーマが無事なら深刻ではない」と判断しました。
しかしuploads配下に複数のバックドアがあることに後から気づきました。
今振り返ると、確認範囲を限定したのが甘かったと思います。
現在はディレクトリ全体を対象に不審なPHPファイルを抽出する方法を標準にしています。
安全な復旧のための正しい初期化手順
経験者の立場から言えるのは、部分修正ではなくクリーンな再構築が最も安全だということです。
事実として、感染ファイルが残ったままの上書き更新では再発するケースが多いです。
一次情報として信頼できるのは、WordPress公式サイトから取得した最新のコアファイルです。
私が実務で行う復旧手順は次の流れです。
- 現状サイトの完全バックアップ取得
- wp-admin と wp-includes を公式版で上書き
- ルート直下の不審なPHPファイル削除
- テーマとプラグインを公式配布元から再インストール
- wp-config.php の不審コード確認
私は以前、急ぎの案件で「怪しいファイルだけ削除」する方法を選びかけました。
その時は時間短縮を優先する判断でした。
しかし内部に潜伏コードが残るリスクを考え、手順をやり直しました。
今振り返ると、復旧の速さより安全性を優先すべきだと改めて感じています。
データベース改ざんの確認と修正ポイント
経験上、ファイルがきれいになってもデータベースに被害が残っていることがあります。
事実として多いのは、管理者ユーザーの不正追加や、投稿データへのスパムリンク埋め込みです。
一次情報として確認するのは、wp_users テーブルの権限、wp_options の siteurl や home の値です。
また、option_value 内に不審なスクリプトが入るケースもあります。
私は以前、ファイル復旧で安心し、DB確認を後回しにしかけたことがあります。
その時は「見た目が戻ったから問題ない」と判断しかけました。
しかし検索結果汚染の事例を思い出し、全テーブル確認に切り替えました。
今振り返ると、この慎重さが被害の長期化を防いだと感じています。
再発防止のために必ず行うセキュリティ強化策
経験者として強く感じているのは、復旧よりも再発防止の設計のほうが重要だということです。
事実として、同じサイトが複数回侵入されるケースは珍しくありません。
一次情報として信頼できるのは、WordPress公式が推奨しているセキュリティ対策や、プラグイン開発元の注意喚起です。
私が復旧後に必ず実施する対策は次の通りです。
- すべてのパスワード変更（WP・サーバー・DB）
- 不要なプラグインとテーマの削除
- ファイル編集機能の無効化
- ログイン試行回数制限の導入
- WAFやセキュリティプラグインの設定見直し
私は以前、復旧が完了したことで安心し、パスワード変更を後回しにしそうになりました。
その時は「侵入口は塞いだから大丈夫だろう」と判断しかけました。
しかし資格情報流出の可能性を考え直し、全アカウントの再設定を優先しました。
今振り返ると、ここを徹底するかどうかが再発率を大きく左右すると感じています。
ログから侵入経路を推測する具体的な見方
経験上、再発防止には「どこから入られたか」を推測する作業が欠かせません。
事実として、ログには攻撃パターンが時系列で残っています。
一次情報として有効なのは、アクセスログのIP・URL・ステータスコードの組み合わせです。
注目すべきポイントは以下です。
- wp-login.php への大量アクセスIP
- xmlrpc.php への連続POST
- /wp-content/uploads/*.php への直接アクセス
- 深夜帯の不自然な管理画面アクセス
私は以前、IPアドレスの確認を簡易的に済ませたことがありました。
その時は「海外IPだからブロックすれば十分だろう」と判断しました。
しかし実際は正規ユーザーの漏洩パスワードが原因でした。
今振り返ると、IPだけでなく認証履歴まで見るべきだったと学びました。
検索結果汚染とブラックリストの確認方法
経験上、サイトが復旧しても検索エンジン側の評価が戻っていないケースがあります。
事実として、マルウェア感染後はGoogleに危険サイトとして登録されることがあります。
一次情報として確認すべきは、Google Search Console のセキュリティの問題レポートです。
また「site:ドメイン名」で検索し、不審な日本語ページやカジノページが出ないか確認します。
私は以前、サーバー復旧だけで作業完了と判断しかけました。
その時は「表示が戻ったから大丈夫だろう」と考えていました。
しかし検索結果に不正ページが残っているのを見て、対応の甘さに気づきました。
今振り返ると、外部評価の確認までが復旧作業だと強く感じています。
よくある質問（FAQ）
Q. 管理画面に入れない場合はどうすればいいですか？
経験上、FTPやサーバーパネルから直接対応することになります。
事実として、管理画面に依存せずともファイルの上書きや削除は可能です。
一次情報として、公式WordPressのコアファイルを再アップロードする方法が有効です。
私は以前、ログイン復旧を優先しようとして時間を使いすぎたことがあります。
その時は「まず入れるようにしないと進めない」と判断しました。
しかしファイル側からの復旧の方が早いと気づき、手順を切り替えました。
今振り返ると、管理画面に固執しない判断が重要だと感じています。
Q. セキュリティプラグインだけで防げますか？
経験上、プラグインは補助であり、万能ではありません。
事実として、古いテーマや放置プラグインが侵入口になるケースが多いです。
一次情報として、脆弱性情報はJVN iPediaやWPScanなどで確認できます。
私は以前、プラグイン導入だけで安心しかけたことがあります。
その時は「これで守られているだろう」と判断しました。
しかしアップデート未実施のテーマが原因だったことがありました。
今振り返ると、運用管理こそが最大の防御だと感じています。
まとめ：安全な復旧と再発防止の判断軸
私が多くの復旧対応をしてきた中で感じている判断の軸は、「早さ」より「正確さ」を優先することです。
事実として、焦って作業すると証拠消失や見落としが発生します。
注意点は、見た目が直っても内部が安全とは限らないことです。
次に取るべき行動は、ログ保存、完全初期化、全パスワード変更、外部評価の確認までを一連の流れで実施することです。
私は以前、表示が戻った時点で安心しかけたことがありました。
その時は「もう大丈夫だろう」と判断しかけましたが、検索汚染が残っていました。何を見落としていたかというと、外部から見たサイト評価でした。
その経験以降、私は必ず検索結果とセキュリティレポートを確認するようにしています。
今振り返ると、復旧とは「元に戻すこと」ではなく「安全な状態を再構築すること」だと強く感じています。
WordPressのハッキング修復はWPプロサポに
WP.復旧センターは「ハッキングされた」「表示がおかしい」「ログインできない」などのWordPressのトラブルをスピーディに修復します。
この記事を書いた人
Sho Suzuki
フロントエンドエンジニア / SEOプロフェッショナル
建築系の大学卒業後、芸術系の大学院を修了。その後、デジタルマーケティングを専門で行う企業にて約6年間フロントエンドエンジニアとして活躍する。同時期に、SEO対策に興味を持ち専門資格を多数取得する。
現在は、テクニカル記事の専属ライターとして多方面で活動中。
