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

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

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


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

ファイルを開くと、中のコードは明らかにウイルスコードであり、bujang.online というサイトから悪意のあるスクリプトをダウンロードしていました。
さらに調査を続けると、2 つ目のウイルスファイル「wp-hide.php」も見つかりました。

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

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

顧客サイトのプラグイン数は多く、合計 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:32 | WP 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.txt | 200 を返し、コンテンツ長は 4 バイト |
| 11:45:15 | テスト/wp-hide.php | バックドアは 401 を返し、認証を要求 |
| 11:45:25 | バックドアのユーザー名を使用して正常に侵入 | HTTP 200;ログに Basic Auth のユーザー名を記録@FradaB321 |
| 11:47 | Revolution 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 です

攻撃者は別のサイトに WP File Manager をアップロードした後、ファイルマネージャーのルートディレクトリをサーバーのルートディレクトリに設定し、別のウェブサイトのファイルにアクセスできるようにしました。(ヒント:Naiba は以前、WP File Manager プラグイン自体の脆弱性によりウェブサイトが感染するケースに遭遇したことがあり、現在ではこのプラグインを基本的に信頼していません。)
まとめ
ウェブサイトが改ざんされた場合、通常の調査方向は非常にシンプルです:
- ウェブサイトのルートディレクトリにあるファイルとフォルダを確認し、WordPress に属さない内容がないか調べます。
- 存在すべきでないファイルを確認し、コードが文字化けしていないか見ます。文字化けしていれば基本的に悪意のあるファイルです。
- インストールしていないプラグインがないか確認します。あれば、おそらく悪意のあるプラグインです。
ほとんどの場合、感染したファイルを削除し、WP コアとプラグインを再上書きインストールすることでこれらのウイルス感染を解決できますが、データベースに感染した場合は、データベース内の悪意のある内容もクリーンアップする必要があります。
今回のウェブサイトウイルス駆除の全過程で、実際に対象ウェブサイトが感染した原因はウェブサイト自体の脆弱性ではなく、同じサーバー上の別のウェブサイトが突破され、すべてのウェブサイトがデフォルトで同じユーザーとユーザーグループを使用していたため、クロスサイト感染が発生したことです。
そのため、このような問題を心配している方は以下の操作を行うことをお勧めします:
- サイトごとに独立した Linux ユーザー;
- サイトごとに独立した PHP-FPM Pool;
wp-config.php当該サイトのユーザーのみ読み取り可能;- データベースに独立したユーザー;
- 管理画面からのファイル編集を禁止;
- アップロードディレクトリで PHP を禁止;
- メンテナンス期間以外はプラグイン、テーマ、コアをロック;
- 管理者は独立した強力なパスワードを使用;
- 管理者、アプリケーションパスワード、コンポーネントの変更を定期的に確認;
- 十分な長さのアクセスログを保持;
- 定期的にサイト外バックアップとファイルベースラインを生成。
もちろん、もしあなたがWP Panelを使用しているなら、この問題を心配する必要はありません。WP Panel はデフォルトでサイトごとに独立した Linux システムユーザーとユーザーグループ、サイトごとに独立した PHP-FPM Pool と socket を提供します。1つのサイトが攻撃されて同じサーバー上の他のサイトに感染する可能性は比較的低いです。