WordPressが乗っ取られた実例｜原因調査から復旧までの全手順を解説

WordPressサイトが不正アクセスを受け、乗っ取られてしまうケースは決して珍しくありません。本記事では、実際に複数のWordPressサイトが同時に感染したインシデントを題材に、原因調査の方法から復旧手順、再発防止策までを具体的に解説します。

「WordPressが乗っ取られたかもしれない」「マルウェアに感染した形跡がある」という方の対応の参考になれば幸いです。

発覚のきっかけ・症状

今回のケースでは、運営中のサイトが表示されなくなったという相談から調査を開始しました。調査を進めると、被害はそのサイト単体にとどまらず、同一サーバーアカウント上で稼働していた複数のWordPressサイトに及んでいることが判明しました。

WordPressの乗っ取り・マルウェア感染でよく見られる症状には、次のようなものがあります。

• サイトが見知らぬページにリダイレクトされる
• 管理画面にログインできない、または見覚えのない管理者ユーザーが存在する
• Googleサーチコンソールから「不審なコンテンツ」の警告が届く
• ファイルの更新日時が、編集した覚えのないタイミングで変化している

これらの症状が一つでも見られる場合、すでに侵入を受けている可能性が高いと考えて調査を進めるべきです。

原因調査：侵入経路の特定

侵入経路

今回確認された侵入経路は、次のような流れでした。

1. 過去に運用を停止していた旧サイト（ファイルはサーバー上に残存、2段階認証は未導入）の wp-login.php から不正ログイン
2. 正規プラグインを偽装したファイルを設置し、Webシェル化
3. 同一サーバーアカウント内の他ドメインへ横展開

ポイントは、「使っていないサイト」がリスクの起点になっていたという点です。サーバー管理画面からは削除済みで表示されていなくても、サーバー上にファイルが残っていればログイン経路として悪用され得ます。停止したWordPressサイトは、ダッシュボードから見えなくするだけでなく、サーバー上のファイル自体を完全に削除しておく必要があります。

永続化されたマルウェアへの対応

不正ファイルを削除しても、しばらくすると同じファイルが復元される、という現象が発生しました。これは、ローカルのファイルパーミッションレベルを超えて動作するプロセス（デーモン）が、.htaccessやindex.phpを継続的に書き換えていたことが原因です。

このような永続化が疑われる場合、ファイル削除だけでは解決しません。サーバー提供事業者側でプロセスレベルの調査・停止を依頼する必要があります。今回もサーバー事業者への連携によって、ようやく不正な書き換えが止まりました。

データベースの調査方法

シンレンタルサーバー（wpX）のようなホスティング環境では、SQLエクスポートを行うと、全フィールドの値がhex形式（例：0x48656c6c6f...）でエンコードされることがあります。この状態では通常のgrep検索では不正コードを見つけられません。

そこで有効なのが、次の二段階アプローチです。

1. プレーンテキストの状態でgrepし、明らかな難読化パターン（eval、base64_decodeなど）を検索する
2. Pythonの正規表現で 0x[0-9a-fA-F]{16,} のパターンを抽出し、hexデコードした上で内容を再スキャンする

タイムスタンプの新しさだけで「怪しい／怪しくない」を判断するのは不十分です。今回のケースでもタイムスタンプ偽装（timestomping）が使われており、内容そのものを確認する工程が欠かせませんでした。

なお、今回はデータベース自体はクリーンで、感染経路はファイル層（uploadsフォルダ内に設置されたWebシェル）でした。データベースとファイルの両方を確認する体制が必要です。

復旧手順

1. サイトの初期化とクリーンインストール

中途半端なファイル削除では取りこぼしのリスクが残るため、ドメインを初期化し、WordPress本体を公式配布元から新規インストールする方針を取りました。

2. データベースのクリーニングとインポート

先述のhex二段階スキャンで不正コードの混入がないことを確認したうえで、既存のデータベースをインポートします。

ここで重要なのが作業の順序です。データベースのインポートより先に管理者パスワードを変更してしまうと、インポート時に古いパスワード情報で上書きされてしまいます。必ず「DBインポート → パスワード変更」の順で行ってください。

3. プラグイン・テーマの扱い

バックアップに含まれていたプラグインファイルは一切再利用しませんでした。バックアップデータ自体に寄生的な感染が及んでいる可能性があるためです。プラグインはすべてWordPress公式ディレクトリから個別に新規取得しました。

4. 誤検知の見分け方

マルウェアスキャナーは、正規のセキュリティ設定を「不審なコード」として検出することがあります。今回も80件を超える検出がありましたが、精査の結果、大半がuploadsディレクトリのPHP実行を禁止する.htaccess（正規のハードニング設定）でした。

判別のポイントは次の通りです。

• FilesMatchブロックが単独で存在するだけなら、正規のハードニング設定である可能性が高い
• 悪性の場合は、特定のバックドアファイル名に対して Allow from all の例外を許可する、第二のFilesMatchブロックが併存している

検出件数の多さに惑わされず、一件ごとに中身を確認する姿勢が重要です。

再発防止策

復旧作業と並行して、以下の対策を実施しました。

• 全パスワードの変更、2段階認証の導入
• Wordfenceなどによるブルートフォース攻撃対策
• 過去に作成された臨時の管理者アカウントの削除
• Google Search Console側の設定不備の修正

なお、運用環境によっては、IPアドレスによるアクセス制限も有効な手段ですが、今回は2段階認証とログイン試行回数の制限を軸にした対策を取りました。

まとめ

WordPressの乗っ取り被害は、表面的なファイル削除だけでは再発を防げません。今回のケースのように、

• 停止済みサイトの完全なファイル削除
• データベース内容までの精査
• 永続化プロセスへの対応
• 復旧後のアカウント・認証まわりの見直し

といった、多層的な対応が必要になります。

自力での調査・復旧に不安がある場合は、専門家に依頼することも選択肢の一つです。

そうなってしまう前にWordpressのセキュリティー確認とサーバーに古いWordpressデータが残っていないかを確認しておくことが予防の１つの手段になります。

この記事が健全なサイト運用の一助になれば幸いです。