WordPressハッキング対応の教科書｜初動〜復旧・再発防止

「Webサイト上に見覚えのないページやコンテンツが表示される」
「WordPressにアクセスすると関係ないサイトへ飛ばされた」
「Google検索結果にECサイトの不正なページが大量にインデックスされた」

WordPressのハッキングは、ある日突然発覚します。

WordPressセキュリティ企業のMelapressが2026年に公開した調査では、WordPressの専門家319人の大半が少なくとも1件のセキュリティインシデントに対応した経験を持っていました。一方で、侵害からの復旧計画を持っていたのは3割未満です。

本記事では、被害に気づいた直後の初動から、原因調査、復旧、Google対策、法的な報告、再発防止、平時の備えまでを1本にまとめました。今まさに被害を受けている方は「発覚直後の初動対応」から読み進めてください。

WordPressがハッキングされた時の症状

WordPressハッキングの症状は、どこで気づくかによって見え方が大きく変わります。

Melapressの調査でも、発覚のきっかけとして最も多かったのは「訪問者や顧客など、誰かがサイトの異変に気づいた」ケースでした。

ここでは症状を気づく場所ごとに整理します。ただし、症状が1つ当てはまるだけで感染と断定はできません。覚えのない変化と、その発生時刻を突き合わせて判断することが大切です。

被害タイプごとに整理した早見表をご用意しましたので、当てはまるものをすべて確認してください。

緊急度が「高」以上のものが1つでもあれば、次章の初動対応にすぐ取りかかってください。

外部からの指摘で気づく症状

サイト運営者本人より先に、外部の人が異変に気づくケースは少なくありません。攻撃者は管理者に気づかれないよう細工することが多いため、指摘を受けた時点で被害が進んでいることもあります。

訪問者や顧客から「変なページに飛ばされる」と言われた

不正リダイレクトの典型的な症状です。ただし多くの場合には、WordPressにログイン中の管理者には正常なページを表示し、検索結果やスマートフォンから来た訪問者だけを別サイトへ転送するよう仕組まれています。

そのため自分で開いても再現しないことがありますが、「再現しない＝問題ない」ではありません。指摘された日時、端末、アクセス経路をできるだけ記録しておくようにしてください。

取引先から「御社からスパムメールが来た」と言われた

サイトのメール送信機能や、サーバー上のメールアカウントがスパム送信の踏み台にされている可能性があります。放置するとドメインがメールのブラックリストに登録され、正規の業務メールまで届かなくなります。サーバー会社の送信ログを確認しましょう。

Google広告が「悪意のあるソフトウェア」を理由に不承認になった

Google広告の審査でサイト内にマルウェアが検出されると、広告が停止されることがあります。サイト自体に目立った異常がなくても、広告の不承認が最初のサインになることがあります。広告管理画面のポリシー通知を確認してください。

検索結果・Googleで気づく症状

検索結果やGoogleのツールに異常が表れるのは、攻撃者が検索エンジンを利用して利益を得ようとしているケースです。Melapressの調査では、検索エンジンの警告で発覚したケースほど検索順位の低下を伴う割合が高く、発見が遅れた状態であることを示しています。

覚えのない日本語や外国語のページが検索結果に出る

Googleが「日本語キーワードハック」と呼ぶ代表的な手口です。偽ブランド品の通販などのスパムページが大量に作られ、検索結果にだけ表示されます。Googleで「site:自社ドメイン」と検索すると、インデックスされているページを確認できます。

サイト引越し屋さん過去に対応した事例でも、改ざんされたサイトのお客様から「社名で検索しても自社サイトが出てこない。調べると、知らない通販サイトに自社のURLが使われている」とご相談いただいたことがあります。

調査すると、mu-pluginsフォルダ内の不審なPHPファイルや、書き換えられたrobots.txtが見つかりました。

復旧後もGoogleのインデックスから外れた状態が残っていたため、サーチコンソールで再登録をリクエストし、検索結果に戻るまで1〜2週間ほど様子を見ていただきました。

ブラウザやGoogleに「危険なサイト」と警告される

Googleセーフブラウジングにマルウェアやフィッシングを検出されると、Chromeなどのブラウザがアクセスをブロックする警告画面を表示します。訪問者はほぼ確実に離脱するため、最も緊急度の高い症状の1つです。Googleの透明性レポートでも、サイトの判定状況を確認できます。

サーチコンソールに見知らぬ所有者が追加されている

攻撃者が自分をサーチコンソールの所有者に追加し、スパムページ入りのサイトマップを送信して、インデックスを早める手口があります。サーチコンソールの「設定」→「ユーザーと権限」で、心当たりのないユーザーやサイトマップがないか確認してください。

サイトの表示・動作で気づく症状

サイトの見た目や動作の変化は、自分でも確認しやすい症状です。ただし、攻撃者は管理者に見つからないよう工夫しているため、普段と違う条件で確認することが大切です。

スマホや検索経由のときだけ別サイトへ転送される

訪問者の種類によって表示内容を変える手口は「クローキング」と呼ばれます。

