functions.phpが自己修復するマルウェアに感染 WordPressの持続的再感染を完全に駆除する方法

functions.phpが自己修復するマルウェアに感染 WordPressの持続的再感染を完全に駆除する方法

functions.phpが自己修復するマルウェアに感染 WordPressの持続的再感染を完全に駆除する方法

functions.php に SC_TH_BEGIN 〜 SC_TH_END で囲まれた難読化コードが注入され、完全削除したはずなのに数週間後に自己修復して再出現する感染は、単一ファイルの削除では解決しない。この種のマルウェアは、複数の隠れた感染拠点から自己を再生し、クリーンアップの試みを検知して適応する高度な仕組みを持つ。根本的な駆除には、侵入経路の遮断と全ファイルの網羅的スキャンが欠かせない。

SC_TH_BEGIN型マルウェアの感染メカニズムと自己修復の仕組み

SC_TH_BEGIN型マルウェアの感染メカニズムと自己修復の仕組み

この手の持続的感染は、単純なワンライナーではなく、組織化されたキャンペーンの一環として設計されている。コードは functions.php の末尾に注入され、SC_TH_BEGIN と SC_TH_END という独自タグで囲まれる。内部にはバージョン番号とハッシュ値が含まれ、これが改ざん検知と自己修復のトリガーになる。

感染のライフサイクルは次の3段階で進行する。まず初期侵入時に、難読化された本体コードが mu-plugins ディレクトリに隠しファイルを書き込む。このファイルがバックドアとして機能し、定期的に functions.php の状態を監視する。次に、functions.php から感染コードが削除されると、mu-plugins の隠しファイルがハッシュ不一致を検知し、自身のロジックで functions.php を再感染させる。さらに、アップロードディレクトリには一見無害なアーカイブファイルが置かれ、これが外部からの指令受け取り口や、別の復旧ポイントとして機能する。

感染コードの隠蔽パターン
Before(感染状態)
/* SC_TH_BEGIN v2.1 a3f8c... */
$abc = base64_decode('UEhO...');
eval($abc);
/* SC_TH_END v2.1 a3f8c... */
After(クリーンアップ直後)
// functions.php のクリーンな終了
After(2週間後 再感染)
/* SC_TH_BEGIN v3.0 b7d2e... */
// this file previously had malicious content but it's been removed and is safe now
/* SC_TH_END v3.0 b7d2e... */
感染状態  クリーン状態
感染が持続する3つの隠れ場所
① mu-plugins の隠しファイル
ハッシュ監視と自己修復ロジックを実行する
② アップロードディレクトリのアーカイブ
外部からの指令受け取りや復旧に使われる
③ 改ざんされた正規のプラグイン/テーマファイル
最初の侵入経路として残り続けることが多い

3つの感染拠点のうち、最も見落とされやすいのは mu-plugins の隠しファイルだ。このディレクトリはプラグイン管理画面に表示されないため、手動での確認が必須になる。また、コメント行だけが残る偽装パターンは、マルウェアがクリーナーの動作を学習し「おとり」として置いている可能性が高い。

自己修復するマルウェアを根本から除去する駆除手順

自己修復するマルウェアを根本から除去する駆除手順

単に functions.php から感染コードを削除するだけでは、裏で動く監視機構が再び書き込んでしまう。以下の手順では、感染のサイクルを断ち切るために、すべての拠点を同時に無効化する。

全ファイルのバックアップと感染範囲の特定

サーバー全体のファイルをローカルにダウンロードし、安全な環境でスキャンする。この段階ではまだサーバー上のファイルには手を加えず、何がどこに潜んでいるかを把握することが目的だ。隠しファイルは先頭にドット(.)が付くものや、ランダムな文字列のファイル名になっていることが多い。

mu-plugins ディレクトリの全ファイルを精査する

wp-content/mu-plugins/ に存在するファイルのうち、自身で設置した覚えのないものはすべて疑う。特に、ファイル名が意味不明な文字列だったり、PHP ファイルでありながらプラグインヘッダーがないものはマルウェアの可能性が高い。正常な mu-plugin も一時的に退避させ、ディレクトリを空にしてから必要なものだけ戻す方法が確実だ。

アップロードディレクトリ内の不審なアーカイブとPHPファイルを削除する

wp-content/uploads/ 以下に .zip や .tar.gz などのアーカイブファイルが存在した場合、それが正規のバックアップやプラグイン由来でない限り削除する。PHPファイルも画像などに偽装されて存在することがあるため、拡張子に関係なくファイルの先頭数行を確認し、PHPタグが含まれていないか検査する。

テーマとプラグインを公式ソースと比較して復元する

