ホーム 経験・テクニック共有 標準記事

標準記事

WordPress サイトがマルウェア感染した場合の調査方法は?同一サーバー上のクロスサイト感染の完全な駆除記録

本日、Naiba は顧客のサイトウイルス駆除タスクを引き受けました。以前遭遇したウイルスとは異なり、今回のウイルスは同一サーバー上の他のサイトからのクロスサイト感染によるものでした。そのため、記事に記録しておきます。 感染した顧客サイトの基本情報 今回 Naiba にウイルス駆除を依頼したのは、2021 年に Naiba がサイト構築を担当した顧客です。サイトはすでにサポート期間を過ぎており、顧客自身が EasyClaw を利用してサイトの…

2026年10月6日に更新 約6分で読めます
WordPress 网站中毒怎么排查?一次同服务器跨站感染的完整查杀记录

本日、Naiba は顧客のサイトウイルス駆除タスクを引き受けました。以前遭遇したウイルスとは異なり、今回のウイルスは同一サーバー上の他のサイトからのクロスサイト感染によるものでした。そのため、記事に記録しておきます。

感染した顧客サイトの基本情報

今回 Naiba にウイルス駆除を依頼したのは、2021 年に Naiba がサイト構築を担当した顧客です。サイトはすでにサポート期間を過ぎており、顧客自身が EasyClaw を利用してサイトの改版や運営などを行い、AI にもスキャンと処理をさせていましたが、根本的に解決されていません。

サーバーは Hostinger の VPS を使用し、宝塔パネルをインストールしています。パネル上には合計 2 つのサイトがあります。

Snipaste 2026 10 06 21 00

サイト一覧に入ると、もう一つのサイトの日次トラフィックが 800MB 以上もあることに気づきました。今回ウイルス駆除を依頼されたサイトの日次トラフィックは 50MB 程度です。Naiba の長年の経験から、このサイトはおそらく異常であり、ウイルス感染か攻撃を受けている可能性が高いと判断しました。ただし、今回の駆除対象ではないため、顧客に一言伝えただけで、このサイトには手を付けませんでした。

ウイルスの調査と駆除

ウイルスを調査するサイトの記事ディレクトリに入ると、WordPress に属さないファイル「site.php」が明らかに見つかりました。

ファイルを開くと、中のコードは明らかにウイルスコードであり、bujang.online というサイトから悪意のあるスクリプトをダウンロードしていました。

さらに調査を続けると、2 つ目のウイルスファイル「wp-hide.php」も見つかりました。

さらにプラグインディレクトリを調査すると、奇妙なフォルダを発見しました。

0 insert-headers-and-footers

これは顧客が AI で処理した際にフォルダに名前を付けたのかもしれませんが、正しくは「insert-headers-and-footers」であるべきです。

WordPress插件目录列表

顧客サイトのプラグイン数は多く、合計 42 個あり、手動で照合するのは面倒なので、Naiba は AI にすべてのプラグインの公式コードとの比較を依頼し、最終的に„WordPress セキュリティモジュールを装ったwp-coreプラグイン„と“POST 実行バックドアが埋め込まれたプラグインとテーマファイル„

これらの悪意のあるコードを削除した後、このサイトのウイルスは完全に駆除されました。

事後分析で根本原因を発見

国慶節の休暇中だったため、日中に処理を終えた後、夜に Naiba はログを分析してこのサイトがどのようにマルウェアを仕込まれたのかを調査しようとしました。その結果、AI がログを分析したところ、上記のサイトが最初にマルウェアを仕込まれたサイトではなく、最初に日次トラフィックが 800MB 以上あったサイトであることが判明しました。

