ご相談者がWordPressマルウェアをプラグインで検出できなかった実例｜複数サイト・DB1,089件を駆除

「Wordfenceでスキャンしたのに、異常が見つからない」
「怪しいファイルは削除したので、もう安全だろう」と判断していませんか？

WordPressのマルウェアは、セキュリティプラグインの検査をすり抜け、
PHPファイルとデータベースの両方へ分かれて残ることがあります。

今回の復旧事例では、多数の不正PHPファイルに加え、
データベース内の1,089レコードから難読化された不正コードを確認しました。

結論から言うと、専門知識がない状態で、今回のような感染を完全に消すのは困難です。
1つ削除して表示が戻っても、別のバックドアや再生成元が残れば復旧とはいえません。

この記事では依頼者様の許可を得た事例をもとに、
サイト名、ドメイン、DB名、投稿タイトル、認証情報などを伏せて掲載しています。

WordPressマルウェアをプラグインだけでは検出できなかった実例

今回の重要なポイントは、セキュリティスキャンで明確な感染判定が出なくても、
実際にはファイルとデータベースの両方にマルウェアが残っていたことです。

さらに、調査対象だけでなく、同一環境に置かれた別サイトにも同系統の感染が広がっていました。
1サイトだけを修正しても、同じ管理領域に感染源が残れば再感染するおそれがあります。

公開画面が普通に表示され、管理画面へログインできる状態でも、
裏側では外部通信、任意コード実行、リダイレクトに使える処理が動く可能性がありました。

このタイプの感染は、サイト全体を常に壊すわけではありません。
特定の端末や操作だけを狙うため、管理者自身が異常を再現できないこともあります。

多数の不正PHPから5ファイルを具体例として解析

サーバー内では多数の不正PHPファイルが見つかり、
今回共有された5ファイルは、感染総数ではなく具体的な解析例です。

解析例だけでも、通信型ローダー、バックドア、Webシェル、ドロッパーなど、
役割の異なる複数種類のマルウェアが混在していました。

特に危険だったのは、正規のWordPressファイルに似た名前を使うものと、
実行時だけ一時ファイルを作って痕跡を減らすものが含まれていた点です。

ファイル名だけで正常・異常を判断すると、正規ファイルを消したり、
反対にバックドアを残したりする可能性があります。

データベースでは1,089件の感染レコード

ファイルをクリーンにした後も、データベースの投稿本文を静的に検査しました。
その結果、1,089レコードに同じ難読化JavaScriptが埋め込まれていました。

不正コードは、スマートフォンなど特定条件の訪問者がページを操作した時に、
外部サイトを開かせるためのクリックハイジャック処理でした。

管理者がパソコンでページを見るだけでは症状が出ない場合があり、
「自分の環境では正常に見える」という確認だけでは安全性を判断できません。

さらに、同じコードが公開記事だけでなく、下書きやリビジョンにも複製されていました。
現在の公開ページだけを直しても、感染の履歴や再利用可能な断片が大量に残る状態です。

今回掲載した件数は、単純な文字列一致だけで数えたものではありません。
スクリプトの開始位置と終了位置、複数の特徴的な処理が同じレコード内にそろうことを確認しています。

リビジョンは公開画面に直接出ない履歴データですが、感染範囲の確認や再発判定では無視できません。

WordPressマルウェアをセキュリティプラグインが見逃す理由

セキュリティプラグインは重要な防御手段ですが、
スキャン結果の「問題なし」は、サイト全体の無感染証明ではありません。

既知の署名に一致しない難読化

マルウェアスキャンは、既知の危険な文字列、改ざんパターン、
正規ファイルとの差分などを使って不審箇所を判定します。

攻撃者が文字列を分割したり、16進数やXORで処理を隠したりすると、
既知の署名と一致せず、検出の優先度が下がることがあります。

不正PHPの中には、関数名を1文字ずつ組み立てるものや、
受け取ったデータを二重に復号してから一時ファイルで実行するものがありました。

人が読んでも意図を理解しにくい構造にすることで、
自動検査だけでなく、短時間の目視確認もすり抜けやすくしています。

検査対象と感染場所が一致しない

ファイル検査が得意な製品でも、すべてのデータベース列、
投稿履歴、独自テーブル、外部キャッシュまで同じ深さで確認するとは限りません。

今回のようにファイルとDBへ役割を分散されると、
片方だけを見ても攻撃の全体像をつかみにくくなります。

正常に見える条件が組み込まれている

訪問端末、参照元、Cookie、ログイン状態、アクセス頻度で、
不正動作を出し分けるマルウェアがあります。

サイト管理者やスキャンBotには正常なページを返し、
一般訪問者の一部だけを狙えば、被害の発見を遅らせられるためです。

WordPressマルウェアを個人で完全駆除するのが難しい理由

今回の規模と構造では、サイト管理者が専門知識なしで、
正常データを守りながら完全駆除するのは現実的ではありません。

これは「管理者の注意不足」という意味ではありません。
感染コードを安全に解析するには、PHP、JavaScript、SQL、Webサーバー設定を横断する知識が必要だからです。

また、マルウェアを実行せずに機能を読み解き、正常データとの差を確認し、
万一の時に戻せる形で修正するには、通常のサイト更新とは異なる手順が求められます。

消すべきものと残すべきものを判定できない

難読化コード、キャッシュ、テーマ独自処理、シリアライズ値は、
見た目だけではマルウェアか正規データか判断できないことがあります。

誤って正常な行やテーブルを削除すれば、投稿、設定、ウィジェット、
プラグイン構成が壊れ、感染とは別の障害を起こします。

1か所の削除では終わらない