ログイン状態、端末、アクセス元（検索結果からか直接アクセスか）によって挙動が変わるため、ログアウトした状態のスマートフォンから、検索結果経由でアクセスして確認します。ただし感染が疑われる場合は、後述のとおり普段使いの端末で何度も開かないようにしてください。

403・500エラーや高負荷が続く

改ざんされたコードのエラー、サーバー上で動く不正なプログラム、ログイン画面への大量アクセスなどが原因で、エラーや高負荷が起きることがあります。ただしサーバー障害や設定ミスでも同じ症状が出るため、本章の最後にある見分け方もあわせて確認してください。

サイト引越し屋さんが保守管理するクライアントのサイトでは、500エラーの通知が届いたのでアクセスログを調べると、外部の特定IPから約1,500件のアクセスがあり、そのうち約1,300件が公開ページへの機械的なPOST送信でした。

500エラーはこの異常なリクエストに対してのみ発生し、通常の閲覧では再現しなかったため、攻撃元のIPを遮断して対応しました。

一方、同じ時期に別のページで出ていた500エラーは、テーマとプラグインの組み合わせによるPHPの致命的エラーで、攻撃とは無関係でした。同じ「500エラー」でも原因が1つとは限らないため、ログで切り分けることが大切です。

見えないリンクや不審な外部スクリプトが埋め込まれている

画面上には表示されないリンクやスクリプトが、ページのソースに埋め込まれていることがあります。ブラウザの「ページのソースを表示」で、見慣れないドメインから読み込まれているスクリプトや、意味の読み取れない文字列（難読化されたコード）がないか確認しましょう。

決済ページに見慣れない入力欄やスクリプトがある

ECサイトで特に警戒すべき症状です。決済画面が改ざんされ、入力したクレジットカード情報が攻撃者に送信される手口（Webスキミング）があります。カード情報や個人情報が漏えいした可能性がある場合は、法的な報告義務が発生します。詳しくは「法的な報告義務と顧客へのお知らせ」で解説します。

管理画面・アカウントで気づく症状

管理画面やアカウント周りの異常は、攻撃者がサイトの管理権限を握っているサインです。権限を奪われると、改ざんを何度でも繰り返されるおそれがあります。

知らない管理者ユーザーがいる、権限が変更されている

「ユーザー」一覧を権限「管理者」で絞り込み、心当たりのないアカウントがないか確認します。

既存ユーザーのメールアドレスや権限が書き換えられていることもあります。見つけてもすぐに削除せず、ユーザー名、メールアドレス、登録日時を先に記録してください。侵入時期を特定する手がかりになります。

サイト引越し屋さんにてご対応した事例では、約1か月の間に身に覚えのない管理者アカウントが18件作られていました。

ユーザー登録は無効にしてあり、作成時の通知メールも1通も送信されていなかったため、管理画面を経由しない方法（脆弱性を突いたコード実行など）で作られたと判断しました。

18件を削除しても数時間後に再び作られたため、新たに作られたアカウントは証拠として残し、侵入経路の特定に使いました。不審なユーザーを消しても、侵入口が開いたままでは何度でも作られてしまいます。

パスワードや管理者メールアドレスが勝手に変わっている

ログインできない、パスワードリセットのメールが届かない場合は、管理者メールアドレスが書き換えられている可能性があります。この場合、管理画面からは対処できないため、サーバーのデータベース管理ツールやWP-CLIから確認・修正します。

プラグインが勝手に停止・追加されている

攻撃者はセキュリティプラグインを無効化して、検知を逃れようとします。正規のプラグインに似た名前の不審なプラグインが追加されることもあります。また、wp-content/mu-pluginsフォルダ（使用必須プラグイン）は通常のプラグイン一覧とは別の場所に表示されるため、見落とされやすい隠し場所です。

サーバー・メールで気づく症状

サーバー側の異常は、サーバー会社からの通知や、ファイルを直接確認することで見つかります。サイトの表示に変化がなくても、裏側で被害が進んでいることがあります。

サーバー会社から大量送信や利用停止の通知が届いた

サーバー会社は、スパム送信や他サイトへの攻撃を検知すると、アカウントを一時停止することがあります。通知には検知内容や対象ファイルが書かれていることが多いので、削除せずに保存し、指示に沿って対応してください。

更新していないファイルが変わっている、uploadsフォルダにPHPファイルがある

wp-content/uploadsは、本来は画像などを保存するフォルダです。ここにPHPファイルがあれば、バックドア（攻撃者用の裏口）の可能性が高いと考えてください。また、.htaccessやwp-config.phpに覚えのない記述が追加されていないかも確認します。

身に覚えのない定期実行（cron）が登録されている

攻撃者は、削除されたファイルを自動で再生成する定期実行を仕込むことがあります。「消しても消しても復活する」場合は、WordPressの予約処理（WP-Cron）とサーバーのcron設定の両方を確認してください。

ハッキングではない可能性｜障害・設定ミスとの見分け方

