WordPressのマルウェア感染でサーバー会社から利用停止された時の確認と再開手順

レンタルサーバー会社から「マルウェアが検出されたため、サーバーやWebサイトの利用を停止しました」と連絡が届き、突然WordPressが表示されなくなって困っていませんか？
管理画面やFTPにも入れず、どのファイルを直せば再開してもらえるのか分からないと、事業への影響も心配になります。

結論から言うと、利用停止を解除する近道は、見つかったファイルだけを慌てて消すことではありません。
通知を保存し、停止範囲と検出根拠、作業できる接続方法、再審査条件を確認したうえで、侵入口まで復旧した証拠をサーバー会社へ提出する必要があります。

この記事では、特定のサーバー会社だけに通用する画面操作ではなく、共用サーバーやクラウド型ホスティングで共通して使える判断順を説明します。
会社ごとに規約や解除条件は異なるため、最終的には届いた通知と公式サポートの指示を優先してください。

WordPressのマルウェアでサーバーが利用停止された直後の初動

WordPressのマルウェアを理由に利用停止された直後は、通知を消さず、現在の状態を変えすぎないことが最優先です。
停止は困る出来事ですが、外部への不正通信や迷惑メール送信、他の利用者への影響を止めるために、サーバー会社が隔離している場合があります。

利用停止通知の全文と受信時刻を保存する

最初に、メール、管理パネルのお知らせ、チケット番号、表示中の警告画面を保存します。
通知に添付された検出ファイル名、対象ドメイン、契約ID、期限、問い合わせ先も、省略せず記録してください。

メール本文だけでなく、受信日時と差出人ドメインも必要です。
停止を装うフィッシングメールの可能性を除くため、メール内のリンクを直接開かず、普段使っているブックマークや公式サイトからサーバー管理画面へ入り、同じ通知があるか確かめます。

電話で説明を受けた場合は、対応日時、担当部署、聞いた内容、次に連絡する窓口をメモします。
あとから担当者が変わっても、同じ前提で話せる記録にしておくと、再審査の行き違いを減らせます。

見つかったファイルを何度も削除しない

通知に不審なPHPファイル名が書かれていても、保存前に削除を繰り返すのは避けてください。
更新日時、設置場所、所有者、権限、ハッシュ値、周辺ログは、侵入時期と感染経路を考える材料になります。

一つ削除して利用再開を申請しても、別のバックドアや不正な管理者、改ざんされたデータベースが残っていれば再検出されます。
再開と再停止を繰り返すと、事業への影響が長引くだけでなく、サーバー会社から追加の確認を求められることもあります。

社内の連絡窓口と作業担当を一本化する

複数人が別々にサーバー会社へ連絡し、同時にファイルやパスワードを変更すると、何が原因で状態が変わったのか分からなくなります。
サーバー会社との窓口、技術作業の担当、社内報告の責任者を決め、変更内容を一つの時系列へ集めてください。

WordPressのマルウェアによる利用停止範囲と検出根拠の確認

WordPressのマルウェアで利用停止になったら、どこまで止められているかと、何を根拠に停止されたかを分けて確認します。
Webサイトが表示されないことと、契約アカウント全体が無効になったことは同じではありません。

サイト単位・サーバー単位・契約単位を分ける

確認したいのは、対象ドメインだけの公開停止なのか、同じサーバー内の全ドメインが止まったのか、FTPやSSH、データベース、メール、管理パネルまで制限されたのかです。
共用サーバーでは、一つの契約に複数サイトがあるため、感染したWordPress以外も調査対象になる場合があります。

メールが使える場合でも、Webから不正送信が発生していないとは限りません。
反対に、メール送信だけ制限され、Web閲覧や管理パネルは利用できるケースもあるので、「何ができないか」を機能ごとに確認します。

検出ファイル・不正通信・負荷の根拠を聞く

通知が「マルウェアを検出しました」だけなら、サーバー会社へ検出日時、対象パス、検出名、隔離や削除の有無を問い合わせます。
可能なら、ファイルのハッシュ値、所有者、更新日時、関連するアクセスログやプロセス情報も確認してください。

