
WordPressサイトがハッキングされた時の難読化PHPコードの見つけ方と完全駆除手順
WordPressサイトのindex.phpなどのコアファイルに難読化された悪意あるPHPコードが埋め込まれ、不審なサイトへリダイレクトされる被害が発生した場合、感染ファイルの完全削除とコアファイルの再インストール、全認証情報の変更を同時に進める必要がある。
この種の改ざんは「goto文」や16進数エンコードした文字列、外部サーバーとの通信機能などを使って巧妙に隠されている。残骸を残さず駆除し、再侵入経路をすべて塞ぐ手順を具体的に追っていく。
なぜWordPressサイトに難読化された悪意あるコードが仕込まれるのか

攻撃者が難読化コードを埋め込む目的は大きく3つある。不正なリダイレクトによるアフィリエイト収益の横取り、サイト訪問者の個人情報やパスワードの窃取(フィッシング)、そしてサイト自体を踏み台にして別のサーバーを攻撃するスパム配信やDDoS攻撃の中継だ。
コードの難読化は、セキュリティプラグインや手動の目視検査をすり抜けるために施される。変数名や関数名をランダムな文字列にし、goto文で処理の流れを複雑に飛ばすことで、実際に何を実行しているのかを読み取りにくくしている。この手のコードは、単独のファイルに留まらず、複数のテーマファイルやアップロードディレクトリに分散して設置されることが多い。
- ● トップページが別ドメインにリダイレクトされる
- ● index.phpの先頭に見慣れない
goto文や16進数文字列のブロックがある - ● 管理画面が重くなり、プラグインの一覧に覚えのない項目が増えている
- ● サイトのURLが正しく表示され、意図しない転送が発生しない
- ● コアファイルが公式のチェックサムと完全一致する
- ● 管理者アカウントやプラグインに不審な追加がない
上記の例は、攻撃者が検索エンジンのボットを判別し、Googleなどのクローラーには元の正常なページを見せ、一般の訪問者だけに不正サイトへ飛ばす「クローキング」という手法の典型的な挙動を示している。
感染したWordPressサイトを手動で完全に駆除する手順

