UpdraftCentralの接続キー流出でWordPressにバックドアを設置された件の調査と対策｜痕跡の見つけ方・復旧手順・追加した設定（php2shell対応で発覚）

　こんにちは、レムシステム株式会社のエンジニア、小村(@system_kom)です。今回は、当社でサーバーを保守しているWordPressサイトで見つかった不正プラグイン（バックドア）の調査と対策をまとめます。

　侵入経路は、バックアップ用プラグイン「UpdraftPlus」の遠隔管理機能「UpdraftCentral」でした。提供元の TeamUpdraft 社が2026年10月17〜18日に不正アクセスを受け、流出した正規の接続キーが悪用されています。同じプラグインを使っているサイトの点検に、役立てていただければ幸いです。

メールでのお問い合わせ

メールフォームからシステムの知りたいことや問題点をお問い合わせ

メールで問い合わせる

電話でのお問い合わせ

電話でお気軽にお問い合わせください（受付時間：平日月-金）

053-525-7357

対象システムと経緯

項目	内容
サーバー	Amazon EC2（Amazon Linux 2023）
Webサーバー	Apache httpd ＋ PHP-FPM（PHP 8.3）
CMS	WordPress（会員ログインやフォームを持つサイト）
データベース	MariaDB（同一サーバー）
発見のきっかけ	10月21日公表のPHPの脆弱性「php2shell」の影響調査中に、数日前に作られた見慣れないプラグインを発見

表1：対象システム

攻撃の流れ

日付	事象
9月〜10月21日	UpdraftCentral への遠隔操作の試行が続くが、正規のキーがないためすべて失敗。管理者へのパスワード総当たり（約2万件）もすべて失敗
10月17〜18日	TeamUpdraft 社が不正アクセスを受け、顧客の UpdraftCentral 接続キーが流出
10月19日	流出したキーで plugin.upload_plugin 命令が送られ、不正プラグインが2回に分けて設置・有効化される
10月20日	バックドア経由で、二要素認証を経ずに管理者権限でログイン（管理画面トップを1回表示したのみ）
10月22日	php2shell 対応のためサイトを停止。不正プラグインを発見し、調査・復旧を開始
10月23〜24日	関係者のIPアドレスに限定して動作確認し、一般公開を再開
10月28日	UpdraftCentral の通信ログから侵入経路を特定
〜10月31日	公開後の監視。攻撃者は手口を変えて再侵入を試みるが、すべて失敗

表2：攻撃の流れ

バックドアの中身

　設置されたのは、どちらも「一般的な単語＋ランダムな英数字」という名前の、ファイル1つだけのプラグインでした（末尾の英数字は伏せています）。

スラッグ	機能
micro-guard-○（Micro Guard ○）	特定のURLパラメータでアクセスすると、ユーザー一覧に表示されない隠し管理者を作ってログインさせる（今回は作成されていなかった）
site-tools-○○○○（Site Tools ○○○○）	特定のURLパラメータでアクセスすると、パスワード・二要素認証なしで管理者としてログインさせる。ログイン履歴プラグインにも記録が残らない

表3：設置されたバックドア

　報道によれば、同じ攻撃では名前の異なる不正プラグインが多数確認されています。スラッグ名だけでなく、「最近作られた、身に覚えのないプラグイン」がないかを確認するのが確実です。

侵入経路の特定：UpdraftCentral の通信ログ

　Apache のアクセスログにはPOSTの中身が残らないため、当初は「更新されていないプラグインの脆弱性」を疑っていました。決め手になったのは、UpdraftPlus がデータベース（wp_options の updraftcentral_client_log）に残す通信ログです。

ログの文言	意味
Command received: plugin.upload_plugin	正しい接続キーで署名された命令として受理された。plugin.delete_plugin も同様
Could not decrypt incoming message	接続キーが一致せず失敗
Message was received, but not understood	動作確認（probe）

表4：UpdraftCentral の通信ログ

　今回は、「Command received: plugin.upload_plugin」の時刻と、不正プラグインのファイル作成時刻が秒単位で一致しました。それ以前の試行はすべて「Could not decrypt」で、攻撃者が10月19日になって初めて正規のキーを手に入れたことがわかります。提供元の公表内容とも一致しています。

　確認の例です（WP-CLI）。

# UpdraftCentral の通信ログ
wp option get updraftcentral_client_log --format=json

# 最近30日以内に作られたプラグインのディレクトリ
find wp-content/plugins -maxdepth 1 -mindepth 1 -ctime -30 -ls

復旧手順

EC2のイメージ（AMI）とデータベースのバックアップを取得し、ログと不正プラグインを証拠として保全
不正プラグインを無効化・削除し、データベースに残った設定値や定期実行の登録も削除
全ユーザーのログイン状態を無効化し、認証キー（SALT）を再生成
WordPress本体を公式のチェックサムと照合。プラグインは公式配布元の最新版で入れ直し、未使用のものは削除
オリジナルテーマは過去のデータと比較し、差分が正規の更新だけであることを確認
関係者のIPアドレスに限定して公開し、動作確認と管理者全員のパスワード変更をしてから一般公開