停止理由がCPU負荷、外部への大量通信、迷惑メール、フィッシングページ、他サイトへの攻撃である場合は、ファイル検出だけの問題ではありません。
どの時刻に、どの接続元または送信先へ、どの程度の挙動があったかを聞くと、調査対象と再発確認の基準を決めやすくなります。

復旧期限・データ保持・再審査条件を確認する

利用停止中のデータがいつまで保持されるか、自動削除や契約終了の期限があるかは、復旧作業より先に確認すべき重要事項です。
バックアップが取得できない状態で期限を迎えると、感染前の業務データや調査証拠まで失う恐れがあります。

再開申請に必要なものも、会社によって異なります。
感染ファイルの削除報告だけでよいのか、原因、対処、認証情報変更、更新、再発防止まで必要か、指定の申請フォームや書式があるかを確認してください。

WordPressのマルウェア調査を制限中でも安全に進める方法

WordPressのマルウェア調査は、利用停止を無理に回避するのではなく、サーバー会社が許可した方法で証拠とデータを確保して進めます。
別サーバーへそのままコピーして公開すると、感染ファイルまで移し、被害を別の環境へ広げる危険があります。

許可された接続方法と一時解除の範囲を確認する

管理パネル、FTP、SFTP、SSHがすべて使えない場合は、調査用の一時接続、特定IPだけの許可、ファイルマネージャー、バックアップ提供のどれが可能かを問い合わせます。
一時解除が認められたら、開始時刻、許可時間、許可された操作、終了連絡の方法を記録します。

アクセスが戻ったからといって、すぐ一般公開へ切り替える必要はありません。
可能なら外部公開を止めたまま、管理者や復旧担当の接続元だけを許可し、調査中のサイトが攻撃や再感染の入口にならない状態を維持します。

現状バックアップと安全な作業コピーを分ける

取得するバックアップは、「そのまま復元する安全なバックアップ」ではなく、「感染時点の状態を保存した調査用コピー」として扱います。
Webファイル、データベース、サーバー設定、ログ、メール設定、cron、DNS、管理者一覧を、感染した環境とは別の保護された保存先へ置いてください。

原本は変更せず読み取り専用に近い状態で保管し、解析や削除は複製した作業コピーで行います。
取得日時、ファイルサイズ、ハッシュ値、取得者を記録すれば、途中で内容が変わっていないか確かめられます。

アクセスできない時は必要資料を具体的に依頼する

サーバー会社が一時接続を認めない場合は、「調査できません」で終わらせず、提供してほしい資料を具体的に伝えます。
対象パスの圧縮データ、データベースダンプ、検出ログ、アクセスログ、メール送信ログ、自動バックアップの取得日時などを依頼します。

サポートが提供できる範囲には限りがありますが、質問が具体的なら可否を判断してもらいやすくなります。
個人情報や認証情報を含むデータの受け渡し方法、暗号化、保存期限も確認し、通常メールへ無防備に添付しないでください。

WordPressのマルウェアを侵入口まで復旧する手順

WordPressのマルウェア復旧は、検出ファイルをゼロにするだけでなく、攻撃者が入った入口と残された権限を閉じるところまで必要です。
サーバー会社のスキャンに合格しても、認証情報や脆弱なプラグインが残れば、利用再開後に再び設置される恐れがあります。

ファイル・データベース・管理者・設定を横断して確認する

WordPress本体、テーマ、プラグイン、uploads、ドキュメントルート外のファイルを、正規配布物や既知の正常版と比較します。
最近更新されたPHPだけでなく、画像に偽装した実行ファイル、.htaccess、wp-config.php、cron、サーバーの自動実行設定も確認します。

データベースでは、不審な管理者、見覚えのない投稿・固定ページ、外部へ飛ばすJavaScript、変更されたサイトURL、追加された自動読み込み設定を調べます。
ファイルが正常でもデータベースに不正コードが残る場合があり、その逆もあるため、片方だけの確認では不十分です。

