「入手元が分からない有償プラグイン」が引き金になった、もう一つの侵害記録です。 コアファイルへの自動再生成型、有償プラグイン内のELF実行バイナリ、 AES-256暗号化シェルドロッパー——検出した3つのアーティファクトを、そのまま公開します。
※ 守秘義務契約のため、サイト名・業種・URL は非公開とさせていただいています。
Photo: Rob Wingate / Unsplash
※ 本ケースは特定事例の実績です。所要時間・潜伏期間はサイト規模・侵害深度・サーバ環境により大きく変動します。守秘義務契約のためサイト名・業種・URLは非公開とさせていただいています。
これは、「入手元が分からない有償プラグイン」がきっかけで起きた、もう一つのフィールドレポートです。 きっかけは、レンタルサーバ会社からの、「改竄されてますよ」の報告だった。調査を進めるほど、事態は深く、そして古くまで遡っていきました。
「プラグインを最新に保っていれば安全」——
その前提そのものが崩れた事例。
ある中小企業のWebサイトで、ある朝レンタルサーバー会社から「改竄の疑いがあります」の連絡が入った。 事業者様が確認すると、画面には意味の分からないコードの羅列が表示され、 WordPress管理画面にもログインできない状態になっていた。事業者様はすぐにWATRIXへ依頼。だが、これは単なる改竄ではなかった—— 後の調査で、事の発端は2年以上前にまで遡ることが判明する。
調査で見つかったのは、身に覚えのない管理者アカウント。だが本当に不気味だったのはその先だ。 WordPress コアのウィジェットクラス2ファイルに関数が埋め込まれ、 WordPress が起動するたび、不正管理者を自動的に再生成する仕組みが仕込まれていた。 アカウントを消しても、消しても、生き返る理由がここにあった。
調査対象を広げると、正規に導入されていたはずの有償プラグインの内部から、ELF実行バイナリとAES-256暗号化のシェルドロッパーを検出。 このバイナリ自体が実行された形跡は確認されなかったが、サーバーレベルでのコード実行を狙った、明らかに高度な攻撃基盤だった。 「プラグインの更新」だけでは、まず気づけない場所に置かれていた。
決め手はファイルのタイムスタンプだった。悪性ファイルの生成日時が、同じフォルダ内の正規プラグインファイルと完全に一致——つまり後から仕込まれたのではなく、導入時点からすでに同梱されていたことが判明した。 サイトを構築した制作会社が入手元不明のいわゆる「海賊版」の有償プラグインを導入しており、それが2年以上眠り続けた時限爆弾だったという結論に至る。 証拠を保全したうえで、WordPress コア・全プラグイン・全テーマを公式配布元から強制再インストール。 全パスワード・認証キーをリセットし、翌朝には復旧を確認した。
「有償プラグインだから安全」とは限りません。制作会社任せにしていた入手元が公式マーケット以外だった場合、 サイトを構築したその瞬間から、時限爆弾を埋め込んでいる可能性があります。
— 本ケースからの教訓（WATRIX による分析）
このケースで実際に検出された3つのアーティファクトです。 いずれも、入手元が公式でない「海賊版」の有償プラグインに、導入した瞬間から同梱されていました。
本サンプルは実際の侵害構造を基に再構成したイメージです。管理者アカウントを削除するだけの対処では、この関数自体が再びアカウントを生成してしまう。
// — コアファイルの末尾に、静かに追記されていた関数 —
if (!function_exists('wpab_bootstrap')) {
function wpab_bootstrap() {
// WordPress起動のたび、不正管理者アカウントの
// 存在を確認し、削除されていれば再作成する。
// 「消しても消しても復活する」の正体はこれ。
}
add_action('init', 'wpab_bootstrap');
}タイムスタンプがプラグイン本体と完全一致——つまり後から追加されたのではなく、導入時点から同梱されていたことを示す決定的な証拠だった。
$ file contenttype.news
contenttype.news: ELF 64-bit LSB executable, x86-64
# 拡張子は画像やニュースフィードを装っているが、
# 実体はサーバー上で直接実行可能なバイナリ。
# 通常のプラグインスキャンでは「画像ファイル」として
# スルーされやすい。このシェルドロッパー自体が実行された痕跡（一時ファイルの中身）は確認されず、発火する前に発見・駆除できた（※同時に発見したコアファイルの管理者自動再生成バックドアは、既に稼働していた）。「拡張子を信じない」ことの重要性を示すサンプル。
# 拡張子は ".bak"（バックアップファイル）を装っているが、
# 中身は AES-256 で暗号化されたペイロード。
# 復号キーとローダーが揃った時点で、
# サーバー上に任意のシェルを展開できる状態だった。
$ openssl enc -d -aes-256-cbc -in banners.bak ...
# （復号には別途仕込まれた鍵ファイルが必要）「制作会社が公式マーケット以外から入手した有償プラグイン」は、それ自体がリスクです。
ファイル名・拡張子は簡単に偽装できます。18体の AI エージェントがタイムスタンプ・バイナリ構造・DBレコードまで同時並列で照合し、 「本当に正規のファイルか」を1つずつ検証する——これが WP-AIレスキューのアプローチです。