当ページは検証・整備中のドラフトです。
内容は実環境での検証や追加調査により変更される予定です。
参照：ページ公開・更新ポリシー
WordPressの改竄やマルウェア感染が疑われる場合は、復旧を始める前に、何が変更されたのか、いつ頃から異常が発生したのかを可能な範囲で調査する。
すべての侵入経路を特定することが目的ではない。残っているファイル、ログ、バックアップなどから原因と影響範囲を確認し、復旧方法と再発防止策を決めるための情報を集める。
調査前の状態を保存する
調査や復旧によって現在の状態が変わる前に、その時点のファイルとデータベースを保存しておく。
普段からサイト全体をバックアップしている場合は、同じ方法で手動バックアップを実行してもよい。ただし通常の世代管理によって後から削除されないよう、調査開始時点のデータとして別に保管する。
ホスティングサービスからアクセスログやエラーログなどを取得できる場合は、それらも保存しておく。
なお、被害が継続している場合は、保存作業に時間をかけるよりサイトの公開停止やアクセス制限を優先する場合もある。
発生した時期を絞り込む
異常に気付いた日時、監視サービスからの通知、ファイルの更新日時、正常だったバックアップなどを比較し、異常が発生した期間を絞り込む。
例えば、3日前のバックアップでは正常だったサイトに、昨日作成された不審なファイルが見つかれば、その間が調査対象となる。
正確な感染日時まで特定できなくても、期間を狭めることで確認するファイルやログを減らせる。
ファイルや設定の変更を調べる
WordPressを構成するすべてのファイルを目視で確認する必要はない。正規ファイルや正常時のデータとの比較、セキュリティツールなどを利用して変更箇所を探す。
サーバへの接続やWP-CLIを利用できる環境では、WordPress本体やWordPress.orgで配布されるプラグインのチェックサムを照合し、正規ファイルとの差異を確認できる。
独自テーマやチェックサムを利用できないものは、正規の配布ファイルや正常だったバックアップとの比較が手掛かりとなる。ホスティングサービスやセキュリティプラグインにマルウェアスキャン機能があれば、それも調査に利用できる。
ユーザー、cron、WordPressやプラグインの設定などは、正常時に作成した設定集との比較も有効である。
不審なファイルを確認する
比較やスキャンで検出されたファイルのほか、本来存在しないファイルが追加されていないか確認する。
用途を確認できないPHPやJavaScript、見覚えのないファイルなどは調査対象となる。ただし、見覚えがないという理由だけで不正なファイルとは判断せず、WordPress、テーマ、プラグイン、ホスティングサービスなどが使用する正規のファイルではないことを確認する。
ファイルの更新日時も、発生時期を調べる手掛かりとして利用できる。
ログから不審なアクセスを調べる
Webサーバのアクセスログやホスティングサービスが提供するログが残っていれば、異常が発生した時期を中心に確認する。
アクセス日時、接続元IPアドレス、アクセスされたURLなどから、管理画面への不審なアクセスや、テーマ・プラグインなどを狙った通信がなかったかを調べる。
期間を絞り込めれば、ログを検索して該当するアクセスを確認することも可能である。一方、大量のログから実際の侵入経路を判断するには専門的な知識が必要となる。
ログが残っていない場合や必要な情報が記録されていない場合は、後から完全な経路を特定できるとは限らない。
原因となった可能性を確認する
ファイルや設定の変更、ログ、使用していたWordPressやテーマ・プラグインの状態などを組み合わせ、原因となった可能性を確認する。
例えば、不審なファイルが作成された時期に特定のプラグインへの不審なアクセスがあり、そのプラグインに該当する脆弱性が確認されていれば、侵入経路を考える材料となる。
ほかにも、不正ログイン、認証情報の漏洩、古いソフトウェアなどが原因候補となる。不審なファイルが見つかった場所と実際の侵入経路が同じとは限らないため、一つの情報だけで判断しない。
WordPress以外への影響を確認する
調査対象をWordPressだけに限定せず、同じ管理環境にも影響がないか確認する。
同じホスティングアカウント内の別サイト、SFTP、データベース、メール、DNS、外部サービスなども対象となる。認証情報の漏洩が疑われる場合は、同じ情報を使用しているサービスも確認しておく。
WordPressではなく、ホスティングアカウントなど別の経路から変更された可能性も考慮する。
調査結果を整理する
調査で分かった内容を記録しておく。
最後に正常だったと考えられる時点、異常を確認した時点、変更されたファイルや設定、不審なアクセス、考えられる原因などをまとめる。
確認できなかった範囲も残しておく。原因を完全に特定できなくても、分かったことと分からなかったことを区別すれば、復旧方法を決める材料になる。
復旧方法を決める
正常だった時点や影響範囲を十分に確認でき、利用するバックアップの正常性を判断できる場合は、バックアップからの復元を検討する。
感染時期や影響範囲を十分に確認できず、既存環境やバックアップを信頼できるか判断できない場合は、信頼できるものだけで新環境を組み立てるクリーンリビルドを検討する。
参考：WordPressをバックアップから復元する
参考：WordPressサイトをクリーンにリビルドする
自分で判断できない場合は専門事業者を検討する
取得できるログの種類やサーバ側で検出された異常については、まずホスティング事業者へ確認する方法がある。
さらに詳しい調査が必要な場合は、WordPressのマルウェア調査・復旧を扱う専門サービスへの依頼も選択肢となる。感染の有無や不正ファイルを調べるサービス、原因調査から除去・復旧まで行うサービスなどがあり、数万円から依頼できるものもある。費用はサイトの規模や被害範囲、調査の深さによって大きく異なる。
証拠保全や詳細な侵入経路の究明まで必要な場合は、フォレンジック調査の領域となる。費用や必要な専門知識も大きく異なるため、通常のWordPress復旧とは分けて考える。
自分で原因を判断できない場合でも、調査前のバックアップやログを残しておけば、ホスティング事業者や専門業者による調査の材料として利用できる。