正規ファイル差し替えと不審コード隔離を使い分ける

WordPress本体や配布元が明確なプラグインは、感染箇所を手作業で一行ずつ削るより、正規版へ差し替える方が確認しやすいことがあります。
ただし、独自テーマやカスタマイズ、アップロード済みデータを一律で上書きすると、正常な機能や顧客データを失うため、対象を分けます。

不審ファイルは、証拠を保存したうえで公開領域から隔離し、正規の用途がないか確認します。
ファイル名が不自然でも正規プラグインの一部である場合があり、反対に自然な名前でもバックドアの場合があるので、名前だけで削除判断をしないでください。

認証情報・脆弱性・外部連携を更新する

復旧作業は、安全な端末からサーバー管理、ドメイン、メール、SFTP・SSH、データベース、WordPress管理者、外部APIの認証情報を整理します。
同じパスワードの使い回しをやめ、利用できる場所では二要素認証を有効にし、既存セッションとアプリパスワードも失効させます。

侵入に利用された可能性があるWordPress本体、テーマ、プラグイン、PHP環境を更新し、不要なものを削除します。
更新できない古い製品は、公開範囲を制限する、置き換える、別環境へ隔離するなど、再開前に運用判断が必要です。

フォームのSMTP、決済、バックアップ、CDN、アクセス解析などの外部キーも確認対象です。
漏えいの可能性があるキーは再発行し、旧キーが確実に無効になったことを確認してください。

WordPressの利用再開を申請する作業報告の作り方

WordPressの利用再開申請では、「直しました」という結論だけでなく、何を確認し、何を変更し、何をもって再発防止できたと判断したかを伝えます。
サーバー会社は、共用環境や外部への被害が再び起きないかを判断するため、作業の再現性と確認根拠を必要とします。

検出内容と実施作業を時系列で整理する

報告は、通知受信、バックアップ取得、調査開始、感染箇所特定、隔離・差し替え、認証情報変更、更新、検証の順に書きます。
対象ファイルや設定はパスと役割を示し、削除したのか、正規版へ差し替えたのか、設定変更したのかを区別します。

検出されたファイル以外も調べた場合は、確認範囲を明記します。
たとえば、同一契約内の他サイト、データベース、管理者一覧、cron、メール送信ログまで確認したことが分かれば、一件だけを消した報告との差が伝わります。

侵入原因は根拠と確度を分けて書く

脆弱なプラグインの悪用ログなど根拠がある場合は、製品名、当時のバージョン、該当時刻、更新または削除した内容を書きます。
原因を特定できない場合は、断定せず「確認できた事実」「可能性がある経路」「確認できなかった範囲」に分けてください。

原因が分からないことを隠して「完全に安全です」と書くより、残る不確実性と監視方法を示す方が正確です。
ログ保存期間が短い、アクセスできない領域があるなどの制約も書き、サーバー会社に追加確認が必要か相談します。

再発防止と監視期間を具体化する

更新した、パスワードを変えた、という一回の作業だけでなく、今後いつ誰が何を確認するかを書きます。
管理者一覧、ファイル変更、ログイン、外部通信、メール送信数、WordPress更新、バックアップ成功を、再開直後は短い間隔で監視します。

サーバー会社から指定のスキャンや再審査手順がある場合は、その結果も添えます。
ただし、スキャン結果が正常でも未知の侵入経路を完全に否定できるわけではないため、監視と更新を継続する前提で報告してください。

WordPressのサーバー再開後に確認する項目

WordPressのサーバー利用が再開されても、トップページが表示された時点で完了にはできません。
公開系、管理系、メール、外部連携、検索、ログを分け、停止前と同じ機能が安全に動くか確認します。

公開ページ・管理画面・SSL・DNSを確認する

PCとスマートフォン、ログインしていないブラウザで、トップ、主要サービス、問い合わせ、購入、会員ページ、404を確認します。
知らないページや外部リダイレクト、警告、証明書エラー、画像欠落、管理画面へのログイン異常がないか見ます。

