自己修復型のWordPressバックドアを調査するサイバーセキュリティのエディトリアルイラスト。暗いサーバールームを背景に、中央のWordPressサイトを表すWebサーバーアイコンから、複数の不審なノードが蜘蛛の巣状に広がり、ファイル、データベース、共有メモリ、スケジュールタスク、隠しプラグインを象徴する層へ接続している。1つの赤いノードが消えても細い光の線で再び生成される、自己修復する分散型バックドアの性質を視覚化する。手前には端末画面と読み取り専用の監査スキャンを示す緑色の走査光、複数のWordPressサイトを一括確認するチェックマーク。脅威を示す赤と警戒色のオレンジ、分析と安全性を示す青と緑の対比、洗練された現代的なテックイラスト、リアルな照明、奥行きのある構図、高品質な日本のITニュース向けビジュアル。画面上の文字、コード、ロゴ、ブランド名、実在の管理画面は描かない。

自己修復型WordPressバックドア「SC」の痕跡チェックスクリプトを公開しました


WordPress のサーバーに、自己修復型バックドア「SC」の痕跡がないかを一括で洗い出すシェルスクリプト check-sc.sh を作成し、GitHub で公開しました。

SC は、セキュリティ企業 Sucuri が 2026年9月30日に公開した分析記事で報告されたマルウェアです。最大の特徴は、見つけたファイルを消しても次のアクセスで復活してしまうこと。どこか1箇所だけを掃除しても駆除できないため、まずは「サーバーのどこに痕跡があるか」を一度に把握することが初動として大切になります。

check-sc.sh は、その洗い出しをコマンド1つで行うための道具です。読み取り専用で、ファイルやデータベースを変更したり、マルウェアを削除したりすることはありません。

SC とは:1ファイルではなく「面」で居座るバックドア

SC は、同じバックドアのコピーを少なくとも8箇所に分散して置き、それぞれが互いを再生成し合う仕組みを持っています。名前は、注入されたコードに含まれる SC_ というマーカーに由来します。

Sucuri の分析によると、痕跡はおもに次のような場所に置かれます。

  • .user.ini の auto_prepend_file:すべての PHP リクエストの前にローダーを読み込ませる、最上流の仕掛け
  • wp-content 直下のランダム名 PHP と、ドットで始まる隠し PHP:例として c1b12371.php と .c1b12371.php のような組(名前はサイトごとに異なる)
  • ドロップイン(db.php / advanced-cache.php):WordPress の起動時に早い段階で読み込まれ、消されたプラグインを書き戻す
  • テーマの functions.php:末尾に再生成用のコードが追記される
  • 偽プラグイン:mu-plugins と通常の plugins の両方に同じものを設置。管理画面のプラグイン一覧からは自分自身を隠す
  • ディスク外のコピー:データベースの option、SysV 共有メモリ、cron。ファイルを全部消しても、次のページ表示でここから一式が復元される

さらにバックドア本体は、隠し管理者アカウントの作成、管理者セッション情報などの送信、セキュリティプラグインの無効化、フロント側への JavaScript 注入(EC サイトではカード情報の窃取にもつながる)といった動きをします。指令の受け取りには、特定のサーバーではなく約20種類の公開 Ethereum RPC ゲートウェイを経由するため、通信先を1つ塞ぐだけでは止まりません。

つまり SC は「怪しいファイルを1つ消せば終わり」という従来の感覚が通用しない相手です。

check-sc.sh で確認できること

指定したディレクトリ以下の wp-config.php を再帰的に探し、見つかった WordPress すべてに対して、SC が使う配置を順番に確認します。1つのサーバーに複数サイトを置いている場合も、まとめてチェックできます。

No.確認する場所見ているポイント
0SysV 共有メモリ(ipcs -m)メモリ上にペイロードが置かれていないか(サーバー全体で1回)
1.user.ini / php.ini / .htaccessauto_prepend_file の指定がないか
2ドロップイン(db.php / advanced-cache.php / object-cache.php)存在するか、存在する場合は難読化・自己修復系のコードを含むか
3wp-content 直下の PHPランダムな16進数名の PHP、ドットで始まる隠し PHP がないか
4mu-plugins心当たりのない PHP が置かれていないか
5wp-content / uploads / themesランダムな16進数名の ZIP(復元用バンドル)がないか
6サイト内の全 PHP ファイル共有メモリ操作、eval + base64_decode 等の難読化実行、SC_ マーカー、Ethereum RPC の通信先を含むか
7データベース(WP-CLI がある場合)Base64 だけの巨大な option、sc_ を含む option、DB トリガー、管理者一覧、ランダム名の cron

いくつか工夫している点もあります。

  • 誤検知を分けて表示:vendor や node_modules、tests 配下は、PHPUnit などが関数名を文字列として持っているだけのケースがほとんどです。除外はせず、「参考」として本体の検出とは分けて表示します。
  • マルウェアに結果を隠させない:WP-CLI は --skip-plugins --skip-themes 付きで実行します。SC はプラグインとして動いて管理者一覧などを隠すため、それを読み込まない状態で確認します。
  • 未確認を「該当なし」と見せない:WP-CLI がない、または DB に接続できない場合は、DB 側を「スキップ(未確認)」と明示します。
  • 最後にサイト別の集計:複数サイトを検査したとき、どのサイトに痕跡があったかを末尾に一覧で表示します。

