DDDefense DeskWordPress 緊急対応
技術資料

レンタルサーバーのWordPressで侵入経路を特定できない理由と復旧の進め方

改ざんされたWordPressの復旧手順は、侵入経路を特定してから同じ欠陥を塞ぐ順序で組み立てられています。しかし共用のレンタルサーバーでは、その特定に必要な記録が最初から残らない場合や、復旧作業の途中で失われる場合があります。どの記録が残らないのかと、経路が確定しないまま安全な状態へ戻すには何を行うのかを確認できます。

公開日 2026.07.28読了目安 8分著者 DD Defense Desk

侵入経路の特定を前提にした復旧手順

改ざんされたWordPressの復旧手順は、多くの場合「侵入経路を特定してから塞ぐ」という順序で書かれています。攻撃者がどの機能のどの欠陥を、いつ、どこから突いたのかが分かれば、その欠陥を修正することで同じ経路からの再侵入を止められるためです。

この順序が成り立つのは、侵入が起きた当時の通信と操作の記録が残っている場合に限られます。記録がなければ、侵入の時刻も、使われた欠陥も確定できません。当方が改ざん対応を行うときも、まずログとファイルの状態の照合から始めますが、共用のレンタルサーバーでは、この照合だけでは経路まで届かないことがあります。

届かない理由は、調査する側の技量ではなく、共用のレンタルサーバーが利用者に開示する記録の範囲にあります。

当方の障害初動フローを確認する →

アクセスログに記録される範囲

エックスサーバーが公開しているアクセスログの仕様では、記録される項目はIPアドレス、時刻、メソッドとURI(アクセス先のパス)、クエリ文字列(URLの「?」以降に付くパラメータ)、応答のステータス、転送量、リファラ(アクセス元のURL)、ユーザーエージェント(閲覧に使われたソフトウェアの名称)です。これは多くの共用レンタルサーバーで使われている一般的なWebサーバーのログ形式です。記録される項目は事業者や追加の監査機能によって増減します。

この一覧に含まれていない情報があります。POST(送信ボタンなどを通じて本文としてデータを送る方式)で送られた中身です。WordPressへの攻撃の多くは、フォームの送信先やプラグインが公開している処理の受け口に対するPOSTで行われます。攻撃が成立したときにアクセスログへ残るのは「その受け口にPOSTが届き、応答は正常だった」という一行で、送られた中身は残りません。

同じ受け口には正規の操作も届きます。記事の保存も、問い合わせフォームの送信も、同じURLへのPOSTとして記録されます。中身が残らない以上、その一行が攻撃だったのか通常の利用だったのかを、アクセスログだけで判別することはできません。

記録される項目のうち、ユーザーエージェント、URI、クエリ文字列、リファラは、アクセスしてきた側が送ってきた文字列をそのまま保存したものです。攻撃者は、ここに何を書くかを自分で決められます。行数の多いログをAIに貼り付けて要約させる場合、攻撃者が書き込んだ文字列も同時に読み込まれます。

調査で必要になる記録共用レンタルサーバーで確認できるか確認できないと決められないこと
リクエストの時刻とURLアクセスログに記録される(保存されている期間内)保存期間を過ぎた分は、いつ何が届いたのかを追えません
POSTで送られた内容記録されません攻撃のリクエストと通常の操作を区別できません
管理画面のログインの成否と操作WordPressの標準機能では記録されませんアカウントが乗っ取られたのかどうかを判別できません
FTPやSFTPの接続記録利用者向けには提供されないことが多いですファイルが転送ソフト経由で置かれたのかを確認できません
データベースへの問い合わせ共用サーバーでは通常取得できませんどのデータが読み出されたのかを確認できません

AIに読ませたログで調査結果が歪む仕組みを確認する →

ログの保存期間と、改ざんに気づくまでの時間

アクセスログには保存期間があります。エックスサーバーでは過去30日分のログファイルが日別に生成され、それ以前の分を手元に残すには「ユーザー領域への保存設定」をあらかじめ有効にしておく必要があります。さくらインターネットのレンタルサーバーでは、アクセスログを保存するかどうかと保存期間(最大24か月)を、利用者がコントロールパネルで設定する仕様です。いずれの場合も、設定していなかった期間の記録を利用者が後から取得することはできません。

一方で、改ざんに気づく時期を運営者が選ぶことはできません。専任の担当者がいない中小企業のサイトでは、最初の知らせがサーバー会社からの通知や検索エンジンの警告、閲覧者からの連絡であることが珍しくありません。侵入から発覚までの間隔は、攻撃者が侵入後に何をしたかによって決まります。

発覚が保存期間を過ぎた後であれば、侵入当時のアクセスログはすでに存在しません。残っているのは、攻撃者が侵入後に設置した仕組みが動いた記録だけです。それは結果の記録であり、入口の記録ではありません。

WordPressが記録していない操作

侵入経路の候補は通信だけではありません。管理画面のパスワードが破られた場合や、他のサービスから流出した認証情報が使い回されていた場合、攻撃者は正規の手順でログインします。このときアクセスログに残るのはログイン先へのPOSTが一行だけで、外形上は運営者自身のログインと変わりません。

WordPressの標準機能には、ログインの成否、利用者アカウントの追加、プラグインの有効化、テーマファイルの編集を記録する仕組みがありません。これらを記録するプラグインは存在しますが、導入前の期間はさかのぼって記録されないため、侵害が起きてから導入しても原因の特定には使えません。