時間イベント証拠
8 月 28 日 10:26攻撃者 IP187.14.109.121ログイン成功****.com管理画面POST /wp-login.php302 を返し、その後管理画面トップが 200 を返す
10:26:46バックエンドのプラグインアップロードページを開く/wp-admin/plugin-install.php?tab=upload200 を返す
10:26:54悪意のあるプラグインをアップロードPOST /wp-admin/update.php?action=upload-plugin
10:27:03悪意のあるプラグイン内のコマンドバックドアを直接実行リクエストwp-cache-4ed103ec.php?...&c=echo+test200 を返す
10:43:22バックドアを使用して実行pwdコマンド実行に成功し、作業ディレクトリを返す
11:37:14攻撃者が再びバックエンドへのログインに成功ログイン POST は 302 を返し、バックエンドは 200 を返す
11:37:47再びバックエンド経由でプラグインをアップロードPOST ...action=upload-plugin200 を返す
11:39:32WP File Manager を有効化ログに有効化が明確に記録されるwp-file-manager/file_folder_manager.php
11:39:40 以降ファイルマネージャーを開き、/ルートディレクトリからサーバーを閲覧File Manager のターゲットl1_Lwデコード後は/
11:43 頃File Manager 経由で x-** にバックドアを書き込む同一 IP が継続的に呼び出しているmk_file_folder_manager、同時に x-teamrc バックドアファイルが出現
11:43:43テスト/site.php攻撃 IP が該当ファイルをリクエスト
11:43:53テスト/aa.txt200 を返し、コンテンツ長は 4 バイト
11:45:15テスト/wp-hide.phpバックドアは 401 を返し、認証を要求
11:45:25バックドアのユーザー名を使用して正常に侵入HTTP 200;ログに Basic Auth のユーザー名を記録@FradaB321
11:47Revolution Slider ディレクトリに補助バックドアを作成xmlc.php、includes/bs4.phpいずれも 200 を返す
10 月 1 日プラグイン、テーマ内に POST 実行バックドアを追加custom-1790893767 和 category-template-1790893826
10 月 4 日偽装したものを追加wp-core永続化プラグイン„WordPress Security Team“を装い、隠しリモート JS を読み込む
10 月 6 日 02:07感染した古いコピーが正式ディレクトリにコピー/復元されるファイルの変更時刻はまだ 8 月だが、inode の作成時刻は 10 月 6 日

簡単に言うと、攻撃者はまず日次トラフィックが比較的多いサイトの管理者権限を取得し、その後バックエンドのプラグインを通じて悪意のあるプラグインをアップロードしました。

そして悪意のあるプラグインが PHP ファイルをアップロードして別のサイトに感染させました。

なぜ一つのサイトが感染すると別のサイトもやられるのか?

一つのウェブサイトが突破され、同じサーバー上の他のサーバーもウイルスに感染する根本原因は、これら二つのサイトが同じ Linux ユーザーグループで実行されていることです。

どちらも www:www です

linux用户组

攻撃者は別のサイトに WP File Manager をアップロードした後、ファイルマネージャーのルートディレクトリをサーバーのルートディレクトリに設定し、別のウェブサイトのファイルにアクセスできるようにしました。(ヒント:Naiba は以前、WP File Manager プラグイン自体の脆弱性によりウェブサイトが感染するケースに遭遇したことがあり、現在ではこのプラグインを基本的に信頼していません。)

まとめ

ウェブサイトが改ざんされた場合、通常の調査方向は非常にシンプルです:

  1. ウェブサイトのルートディレクトリにあるファイルとフォルダを確認し、WordPress に属さない内容がないか調べます。
  2. 存在すべきでないファイルを確認し、コードが文字化けしていないか見ます。文字化けしていれば基本的に悪意のあるファイルです。
  3. インストールしていないプラグインがないか確認します。あれば、おそらく悪意のあるプラグインです。

ほとんどの場合、感染したファイルを削除し、WP コアとプラグインを再上書きインストールすることでこれらのウイルス感染を解決できますが、データベースに感染した場合は、データベース内の悪意のある内容もクリーンアップする必要があります。

今回のウェブサイトウイルス駆除の全過程で、実際に対象ウェブサイトが感染した原因はウェブサイト自体の脆弱性ではなく、同じサーバー上の別のウェブサイトが突破され、すべてのウェブサイトがデフォルトで同じユーザーとユーザーグループを使用していたため、クロスサイト感染が発生したことです。

そのため、このような問題を心配している方は以下の操作を行うことをお勧めします:

  • サイトごとに独立した Linux ユーザー;
  • サイトごとに独立した PHP-FPM Pool;
  • wp-config.php当該サイトのユーザーのみ読み取り可能;
  • データベースに独立したユーザー;
  • 管理画面からのファイル編集を禁止;
  • アップロードディレクトリで PHP を禁止;
  • メンテナンス期間以外はプラグイン、テーマ、コアをロック;
  • 管理者は独立した強力なパスワードを使用;
  • 管理者、アプリケーションパスワード、コンポーネントの変更を定期的に確認;
  • 十分な長さのアクセスログを保持;
  • 定期的にサイト外バックアップとファイルベースラインを生成。

もちろん、もしあなたがWP Panelを使用しているなら、この問題を心配する必要はありません。WP Panel はデフォルトでサイトごとに独立した Linux システムユーザーとユーザーグループ、サイトごとに独立した PHP-FPM Pool と socket を提供します。1つのサイトが攻撃されて同じサーバー上の他のサイトに感染する可能性は比較的低いです。

この記事を評価する post

次のステップ

おすすめの次のステップ 宝塔パネルから WP Panel への切り替え WordPress サイトを宝塔パネルから WP Panel に移行する方法

ディスカッションに参加

経験の共有、質問、または更新が必要な箇所の指摘を歓迎します。