WordPressデータベースに潜むバックドアを駆除｜スキャンで見つからなかった復旧事例

「セキュリティプラグインでスキャンしたのに、
WordPressの感染が見つからない」と困っていませんか？

今回の復旧事例では、マルウェア本体がPHPファイルではなく、
WordPressのデータベースに隠されていました。

公開画面や管理画面が普通に見えても、ファイルとデータベースを結び付けて調べなければ、
バックドアやSEOスパム用の仕組みを見落とすことがあります。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、データベース内へ隠されたバックドアの見つけ方と、安全な復旧順序を解説します。

結論から言うと、WordPressの感染調査はファイルだけでは不十分です。
テーマやプラグインが読み込むデータベース値、別プレフィックスのテーブル、管理者情報まで確認する必要があります。

この記事では、ご依頼者様のサイト名、ドメイン、認証情報などを伏せ、
復旧判断に必要な技術情報だけを掲載しています。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressデータベースのバックドアが見つかった復旧事例

今回確認したのは、業務で使われているWordPressサイトです。
既存のセキュリティスキャンでは、データベース内のバックドア本体が明示的に検出されていませんでした。

ただし、これは「セキュリティプラグインが役に立たない」という意味ではありません。
スキャン対象や検出方式によって、確認できる範囲が違うということです。

無料・有料を問わず、外部URLスキャン、ファイルスキャン、データベース検査にはそれぞれ役割があります。
検出されなかったことだけで、安全とは判断できません。

クイックレスキュー

無料マルウェアスキャンサービス4選｜WordPress感染確認と防御の始め方 無料マルウェアスキャンサービスでWordPressの感染疑いを確認したい方へ。Sucuri、VirusTotal、Google Safe Browsing、Wordfenceの違いと限界、スキャン後にクイックレスキ…

WordPressテーマの数行からデータベースの本体を発見

感染の手がかりは、テーマのfunctions.php冒頭に残っていた短いコードでした。
見つかった時点ではコメントアウトされ、実行されない状態になっていました。

// $themes_css = get_option( 'themes_css' );
// if ( $themes_css ) {
//     $themes_css['themes'] = $themes_css['themes']();
//     require_once $themes_css['footer'];
// }

themes_cssという名前だけを見ると、テーマの見た目を保存する設定にも見えます。
しかし、データベースから取り出した値を関数として呼び出し、さらにファイルを読み込む構造は正規のCSS設定とは異なります。

wp_optionsのthemes_cssに約9KBの値

データベースのwp_optionsを確認すると、themes_cssという設定が残っていました。
値の中には、16進数で表現された長いPHPコードが格納されていました。

16進数の部分を実行せずに静的解析すると、PHPコードへ戻ることを確認しました。
そこには、外部から送られた命令を実行できる処理や、外部サーバーとの通信処理が含まれていました。

不審な文字列は、デコードして内容を読むだけにします。復元したPHPをブラウザやサーバーで実行してはいけません。

WordPressデータベースに偽のテーブルと隠し管理者

この感染は、themes_cssだけを削除すれば終わるものではありません。
データベースには、backupdb_wp_で始まる偽のWordPressテーブルが23個作られていました。

名前だけを見るとバックアップに見えますが、実際には別の投稿、ユーザー、設定を保存できる一式です。
正規サイトとは無関係な英語SEO記事や、IP判定用と考えられる323件のデータも確認しました。

通常のユーザー一覧には見えない管理者

まず、WordPress管理画面のユーザー一覧で、表示されている管理者を確認しました。
掲載画像では、依頼者に関係するユーザー名、氏名、メールなどをすべてマスキングしています。

管理画面に表示される一覧だけでは、感染用の別テーブル側まで確認できません。
偽テーブルのbackupdb_wp_usersには、通常テーブルに存在しないID 123456のユーザーがありました。

対応する権限情報には管理者権限が設定され、メールアドレスや表示名は空欄でした。
この不整合も、正規運用のユーザーではないと判断する重要な根拠です。

このユーザーは通常の管理画面を眺めるだけでは、感染の全体像として把握できません。
攻撃者が接続先テーブルを切り替えた時だけ利用する、別のWordPress環境として残されていたと判断しました。

クイックレスキュー