DNSやCDNを変更した場合は、古いサーバーと新しいサーバーが混在していないかも確認します。
自分の端末だけで正常でも、別回線や別地域では古い設定が残ることがあるため、複数の確認元を使います。

メール・フォーム・定期処理を別々に確認する

メールは外部からの受信、外部への送信、返信、フォーム通知を分けて少数のテストで確認します。
迷惑メール送信を理由に停止された場合は、送信キュー、送信数、バウンス、不審な転送、SMTP資格情報も監視してください。

WordPressの予約投稿、バックアップ、在庫同期、会員通知などの定期処理は、ページ表示が戻っても止まったままの場合があります。
cronや外部APIを再設定した場合は、実行履歴と失敗通知まで確認します。

検索結果・外部通信・再検出を継続監視する

再開後は、検索結果に不審なページが残っていないか、Search Consoleなどにセキュリティ警告がないかを確認します。
サーバーログでは、未知の管理画面ログイン、同じ不審パスへのアクセス、急なCPU負荷、外部通信、メール送信数の増加を見ます。

異常が再発したら、直前の変更と発生時刻を保存し、サーバー会社へ同じチケットで連絡できるようにします。
再停止を恐れて記録を消すのではなく、早い段階で封じ込めれば、被害と停止時間を小さくできます。

WordPressのマルウェアとサーバー利用停止に関するよくある質問

利用停止通知にある感染ファイルだけ消せば再開できますか？

再開できる場合があっても、それだけで安全とは判断できません。別のバックドア、不審な管理者、データベース改ざん、漏れた認証情報、脆弱なプラグインが残ると再検出されます。通知された対象を起点に、同一契約内と侵入口まで確認してください。

FTPに入れない場合は復旧できませんか？

FTP以外に、SFTP・SSH・ファイルマネージャー・特定IPの一時許可・バックアップ提供が使える場合があります。許可なく制限を回避せず、サーバー会社へ調査用の接続方法と提供可能なデータを具体的に問い合わせてください。

感染したデータを別サーバーへ移せば早く公開できますか？

感染状態をそのまま移すと、別環境でも不正通信や改ざんが再開する恐れがあります。調査用コピーは隔離して保存し、クリーンなWordPressへ正規ファイルと確認済みデータだけを戻してから、公開前検証を行うのが安全です。

サーバー会社へ原因を特定したと断言する必要がありますか？

根拠がなければ断言する必要はありません。確認できた事実、可能性がある経路、ログ不足などで未確認の範囲、実施した再発防止と監視を分けて報告します。追加確認が必要かをサーバー会社へ相談できる正確な報告が大切です。

WordPressのマルウェア利用停止は証拠保全から再審査まで順番に進める

WordPressのマルウェアでサーバーを利用停止されたら、通知を保存し、停止範囲、検出根拠、接続方法、データ保持期限、再審査条件を確認します。
感染ファイルを一つ消すだけではなく、ファイル、データベース、管理者、認証情報、脆弱性、外部連携まで確認することが重要です。

復旧後は、実施内容と根拠、未確認の範囲、再発防止、監視計画を時系列で報告し、サーバー会社の再審査を受けます。
利用再開後も、Web表示だけで終えず、メール、フォーム、定期処理、検索結果、ログを確認してください。

アクセスできない、同一契約に複数サイトがある、ログが足りない、再停止したという場合は、状態を変えすぎる前に復旧経験のある担当へ相談すると、証拠と復旧の選択肢を残しやすくなります。

WordPressのマルウェア利用停止を自分で復旧できない時は

サーバー会社から利用停止され、WordPressの調査、マルウェア駆除、再開申請をどこから進めるか分からないなら、
クイックレスキューが被害範囲の確認から復旧・再発防止まで対応します。

状態を変更しすぎる前に相談すれば、調査に必要な証拠と安全な再開手順を残しやすくなります。