サーバー会社から不正アクセス・利用停止の通知が来た時の確認と復旧準備

サーバー会社から『不正アクセスを検知したため利用を停止しました』という通知が来たら、
最初に必要なのは、急いでファイルを削除することではありません。通知の真正性と停止範囲を確認し、消える前に証拠を保存することです。

通知本文にマルウェア、迷惑メール、大量通信、規約違反などと書かれていても、
原因は一つとは限りません。WordPressだけでなく、同じ契約内のメール、FTP、データベース、別サイトまで影響している場合があります。

よこやま良平

20年以上ITエンジニアとして、WordPressの制作・保守・復旧に携わっている、よこやま良平です。サーバー停止を伴う復旧では、技術作業だけでなく、事業者へ提出できる経緯と再発防止策を整えることが重要です。

結論から言うと、正しい順番は『真正性確認→証拠保存→停止範囲確認→封じ込め→原因除去→解除申請→再公開後の監視』です。
停止を回避する裏技を探すのではなく、サーバー会社が安全と判断できる材料を揃えます。

この記事では、料金未払いによる停止や単純なサーバー障害ではなく、
不正アクセス・改ざん・マルウェア・大量送信など、セキュリティ上の理由で利用制限されたケースに絞って解説します。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

サーバー会社の不正アクセス通知は最初に真正性と期限を確認する

サーバー会社から通知が来た時の最初の結論は、メール内のリンクを押さず、
普段使っているブックマークや契約書に記載された公式URLから管理画面へ入り、同じお知らせがあるか確認することです。

攻撃直後は不安が強く、『24時間以内に確認しないと全データを削除する』などの文面を信じやすくなります。
しかし、サーバー会社を装ったフィッシングで認証情報を追加窃取する手口もあるため、通知自体の検証が必要です。

通知メールの差出人だけで本物と判断しない

表示名やFromアドレスは偽装できます。差出人ドメイン、Reply-To、リンク先ドメイン、メールヘッダー、
契約者名・サーバーID・問い合わせ番号の整合を確認し、疑わしい添付ファイルは開かないでください。

停止理由・対象・期限を一つずつ分けて読む

通知では、検知日時、対象ドメイン、契約ID、検知ファイル、送信元IP、停止した機能、回答期限を抜き出します。
『サービス停止』でも、Web公開だけ、メール送信だけ、FTPだけ、契約全体など範囲が違います。

日時にはタイムゾーンを付けてください。サーバーログがUTC、管理画面がJSTの場合、
同じ出来事が9時間ずれて見えます。通知の原文と、自分が換算した時刻を別に記録すると調査が崩れません。

WordPress不正アクセスの症状別診断｜ログイン不能・マルウェア感染の対処法

サーバー会社の通知内容ごとに封じ込め方法を変える

通知に書かれた違反理由によって、最初に止める機能は変わります。
マルウェア検知、迷惑メール送信、外部攻撃への加担、CPU負荷、フィッシングページ公開を同じ手順で扱うと、必要な証拠を取り逃がします。

まず『外部から攻撃を受けた被害』と『侵害されたサーバーが第三者を攻撃した加害通信』を分けてください。
後者ではサイト表示が正常でも、メール送信やPHPの外部通信を早急に止める必要があります。

マルウェア・改ざんファイル検知ではパスと時刻を保存する

検知ファイルの絶対パス、更新時刻、所有者、パーミッション、検知名、ハッシュを保存します。
同名ファイルだけで安全・危険を決めず、正規配布物との差分と、そのファイルへ到達したリクエストを確認します。

サーバー会社が自動隔離している場合は、勝手に元の場所へ戻さず、検体提供の可否を問い合わせます。
隔離済みという事実と、WordPress全体が安全であることは別なので、残存ファイルと永続化設定も調べます。

迷惑メール・フィッシング送信では送信経路を先に止める

メール送信停止の通知では、SMTPアカウント、問い合わせフォーム、PHPのmail関数、外部配信API、予約タスクを切り分けます。
送信キュー、宛先数、件名、送信元スクリプト、認証成功ログを保存し、漏えいした資格情報を失効してください。

フォームだけを停止しても、埋め込まれたPHPや盗まれたSMTPパスワードから送信が続く場合があります。
Webとメールの両方を確認し、通常業務の送信まで止めた場合は社内へ代替連絡手段を案内します。

高負荷・大量通信では攻撃元と通信先を分ける

CPUや転送量の超過は、DDoSを受けた結果だけでなく、侵害されたPHPが外部へ大量アクセスした結果でも起きます。
受信リクエスト、実行プロセス、外向き通信、cron、アクセス元と通信先を時間帯ごとに比較します。

単純に上位プランへ変更して負荷枠を増やしても、原因が不正プロセスなら被害時間を延ばすだけです。
リソース制限を解除する前に、異常処理を止め、再発しないことをログで確認してください。