使い方

SSH でサーバーにログインし、WordPress を置いているディレクトリ(またはその親)を引数に指定して実行します。

ダウンロードして実行する場合

curl -sO https://raw.githubusercontent.com/web-soudan/wp-security-audit-on-jp-hosting/main/check-sc.sh
chmod +x check-sc.sh
./check-sc.sh /home/example/public_html

ダウンロードせずに実行する場合

curl -s https://raw.githubusercontent.com/web-soudan/wp-security-audit-on-jp-hosting/main/check-sc.sh | bash -s -- /home/example/public_html

/home/example/public_html の部分は、お使いの環境のパスに置き換えてください。親ディレクトリを指定すれば、その下にある複数の WordPress をまとめて検査します。

サーバーに WP-CLI が入っていれば、データベース側(option・管理者・cron・DB トリガー)も自動で確認します。WP-CLI がない場合はファイル側のみの確認になり、その旨が表示されます。

サイト内の全 PHP ファイルを検索するため、サイトの規模によっては数分かかることがあります。なお、2MB を超える PHP ファイルは正規のライブラリであることが多いため、検索対象から外しています。

結果の見方と注意点

出力の各行は、先頭の記号で意味が分かれています。

  • [!]:要調査。SC が使う配置と一致した項目で、件数としてカウントされます
  • [i]:参考情報。「該当なし」や、誤検知の多い開発用ライブラリ配下の結果など

最後に、検査したサイトごとの件数と、全体の判定メッセージが表示されます。

ここで必ず押さえておいていただきたいのが、次の2点です。

検出 = 感染確定ではありません。 たとえば db.php や advanced-cache.php、object-cache.php は、キャッシュ系や DB 系のプラグインが正規に作成するファイルです。mu-plugins も、ホスティング会社や制作会社が意図的に置いている場合があります。[!] が出たら、そのファイルに心当たりがあるか、中身が正規のものかを確認してください。

未検出 = 安全の保証でもありません。 SC はファイル名・option 名・cron 名をサイトごとにランダム化します。スクリプトは既知の配置パターンをもとに探しているため、未知の配置は検出できません。WordPress 本体・プラグイン・テーマを最新に保つことに加え、管理画面のプラグイン一覧と wp plugin list の結果に差がないか(管理画面から隠されたプラグインがないか)も確認されることをおすすめします。

また、共有メモリ(ipcs -m)の結果は、共有ホスティングでは別アカウントが所有するセグメントが表示されることもあります。キーと所有者を見て判断してください。

痕跡が見つかったら:消す「順番」が重要です

SC は互いを再生成し合うため、見つけたファイルから1つずつ消していくと、必ず復活します。Sucuri は、次の順序を崩さずに一度で作業するよう推奨しています(スクリプトの判定メッセージにも同じ手順を表示します)。

  1. auto_prepend_file を先に無効化する。 PHP はこの設定を最大300秒キャッシュするため、読み込み先のファイルをいきなり削除すると、アカウント上のすべての PHP リクエストがエラーになるおそれがあります。先に読み込み先を無害な空ファイルにしてから、.user.ini などの指定を外します。
  2. ディスク外のコピーを消す。 option に格納されたペイロード、共有メモリのセグメント、sc_ 系の制御 option / transient を削除します。
  3. cron イベントと DB トリガーを削除する。 トリガーが残っていると、管理者アカウントが再作成されます。
  4. 隠し管理者アカウントを削除する。
  5. ファイルを一度に消す。 ローダー、シム、mu-plugins と plugins の偽プラグイン、ZIP、ドロップインをまとめて削除します。テーマの functions.php は、追記されたブロックだけを取り除きます。
  6. 再スキャンして、ファイルが再生成されないか監視する。

あわせて、データベース・管理者・API キーなど、攻撃者が触れた可能性のある認証情報はすべて変更してください。また、そもそもの侵入経路(古いプラグインなど)を塞がない限り、再感染のリスクは残ります。

本番サイトでの作業は影響が大きいため、手順に不安がある場合は無理をせず、専門家にご相談ください。

まとめ

SC は、ファイル・データベース・メモリにまたがって居座り、1箇所消しても復活する厄介なバックドアです。だからこそ、まずは check-sc.sh で痕跡の有無と場所を一度に洗い出し、そのうえで正しい順番で駆除することが大切です。

スクリプトは読み取り専用なので、日頃管理している WordPress の定期チェックにもお使いいただけます。不具合や改善のご提案は、GitHub の Issue / Pull Request でお気軽にお寄せください。

「スクリプトで [!] が出たが、正規のファイルか判断できない」「駆除や復旧を任せたい」「再発しないよう保守を見直したい」といった場合は、Webの相談所までご相談ください。WordPress の調査・復旧から、その後の保守・運用まで対応いたします。

参考


トップへ戻る