似た症状は、ハッキング以外でも起こります。プラグインやテーマの更新直後のエラー、サーバー会社側の障害、WAF（Webアプリケーションファイアウォール）の誤検知による403エラー、制作会社による作業などです。

見分けるポイントは4つあります。変化に心当たりがあるか、変化の時刻と作業の時刻が一致するか、サーバー会社の障害情報が出ていないか、ログに不審なアクセスがないかです。

判断がつかない場合は、「ハッキングされている前提」で次章の記録と保全から始めてください。ハッキングでなかったとしても、記録と保全で失うものはありません。逆に、障害だと決めつけて証拠を消してしまうと、取り返しがつかなくなります。

感染が疑われるページを、普段使いの端末で何度も開かないでください。Googleも、マルウェアを含む可能性のあるページはブラウザで直接開かず、サーチコンソールのURL検査ツールで確認するよう案内しています。

発覚直後に必要な初動対応

初動の24時間でやるべきことは3つです。被害の拡大を止めること、証拠を残すこと、再侵入の道を塞ぐことです。この段階で慌てて「修理」を始めると、原因がわからなくなり、再発の原因になります。以下の順番で進めてください。

初動でやってはいけないNG行動

焦っているときほど、よかれと思った行動が状況を悪化させます。次の行動は避けてください。

特に注意したいのは、自動バックアップの上書きです。バックアップの保存世代が少ないと、発覚までの間に感染前のバックアップが消えてしまいます。まず、今あるバックアップの世代と日付を確認してください。

①症状・URL・発見時刻を記録する

最初に、見えている症状をそのまま記録します。記録する項目は、発見日時、症状が出ているURL、画面のスクリーンショット、誰がどう気づいたか、直近で行った作業（更新、プラグイン追加、作業者）です。

同時に「対応ログ」を始めましょう。何時に誰が何をしたかを時系列でメモしておくと、後の原因調査、関係者への報告書、個人情報保護委員会への報告に、そのまま使えます。スクリーンショットに個人情報が写っている場合は、取り扱いに注意してください。

②訪問者への被害を止める

マルウェアの配布、フィッシング、不正リダイレクトが疑われる場合は、訪問者を守るためにサイトを一時的に隔離します。方法は、被害の深刻さに応じて選びます。

決済や会員登録のフォームがある場合は、最優先で停止してください。また、同じサーバー上の別のサイトを誤って止めないよう、対象のディレクトリをよく確認しましょう。

③ログと感染状態を保全する

原因調査に必要なデータを、安全な場所へコピーします。保全するのは、WordPressのファイル一式、データベースのダンプ、アクセスログとエラーログ、WAFやセキュリティプラグインのログです。

レンタルサーバーのアクセスログは、保存期間が数日から数週間と短いことがあります。消える前に、すぐダウンロードしてください。

保全した「感染状態のデータ」は、復元用のバックアップとは明確に分けて保管します。フォルダ名に「感染」「調査用」と付け、公開領域ではない場所に置き、扱える担当者を限定しましょう。

④安全な端末から全認証情報を変更する

攻撃者はパスワードを盗んでいる可能性があります。変更作業は、感染していないことが確認できる端末から行ってください。作業用パソコンがマルウェアに感染し、FTPのパスワードを盗まれたことが侵入の原因というケースもあるためです。

変更対象の一覧

WordPressの管理者パスワードだけを変えても、他の入口が残っていれば再侵入されます。サイトに変更を加えられる入口を、すべて洗い出して変更します。

• WordPressの全ユーザー（特に管理者と編集者）
• サーバーのコントロールパネル
• FTP、SFTP、SSH（SSH鍵も含む）
• データベース（変更後はwp-config.phpの設定も更新）
• メールアカウント
• ドメインの管理画面（レジストラ）、DNS、CDN
• サーチコンソール、Googleアナリティクス、広告アカウント
• 外部サービスと連携しているAPIキー

パスワードは使い回さず、サービスごとに固有の強いものにしてください。2段階認証が使えるサービスは、この機会に有効にします。

全ログインセッションの無効化

パスワードを変更しても、攻撃者がすでにログインしている状態（セッション）は残ることがあります。

WordPressでは、wp-config.phpのセキュリティキー（ソルト）を新しいものに差し替えると、全ユーザーを強制的にログアウトできます。新しいキーはWordPress公式の生成ページ（api.wordpress.org/secret-key/1.1/salt/）で作成できます。

サーバーのコントロールパネルやGoogleアカウントなども、「すべての端末からログアウト」を実行してください。

⑤関係者へ第一報を入れる

原因がわからない段階でも、関係者への第一報は早めに入れます。連絡先と目的は次のとおりです。

＝＝＝

被害発覚直後の誤ったファイル削除や一括更新は、復旧を困難にする最大の原因です。

サイト引越し屋さんでは、感染状態の保全からアクセスの緊急遮断、安全なバックアップの選定まで、被害を最小限に抑える初動対応を代行します。

>>無料ご相談窓口はこちらをクリック

原因調査と被害範囲の特定

復旧の前に、「どこから入られたか」と「どこまで被害が及んでいるか」を特定します。原因を特定しないまま復旧すると、同じ侵入口から再び改ざんされます。