wp user session destroy --all
wp config shuffle-salts
wp core verify-checksums
wp plugin verify-checksums --all

　影響範囲の確認では、管理者・編集者の追加や権限の変更、新規登録設定の改ざん、記事へのスクリプト埋め込み、OSの不審なプロセス・定期実行・SSH鍵も確認し、いずれも問題はありませんでした。EC2にIAMロールを付与していなかったため、AWS環境への波及もありません。

追加した設定

対策	内容
UpdraftPlus の更新	無償版 1.26.13、有償版 2.26.13 以降で流出したキーが無効化される。使っていない UpdraftCentral のキーは削除し、登録キー0件を維持
UpdraftCentral 通信の拒否	UpdraftCentral を使わないため、通信部品を名乗る User-Agent（class-udrpc.php）のアクセスを Apache で拒否
REST API 一括実行の制限	未ログインの利用者からの /wp-json/batch/v1 を mu-plugin で拒否。本当の攻撃対象を隠すために使われていた
プラグインの自動更新	すべてのプラグインで有効化。今回も自動更新で UpdraftPlus が修正版になり、キーが無効化された
アップロード領域でのPHP実行禁止	wp-content/uploads に置かれたPHPを実行させない
XML-RPC の遮断	総当たり攻撃に使われる xmlrpc.php を拒否
攻撃元IPの遮断	AWSのネットワーク ACL で、本件の攻撃元をネットワークの段階で遮断
ログの拡充	アクセスログに User-Agent・Referer を記録し、保存期間を延長（元は約4週間）

表5：追加した設定

# Apache：UpdraftCentral を名乗る通信を拒否（UpdraftCentral を使わないサイトのみ）
RewriteCond %{HTTP_USER_AGENT} class-udrpc\.php [NC]
RewriteRule .* - [F]

# アップロード領域でのPHP実行禁止
<Directory "/var/www/html/wp-content/uploads">
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>

# XML-RPC の遮断
<Files "xmlrpc.php">
    Require all denied
</Files>

php2shell と Amazon Linux 2023 の更新漏れ

　php2shell（CVE-2026-109618 / CVE-2026-109619、CVSS v4.0 9.2）は、認証なしでリモートコード実行を許すPHPの脆弱性です。修正版は 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 です。今回のサーバーでは、悪用の痕跡はありませんでした。PHPを 8.3.36 に更新し、回避策として session.upload_progress.enabled = 0 も設定しています。この設定は、CLI用ではなく PHP-FPM が読む設定ファイルに入れる必要があります。

　調査の中で、もう一つ問題が見つかりました。OSが構築時のリリースに固定されたままで、約1年半、OS・PHPのセキュリティ更新が入っていなかったのです。Amazon Linux 2023 は、リリースバージョンを明示的に上げないと dnf upgrade を実行しても新しい修正が入らない仕組みです。

# 新しいリリースがあるか確認
dnf check-release-update

# 最新リリースに追従するように設定して更新
echo latest | sudo tee /etc/dnf/vars/releasever
sudo dnf upgrade

　なお、OSを更新したところ、削除していた PHP-FPM の標準設定（/etc/php-fpm.d/www.conf）や Apache の初期画面の設定（/etc/httpd/conf.d/welcome.conf）が復元され、サイトの設定と競合して表示されなくなりました。これらのファイルは削除せず、中身を空にした状態で残すのが安全です。

公開後の監視で見えたこと

　公開再開後の1週間、アクセスログ、管理者・プラグイン・ファイルの変更、チェックサム照合、UpdraftCentral の状態を毎日確認しました。

攻撃	件数	結果
UpdraftCentral を名乗る通信	17件	送信元を分散させるなど手口を変えたが、すべて失敗・拒否
REST API 一括実行の悪用	25件	制限の導入後は拒否
XML-RPC への攻撃	79件	すべて拒否（403）
ログイン失敗	425件	すべて失敗

表6：公開後1週間に確認した攻撃

　攻撃者は、削除済みのバックドアの再利用や、隠しアカウントでのログインも試していました。こうした通信は、侵入が成功していたかどうかを判断する手がかりにもなります。また、新しく作った管理者のユーザー名を狙ったログイン試行もあったため、投稿者アーカイブや REST API からユーザー名がわからないようにする対策もおすすめしています。

まとめ

確認すること	方法
UpdraftPlus のバージョン	無償版 1.26.13、有償版 2.26.13 以降か
UpdraftCentral の接続キー	使っていないキーが残っていないか
通信ログ	updraftcentral_client_log に 10月17日以降の「Command received」がないか
プラグイン	身に覚えのない、最近作られたプラグインがないか
OSの更新	Amazon Linux 2023 なら、リリースが固定されたままになっていないか

表7：確認項目のまとめ