WordPressが乗っ取られた時の復旧手順と、作り直しの判断基準

WordPressが乗っ取られたとき、やってはいけないのは、見つけた不正ファイルをその場で消すことです。消した瞬間に相手に気づかれ、作り直され、何が入っていたかの証拠も消えます。最初にやるのは、全ファイルとデータベースを手元に取ること。そこから、侵入経路の確定、不正の洗い出し、直すか作り直すかの判断、認証情報の全変更、入口の封鎖、守りの切り替え、と進めます。

この記事は、その手順を順番どおりに書いたものです。各手順で何を見て、何を基準に判断するかまで書いています。根拠として、サーバー会社に「復旧は不可能」と言われたサイトを2日で元に戻した件と、パスワードを変えても再侵入が続いたサイトの件、2つの対応記録を末尾に載せています。本文で「事例1では」「事例2では」と書いている数字は、そこから引いたものです。最終更新：2026年10月17日（対応事例 2件）

乗っ取りのサインは4つ、見た目が普通でも疑う

乗っ取られたサイトの多くは、自分で開いても普通に見えます。攻撃者はサイトを壊すより、気づかれずに使い続けたいからです。次の4つのうち1つでも当てはまれば、乗っ取りを前提に動いてください。

検索結果に見覚えのないページが出る

Googleで site:自分のドメイン と検索して、見覚えのない商品名や外国語のページが並んでいたら、サイトの中に迷惑ページが作られています。自分でサイトを開いても見えないことがあります。検索エンジンのクローラーにだけ別の内容を見せる手口（クローキング）があるからです。事例1では、依頼主も訪問者もいつもどおりのサイトを見ていて、侵入から2週間近く気づきませんでした。

管理者に知らないアカウントが増えている

管理画面の「ユーザー」→「ユーザー一覧」を「管理者」で絞り込み、1件ずつ身元を確かめます。名前に見覚えがあっても、メールアドレスが自社のものかまで見てください。事例2では、管理者権限のアカウントが50個作られていました。サイトの表示には何の変化もありませんでした。

消したファイルや変えたパスワードが元に戻る

不審なファイルを消しても数分で復活する。管理者のパスワードを変えても、また知らないうちにログインされている。どちらも、表面に見えている不正の裏に、戻すための仕組みが残っているサインです。ファイルが復活するならWordPress本体かテーマの中に、パスワードを変えても入られるならデータベースの中（作り置きのアカウント）に、仕組みがあります。

突然エラー画面になり、サーバー会社も直せない

ある日突然、全ページがエラー画面になる。サーバー会社に問い合わせると「お客様側のファイルの問題で、こちらでは復旧できない」と言われる。攻撃者が最後にサイトを壊すか、不正な設定ファイルを大量にばらまいた状態です。サーバー会社はサーバーの運用に責任を持っていますが、その上にあるWordPressの中身までは直しません。「復旧できない」は、その意味です。

最初にやるのは消すことより、全部を手元に取ること

全ファイルとデータベースを取ってから触る

FTPかサーバーの管理画面から、公開フォルダの全ファイルと、データベース全体を手元に取得します。何も消さず、何も直さず、まず取る。これが解析の材料になり、作り直すときの記事と写真の元になり、万一のときに戻す元にもなります。取るのは早いほどいい。攻撃者が活動中なら、今この瞬間もファイルが書き換わっています。事例1では約2.6GB、事例2では約22,000ファイルを取得しました。

サーバー上で解析せず、切り離した環境で見る

取得したデータは、手元のパソコンか、インターネットから切り離した環境で開きます。サーバー上で解析しようとすると、見ている間に書き換わり、相手にこちらの動きも伝わります。切り離した環境なら、相手は何もできません。この後の照合も検索も、すべてこちらの環境で行います。

メールと決済は別の仕組みかを先に確かめる

依頼主がいちばん心配するのは、ホームページよりメールです。会社のメールが同じサーバーで動いているなら、メールの設定とパスワードがサーバー管理画面側で管理されているか、WordPressとは別の仕組みかを確かめます。別の仕組みなら、WordPressの乗っ取りは通常メールに影響しません。ネットショップなら、決済がサイト内で処理されているか、外部の決済サービスに飛んでいるかも同じです。ここを最初に確かめて伝えると、落ち着いて話ができます。

侵入経路はアクセスログの時刻で確定する

入口が分からないまま設定を固めても、別の入口が開いていれば同じことが起きます。経路はアクセスログで確定します。