ここではサーバー作業ができる担当者向けに、具体的な調査方法を解説します。技術的な作業が難しい場合は、専門業者への依頼を検討してください。

WordPressへのよくある侵入経路

WordPressで公表される脆弱性の大半は、プラグインとテーマに由来します。本体を最新にしていても、プラグインが古ければ侵入を許します。代表的な侵入経路は次のとおりです。

サイト引越し屋さんが過去に対応した事例でも、侵入経路がプラグインの脆弱性である案件は多々あります。

あるプラグインに「ログインなしで管理者権限を得られる」脆弱性が公表された2日後には、不正な管理者アカウントが作られていました。

攻撃元のIPアドレスは米国、オランダ、フランスなど毎回異なり、公開された攻撃コードを使った無差別なスキャンだったと考えられます。

あるクライアントのサイトでは、バージョンを固定するプラグインの影響でWordPress本体も古いまま止まっており、更新画面には「最新バージョンをお使いです」と表示されていました。

また別の事例では、お客様が後から同じサーバーに追加したサイトだけWAFが無効になっており、そこが侵入口になった可能性がありました。

改ざんファイルの探し方

改ざんファイルは、公式の配布物と比較するのが最も確実です。WP-CLI（WordPressをコマンドで操作するツール）が使える環境なら、次のコマンドで確認できます。

コマンド例（サーバー作業ができる方向け）

# WordPress本体を公式配布物と比較

wp core verify-checksums

# 公式ディレクトリ掲載プラグインを公式配布物と比較

wp plugin verify-checksums --all

# 直近7日以内に更新されたPHPファイルを探す

find . -name "*.php" -mtime -7

# uploadsフォルダ内のPHPファイルを探す（原則として存在しないはず）

find wp-content/uploads -name "*.php"

# 難読化コードによく使われる関数を含むファイルを探す

grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" --include=*.php .

最後のコマンドは、正規のプラグインも検出することがあります。検出されたファイルは中身を確認し、公式配布物と比較して判断してください。また、ファイルの更新日時は攻撃者が偽装できるため、日時だけで判断しないでください。

ファイル以外では、.htaccessに特定の条件（検索エンジン経由、スマートフォンなど）で転送するような記述がないか、wp-config.phpの冒頭や末尾に不審なコードがないか、mu-pluginsフォルダに見覚えのないファイルがないかも確認します。

データベースの確認ポイント

改ざんはファイルだけでなく、データベースにも及びます。管理者ユーザー、サイトURLの設定、予約処理（cron）、投稿やオプションに埋め込まれたスクリプトを確認します。データベースを操作する前には、必ずダンプを取得してください。

コマンド例（サーバー作業ができる方向け）

# 管理者ユーザーの一覧

wp user list --role=administrator

# サイトURLが書き換えられていないか

wp option get siteurl
wp option get home

# 登録されている予約処理（cron）の一覧

wp cron event list

# 投稿やオプションに埋め込まれたスクリプトを探す（SQL）
　※テーブル名の「wp_」は環境によって異なります

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

アクセスログから侵入の痕跡を読む

アクセスログは、侵入の時期と経路を特定する最も重要な証拠です。たとえば次のような記録は、典型的な攻撃の痕跡です。

ログの例

203.0.113.5 - - [12/Sep/2026:03:14:07 +0900] "POST /wp-login.php HTTP/1.1" 200
203.0.113.5 - - [12/Sep/2026:03:14:09 +0900] "POST /xmlrpc.php HTTP/1.1" 200
198.51.100.8 - - [13/Sep/2026:02:01:44 +0900] "POST /wp-content/uploads/2026/09/cache.php HTTP/1.1" 200

1行目と2行目は、ログイン画面とXML-RPCへの総当たり攻撃の可能性を示します。3行目のように、uploadsフォルダ内のPHPファイルへPOSTリクエストが成功している場合は、バックドアが使われている可能性が高いと言えます。

調べ方のコツは、先ほど見つけた改ざんファイルの更新時刻の前後を集中的に見ることです。

特定のプラグインのファイルやadmin-ajax.phpへの不審なリクエストが見つかれば、そのプラグインの脆弱性を突かれた可能性があります。

ここで特定した「最初の侵入時刻」は、どの時点のバックアップが安全かを判断する材料になります。

＝＝＝

バックドアや難読化された不正コードは、ファイルの日時偽装やmu-pluginsへの隠蔽など巧妙に見失わせる細工がされています。

そのため、エンジニアがサーバーログとファイル差分を徹底調査し、侵入口を突き止める必要があります。自社で対応が難しい場合は専門的への依頼が確実です。

>>サイト引越し屋さんへの無料相談窓口はこちらをクリック

同じサーバー契約内の別サイトも調べる

見落とされやすいのが、同じサーバー契約内にある別のサイトです。多くのレンタルサーバーでは、同じ契約内のサイトが同じユーザー権限で動いています。そのため、1つのサイトが乗っ取られると、他のサイトのファイルも書き換えられる状態になります。