サーバー利用停止の前後は証拠を消さずに保全する

利用停止の通知を確認したら、次は削除ではなく保全です。
感染ファイルだけを先に消すと、侵入口、実行時刻、外部通信、影響範囲を説明する材料が失われ、解除申請や再発防止が難しくなります。

ただし、公開を続ければ被害が広がる状況では封じ込めを優先します。
可能ならWAFやメンテナンス表示、管理画面の一時制限を使い、証拠の複製と外部公開の停止を両立させます。

保存する資料はログ・ファイル・通知・画面の4群

アクセスログ、エラーログ、FTP・SSHログ、メール送信ログ、WAFログを、
提供期間が切れる前にダウンロードします。管理画面の一覧だけでなく、可能なら加工されていない元データを保存してください。

Webファイルとデータベースは、感染状態を含んだ調査用コピーとして保存します。
これは復元用バックアップではありません。正常なバックアップと混ぜず、読み取り専用の保管先へ分け、取得日時とSHA-256を記録します。

証拠保存と緊急停止を同じ作業記録へ残す

攻撃中の処理を止めるためにファイル名変更や権限変更を行った場合は、変更前後のパス、時刻、担当者、理由を記録します。
『消していないから安全』ではなく、誰が何を変えたか追跡できる状態が重要です。

自分でログを扱うのが難しい場合でも、通知を受けた時刻、管理画面へ入れた時刻、サイトが止まった時刻だけは残してください。
この3点があるだけでも、サーバー会社の記録と突き合わせやすくなります。

WordPressハッキング発覚直後の初期対応チェックリスト

サーバー会社へ停止範囲・保存期間・復旧条件を確認する

利用停止済みなら、復旧作業を始める前に『何が止まり、何が操作可能で、何を提出すれば解除されるか』を確認します。
事業者ごとに隔離方法や審査条件が違うため、一般論だけで復旧手順を決めないことが正解です。

問い合わせでは一度に必要事項をまとめて聞く

問い合わせ番号を件名に入れ、対象契約とドメインを明記したうえで、検知根拠、対象ファイル、ログ提供可否、
バックアップ保持期限、SFTP・SSH利用可否、復旧データのアップロード方法、解除審査の形式を質問します。

『直してください』だけでは、事業者が管理する設備と、利用者が管理するWordPressの責任範囲を分けられません。
自分側で必要な作業と、事業者側でしかできない解除操作を分けて確認すると往復が減ります。

停止回避のため別URLで公開し直さない

利用停止中のデータを別サーバーやサブドメインへそのまま移し、公開を再開するのは危険です。
感染したコードや漏えいした認証情報まで複製すれば、被害を拡大し、移転先でも停止される可能性があります。

事業継続が必要でも、まず安全な静的案内ページや別の連絡窓口を検討し、
感染環境と切り離します。顧客情報を扱うフォームや決済機能は、安全確認が終わるまで復帰させない判断も必要です。

サーバー利用再開には原因除去と再発防止の報告を準備する

解除申請で重要なのは『怪しいファイルを削除しました』という一文ではありません。
侵入原因、影響範囲、除去内容、認証情報の変更、脆弱性対策、検証結果を一つの流れとして説明できることです。

復旧は正常な基準と照合して全体を確認する

WordPress本体は公式配布物と照合し、テーマとプラグインは正規配布元の同一バージョンまたは安全な最新版と比べます。
uploads、mu-plugins、wp-config.php、.htaccess、cron、管理者ユーザー、データベース内の不審な設定も確認します。

一つのバックドアを削除しても、別の管理者、予約タスク、APIキー、改ざん済みプラグインが残れば再侵入されます。
検知されたファイルを入口に、同時刻帯の変更と外部通信を横へ広げて確認してください。

WordPress改ざんチェックの完全手順｜感染の確認方法から復旧・再発防止まで

認証情報は安全な端末から依存順に変更する

管理メール、ホスティング、ドメイン・DNS、FTP・SSH、データベース、WordPress、外部APIの順で見直し、
古いセッション、アプリパスワード、SSH鍵、APIトークンも失効します。パスワード変更だけで終えてはいけません。

プラグインやテーマの脆弱性が原因なら、安全な版へ更新するか削除します。
使っていない管理者と外注先アカウントを無効化し、最小権限に戻したうえで、ログイン保護とuploads内PHP実行防止などを追加します。

WordPressセキュリティを強化するサーバー側の設定まとめ｜レンタルサーバー別に徹底解説

サーバー会社への復旧報告は時系列と確認結果で書く

復旧報告は長い言い訳ではなく、事業者が安全性を判定できる事実を簡潔に並べます。
検知内容に対して、いつ、何を調べ、何を除去し、どう再発を防ぎ、何を検証したかを対応させてください。

通知番号・対象・作業・結果を固定書式にする

