WordPressで突然リダイレクト？実際の感染事例から学ぶクローキング型マルウェアの探索・復旧手順

WordPressサイトを運営していると、ある日突然以下のような不可解な症状に遭遇することがあります。

• トップページを開くと、身に覚えのない海外サイトや不審なWebサイトへ飛ばされる
• Google等の検索結果からアクセスすると普通に表示されるのに、自分のブラウザで直打ちすると別サイトへリダイレクトされる
• 管理画面（/wp-admin/）は正常に開くのに、公開ページだけが不具合を起こす
• 悪意のあるファイルを削除したはずなのに、時間が経つとまた復活する

今回解説するのは、まさにこのような「通常の確認箇所を調べても原因が見つからない」というクローキング型リダイレクトマルウェアの実際の発症事例です。

詳細な調査の結果、MU-Plugins（Must-Use Plugins）を悪用したクローキング型リダイレクトと、index.php を常時監視・自動復元する「永続化（Persistence）」の仕組みが組み込まれていたことが判明しました。

この記事では、実際の障害調査・復旧手順を時系列で追いながら、以下のポイントを分かりやすく解説します。

1. どこを、なぜ調べるのか（障害切り分けの思考プロセス）
2. 不審ファイルと正常ファイルの判別方法
3. 悪用されていたMU-Pluginとクローキングの仕組み
4. マルウェアの永続化（再発）を防ぐ対処手順

この記事は、実際私が遭遇した経験を元に記述しています。あなたのサイトで同様の症状が発生した際、迅速に原因を特定するための実践的なガイドとしてご活用ください。

今回の症状と発生の流れ（時系列）