集中した宛先の時刻と、DBの操作時刻を突き合わせる

サーバーのアクセスログ（多くのサーバーで管理画面からダウンロードできます）を開き、同じ宛先への要求が短時間に集中している箇所を探します。数十〜数百回、同じURLへ、同じ海外IPから。見つけたら、その時刻の直後にデータベースで何が起きたかを見ます。ユーザーの作成日時（wp_usersテーブルのuser_registered）、投稿の更新日時、設定の変更。ログの集中とデータベースの操作が1分以内に並んでいれば、その宛先が経路です。事例2では、22時29分台の約200回の連続要求の直後、22時30分04秒に管理者アカウントが作られていました。

入口になりやすいのはAPIと古いPHP

ログで探すときに、先に見る宛先があります。/wp-json/（REST API。特に /wp-json/batch/v1 のバッチリクエストは、複数の処理を1回の通信にまとめられるため、ログイン失敗のロックを回避する攻撃に使われます）、/xmlrpc.php（外部からの遠隔操作機能）、/wp-login.php（総当たり）、そしてテーマやプラグインの中の古いPHPファイルへの直接アクセス。WordPress本体やPHPが何年も更新されていなければ、公表済みの脆弱性を自動で探す攻撃に当たっているだけ、ということが多いです。

ログは中身を記録しないので時刻の一致で判断する

Webサーバーのアクセスログは、通信の「宛先」と「時刻」は記録しますが、「送られた中身」は記録しません。だから、どんなデータを送って権限を奪ったかの細かい手順までは分かりません。それでも、宛先の集中とデータベースの操作時刻が一致すれば、経路としては確定できます。確定できれば塞げます。「手順まで分からないから経路も不明」とは考えないでください。

不正の洗い出しはファイル・DB・ユーザーの3か所

不正は、ファイルの中、データベースの中、ユーザーの中、の3か所に残ります。1か所だけ見て「無かった」と判断すると、残りの2か所から戻ってきます。

本体・プラグイン・テーマを公式版と1件ずつ照合する

今使っているバージョンのWordPress本体を公式サイトからダウンロードし、取得したファイルと1件ずつ比べます。公式に存在しないファイルは不正プログラム、公式と中身が違うファイルは改ざんされたファイルです。プラグインは各配布元の同じバージョン、テーマは制作元の元ファイルと同じように比べます。自社制作のテーマで元ファイルが無ければ、プログラム部分を目で全部読みます。差分を取るツールは何でも構いません。大事なのは「全部」比べることです。事例2では本体4,177、プラグイン約6,800、テーマ約580ファイルを照合して、改ざん0件を確定させました。

画像フォルダに偽装したプログラムが無いか全件見る

写真をアップロードするフォルダ（wp-content/uploads）は、不正プログラムの隠し場所の定番です。拡張子が .jpg や .png でも中身がプログラムということがあります。拡張子に関係なく、ファイルの先頭がPHPのコードで始まっていないか、画像として開けるかを全件確認します。写真が多いサイトほど時間がかかりますが、ここを飛ばすと、作り直したサイトに裏口を自分で運び込むことになります。事例1では5,165ファイル、事例2では約10,300ファイルを見ました。

記事と設定データを不正なコードで全文検索する