特に危険なのは、更新されずに放置された古いサイトや、テスト環境、使っていないWordPressです。1サイトだけ直しても、別のサイトに残ったバックドアから再感染します。同じ契約内にあるWordPressをすべて洗い出し、同じ調査を行ってください。

当社が復旧を担当した法人様のケースでは、1つのサーバー契約の中に数十個のWordPressが置かれ、不正なファイルが10か所以上に設置されていました。

お客様からは「重要な1サイトだけ直せばよいのでは」とご相談いただきましたが、他のサイトや共通領域に残った不正ファイルから再感染する可能性が高いため、クリーンな別サーバーへ分けて移すことをご提案しました。

あわせて、使っていないサブドメインやサブディレクトリを精査・削除しました。

1つのサーバーに多くのサイトをまとめると、共倒れのリスクが高まります。当社では、1サーバーに置くサイトは理想は1つ、多くても3〜5つ程度に抑えることをおすすめしています。

マルウェアスキャンツールの使い分け

スキャンツールは、大きく2種類あります。1つは、Sucuri SiteCheckのように外部から公開ページをスキャンするツールです。手軽ですが、見えるページしか調べられません。

もう1つは、Wordfenceなどのセキュリティプラグインや、サーバー会社が提供するサーバー内部をスキャンするツールです。ファイル単位で検査できます。

ただし、スキャンツールは万能ではありません。「検出されなかった＝安全」ではない点に注意してください。また、感染後にプラグインをインストールすると、攻撃者のコードが動いている環境でスキャンすることになり、正しく検出できないことがあります。

スキャン結果は、手作業の調査を補う材料として使いましょう。

WordPressの復旧方法と手順

原因と被害範囲が見えたら、復旧に進みます。復旧方法は大きく3つあり、バックアップの有無、被害の深刻さ、侵入口の特定度合いによって選びます。

どの方法を選ぶ場合でも、侵入口を塞いでから公開することが共通の原則です。

3つの復旧パターンの比較

判断に迷ったら、「再発を確実に防げるか」を最優先にしてください。一度再発すると、Googleの評価も顧客の信頼も、さらに大きく損なわれます。

バックアップから復元する手順

最も重要なのは、どの時点のバックアップが安全かを見極めることです。アクセスログで特定した最初の侵入時刻より前のバックアップを選びます。

攻撃者はバックドアを仕込んでから、しばらく経って改ざんを始めることがあります。症状が出た日の直前のバックアップが安全とは限りません。

手順は次のとおりです。

1. 感染状態のデータが保全済みであることを確認する
2. 安全と判断した時点のバックアップを復元する
3. 公開する前に、認証情報の変更と侵入口の修正（脆弱なプラグインの更新・削除など）を行う
4. 改ざんファイルの調査と同じ方法で、再度チェックする
5. 問題がなければ公開する

復元すると、バックアップの時点以降に追加した記事や注文データは失われます。感染状態のデータから、記事の本文や注文情報だけを確認しながら戻してください。

バックアップがない場合のクリーンアップ手順

バックアップがない場合は、感染したサイトから不正なものを取り除きます。基本方針は、疑わしいファイルを探して消すのではなく、公式の正常なファイルで丸ごと置き換えることです。

1. WordPress本体を公式配布物で置き換える（wp-adminとwp-includesを丸ごと入れ替える）
2. プラグインとテーマを、公式サイトや販売元から入手し直して置き換える
3. 自作テーマや独自コードは、正常な版と差分を比較して改ざん部分を取り除く
4. uploadsフォルダ内のPHPファイルなど、画像以外の不審なファイルを削除する
5. .htaccessとwp-config.phpの不審な記述を取り除く
6. データベース内の不審なスクリプト、ユーザー、予約処理を削除する

見落としが1つでもあると再発するため、作業後は改めてスキャンと手作業の確認を行ってください。

当社サイト引越し屋さんでクリーンアップ後の確認を行う際は、WordPress本体とプラグインのファイルを公式配布物のチェックサムと照合し、改ざんがないかを確かめています。

あわせて、uploadsフォルダ内のPHPファイル、mu-pluginsフォルダ、テーマのfunctions.phpを確認し、eval、base64_decode、gzinflate、shell_execなど、不正なコードによく使われる関数を検索します。

なお、uploadsフォルダ内のPHPファイルがすべて不正とは限りません。セキュリティプラグインなどが作る正常なファイルもあるため、中身を確認してから削除してください。

クリーンなサーバーへ再構築・移行する手順

被害が広範囲に及んでいる場合や、再発を繰り返している場合に最も確実なのが、クリーンな環境への再構築です。新しいサーバー、または新しいディレクトリに、公式配布物のWordPress本体とプラグインをインストールし、検証済みのデータだけを移します。

移すのは、記事などのデータベースの中身と、画像ファイルだけです。uploadsフォルダは丸ごとコピーせず、画像の拡張子（jpg、png、webpなど）のファイルに絞って移すことで、バックドアの持ち込みを防げます。データベースも、不審なユーザーやスクリプトを取り除いてから移します。