改ざんの可能性があるテーマやプラグインは、公式リポジトリからダウンロードしたクリーンなファイルで上書きする。子テーマの functions.php だけが標的になっていたとしても、親テーマや他のプラグインに仕込まれたバックドアが感染を再開させることがあるため、疑わしい拡張機能はすべて置き換える。

STEP 1 全ファイルをローカルにバックアップし、感染範囲をスキャンする
STEP 2 mu-plugins ディレクトリを空にし、正規のファイルだけ戻す
STEP 3 uploads 内の不審なアーカイブとPHPファイルをすべて削除
STEP 4 テーマ・プラグイン全ファイルを公式版で上書き
STEP 5 全パスワードを再変更し、侵入経路を遮断する

クリーンアップ後に再感染を防ぐための恒久対策

クリーンアップ後に再感染を防ぐための恒久対策

ファイル改ざん監視を導入する

WordPress のコアファイルやテーマ、プラグインの変更をリアルタイムで検知するセキュリティプラグインを導入する。改ざんが発生した瞬間に通知を受け取れるため、感染の早期発見につながる。ファイル整合性チェック機能を持つものを選び、既知のクリーンな状態との差分を定期的に比較する設定にしておく。

書き込み権限の厳格化

functions.php や mu-plugins ディレクトリに対して、Web サーバーの実行ユーザーが書き込みできないようにパーミッションを設定する。通常、PHP ファイルは 644、ディレクトリは 755 が基本だが、特に標的になりやすいファイルは 444 に設定して変更を防止する。ただし、テーマやプラグインの自動更新を利用している場合は、更新時に権限を一時的に戻す運用が必要になる。

使用していないプラグインとテーマの完全削除

無効化されているだけのプラグインやテーマも、ファイル自体がサーバー上に残っていれば攻撃の入り口になる。WordPress の管理画面から完全に削除し、ディレクトリごと消去する。休眠中の拡張機能は更新が止まっていることが多く、既知の脆弱性を放置することになる。

よくある質問

functions.php の感染コードを手動で削除するだけではなぜダメなのか

感染コード自体が別の場所にバックドアを設置しており、そのバックドアが functions.php の状態を監視しているためだ。削除を検知すると自動的に再書き込みが行われ、さらにバージョン番号を上げて「対策済み」を装うケースもある。感染コードの削除と同時に、すべてのバックドアを無効化しなければ根本的な解決にはならない。

mu-plugins ディレクトリに心当たりのないファイルがあるが、削除しても問題ないか

mu-plugins は「マストユースプラグイン」と呼ばれ、有効化操作なしで自動的に読み込まれる特殊なディレクトリだ。正規のファイルはプラグイン名や機能がわかる名前になっていることが多い。ランダムな文字列や .php 以外の拡張子を持つファイルはマルウェアの可能性が高い。まずすべてを退避させ、サイトが正常に動作することを確認してから、必要なものだけ戻す手順が安全だ。

アップロードディレクトリ内の .zip ファイルはすべて削除すべきか

自身でアップロードした覚えのないアーカイブファイルは削除する。正規のプラグインやテーマが生成するバックアップファイルもあるが、マルウェアがアーカイブを設置する場合、ファイル名が日付とは無関係な文字列だったり、設置日時が不自然に新しいことが多い。不安な場合は、ファイルをダウンロードして中身を確認し、PHPコードや難読化されたスクリプトが含まれていないか検査する。

感染を完全に駆除したかどうかをどう確認すればいいか

セキュリティスキャナーを複数かけ、感染の痕跡が検出されないことを確認する。さらに、functions.php のハッシュ値を記録し、1週間後、2週間後と定期的に比較して変化がないことを検証する。サーバーのアクセスログも確認し、不審な POST リクエストや、管理画面外からの PHP ファイルへの直接アクセスがないかを監視する。

SC_TH_BEGIN タグは特定のマルウェアファミリーの特徴か

このタグは、標的のサイトを識別し、感染状況を管理するためのキャンペーン固有のマーカーと考えられる。バージョン管理とハッシュ検証の仕組みから、手動での駆除を想定した設計になっている点が特徴的だ。未知のマルウェアファミリーである可能性もあり、一般的なマルウェアスキャナーの定義ファイルが追いついていない場合がある。

この記事のポイント

  • functions.php だけの削除では自己修復型マルウェアの再感染を防げない
  • mu-plugins の隠しファイルと uploads 内のアーカイブが感染の復旧ポイントになる
  • 全テーマ・プラグインを公式ソースで上書きし、バックドアを一掃する
  • パーミッションの厳格化とファイル改ざん監視で恒久的な防御を敷く
  • 駆除後はハッシュ値の定期比較で再感染の兆候を早期発見する
佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化 ・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門 ・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標 ・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意 ・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

メッセージを残す