データベースの中も見ます。記事・固定ページの本文に <script、eval(、base64_decode、外部サイトへの iframe や転送が埋め込まれていないか。記事に付随する設定データ（postmeta）、サイト全体の設定（options）、ウィジェットの中身も対象です。あわせて、医薬品・ギャンブル・偽ブランドなどスパムによく使われる語で検索し、迷惑ページが作られていないかを見ます。.htaccess の訪問者を別サイトへ飛ばす設定も確かめます。

管理者アカウントの作り置きを全部洗う

ユーザー一覧の管理者を全部確認し、身元の分からないものを書き出します。表示名が正規の管理者に似せてあっても、メールアドレスと作成日時で見分けられます。パスワードを変えても再侵入が続くサイトは、ここに原因があることがほとんどです。攻撃者は不正なファイルを置けなかったとき、データベースの中に管理者を大量に作り置きして入口を維持します。事例2では、Webシェル（遠隔操作用の不正ファイル）の設置が、置こうとしたフォルダが存在しなかったために失敗し、代わりに50個の管理者が作られていました。

他サイトへの波及はFTP・cron・ログで確かめる

同じサーバーで複数のサイトを動かしているなら、波及の有無も確認します。見るのは、FTPアカウントに不正な追加・変更が無いか、サーバーの自動実行設定（cron）に見覚えのないプログラムが無いか、サーバー管理画面のログイン履歴に攻撃元IPからのアクセスが無いか、そして不正プログラム（Webシェル）が設置されていないか。Webシェルが置かれていなければ、他サイトへ移る足がかりが無いので、WordPress固有の機能を使った攻撃が他サイトへ波及する可能性は低くなります。ただし、これは「今回の攻撃が波及していないこと」の確認であって、各サイトの安全を保証するものではありません。報告するときはそう書き分けます。

直すか作り直すかは「復活の仕組み」の有無で決める

洗い出しが終わると、見つかった不正を消して直すか、WordPressを新しく置いて作り直すかを決めることになります。基準は1つ、消しても戻る仕組みがあるかどうかです。

本体に復活の仕組みがあれば直さず作り直す

照合の結果、WordPress本体のファイルが書き換えられていて、不正プログラムが消されると自動で作り直す仕組みが埋め込まれていたら、直すのはやめます。本体のファイルが動くたびに復活するので、表面の不正ファイルを消し続けても終わりません。裏口が数十個あれば、1つ見落としただけで元に戻ります。事例1は、本体8ファイルに復活の仕組み、裏口が40個以上、作業中に消したファイルがその場で復活する状態でした。この時点で作り直しに決めています。

入口がアカウントだけなら削除と遮断で済む

逆に、ファイルの照合で改ざんも不正な追加も0件、データベースに不正なコードも無く、入口が作り置きされた管理者アカウントだけなら、作り直す必要はありません。アカウントを全部削除し、全ログインを無効化し、経路を遮断すれば止まります。事例2がこの形でした。約22,000ファイルの照合で不正0件を確定させたうえで、50アカウントの削除とREST APIの遮断で対応しています。

「復旧は不可能」は今のファイルを直す前提の話

サーバー会社が「復旧できない」と言うとき、見ているのはサーバー上のファイルの状態です。数千か所に不正な設定ファイルがばらまかれ、本体が書き換えられ、裏口が数十個。これを1つずつ元に戻すのは、たしかに現実的ではありません。ただ、WordPressのサイトは「本体のプログラム」「記事・写真のデータ」「デザイン（テーマ）」に分かれています。本体は公式サイトから最新版を新しく置けばいい。記事はデータベース、写真はファイルとして残っていて、安全を確認して移せます。直せないのは今のファイルであって、サイトではありません。事例1では、約5,200か所に実行禁止の設定ファイルがばらまかれた状態から、2日で元のデザイン・記事・写真のまま戻しています。

作り直しは新規設置に、確認済みの記事と写真だけ移す

不正プログラムは削除せず公開領域の外へ隔離する

作り直す前に、サーバー上で動いている不正プログラムを止め、感染したファイル一式を公開領域の外（ブラウザからも検索エンジンからも届かない場所）へ移します。削除せず隔離するのは、あとから「何が入っていたか」を確認できるようにするためです。保証期間中に似た症状が出たとき、比べる元があるかどうかで調査の速さが変わります。

最新版を新規に置き、記事と写真だけを移す

最新のWordPressを公式サイトから取得し、まっさらな状態で新規に設置します。古いサイトを上書き更新するのではありません。上書きでは、公式に無い追加ファイル（裏口）がそのまま残ります。新しいサイトに移すのは、照合で安全を確認した記事（データベース）と写真（ファイル）だけ。写真は1枚ずつ、画像として開けること、中身がプログラムでないことを確認してから移します。

テーマは全件確認して新しいPHPで動かす

デザイン（テーマ）をそのまま使いたい場合は、テーマのプログラム部分を全件確認し、不正な書き込みが無いことを確かめてから移します。あわせて、新しいPHPで動くように直します。PHP 5や7向けに書かれたテーマは、PHP 8ではそのまま動かないことが多い。ここを直さないと、次の手順の「PHPを最新に上げる」ができません。テーマの修正量は、古さと独自の作り込みの量で決まります。

配布終了のプラグインは入れ直さず捨てる

プラグインは、公式ディレクトリか配布元から最新版を新しく入れ直します。古いファイルは1つも持ち込みません。配布が終了していて更新が受けられないプラグインは、入れ直さず撤去します。脆弱性が見つかっても直されないので、置いておくこと自体が次の入口になります。同じ機能が必要なら、更新が続いている別のプラグインに替えます。

認証情報は全部変え、ログイン状態も全部無効にする

パスワードはDBからサーバーまで全部変える

攻撃者は管理者権限を持っていたので、見えるものは全部見られた前提で動きます。データベースの接続パスワード、WordPressの管理者と投稿者、FTP、サーバー管理画面。全部を新しいものに変えます。依頼主からメールで送られてきたパスワードがあれば、それも無効にします。メールに書いたパスワードは、漏れている前提です。

全ログインを破棄し、不正アカウントを削除する

パスワードを変えても、攻撃者がすでに持っているログイン状態（セッション）はそのまま有効です。全ユーザーのログインセッションを強制的に無効化します（セキュリティ系プラグインの機能か、wp-config.php の認証キーの再生成で全セッションが切れます）。全ユーザーが再ログインを求められますが、それでいい。作り置きされた不正アカウントは、この時点で全部削除します。

管理者の連絡先を本人にする

管理者アカウントのメールアドレスが、以前の制作会社や退職した担当者のままになっていないかを見ます。連絡先が本人でないと、WordPressからの更新のお知らせも、不審なログインの通知も、誰にも届きません。制作会社が変わったサイトで、よく残っている設定です。事例1がこの状態でした。

正規の管理者が消えていたら権限を戻して報告する

不正アカウントを一括削除したとき、正規の管理者まで一緒に消えていることがあります。管理者が1人もいないと、WordPressの更新もプラグインの管理もユーザーの追加もできません。その場合は、既存の編集者アカウントを管理者に変更して作業を続け、事前に相談せず権限を変えたことを報告書の冒頭に書いて了承を取ります。やむを得ず触った設定は、隠さず最初に書きます。事例2で実際にそうしました。

入口を塞ぐのはPHPの更新と外部アクセスの遮断

作り直しただけ、アカウントを消しただけでは、同じ入口から同じ手口でまた入られます。復旧と同じ日に塞ぎます。

PHPを最新に上げ、侵入に使われた設定を無効化する

サーバーのPHPを、そのサーバーで選べる最新の安定版に上げます。古いPHPの脆弱性を突く攻撃は、PHPを上げるだけで通らなくなります。あわせて、侵入に使われたPHPの機能や設定（事例1では register_argc_argv）を無効化します。テーマを新しいPHP向けに直してあれば、ここで表示が崩れることはありません。

REST API・XML-RPCを外から閉じる

REST APIへの外部からのアクセスと、XML-RPC（外部からの遠隔操作機能）を遮断します。どちらもWordPressの標準機能で、使い道はありますが、サイトの更新を管理画面からしかしないなら外から開けておく理由がありません。SiteGuard WP Plugin などのセキュリティプラグインで設定できます。あわせて、ユーザー名が外部から取得できないようにする設定（?author=1 や /wp-json/wp/v2/users の遮断）も入れます。設定したら、実際に外部からアクセスして遮断されていることを確かめます。

画像フォルダでプログラムを動かさない

写真をアップロードするフォルダの中でPHPが実行されないよう、.htaccess で制限します。画像のふりをしたプログラムを置かれても、動かなければ裏口にはなりません。多くのセキュリティプラグインにこの設定があります。

バックアップがURLで取れないか確かめる

バックアップ用プラグインが保存したサイト全体のバックアップが、URLを直接指定すれば誰でもダウンロードできる場所に置かれていることがあります。中にはデータベースごと入っているので、取られれば全ユーザーの情報と設定が渡ります。保存先のフォルダに外部からアクセスできないか、実際にURLを叩いて確かめ、取れるなら遮断します。事例2では3点、別の案件では7点が公開状態でした。

使っていないサイト・テーマ・プラグインは消す

同じサーバーに置いたまま何年も更新していない別サイト（多言語版、キャンペーンサイト、テスト環境）は、そこが入口になって本体のサイトまで波及します。使っていなければ閉鎖します。停止中のプラグインや有効でないテーマも、ファイルはサーバー上に残り、脆弱性の対象です。使っていないものは削除します。

復旧の翌日に、何もしなくても守られる状態にする

復旧と封鎖が終わったら、依頼主が特別な操作をしなくても守られる状態に切り替えます。乗っ取りの原因が「何年も更新されなかったこと」なら、人の手に頼る対策は続きません。

本体・プラグイン・テーマを自動更新にする

WordPress本体に加えて、プラグインとテーマも自動で最新版に更新されるようにします。これがいちばん効果の大きい対策です。独自に手を入れたテーマが上書きされないよう、子テーマにしておくか、自動更新の対象から外す設定をします。「更新のお知らせが出たら、そのまま更新して問題ありません」と言える状態にしておきます。

WAFとhttpsを有効にする

サーバー会社の攻撃防御機能（WAF）を有効にします。よく使われる攻撃の手口を、WordPressに届く前にサーバーの入口で止めます。まだhttpになっていればhttpsに切り替え、古いアドレスからの自動転送を設定します。名刺やパンフレットの表記は変えなくて済みます。

ログインに画像認証・回数制限・通知を付ける

ログイン画面に画像認証を追加し、パスワードを続けて間違えると一定時間ログインできないようにし、ログインがあるたびに登録メールアドレスへ通知が届くようにします。身に覚えのない通知が届いたら、すぐ連絡をもらう取り決めにします。ネットショップでWooCommerceを使っている場合、画像認証がお客様のログインにもかかるので、そこは外します。

Search Consoleで改ざんの通知を受ける

GoogleのSearch Consoleにサイトを登録し、サイトマップを送信します。サイトが改ざんされたり、迷惑ページが作られたりしたとき、Googleから通知が届きます。費用がかからず、表示速度に影響しない監視です。

守りは使う人が困らない形で入れる

「全部入れる」が正解とは限りません。サイト内に改ざん監視ツールを入れると表示が遅くなることがあります（事例1では約0.7秒）。侵入口を塞ぎ、WAFで防ぎ、Googleで監視できていれば、表示速度を犠牲にしてまでサイト内に監視を置く理由は薄い。ログインURLの変更も、管理者がアドレスを忘れて入れなくなるおそれがあるなら、画像認証と回数制限で同等の防御にします。守りは、使う人が困らない形で入れないと、結局外されます。

復旧後に残ることと、担当者に伝えること

検索結果の痕跡は数週間残る

クローキングで検索エンジンにだけ見せていた迷惑ページは、サイト側から消えても、Googleの検索結果に一時的に残ります。数週間で自然に消えますが、消えるまでの間は、会社名で検索すると見覚えのないページが出ることがあります。先に伝えておきます。迷惑ページが大量に登録されてしまい、順位まで落ちている場合の戻し方は別の記事に書いています。

普段の更新は投稿者アカウントで行う

ブログの更新は、普段は「投稿者」のアカウントで行ってもらいます。「管理者」は設定変更など必要なときだけ。管理者で毎日ログインしていると、そのパスワードが漏れたときに全部持っていかれます。パスワードをメールに書いて送らないことも、あわせてお願いします。

DBパスワードは設定ファイルと同時に変える

データベースの接続パスワードは、変えるだけだとサイトが即座に表示できなくなります。設定ファイル（wp-config.php）の接続情報を同時に書き換える必要があるからです。WordPressの外で同じデータベースを使っているプログラム（掲示板、独自のフォームなど）があれば、そちらの設定も一緒に書き換えます。依頼主側で作業する場合は、必ず技術担当者に頼むよう、注意書きをつけて渡します。やり方を間違えると壊れる推奨事項ほど、注意書きが要ります。

再発保証の期間と確認日を決める

復旧後、作業翌朝と数日後に、サーバー上に不審なファイルが増えていないかを再確認します。そのうえで、同じ原因による再発を無償で対応する期間（事例1では3か月）を決めて報告書に書きます。保証期間中にすぐ対応できるよう、作業用の管理者アカウントを期間の終わりまで残し、その後削除することも伝えておきます。

実際の対応事例

本文の手順の根拠になった2件です。症状・原因・対応内容・結果を同じ形式で記録しています。

「復旧は不可能」と言われた製造業の会社サイト

復旧の技術的な中身より、「メールは影響していません」「記事と写真は全部残っています」「名刺の表記は変えなくていいです」を先に伝えることで、話が前に進みました。

パスワードを変えても再侵入が続いた会社サイト

依頼主が気にしていたのは「自分たちが頼んだバージョンアップのせいで乗っ取られたのではないか」でした。調べた結果は、更新そのものは正しく、更新で増えた入口が初期設定のまま開いていたこと。更新を止めていたら、別の脆弱性で入られていた状態です。それを正確に報告書に書くのは、依頼主にとっても、更新作業をした側にとっても必要なことでした。

よくある質問（FAQ）

サーバー会社に「復旧は不可能」と言われました。本当に戻せますか？

サーバー会社が見ているのは、今サーバー上にあるファイルの状態です。それを直して戻すのが不可能、という意味であることがほとんどです。記事はデータベース、写真はファイルとして残っていれば、最新のWordPressを新しく置いて、安全を確認した記事と写真を移すことで、元のデザインのまま戻せます。事例1では約5,200か所に不正な設定ファイルがばらまかれた状態から、2日で復旧しました。

不正なファイルを消しても、すぐ復活します。どうすればいいですか？

WordPress本体かテーマのどこかに、消されたら作り直す仕組みが埋め込まれています。表面のファイルを消し続けても終わりません。全ファイルとデータベースを手元に取り、サーバーと切り離した環境で公式配布版と照合して、仕組みの場所を特定してから、作り直すのが確実です。消す前に取る、が順番です。

管理者のパスワードを変えたのに、また入られます。なぜですか？

パスワード以外の場所に入口が残っています。多いのは、管理者権限のアカウントの作り置きです。正規の管理者がパスワードを変えても、残りのどれかで入れます。ユーザー一覧の管理者を全部確認し、作り置きを削除したうえで、全ログインセッションを無効化します。あわせて、入られた経路を特定して遮断しないと、また作り置きされます。事例2では50個の作り置きがあり、経路はREST APIのバッチリクエストでした。

バックアップがありません。それでも復旧できますか？

感染した状態のサーバーから全ファイルとデータベースを取れば、それが復旧の材料になります。きれいなバックアップがなくても、記事（データベース）と写真（ファイル）に不正な書き込みが無いことを確認できれば、新しいWordPressに移せます。事例1もきれいなバックアップは無く、感染した状態から取ったデータを解析して戻しています。

会社のメールは止まりますか？

ホームページとメールは別の仕組みで動いていることがほとんどです。WordPressの乗っ取りがメールに影響することは通常ありません。ただし、同じサーバーのパスワードが漏れている可能性はあるので、サーバー会社でパスワードを変更します。事例1でも事例2でも、メールへの影響はありませんでした。

バージョンアップをしたせいで乗っ取られたのでしょうか？

更新そのものが原因になることは、まずありません。ただ、何年も更新していなかったサイトを一気に最新版へ上げると、新しい機能（REST API、XML-RPC、バッチリクエストなど）が一度に増え、初期設定のまま外から開いた状態になります。事例2がこの形で、使われたバッチリクエストは更新前のバージョンには存在しない機能でした。更新のたびに、入口の設定を見直すことで防げます。

復旧にどれくらいかかりますか？

取得・解析・隔離・作り直し・侵入口の封鎖までで1〜2日、翌1〜2日で守りの切り替え、が目安です。写真の点数とテーマの作り（新しいPHPで動くか）で前後します。入口がアカウントだけで作り直しが不要なら、1日で終わることもあります。侵入者が活動中の場合は、先に取得を済ませることを優先します。

自分で直せますか？業者に頼むべきですか？

全ファイルの取得、公式版との照合、データベースの全文検索、ログの時刻の突き合わせまでを自分でできるなら、この記事の手順で進められます。「消しても戻る」「変えても入られる」が起きているなら、仕組みが見えていない状態なので、照合とログ解析ができる人に見てもらうほうが早いです。何をどこまでやったかを報告書で残してもらってください。

まとめ

• 乗っ取りのサインは、検索結果の見覚えのないページ、知らない管理者、消しても戻る・変えても入られる、突然のエラー画面。見た目が普通でも疑う
• 最初にやるのは消すことより、全ファイルとデータベースを手元に取ること。解析は切り離した環境で
• 侵入経路は、アクセスログで集中した宛先の時刻と、データベースの操作時刻を突き合わせて確定する
• 不正はファイル・データベース・ユーザーの3か所に残る。全部を公式版と照合し、全文検索し、管理者の作り置きを洗う
• 本体に復活の仕組みがあれば直さず作り直す。入口がアカウントだけなら削除と遮断で済む。「復旧は不可能」は今のファイルを直す前提の話
• 作り直しは最新版の新規設置に、確認済みの記事と写真だけを移す。不正物は削除せず隔離、配布終了のプラグインは捨てる
• パスワードはDBからサーバーまで全部変え、全ログインを無効化し、管理者の連絡先を本人にする
• 入口はPHPの更新とREST API・XML-RPCの遮断で塞ぐ。バックアップの公開状態と、使っていないサイト・テーマ・プラグインも見る
• 復旧の翌日に自動更新・WAF・https・ログイン保護・Search Consoleで、何もしなくても守られる状態に。守りは使う人が困らない形で