目次
WordPressのページが別サイトへ転送される。知らない管理者が増えている。見覚えのない広告が出る。そんな異変に気付いたとき、目についたファイルを削除して画面を戻すだけでは、侵入経路や影響を調べにくくなる場合があります。まず必要なのは、被害を広げない対応と、判断に使う情報を残すことです。
この記事は2026年10月18日にWordPress公式資料とJPCERT/CCなどの資料を確認した初動対応ガイドです。特定サイトの侵害を確認した記事ではありません。状況によって適切な順序が変わるため、個別の復旧手順ではなく、運営者が保守担当や専門家と何を決めるかを説明します。
スポンサーリンク
症状と侵害の確定を分けて記録する
WordPress公式の案内は、何が起き、いつ気付き、最近どのような変更をしたかを記録することから始めています。意図しない利用者の追加や警告などは調査のきっかけになりますが、すべての表示異常が同じ侵入原因とは限りません。出典：WordPress公式：FAQ My site was hacked。
本サイトの提案は、発見した事実と推測を分けた時系列表を作る方法です。「10時に転送を確認した」と「10時に侵入された」は別です。発見時刻、最後に正常を確認した時刻、影響するURL、確認に使った端末やログイン状態を残してください。
説明用に、管理者では正常に見えるのに、検索結果から訪れた利用者だけが転送される例を考えます。この場合、管理者の画面が正常なことは、すべての利用者に被害がない証明にはなりません。再現条件は記録しますが、疑わしい転送先を通常の作業端末で繰り返し開かないようにします。
最初に連絡と判断の担当を決める
保守会社、サーバー事業者、サイトの業務責任者へ連絡し、対応の窓口を一本化します。誰かが初期化し、別の人がログを集め、さらに別の人がパスワードを変える状況では、必要な調査ができなくなることがあります。作業内容と時刻を一つの記録へ集めてください。
サイト上の連絡手段やメールアカウントにも影響が疑われるなら、別の確認済みの経路を使います。緊急時の連絡先は普段からサイトの外にも保管しておくと、管理画面へ入れない状況でも相談できます。共有する資料は必要な担当へ限定します。
契約によってはサーバー事業者が対応できるのは基盤の調査までで、WordPressの侵入調査や復旧は別の依頼になる場合があります。「保守を頼んでいるから全部調べてもらえる」と推測せず、実施範囲、証拠の保管、費用、連絡頻度を確認します。
スポンサーリンク
公開を続けるか制限するかを判断する
訪問者への不正な配信や情報取得が続いている疑いがあれば、調査の準備だけで公開状態を放置しないでください。サイトの停止、影響する機能の停止、通信の制限などを、業務責任者と保守担当が判断します。決済や会員情報を扱う場合は、処理を続ける影響も考慮します。
メンテナンス用プラグインで通常画面を隠しただけでは、すべてのURL、API、直接ファイルへのアクセスが止まるとは限りません。どの経路を制限できたかを確認します。調査に必要な管理経路は確保しつつ、攻撃者の接続を残さないよう専門担当と調整してください。
証拠保全と隔離を完全な二択にしないことも重要です。採取を待つ間の危険が大きければ、制限を先に進める場合があります。実施した措置と失われる可能性がある情報を記録し、停止の判断を遅らせる口実に調査を使わないようにします。
上書きする前に残せる情報を確保する
本サイトでは、少なくとも対象環境、発見時刻、症状、実施した操作、関連するログの場所を整理することを提案します。ファイルやDB、サーバー状態の採取は、権限と専門知識が必要な場合があるため、事業者や調査担当の方法に従います。
- 画面の状態：該当URL、表示や警告の内容、確認した日時と条件を記録する。
- ログ：Webアクセス、エラー、WAF、管理操作、ホスティング側の記録など、取得可能な範囲と保持期限を確認する。
- 変更履歴：更新、テーマ編集、ユーザー追加、外部連携の変更など、正規の作業と対応付ける。
- 環境の保全：ファイル・DBなどの取得対象と保管先を専門担当と決め、実行や再公開をしない。
保存した資料は、取得した元、取得時刻、担当者、保管場所を対応付けます。元の記録を直接編集して注釈を加えるより、作業用コピーと注釈を分けて扱う方が、後で内容の変化を説明しやすくなります。詳細なフォレンジック保全が必要な場合は、独自の簡易手順で済ませず専門家へ依頼してください。
ログにはCookieやトークン、個人情報などを含む場合があります。OWASPは秘密や機微な情報をログへ残さない配慮と、ログ自体の保護を説明しています。調査で必要な原本は適切に管理し、一般の問い合わせや公開資料には必要な範囲だけを共有します。出典：OWASP公式：Logging Cheat Sheet。
スポンサーリンク
見つかった一つのファイルを侵入原因にしない
不審なファイルや投稿は、侵入の入口ではなく、侵入後に置かれた結果かもしれません。削除して表示が戻っても、別のユーザー、設定、定期処理、連携などに影響が残る可能性があります。見つけた対象と、そこから何が分かるかを分けて評価してください。
本サイトの点検案は、WordPressのコードだけに範囲を固定しない方法です。ホスティングの管理アカウント、FTPやSSH、管理者端末、別のサイト、外部連携が同じ資格情報や領域を共有していないかを調べます。WordPress公式の案内も、ローカル環境とホスティング事業者への確認を挙げています。出典：WordPress公式：サイト以外の環境も含めた確認。
スキャンで何も出なかった場合も、検査対象と範囲を記録します。公開ページを確認する検査と、サーバー内部やDBを確認する調査は同じではありません。「検出なし」を「過去の侵害も情報漏えいもない」へ広げないようにしてください。
認証情報は信頼できる経路から扱う
侵害が疑われる管理者端末から新しいパスワードを設定したり、疑わしいサーバーへ新しい秘密を先に登録したりすると、その安全性も説明できなくなります。信頼できる端末と連絡経路を使い、失効と交換の順序を対応担当と決めます。
対象はWordPressのログインだけとは限りません。ホスティング、ファイル転送、DB、メール、外部サービス、アプリケーションパスワードなど、今回の影響範囲で扱われた可能性があるものを列挙します。すべてを一斉に変えて依存関係を壊さないよう、緊急の失効と復旧用の再設定を分けて進めます。
既存のセッションやトークンが残る場合もあるため、通常のパスワード変更だけで全経路が終了したとは推測しません。利用方式ごとに必要な失効を明示し、旧資格情報で接続できないことを確認します。交換のための一覧に、秘密の値そのものを書き込まないようにしてください。
復旧は入口への対処と正常性の確認を組にする
復旧先のコードは、信頼できる配布元や管理しているソースから用意します。バックアップを利用する場合は、その時点ですでに不正な内容を含んでいないかを検討します。最新の保存物だから正常とも、古い保存物だから安全とも決められません。
本サイトでは、侵入に関係した可能性がある弱点への対処、必要なデータの復元、認証情報の扱い、業務の試験を一つの計画にすることを提案します。調査が終わっていない点は未確認として残し、再開時にどの危険が制限できたかを説明できる状態にしてください。
本番を動かしながらすべてを上書きするより、隔離した復旧環境で確認する方が適切な場合があります。ただしコピーした環境からメールや決済、外部APIが動かないよう、副作用も管理します。画像、投稿、認証、フォーム、連携、ログの転送まで試験してから再開を判断します。
分からない段階でも相談できる
JPCERT/CCは、被害組織や保守・調査ベンダーからの相談を受け付け、初動の対応方針や必要な調査などの相談にも対応すると案内しています。事案によってセキュリティベンダーへの相談を求める場合があり、復旧作業をすべて代行する窓口という意味ではありません。出典：JPCERT/CC：インシデント相談・情報提供。
相談時は、組織やサイトの概要、症状、発見時刻、影響する機能、実施した措置、現在の公開状態、取得できる資料を整理します。すべてを確定してから相談する必要はありません。何が不明かを明示すると、次に何を調べるべきかを相談しやすくなります。
利用者への連絡や公表が必要かも、事実と影響の評価に沿って判断します。サイトが表示できるようになったので情報漏えいもなかったと断定したり、調査前に攻撃主体を名指ししたりしないでください。必要な対外対応は、組織の責任者や関係する専門担当と進めます。
スポンサーリンク
再開後に同じ確認を続けられる形へ
再開後は、不審なユーザーや設定の再出現、意図しない転送、異常な外部通信、ログ収集の停止など、今回の事象に合う監視を決めます。担当、通知先、次の確認日時を残し、復旧した日で記録を終えないようにします。
日常点検の手順は関連記事のサイトヘルスとファイル整合性の確認手順、復旧の備えはバックアップの分離とObject Lockも参照してください。今回は、それらの備えを実際の異変に対してどう使い、誰が判断するかを整理しました。
改ざん対応では、急いで元の見た目へ戻すことと、安全に再開することを区別します。症状を記録し、被害の拡大を抑え、資料を保全して、確認できた範囲と残る課題を共有する。その順序を担当者同士で決められる準備が、初動の迷いを減らします。