移行後に動作確認をして、DNSを切り替えれば完了です。サーバー環境やPHPのバージョンを見直す機会にもなります。

ただし、元の環境に戻せず作り直しになると、時間がかかります。2026年10月にランサムウェア被害を受けた日本バスケットボール協会の公式サイトの例では、新しい環境での再構築に1か月以上かかる見通しとも言われています。

以前にサイト引越し屋さんにて対応した案件では、1つのサーバー内の多数のサイトが感染しており、公開ディレクトリの外まで不正ファイルが広がっていたため、新しいサーバーでの再構築を選びました。

復旧作業では、既存ユーザーの権限をいったんすべて無効化し、2種類のマルウェアスキャンで検知がないことを確認したうえで、本体・プラグイン・テーマを最新版に更新し、サーバーのWAFも有効にしています。

メールは旧サーバーに残し、DNSのAレコードだけを新サーバーに向けることで、メールを止めずにWebサイトだけを切り替えました。作業期間の目安は1サイトあたり2〜4日で、最初の1サイトは依頼の翌日に復旧しています。

侵入口を塞いでから公開する

どの方法で復旧した場合でも、公開の前に侵入口を塞ぎます。バックアップを戻しただけでは、侵入された原因は残ったままです。下記の点に注意してください。

• 侵入に使われたプラグインやテーマを、更新・削除・代替品へ変更する
• 使っていないプラグイン、テーマ、ユーザーを削除する
• すべての認証情報を変更し、2段階認証を有効にする（初動で済んでいれば再確認）
• ファイルの権限設定を適正にする
• 同じサーバー内の他サイトも、同じ対策を済ませる

SEOと信用への影響を最小化するGoogle対策

サイトを復旧しても、Googleの警告や検索結果に残ったスパムページは、自動ではすぐに消えません。ここからは、検索順位と信用へのダメージを最小限に抑えるためのGoogle対策を解説します。

ハッキングによる検索順位への影響

Melapressの調査では、検索エンジンの警告をきっかけに発覚したインシデントのうち46%で検索順位の低下が起きていました。他の経緯で発覚したケースでは14.5%で、約3倍の差があります。これは警告そのものが原因というより、検索エンジンに見つかるほど長く放置された結果と考えられます。

調査には、ハッキング後にアクセスが急減し、順位が完全には戻らなかったというECサイトの事例も紹介されています。早く気づき、早く対処するほど、検索順位へのダメージは小さく抑えられます。

「セキュリティの問題」と「手動による対策」の違い

サーチコンソールには、ハッキングに関係するレポートが2つあります。

「セキュリティの問題」は、マルウェア、フィッシング、ハッキングされたコンテンツなど、訪問者に危険が及ぶ問題を知らせるレポートです。ブラウザの警告表示の原因になります。

「手動による対策」は、Googleのスパムポリシーに違反していると判断された場合に表示されるレポートです。ハッキングで作られたスパムページが原因で、サイトが手動による対策を受けることもあります。

どちらか一方だけを確認して終わりにせず、両方を確認してください。

サーチコンソールで再審査をリクエストする手順

サイト全体の修正が終わったら、Googleに再審査をリクエストします。

1. サイト全体の問題と侵入口をすべて修正する
2. 該当するレポートを開き、表示されている問題をすべて確認する
3. 「審査をリクエスト」から、行った対応を具体的に記入する（何が起きたか、何をどう修正したか、再発防止策）
4. 審査結果を待つ

レポートに表示されるURLはあくまで例です。表示されたページだけを直しても、他のページに問題が残っていれば審査は通りません。審査には数日から数週間かかることがあります。審査中に同じリクエストを繰り返し送らず、再感染がないか監視を続けてください。

スパムURLをインデックスから削除する

日本語スパムなどで作られたページは、サイトから削除した後も検索結果に残ります。削除したスパムURLには、「404（見つからない）」ではなく「410（完全に削除済み）」を返すと、Googleにより早く削除を伝えられます。スパムURLに共通するパターンがあれば、.htaccessでまとめて410を返せます。

.htaccessの記述例

# 例：/spam-dir/ 配下のスパムURLに410を返す
RewriteEngine On
RewriteRule ^spam-dir/ - [G]

あわせて、正しいサイトマップをサーチコンソールに送信し直してください。サーチコンソールの「削除」ツールを使えば、検索結果から急いで非表示にできますが、効果は約6か月の一時的なものです。410の設定と組み合わせて使いましょう。

ブラックリストの解除

Googleセーフブラウジングの判定状況は、Googleの透明性レポートで確認できます。サーチコンソールで審査が通れば、ブラウザの警告も解除されます。セキュリティソフトの会社ごとにも独自のブラックリストがあるため、訪問者から警告の報告があれば、各社の申請窓口から再審査を依頼します。

スパムメールの踏み台にされた場合は、メール送信のブラックリスト（RBL）に登録されていないか確認してください。解除申請は各リストの運営者に行いますが、原因を解消する前に申請すると、再登録されて解除が難しくなります。