対象となったサイト（※ここでは仮に [https://example.com/](https://example.com/) とします）では、以下のような流れで段階的に障害が発生・進行しました。

1. Webサイトの白画面化（画面が真っ白になりアクセス不可）
2. wp-login.php の消失を確認
3. WordPressコアファイルの再配置・復旧を実施（一度サイトが表示される状態へ回復）
4. トップページのみ外部サイトへリダイレクトされる二次障害が発生
5. 一般的な設定箇所の確認を実施
   • 管理画面のURL設定：正常
   • .htaccess：不審なリダイレクト記述なし
   • wp-config.php：不正コードなし
   • データベース（wp_options テーブル）：外部URL等の書き換えなし
6. wp-content/mu-plugins（MU-Plugin）の内部探索を実施
7. 隠蔽されたクローキングおよび外部リダイレクト処理を発見・無効化

一般的な調査手順で見落とされやすい場所に潜んでいたことが、本件の解決を難しくしていた要因です。

マルウェア調査の基本順序（初心者向けルート）

WordPressで不審なリダイレクトが発生した場合、まずは影響範囲の狭い場所・設定情報から順に確認していくのが鉄則です。

順序	確認対象	主な確認内容・目的
1	基本設定	「設定」→「一般」のWordPressアドレス / サイトアドレスに不正なURLが入っていないか
2	.htaccess	RewriteRule 等による不正な外部転送記述がないか
3	wp-config.php	定義値（WP_HOME / WP_SITEURL など）やコード冒頭に不正なPHP処理がないか
4	データベース	wp_options テーブル内の siteurl / home の値の確認
5	テーマ・プラグイン	有効化しているテーマ（functions.php 等）や通常のプラグイン（wp-content/plugins）の検証
6	MU-Plugin	wp-content/mu-plugins/ ディレクトリ内の不審ファイルの有無
7	コアファイル	ルートディレクトリの index.php や wp-load.php 等の改ざんチェック
8	キャッシュ	サーバー側・プラグイン側のキャッシュ構造の確認

今回の事例では、1〜5の一般的な調査では異常が検出されず、6のMU-Plugin内で初めて不正なコードが特定されました。

なぜ攻撃者は「MU-Plugin」を悪用するのか？

MU-Plugin（Must-Use Plugins）とは、WordPressの仕様として「常に自動で有効化される拡張機能」を格納するディレクトリ（wp-content/mu-plugins/）です。

通常のプラグインとは異なり、以下の特徴を持ちます。

• 管理画面から無効化できない（プラグイン一覧の「必須」タブに表示されるのみ）
• WordPress起動時の初期段階（コア処理の直後）に強制実行される
• セキュリティプラグインの防御をすり抜けやすい

セキュリティ監視の目を盗みつつ、サイト全体の挙動を強力に制御できるため、近年攻撃者に非常によく悪用される領域となっています。

MU-Pluginから発見された不審ファイルの分析

今回の事例では、wp-content/mu-plugins/ 内に以下のファイル群が存在していました。

• 00-ms-jp-guard.php
• 00-ms-jp-kill.php
• ms-index-heal.php
• ms-vitrin-gate.php
• ms-early-router.php

このうち、実害（外部転送および検索エンジンの騙し）を引き起こしていた主要ファイルについて解説します。

1. ms-vitrin-gate.php（動的リダイレクト指示ファイル）

トップページへのアクセスを検知した際、外部サーバーから動的に転送先URLを取得・蓄積するファイルです。

1. 外部通信によるリダイレクト先の取得
   外部の指定URL（例: https://[不審な外部ドメイン]/ist.txt など）へ通信を行い、転送先設定データをダウンロードします。
2. ローカルキャッシュファイルへの書き込み
   取得した転送先情報をサイト内の ist-dest.txt というテキストファイルへ保存します。（※実際に確認されたファイル内には不審な転送先URLが記録されていました）
3. 条件合致による転送実行
   ist-dest.txt を削除した瞬間、リダイレクト動作が即座に停止したことから、本ファイルが参照元として機能していたことが確認されました。

[外部サーバー (ist.txt)] ──(通信)──> [サイト内 (ist-dest.txt)] ──> [訪問者を不審サイトへ転送]

2. ms-early-router.php（クローキング処理ファイル）

アクセスしてきたユーザーの User-Agent（ブラウザやロボットの識別情報）を判定するファイルです。

判定対象には以下のBotが含まれていました。

• Googlebot / Googlebot-Image / Googlebot-Mobile
• AdsBot-Google
• bingbot / BingPreview

【Botと判定された場合の挙動】

検索エンジンのクローラーに対しては、偽装された安全なレスポンス（license.html の読み込みや独自のレスポンスヘッダー X-Medusa-Early: 1 の付与）を返していました。

これにより、「検索エンジンの巡回時には正常なサイトに見せかけ、一般の人間が訪問した時だけ別サイトへリダイレクトさせる」というクローキング（SEOスパム）を成立させていました。

【重要】「ms-」で始まるファイルを安易に全削除してはいけない理由

今回の事例で非常に重要な注意点があります。

WordPressには、公式のマルチサイト機能用コアファイルとして「ms-」で始まる正常なファイルが多数存在します。

• ms-site.php
• ms-load.php
• ms-functions.php
• ms-default-constants.php

「ms- から始まるから怪しい」「不審な名称に見える」という理由だけで一括削除してしまうと、WordPressのコア構造が破壊され、サイトが完全に停止する危険があります。

正常ファイルと不審ファイルの判別基準

• 公式コアチェック: 公式のWordPressインストーラに含まれるファイルと同名・同一ハッシュか確認する
• 外部通信処理: ファイル内に不審なドメインへの curl_exec や file_get_contents が含まれていないか
• 難読化: 解読不可能な文字列や eval(base64_decode(...)) などの難読化関数が使われていないか
• 自己復元処理: ルートの index.php などを監視・上書きする記述がないか

マルウェア探索時に警戒すべきキーワード・関数

調査の際、ファイル検索で以下の関数・記述が含まれている場合は精査が必要です。

• eval(
• base64_decode(
• gzinflate(
• assert(
• file_put_contents(
• curl_exec(
• header('Location:
• wp_redirect(

注意: などの関数自体は、正常なプラグインやテーマでもシステム処理のために使用されます。「該当関数が存在する＝100%マルウェア」と断定せず、前後の処理文脈を確認することが重要です。

今回の感染事例で浮き彫りになった「永続化」の恐怖

今回のMU-Plugin群の中に存在した以下のファイルは、マルウェアを「消しても消しても復活させる」ための永続化（Persistence）メカニズムとして機能していました。

• 00-ms-jp-guard.php
• 00-ms-jp-kill.php
• ms-index-heal.php

これらは、ルートディレクトリの index.php や重要なコア構造を常時監視し、管理者が該当箇所を修正したり削除したりしても、バックアップデータから即座に不正コードを再生成（復元）する仕組みを持っていました。

単体の不審ファイルを消すだけでは意味がなく、監視・復元を行っている「親」の仕組みごと一括して特定・排除する必要がありました。

実際に実施した復旧・調査のロードマップ

今回のトラブル解決にあたり、実際に行ったステップは以下の通りです。

[ステップ1: コア復旧]
・WordPressコアファイルの整合性チェック
・wp-login.php / wp-admin / wp-includes / wp-load.php の正常ファイルへの置換
・管理画面へのアクセス権を確保

[ステップ2: 原因の切り分け]
・テーマの一次変更（デフォルトテーマへ）
・プラグインの一括停止
・.htaccess / wp-config.php / DB(wp_options) の精査

[ステップ3: MU-Pluginの特定と無効化]
・wp-content/mu-plugins 内の非公式ファイル特定
・悪質ファイルの隔離・無効化
・生成されたキャッシュファイル（ist-dest.txt 等）の破棄
・リダイレクトおよびクローキング動作の完全停止を確認

障害調査時に「絶対にやってはいけないこと」

過度な焦りによる二次被害を防ぐため、以下の作業は絶対に行わないでください。

• バックアップなしでのファイル削除・編集（元に戻せなくなります）
• ファイル名だけを見た安易な一括削除（正常なコアファイルを消してしまう危険）
• データベースの直接編集（構文エラーによるDB破損リスク）
• 不審コードの安易なローカル実行（手元環境への感染リスク）
• 調査用一時ファイル（phpinfo.php やテスト用PHP）のサーバー上への放置

復旧完了後に必須となる再発防止策（セキュリティチェックリスト）

不審ファイルの削除・リダイレクト停止が確認できた後は、直ちに以下のセキュリティ強化を実施します。

• [ ] 全パスワードの変更
  • WordPress管理者アカウントのパスワード
  • データベース（MySQL）ユーザーのパスワード
  • FTP / SFTP / SSH 接続パスワード
  • サーバー管理画面（cPanel、DirectAdmin、エックスサーバー等）のログインパスワード
• [ ] 認証用SALT鍵の再生成
  • wp-config.php 内の AUTH_KEY や LOGGED_IN_KEY 等を更新し、既存セッションを全切断
• [ ] WordPress本体・テーマ・プラグインの最新化
• [ ] 不要なテーマ・プラグインの完全削除
• [ ] サーバー側WAF（Web Application Firewall）の有効化
• [ ] 定期自動バックアップ体制の構築
• [ ] Google Search Consoleでのカバレッジ・セキュリティ問題の確認

まとめ

改ざんやマルウェア被害に直面した際、最も重要なのは「焦って目についたファイルを片っ端から消す」のではなく、「構造を理解して順番に切り分ける」ことです。

今回のケースはMU-Pluginとクローキングを組み合わせた一例であり、攻撃の手法は日々変化しています。しかし、

• どの順番で調査を進めるか
• 正常ファイルと悪質ファイルをどう見分けるか
• 再発防止のための永続化対策をどう潰すか

という根本的な考え方は、すべてのWordPressトラブルシューティングにおいて共通する重要な知識です。

万が一ご自身のサイトで同様の症状が発生した際は、本記事の調査順序を参考に、落ち着いて原因の特定を進めてみてください。