問い合わせを重ねる場合も、同じチケットや通知番号を使います。
新しい問い合わせを何本も作ると情報が分散し、担当部署が過去の回答を追えず、解除判断が遅れることがあります。

件名：通知番号XXXX／対象ドメインの復旧完了報告

1. 対象契約・ドメイン
2. 通知を確認した日時（JST・UTCを明記）
3. 原因と影響範囲
4. 除去・更新・認証情報失効の内容
5. 再発防止策
6. 表示・メール・ログ・再検査の結果
7. 利用再開審査のお願い

断定できない原因は推定と確認済みを分ける

侵入経路が確定していないのに『原因は完全に解決した』と書く必要はありません。
確認できた事実、可能性が高い原因、確認できなかった範囲を分け、代わりに実施した防御策と監視計画を示します。

たとえばログ保存期間が短く侵入時刻を確定できない場合は、その制約を明記します。
そのうえで全コア交換、不要プラグイン削除、資格情報失効、WAF有効化、一定期間の送信量監視を実施したと説明します。

サーバー利用停止対応で避けるべき失敗を知る

利用停止を長引かせる最大の失敗は、早く公開したい気持ちから検証を省くことです。
復元、削除、パスワード変更のどれか一つだけでは、原因や永続化経路が残り、解除後すぐに再感染する恐れがあります。

古いバックアップなら安全とは限らない

バックアップ日時が検知日より前でも、その時点ですでに侵入されていた可能性があります。
復元前に、取得日時、WordPressとPHPの版、既知の脆弱性、管理者、ファイル差分を確認し、安全な基準として使えるか判断します。

復元後は更新と認証情報失効を行い、同じ脆弱性を閉じます。
バックアップを戻しただけで解除申請すると、サーバー会社の再検査で同じ不審ファイルが検出されることがあります。

検査結果を一種類だけで安全宣言しない

セキュリティプラグインのスキャン、サーバー会社の検査、手動差分確認は得意分野が違います。
一つで『異常なし』でも、難読化コード、データベース改ざん、外部アカウント、漏えい済み鍵までは確認できない場合があります。

クイックレスキュー365は不正ログインブロックやXMLRPC遮断、uploads内PHP実行防止などの予防に使えますが、
マルウェアのスキャン機能はありません。検出が必要ならWordfenceなどの検査と、手動確認を組み合わせてください。

日本製セキュリティ対策で不正アクセスを遮断「クイックレスキュー365」無料ダウンロード

サーバー利用再開後は段階公開と72時間以上の監視を行う

利用再開の許可が出ても、すべての機能を同時に戻さないことが安全です。
静的表示、管理画面、ログイン、フォーム、メール送信、決済、外部APIの順に段階確認し、異常があれば停止できる状態を保ちます。

公開前に機能とセキュリティを二方向で確認する

PCとスマートフォンで主要ページを表示し、404・500・リダイレクト・画像欠落を確認します。
同時に、新規管理者、不審なcron、未知のPHP、外部通信、メールキュー、CPU負荷、WAF検知を確認してください。

キャッシュが残ると、復旧済みなのに古い改ざんページが見える場合があります。
WordPress、サーバー、CDN、ブラウザーのキャッシュを区別して更新し、別回線やシークレットウィンドウでも確認します。

解除後72時間を重点監視期間にする

最初の72時間は、ログイン失敗、POSTリクエスト、未知の管理者、ファイル更新、メール送信量、外部通信を短い間隔で見ます。
さらに1〜2週間は日次で確認し、同じパターンが再発していないか追います。

バックアップはWeb公開領域と別の保存先へ置き、復元テストも行います。
次の通知に備えて、サーバー会社の窓口、ログの保存期間、緊急連絡先、対応手順を社内の運用資料へ残してください。

プラグイン設定だけでなく、更新・バックアップ・緊急復旧まで継続して任せたい場合は、
保守サービス「クイックレスキュー365」の内容も確認してください。

WordPress・サイト保守クイックレスキュー365

サーバー会社の不正アクセス通知でよくある質問

サーバー会社の利用停止通知は順番を守って復旧する

サーバー会社から不正アクセス・利用停止の通知が来たら、最初に通知の真正性、対象、期限を確認します。
その後、ログ・ファイル・通知を保全し、停止範囲と解除条件を確認してから、原因除去と再発防止へ進んでください。

復旧のゴールはサイトが表示されることだけではありません。
侵入口と残存経路を閉じ、サーバー会社へ事実を説明でき、再公開後の監視まで続けられる状態が本当の復旧です。

自分で判断できない時は、通知メール、問い合わせ番号、契約情報、取得できたログ、直前の変更内容をまとめて相談してください。
削除や上書きの前なら、原因と影響範囲を追える可能性が高くなります。

WordPressの不正アクセス・利用停止が自分で直せない時は

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で