WordPressの管理者ユーザーが勝手に増えた時の危険性と初動対応 WordPressに見知らぬ管理者ユーザーが増えて困っていませんか？削除前の証拠保全、権限停止、セッション遮断、認証情報変更、侵入口調査、投稿を失わない削除判断を初心者…

WordPressのセキュリティスキャンで見つかりにくかった理由

今回のバックドアが見つかりにくかった最大の理由は、危険な処理が複数の場所へ分割されていたことです。
ファイル側だけ、データベース側だけを見ても、動作全体を理解しにくい構造でした。

Wordfenceでバックドアが検出されなかった理由

当該サイトではWordfenceのスキャンを実行し、ファイルの変更、マルウェアスキャン、
コンテンツの安全性など、複数の検査が完了した状態を確認しました。

それでも、wp_optionsのthemes_cssに保存されたバックドア本体や、
backupdb_wp_で始まる偽テーブル群は、検出結果へ明示されていませんでした。

Wordfenceはファイルだけでなく、投稿、コメント、一部のWordPressオプションも検査します。
しかし、データベース内のすべてのテーブルと値を、実行コードとして完全解析するわけではありません。

Wordfence公式も、感染の一部がスキャン対象外のデータベーステーブルにあり、
手動でのデータベース駆除が必要になる場合があると案内しています。

今回の感染は、テーマ側の短いローダーとDB内のペイロードを関連付け、
16進数の値を実行せずに解析して初めて、バックドアと判断できました。

Wordfenceで異常が出ないのに不審な症状が続く場合や、DB内の値を判断できない場合は、
削除を始める前にWordPress復旧の専門家へ調査を依頼してください。

テーマ側のコードには、よく知られたevalやbase64_decodeが直接書かれていません。
関数名や引数もデータベースから取り出すため、単純な文字列検索では弱い判定になりやすいのです。

また、管理者やログイン中の接続元には不正表示を見せない条件もありました。
サイト所有者が自分のパソコンで確認しても正常に見えるため、検索結果や非ログイン状態との違いを確認する必要があります。

クイックレスキュー

WordPressマルウェア駆除を自分で行う方法｜感染ファイルを見つける基本手順 WordPressマルウェア駆除を自分で進めたい方へ。感染ファイルが見つかりやすい場所、候補の絞り込み方、削除前の判断基準、再発防止の入口対策まで初心者向けに解説します…

themes_css型バックドアはGootloader系の調査報告と一致

今回確認したthemes_css、テーマ側ローダー、backupdb_テーブル、IPによる表示制御は、
過去に公開されたセキュリティ調査の特徴と一致します。

Sucuriは2018年、WordPressテーマからthemes_cssを読み込み、偽のバックアップテーブルへ接続してSEOスパムを配信する仕組みを報告しました。
後年のSophosによるGootloader調査でも、同じbackupdb_wp_lstatや、POST経由の簡易コマンドシェルが解析されています。

Sucuri Blog

Clever SEO Spam Injection Our security analyst describes a clever piece of malware involved in SEO spam campaigns.

Sophos

Gootloader inside out Open-source intelligence reveals the server-side code of this pernicious SEO-driven malware – without needing a lawyer afterward

ただし、公開された攻撃事例と特徴が一致しても、今回の初期侵入経路までは断定できません。
古いプラグイン、漏えいした認証情報、別のWebシェルなど、侵入口の判断にはアクセスログや更新履歴が必要です。

マルウェアの系統名と、実際に侵入された原因は別の問題です。IOCが一致しても、侵入経路は証拠がそろうまで推定として扱います。

WordPressデータベースのバックドアを駆除した手順

復旧では、怪しいものを先に消すのではなく、原本保全、範囲確認、隔離・削除、再確認の順番を守ります。
データベース操作を誤ると、正常な設定や投稿まで失うためです。

1. ファイル・DB・ログを原本保全

最初にWordPress全体とデータベースを保存し、取得日時とSHA-256を記録しました。
削除前の状態を残しておけば、後から侵入経路や取り残しを調べ直せます。

2. themes_cssと偽テーブルを隔離・削除

wp_optionsのthemes_cssを削除し、backupdb_wp_で始まる23テーブルを対象確認後に削除しました。
似た名前の正規バックアップがないことを、テーブル構造と内容で確認してから実施しています。

3. テーマ側ローダーを行ごと削除