ファイルを置く手段も通信だけではありません。FTPやSFTPの接続記録は、事業者側では保持していても、共用のレンタルサーバーでは利用者向けに提供されないことが多く、照会しても提供の対象外とされることがあります。転送ソフトの設定に保存されたパスワードが端末のマルウェアに読み取られた場合、利用者が確認できる記録には、その経路を示す痕跡が残りません。

復旧作業で失われる痕跡

記録が残っている場合でも、復旧の過程でその一部は失われます。影響が大きいのはファイルの更新日時です。改ざんされたファイルを見分ける手がかりとして更新日時を使いますが、バックアップからの上書き復元、プラグインの一括更新、転送ソフトによるファイルの入れ替えは、いずれも更新日時を書き換えます。攻撃者が更新日時を意図的に元の値へ戻していることもあります。

セキュリティプラグインによる自動駆除や、サーバー会社によるファイルの隔離も同じ結果を生みます。不正なファイルが手元から消えれば、それがいつ、どのディレクトリに、どのような内容で置かれていたのかを後から調べられなくなります。

バックアップにも期限があります。自動バックアップの世代が2週間分であれば、侵入がそれより前に起きていた場合、侵入前の状態はすでに残っていません。改ざん後の状態が正常な状態として上書き保存されていることもあります。

調査の余地を残すには、手を加える前に、ファイル一式とデータベース、取得できるログを別の場所へ複製しておく必要があります。この複製は、原因の調査だけでなく、どこまで被害が及んだのかを後から確認する材料にもなります。

改ざん検知の通知が届いたときの初動を確認する →

経路が確定しないまま安全な状態へ戻す手順

経路を特定できない場合、「同じ穴を塞いだ」という確認はできません。そこで塞ぐ対象を入れ替えます。特定の欠陥ではなく、攻撃者がいま持っている可能性のあるアクセス手段そのものを対象と考え、それらを一度すべて無効化します。

この方針は、サーバー会社の案内とも一致します。エックスサーバーは不正アクセス時の対応として、通知したファイル以外にも不正なファイルが存在する可能性があるため利用者自身ですべてのファイルを精査するよう求めたうえで、すべてのファイルを削除することを強く推奨しています。どのファイルが汚染されているかを一つずつ判定するより、正しいと分かっているものだけで作り直すほうが、取りこぼしが起きにくいためです。

削除して作り直すには、正しい状態が手元に定義されている必要があります。WordPressの本体と公式配布のプラグインは配布元から取得できますが、独自に制作されたテーマや個別に改修されたファイルは、制作時のソースが手元にあるかどうかで作業量が変わります。

経路が特定できないときの復旧手順

  1. 1

    現状の保全と公開停止

    手を加える前にファイル一式とデータベース、取得できるログを別の場所へ複製し、閲覧者への被害と記録の上書きを止めます。

  2. 2

    ファイルの再構成

    サーバー上のファイルを削除し、公式の配布物と手元のソースから作り直します。

  3. 3

    データベースの精査

    利用者アカウント、自動読み込みの設定、投稿本文に残った不正なコードを個別に確認します。

  4. 4

    認証情報の更新

    管理画面、FTP、データベース、サーバーの管理画面のパスワードと鍵をすべて入れ替えます。

データベースの精査を省略できない理由

ファイルを作り直しても、不正な管理者アカウントがデータベースに残っていれば、攻撃者はそのアカウントで再びログインできます。セキュリティ企業Sucuriが2023年に駆除対応を行った侵害サイトの調査では、データベースにマルウェアが仕込まれていたサイトの55%で、不正な管理者アカウントが1つ以上見つかっています。同じ調査では、対応した侵害サイトの49.21%からバックドアが1つ以上検出されています。いずれも同社へ依頼が寄せられたサイトの数値であり、WordPressサイト全体の割合ではありませんが、復旧の場面で何を疑うべきかを示す目安になります。

経路を特定できていない以上、こうした痕跡が残っているかどうかは、確認しない限り判断できません。確認を省いて公開を再開すると、攻撃者のアクセス手段が残っていた場合に、運営者がそれに気づく機会のないまま運用を続けることになります。

当日中初動の緊急対応の内容を確認する →

参考情報(外部サイト)

本文で参照した外部の公開情報です。

記録の限界を構成の側で減らす

侵入経路を特定できるかどうかは、記録が残っているかに左右されます。共用のレンタルサーバーでは、その記録の範囲を利用者が決められません。ログの保存設定を事前に有効にしておけば確認できる範囲は広がりますが、POSTの中身と管理画面の操作は、それでも記録されません。

公開側でプログラムを動かさない構成へ移行すると、この前提が変わります。閲覧のたびに実行されるプログラムとデータベースが公開側にないため、それらを突いて侵入する経路は大きく減らせます。加えて、公開されているファイルは手元のデータから生成したものであり、正しい状態をいつでも定義できます。公開側のファイルが書き換えられても、生成し直して配置すれば元の状態に戻せます。

記事の編集は管理画面で従来どおり行えます。ただし、編集用の管理環境と、生成したファイルを公開先へ配置する仕組み、そして契約しているホスティングの管理画面は残ります。これらのパスワード管理と更新は引き続き必要です。

Next

消しても再発する改ざん、部分的な駆除で足りるか作り直しが必要か

消しても再発する仕組みを確認する →

← コラム一覧へ戻る

緊急: 当日中初動