「対応は完了しているはず」のサイトの、セカンドオピニオンを依頼された。
他社がすでに駆除作業を行い、「復旧済み」とご案内されていたサイトだった。担当者様から「念のため確認してほしい」というご相談を受け、 WATRIXがセカンドオピニオンとして調査に入る。管理画面の裏側を確認すると、処理が完全に停止していることに気づく—— フロントは見た目上は正常表示のままで、外形上は気づきにくい状態だった。
他社の駆除作業がすでに完了しているとご案内されていたサイトについて、「念のため確認してほしい」というセカンドオピニオンのご依頼をいただきました。 実際に調査すると、まだ息をしているバックドアが複数見つかった記録です。
※ 守秘義務契約のため、サイト名・業種・URL は非公開とさせていただいています。
※ 本ケースは特定事例の実績です。所要時間・被害範囲はサイト規模・侵害深度・サーバ環境により大きく変動します。守秘義務契約のためサイト名・業種・URLは非公開とさせていただいています。
これは、他社の駆除作業が完了しているとされていたサイトに、セカンドオピニオンとして招かれたフィールドレポートです。 きっかけは、「一度直したはずなのに、なんとなく様子がおかしい」というご相談でした。

「駆除完了」という言葉だけでは、
安全は証明できない。
他社がすでに駆除作業を行い、「復旧済み」とご案内されていたサイトだった。担当者様から「念のため確認してほしい」というご相談を受け、 WATRIXがセカンドオピニオンとして調査に入る。管理画面の裏側を確認すると、処理が完全に停止していることに気づく—— フロントは見た目上は正常表示のままで、外形上は気づきにくい状態だった。
調査の結果、同一パターンの多形化したが4ファイルに混入していることを確認。 さらに、「.old」サフィックスの隠しディレクトリが2つ見つかり、 その一つは実際にWeb経由で直接アクセス可能な、現役のリモートコード実行経路だった。 「対応完了」という説明とは裏腹に、侵害は継続していた。
前任の対応では、WordPressコアの強制再インストールが行われた形跡があった。しかしこれは公式ファイルの上書きだけを行うもので、wp-includes本体ではない.oldサフィックスの別ディレクトリ——攻撃者が仕込んだ隠しコピー——は対象外だった。 証拠保全のうえ、該当箇所をドキュメントルート外へ隔離し、Web到達不可を確認してから完全削除した。
復旧確認後、念のための追加監査で、Linuxの正規プロセス名(システムデーモン名など)になりすました 実行可能バイナリが32個、コアファイルに紛れて残っていることを発見。 ファイルの上書き方式による駆除では、公式ファイルに存在しない「余分なファイル」までは 削除されない仕様のための見落としだった。証拠保全のうえ完全削除し、あわせて ファイル整合性監視・監査ログ・バックアップ自動化・ログイン保護機能の恒久対策一式を導入した。
「駆除済みです」という報告は、必ずしも「もう安全」を意味しません。上書き型の対応は、正規ファイルを直すことはできても、 そこに存在してはいけない“余分なファイル”そのものを見つけられるとは限らないからです。
— 本ケースからの教訓(WATRIX による分析)
このケースで実際に検出された3つのアーティファクトです。 いずれも、他社が「対応完了」としていたサイトの中に、生き残っていたものでした。

フォルダ名の末尾に「.old」を付けるだけで、一見「無効化済みの古いコピー」に見える。だが実際にはWebサーバーはこの場所も普通に配信してしまう——名前を信じないことの重要性を示すサンプル。
// — 本来のコアファイルとは別に存在した、"退避用"ディレクトリ —
// wp-includes.old/ という、WordPress本体には存在しないはずの名前
// このパスへ直接HTTPアクセスすると、200 OKで応答してしまう
// つまり「使われていない古いファイル」ではなく、
// 外部から今も実行できてしまう現役の入り口だった。単純な文字列一致のスキャンでは、鍵とパラメータ名が毎回違うため4つとも検出をすり抜けてしまう。攻撃者側の自動注入ツールによる多形化と推定される。
// 4つのファイルは、それぞれ異なるPOSTパラメータ名と
// 異なるXOR暗号鍵を使っていた(手口は同じ、指紋は毎回違う)
//
// File A: $_POST['parameter_group'] を XOR鍵 82 で復号
// File B: $_POST['data'] を XOR鍵 63 で復号
// File C: $_POST['fac'] を XOR鍵 52 で復号
// File D: 同様の変種(別パラメータ・別鍵)32個すべて生成日時は完全一致していたが、ファイルごとのハッシュ値はすべて異なっていた。単純なコピーではなく、個体ごとに変化を持たせて検知を避ける工夫がされていたと考えられる。
$ ls -la
-rwxr-xr-x systemd
-rwxr-xr-x cron
-rwxr-xr-x ssh-agent
-rwxr-xr-x chromium
... (計32個、すべて同一サイズ・同一生成日時)
$ file systemd
systemd: ELF 64-bit LSB executable, x86-64, statically linked, stripped
# OS標準のプロセス名を装っているが、実体は
# WordPress本体には存在しないはずの実行可能バイナリ「一度は再インストールして駆除した」は、それ自体が安全の証明にはなりません。
18体の AI エージェントが、正規ファイルには本来存在しないはずの“余分なファイル”まで含めて機械的に洗い出す—— これが WP-AIレスキューのアプローチです。
上書き型の駆除では、正規ファイルには存在しないはずの“余分なファイル”までは見つけられません。まずはサイト URL を1行、確認させてください。
URL1行で無料診断を始める