不正ファイルを消しても、DB内のコードが残ることがあります。
DBを修正しても、バックドアが再び同じコードを書き込む場合があります。

さらに、管理者ユーザー、Cron、認証情報、.htaccess、外部連携、
アクセスログを確認しなければ、再侵入の入口を残す可能性があります。

今回の通信型ローダーは、robots.txtを削除し、.htaccessを書き換える機能も備えていました。
見つかったPHPだけを消しても、アクセス制御や別の許可ファイルが残る可能性があります。

別のバックドアは、通常のページアクセスでは何も表示せず、
攻撃者だけが知るCookieやPOST値を受けた時に命令を実行する仕組みでした。

削除後の検証に専門的な検索が必要

今回のDB駆除では、既知の断片だけでなく、開始タグと終了タグの位置、
難読化関数、外部誘導文字列などを組み合わせて削除前後を比較しました。

駆除後は投稿、下書き、リビジョンに残存がないことを確認し、
主要テーブルにも同じ指標がないことを再検索しています。

自分で削除を試す前に、ファイル・DB・ログの原本を保存してください。復元できない一括操作は、調査と復旧の両方を難しくします。

WordPressマルウェア駆除で実施した確認と復旧

完全駆除では、目についたコードを消すだけでなく、
証拠保全、感染範囲の確定、駆除、残存確認を順番に行います。

1. 原本を保存して感染範囲を確定

まずWebサーバー内のファイル一式とデータベースを別の安全な場所へ保存し、
不正ファイル、外部通信先、難読化処理、DB内の一致箇所を静的に調べます。

2. ファイルとデータベースを別々に駆除

多数の不正PHPは役割と感染範囲を確認したうえで隔離・撤去し、
DBは正規本文を残しながら、埋め込まれた不正スクリプト部分だけを除去しました。

感染していた1,089件を一律に削除すると、公開記事や履歴も失われます。
そのため、悪性部分の境界を特定し、正常コンテンツを保持する処理が必要でした。

3. 駆除後に同じ指標を再検索

処理後のDBでは、投稿本文、投稿メタ、設定、コメント、コメントメタ、
ユーザーメタを横断し、今回の不正コードを示す指標が0件であることを確認しました。

さらに、見覚えのない管理者、疑わしいCron、DBトリガーも確認し、
今回の検査範囲では残存を認めませんでした。

最後に、修正済みDBをもう一度独立した検索条件で確認しました。
駆除に使った条件だけでなく、関連する難読化関数や外部誘導の痕跡も照合しています。

この「別の見方でも0件か」を確認する工程が、
大量処理による取り残しや、条件漏れを減らすために重要です。

なお、ファイル感染とDB内のクリックハイジャックが、
同じ攻撃者によるものかどうかは証拠が足りないため断定していません。

サイト管理者が異常に気付いた直後は、まず日時、表示されたURL、端末、操作内容を記録してください。
スマートフォンで起きた場合は、画面録画やスクリーンショットも調査の手がかりになります。

その後、公開を一時的に止められるかを検討し、サーバー、FTP・SSH、WordPress、DBの認証情報を整理します。
ただし、感染した端末やサイト上でパスワードを変更すると再取得される恐れがあるため、安全な端末から行います。

証拠保全前にプラグインの再インストールやDB最適化を繰り返すと、更新日時やログが変わります。
相談時には「何を削除したか」「いつスキャンしたか」も伝えると、調査を進めやすくなります。

クレジットカード情報や会員情報を扱うサイトでは、技術的な復旧だけでなく、
影響範囲の確認、関係者への連絡、法令や契約に沿った対応が必要になる場合もあります。

実務では、分からない部分を無理に断定せず、確認できた事実と推定を分けることも安全な復旧に欠かせません。

WordPressマルウェア駆除のよくある質問

Wordfenceで異常なしなら安全ですか？

安全とは限りません。Wordfenceは有効な防御・検査手段ですが、難読化、DB内の保存場所、実行条件などにより、今回のように明確な検出へ至らない場合があります。症状や外部警告がある時は、手動調査を追加してください。

感染ファイルを全部削除すれば直りますか？

ファイルだけでは不十分な場合があります。今回もWebサーバー内をクリーンにした後、DB内で1,089件の感染を確認しました。ファイル、DB、管理者、Cron、ログを関連付けて調べる必要があります。

DBの検索結果を一括置換してもよいですか？

バックアップと検証環境なしでは勧めません。開始・終了位置を誤ると本文を壊し、シリアライズデータでは文字数不整合も起こります。削除前後の件数照合と、復元できる原本が必要です。

どの段階で専門家へ相談すべきですか？

不審な転送、検索結果の改ざん、サーバー会社やGoogleからの警告、知らないPHP、管理者、DB内コードのいずれかを確認した時点です。試行錯誤で証拠や正常データを失う前に相談してください。

WordPressマルウェアはプラグインの検出結果だけで判断しない

今回の実例では、多数の不正PHP、別サイトへ広がった感染、DB感染1,089件が見つかりました。
スキャンで明確に検出されず、管理者の画面では正常に見える感染もあります。

ファイルだけ、DBだけ、表示確認だけで終わらせず、
複数の層を横断して残存と再生成元を確認することが完全駆除への近道です。

感染の疑いがある時は、正常に見えるからと放置せず、
自分で大量削除を始める前にご相談ください。

WordPressマルウェアを自分で消せない時はすぐにご相談ください

ホームページの乗っ取り、マルウェア感染、不正アクセスでお困りなら、
クイックレスキューがファイルとデータベースを横断して調査します。

専門知識がなくても大丈夫です。状況を確認し、必要な調査・駆除・復旧をまとめてご案内します。