感染が疑われるファイルとディレクトリを優先して検査する
改ざんされたコードは、WordPressのルートディレクトリ直下のindex.phpやwp-config.phpだけでなく、テーマやプラグインのディレクトリ、アップロードディレクトリにも潜む。次の場所を重点的に確認する。
- ルートディレクトリの全
.phpファイル(index.php、wp-load.php、wp-settings.phpなど) /wp-content/themes/配下の全テーマ(特にアクティブなテーマのfunctions.php)/wp-content/plugins/配下の全プラグインファイル/wp-content/mu-plugins/(もし存在すれば)/wp-content/uploads/配下のPHPファイル(本来PHPファイルが存在すべきではないディレクトリ)/wp-includes/配下のコアファイルの改ざん有無(後述のチェックサム検証で判別可能).htaccessファイル(リダイレクトルールや不正なコードブロックが追記されていないか)
WordPressコアファイルの再インストールとチェックサム検証
wp-content ディレクトリと wp-config.php を除き、WordPressのコアファイルをすべて公式の配布ファイルで上書きするのは安全かつ最も確実な駆除方法だ。管理画面の「ダッシュボード」→「更新」から「再インストール」を実行するか、手動で行う場合は次の手順を踏む。
wp-content ディレクトリと wp-config.php をローカルにバックアップ(退避)するwp-admin と wp-includes を完全に削除し、展開した公式ファイルの同名ディレクトリをアップロード.php ファイル(wp-config.php を除く)を公式ファイルで上書きwp-content と wp-config.php をサーバーに戻し、wp-config.php に手動で追記された不正な行がないか目視確認wp-includes/version.php を確認し、バージョン番号が正しいか検証。その後、プラグイン「WordPress Core Verify」などでチェックサムを検証する管理画面にアクセスできるなら「ダッシュボード」→「更新」の「WordPressを再インストール」ボタンを押すだけで同等の処理が完了する。手動で行う場合も、wp-content と wp-config.php を保護している限り、データ消失の心配はない。
感染源を特定するためにサーバーログとタイムスタンプを照合する
どの脆弱性から侵入されたかを特定するには、改ざんされたファイルのタイムスタンプとサーバーのアクセスログ、エラーログを突き合わせる。ログに「POST /wp-admin/admin-ajax.php」や「POST /xmlrpc.php」への不自然な連続リクエストが記録されていれば、ブルートフォース攻撃やXML-RPCを経由した侵入が疑われる。
ホスティングのコントロールパネルから「Raw Access Logs」や「エラーログ」をダウンロードし、改ざん発生日時の前後を中心に調べる。プラグインやテーマのアップデートを長期間放置していた場合は、脆弱性情報データベース(CVE)で該当バージョンの既知の脆弱性を検索し、侵入経路の仮説を立てる。
適切なファイルパーミッションに設定し直す
ディレクトリは755、ファイルは644を基本とし、wp-config.phpだけは440または400に設定して読み取り権限を厳格にする。特にwp-content/uploads/ 配下にPHPファイルが置かれている場合は、そのディレクトリでPHPの実行を.htaccessで明示的に拒否しておくべきだ。
# .htaccess を wp-content/uploads/ に設置する場合
<FilesMatch "\.(php|php\.)$">
Require all denied
</FilesMatch>プラグインとテーマをクリーンな状態に置き換える
すべてのプラグインとテーマを、公式ディレクトリまたは購入元から再ダウンロードした完全に新しいファイルで上書きする。非公式サイトから入手したプラグインやテーマ、長期間更新が止まっているものは、この機会に削除するか代替に切り替える。
とくに mu-plugins ディレクトリは、手動で設置しない限り通常は存在しない。見慣れないディレクトリ名やPHPファイルがあれば、即座に削除する。
データベース内の不正なコードや管理者アカウントを検査する
phpMyAdminやWP-CLIを使って、wp_options テーブルの「siteurl」や「home」、wp_posts の投稿内容に不審なスクリプトタグやiframeが埋め込まれていないかを調べる。同時に、wp_users テーブルで身に覚えのない管理者アカウントが追加されていないかも必ず確認する。
データベース内の隠し管理者を一括で探すには、WP-CLIで次のコマンドを実行すると早い。
wp user list --role=administrator全認証情報を変更しセキュリティキーを再生成する
駆除作業が完了したら、WordPress管理画面の全ユーザーパスワード、データベースパスワード、SFTP/SSHパスワード、ホスティングのコントロールパネルパスワードをすべて変更する。wp-config.php の「AUTH_KEY」「SECURE_AUTH_KEY」などのセキュリティ用ソルトも、WordPress.orgの公式ソルト生成ツールで新しいものに置き換える。
よくある質問
クリーンなバックアップがない場合、復旧の優先順位はどう決めればよいか
バックアップが存在しない、またはバックアップ自体が感染後のものである場合は、コアファイルの再インストールとプラグイン・テーマの全置き換えを最優先する。データベースの修復はその後で、不正な投稿やユーザーを手動で削除する。サイトのダウンタイムを最小限にするため、メンテナンスモードを有効にして作業するのが安全だ。
無料のプラグインやテーマが感染の原因になることはあるか
公式ディレクトリで配布されている無料プラグインでも、深刻な脆弱性が発見されて更新が滞れば攻撃の糸口になりうる。とくに、公式ディレクトリ以外のサイトから配布されている「nulled(クラック)」版の商用プラグインやテーマは、ほぼ確実にバックドアが仕込まれているため、絶対に使用してはいけない。
データベースを直接編集する際の注意点は何か
phpMyAdminなどでデータベースを直接操作する場合は、必ず事前にデータベース全体のダンプ(エクスポート)を取っておく。wp_options テーブルの「active_plugins」行を誤って削除すると全プラグインが無効化されるため、行の値を直接編集するよりも、WP-CLIのwp optionコマンドを使うほうが安全に操作できる。
cronジョブに疑わしいタスクが仕込まれていないか調べる方法は
WordPressの疑似cron(WP-Cron)はwp_options テーブルの「cron」オプションに格納されている。WP-CLIでwp cron event listを実行すると登録されている全タスクを一覧できる。ホスティング側の本物のcronジョブ(crontab)に不正なエントリが追加されていないかも、ホスティングの管理画面またはSSHで確認する。
攻撃者に検索エンジンのボット判定をすり抜けられた場合の追加対策は
難読化コードがボット判定を行っている場合、駆除後もクローキング用のキャッシュがCDNや検索エンジンに残っている可能性がある。サイト駆除後にGoogleサーチコンソールで「URL検査」→「インデックス登録をリクエスト」を実行し、CDNの全キャッシュをパージする。HTTPヘッダーを改ざんされていないかも、curlコマンドなどで確認しておくべきだ。
この記事のポイント
- 難読化PHPコードは複数ファイルに分散して設置されるため、ルート直下、テーマ、プラグイン、アップロードディレクトリをすべて検査する
- WordPressコアファイルは
wp-contentとwp-config.phpを保護したうえで公式ファイルで完全に上書きする - 改ざんファイルのタイムスタンプとサーバーログを照合し、侵入経路を特定して永続的な対策を講じる
- 全認証情報の変更とソルトの再生成を駆除と同時に行い、再侵入を防ぐ
- クリーンなバックアップがある場合は、全ファイルとデータベースの削除後にバックアップから復元するのが最も確実な方法である

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