functions.phpのコードは、コメントアウトのまま残さず削除しました。
再侵入時にコメント記号だけを外して再利用される可能性を減らすためです。

4. Webルート全体と別の永続化を確認

テーマだけで終わらせず、プラグイン、mu-plugins、uploads、WordPressルート、.htaccess、.user.ini、Cron、管理者ユーザーも確認しました。
バックドア本体を削除しても、再生成元が残っていれば復旧にはなりません。

クイックレスキュー

バックドアは動作してなくても消すべき？放置リスクを解説 バックドアや不審なPHPファイルは、動作していないように見えても放置は危険です。再感染・検索汚染・サーバー停止を防ぐため、消すべき理由と安全な調査方法を初心者向け…

WordPress復旧中に正規の.user.iniを消した失敗

今回の作業では、駆除途中にPHPの警告が画面へ表示される事態も起きました。
原因はマルウェアではなく、正規の.user.iniを削除されたことです。

Warning: Undefined array key 9 in .../header-parts-navi.php on line 38

テーマにはPHP 8で警告が出る古い処理がありましたが、以前は画面表示を抑える設定が有効でした。
.user.iniを消したことで、もともと存在した警告が見えるようになったのです。

正規の.user.iniを復元し、テーマ側も表示内容を変えずにPHP 8へ対応させました。
この事例からも、名前や設置場所だけでファイルを削除してはいけないことが分かります。

WordPressデータベース感染の再発防止で行うこと

駆除後は、データベースだけをきれいにして終わらせず、侵入に使われた可能性がある権限と公開資産を見直します。
バックドアがあった以上、認証情報は漏えいしている前提で交換する方が安全です。

また、通常のwp_以外で始まるテーブル、autoloadされる大容量オプション、見覚えのない管理者を定期的に確認すると、同系統の感染を早く見つけやすくなります。

クイックレスキュー

WordPressマルウェア駆除後にやることは？再感染を防ぐ設定と見直しポイント WordPressマルウェア駆除後にやることが分からず不安な方へ。再感染を防ぐ設定見直し、管理者・パスワード・uploads制限・バックアップ・監視ポイントまで初心者向けに解説…

WordPressデータベースのバックドアでよくある質問

Wordfenceで問題が出なければ安全ですか？

安全とは限りません。Wordfenceはファイル、投稿、コメント、一部のオプションを検査しますが、DB内のすべてのテーブルと値を完全解析するわけではありません。今回も別の警告はありましたが、themes_cssのバックドア本体と偽テーブル群は明示検出されていませんでした。

themes_cssがあれば必ず感染ですか？

名前だけでは断定しません。値の構造、デコード後の内容、テーマ側の呼び出しコード、別プレフィックスのテーブル、外部通信などを組み合わせて判断します。

backupdb_wp_テーブルは全部削除してよいですか？

すぐには削除しないでください。正規のバックアップや移行用テーブルの可能性もあります。原本を保存し、テーブル構造、投稿、ユーザー、呼び出し元コードを確認したうえで判断します。

ファイルを正常版に戻せば復旧完了ですか？

完了とは限りません。DBオプション、偽テーブル、管理者、Cron、認証情報、ログ、検索結果まで確認します。呼び出し役と本体の片方だけが残ると、再感染や再利用につながります。

WordPressデータベースのバックドア復旧事例まとめ

今回のWordPress感染では、テーマ内の短いローダーと、データベースのthemes_cssが組み合わさっていました。
さらに偽のbackupdb_wp_テーブルへ、スパム記事、IP情報、隠し管理者が保存されていました。

「スキャンでは何も出ないが、検索結果やアクセスの様子がおかしい」という場合は、
不審ファイルだけでなく、データベース、別テーブル、管理者、Cronまで調べてください。

WordPressデータベースの感染を自分で判断できない時は

Wordfenceで異常が出なかったからといって、安全だとは断定できません。
今回のように、バックドア本体がデータベースに隠れ、偽テーブルまで作られている場合があります。

DB内の長い文字列が安全か分からない、バックドアや偽テーブルをどこまで消すべきか判断できない場合は、
誤削除する前に、WordPress復旧の専門家であるクイックレスキューへご相談ください。

プラグインの結果だけで安全と判断せず、ファイル、データベース、管理者、ログを関連付けて調査します。
証拠保全から駆除、再発防止まで、専門家へまとめてお任せください。