サイト引越し屋さんにてハッキングの復旧をお受けする際も、サイトを直す作業とは別に、サーチコンソールでの不正なインデックスの削除、Webサイトのブラックリストやセキュリティソフト各社のスパム登録の削除、独自ドメインのメールアドレスのスパム判定の解除が必要になるケースがあることを、事前にお伝えしています。

ハッキングでサイトが長期間止まると、Googleから危険なドメインと見なされ、その後の検索順位も上がりにくくなります。サイトの復旧とあわせて、できるだけ早く解除の手続きまで進めてください。

法的な報告義務と顧客へのお知らせ

ハッキングで個人情報が漏えいした、またはそのおそれがある場合、法律に基づく報告と本人への通知が必要になることがあります。報告の期限は短いため、初動の段階から視野に入れておきましょう。

なお、本章は一般的な情報です。個別の判断は、弁護士や個人情報保護委員会の相談窓口に確認してください。

個人情報漏えい時の個人情報保護委員会への報告

2022年4月に施行された改正個人情報保護法により、一定の漏えいが起きた場合の報告と本人への通知が義務になりました。報告の対象となるのは、次のいずれかに当てはまる場合です。

参考：「個人情報保護法」を分かりやすく解説。個人情報の取扱いルールとは？ – 政府広報オンライン

• 要配慮個人情報（病歴など）が漏えいした
• 財産的な被害が生じるおそれがある（クレジットカード情報など）
• 不正の目的によるおそれがある（不正アクセスによる漏えいなど）
• 1,000人を超える漏えいがあった

不正アクセスによる漏えいは、1件でも、また「漏えいのおそれ」の段階でも報告の対象です。ハッキングはこれに当たる可能性が高いと考えてください。

報告は2段階です。速報は、事態を知ってから速やかに（おおむね3〜5日以内）行います。確報は30日以内、不正の目的による場合は60日以内に行います。あわせて、影響を受ける本人への通知も必要です。

クレジットカード情報が関係する場合

決済ページの改ざんなど、カード情報の漏えいが疑われる場合は、すぐに決済代行会社とカード会社に連絡してください。被害拡大を防ぐため、カード決済の停止を求められることが一般的です。

また、カード業界のセキュリティ基準（PCI DSS）に基づく専門のフォレンジック調査会社による調査を求められることがあります。調査には時間と費用がかかるため、ECサイトでは平時から決済まわりのセキュリティを特に重視してください。

IPAやJPCERT/CCへの届出・相談

法的な義務ではありませんが、公的機関への届出や相談も検討してください。

業種によっては、監督官庁への報告が別途必要な場合もあります。

顧客向けお知らせ文のテンプレート

サイトの閲覧者や顧客へのお知らせ文の例です。あくまで一般的なひな形としてのサンプルになりますので、各々の会社に合わせた形で編集してお使いください。

事実がわかっている範囲で、正確に書くことが大切です。

当社ウェブサイトへの不正アクセスに関するお知らせとお詫び

平素より当社ウェブサイトをご利用いただき、誠にありがとうございます。
◯年◯月◯日、当社ウェブサイトが第三者による不正アクセスを受け、
一部のページが改ざんされていたことが判明いたしました。

1. 発生した事象
　◯月◯日から◯月◯日までの間、当社サイトの一部ページにアクセスした際、
　外部の不審なサイトへ転送される状態となっておりました。

2. 現在の状況
　◯月◯日に原因を特定して修正を完了し、安全を確認した上でサイトを再開しております。
　現時点で、お客様の個人情報の漏えいは確認されておりません。
　（※漏えいがある場合は範囲を記載）

3. お客様へのお願い
　上記期間中に当社サイトを閲覧された方は、お使いの端末で
　セキュリティソフトによるスキャンを実施いただきますようお願いいたします。

4. 再発防止策
　セキュリティ対策の強化と監視体制の見直しを実施いたしました。

お客様にはご迷惑とご心配をおかけしましたことを、深くお詫び申し上げます。

お問い合わせ窓口：◯◯（電話・メール・受付時間）

WordPressのハッキング再発を防ぐセキュリティ対策

一度ハッキングされたサイトは、再び狙われやすくなります。攻撃者のリストにサイトが載っていたり、侵入の自動化ツールに脆弱性を知られていたりするためです。復旧で終わりにせず、再発を防ぐ仕組みを整えましょう。

アップデート運用と不要なプラグイン・テーマの削除

侵入経路の多くを占めるプラグインとテーマの脆弱性は、更新で防げます。自社運用かつリソースが限られている場合には、WordPress本体のマイナー更新とプラグインは自動更新を有効にしておくことも検討してください。

自社で対応が難しい場合や大きなバージョンアップについては、専門業者への委託を推奨します。

長期間更新されていないプラグインは、開発が止まっている可能性があります。代わりのプラグインへの乗り換えを検討してください。また、使っていないプラグインとテーマは「無効化」ではなく「削除」してください。無効化していても、ファイルが残っていれば脆弱性を突かれることがあります。

ログインの強化

管理画面へのログインは、攻撃者が最も狙う入口です。次の対策を組み合わせて強化します。

• adminなど推測しやすいユーザー名を使わない
• パスワードはローマ字（大文字・小文字）や数字を組み合わせた12桁以上の内容にする
• ログイン画面のURLを変更し、デフォルトログイン画面からのリダイレクトを解除する
• ログイン画面に画像認証を導入する
• ログインの試行回数を制限する
• 可能であれば、管理画面へのアクセスをIPアドレスで制限する

WAFと改ざん検知・稼働監視

WAFは、脆弱性を狙った攻撃を入口で防ぐ仕組みです。多くのレンタルサーバーに標準で搭載されているほか、クラウド型のWAFやセキュリティプラグインでも導入できます。

あわせて、ファイルの変更を検知して通知する改ざん検知と、サイトが正常に表示されているかを確認する稼働監視を導入しましょう。

サーチコンソールのメール通知も必ず有効にしてください。Melapressの調査で最も多かった「他人からの指摘で気づく」状態から、「自分たちが先に気づく」状態に変えることが目標です。

バックアップの基本は独立環境

バックアップで最も避けるべきなのは、Webサーバーと同じ領域にバックアップファイルを保管しておくことです。サーバー自体がハッキングを受けたり管理者権限を奪われたりした場合、サーバー内のバックアップファイルごと改ざん・削除されて復元手段を失います。

WordPressが稼働しているサーバーとは完全に切り離された外部ストレージ（AWS S3、Google Cloud Storage、Dropboxなど別系統のクラウドやローカル環境）へバックアップを保管してください。

WordPressと自動連携する場合は、APIやユーザー権限を細かく制御できるAWS S3が推奨です。

また、WordPressのハッキングは、侵入された当日に気づくとは限りません。数週間〜数カ月前から潜伏してバックドアが仕込まれているケースも多いため、直近数日分の上書き保管だけでは改ざん後のデータしか戻せなくなります。

被害前の正常な状態までさかのぼれるよう、少なくとも数ヶ月分の履歴保持を推奨します。

ユーザー権限の管理と編集者への教育

WordPressのユーザーには、必要最小限の権限を与えます。記事を書くだけの人は「投稿者」や「編集者」にし、「管理者」は限られた人だけにしてください。退職者や契約が終わった外部スタッフのアカウントは、すぐに削除します。1つのアカウントを複数人で共有するのもやめましょう。

また、サイトのセキュリティは、管理者以外の行動にも左右されます。フィッシングメールに注意すること、出所のわからないプラグインを入れないこと、異変に気づいたらすぐに報告することを、編集に関わる全員で共有してください。

WordPressのハッキング対応でよくある質問

WordPressのハッキング対応について、よくいただく質問にお答えします。

Googleの危険なサイトという警告は、いつ消えますか？

サイト全体の問題と侵入口を修正し、サーチコンソールで審査をリクエストして、審査が通れば解除されます。審査には数日から数週間かかることがあります。修正が不十分だと審査が通らず、解除までの期間が延びるため、全体を確認してからリクエストしてください。

バックアップを戻せば、復旧は完了ですか？

完了ではありません。侵入に使われた脆弱なプラグインや、漏えいした認証情報が残っていれば、同じ経路から再発します。復元の後に、侵入口の修正と認証情報の変更を必ず行ってください。

ハッキングの復旧費用はどれくらいですか？

被害の範囲、サイトの規模、侵入口の特定の難しさ、復旧対応の内容によって大きく変わります。
弊社サイト引越し屋さんの場合には、WordPressハッキングの復旧対応を4万円（税別）～ご対応しております。

ハッキングされたら、サーバーやドメインを変えるべきですか？

必須ではありません。ただし、被害が広範囲な場合は、クリーンなサーバーへの移行が再発防止に有効です。ドメインは、変更すると検索エンジンの評価を引き継ぐのが難しくなるため、原則として変えないほうがよいでしょう。

小さなサイトでもハッキングされるのですか？

されます。WordPressへの攻撃の多くは、脆弱性のあるサイトを自動で探して侵入するツールによって行われます。サイトの規模や知名度に関係なく、弱点があれば狙われます。

セキュリティプラグインを入れていれば安全ですか？

セキュリティプラグインは有効な対策ですが、万能ではありません。プラグイン自体が無効化されることもあります。更新、ログインの強化、バックアップ、監視を組み合わせた多層的な対策が必要です。

まとめ

WordPressのハッキング対応で大切なのは、慌てて消したり戻したりする前に、記録と保全から始めることです。そのうえで被害を止め、原因と侵入口を特定し、正常な状態に戻してから公開します。Googleの警告解除や法的な報告、顧客へのお知らせまで終えて、はじめて対応は完了します。

そして、最も効果的な対策は、被害に遭う前の備えです。更新と監視で侵入を防ぎ、復元テスト済みのバックアップと対応計画で「復旧力」を高めておきましょう。自社での対応が難しい場合や、今まさに被害を受けている場合は、サイト引越し屋さんにご相談ください。