サーバーへの不正アクセスに気づいたとき、最初にやるべきことは「ファイルを消して元に戻すこと」ではなく、被害の拡大を止め、何が起きたかを調べられる状態を残すことです。この記事では、隔離 → 証拠保全 → 影響範囲の特定 → 再構築 → 認証情報の変更 → 関係者への通知、という対応の順番と、それぞれで判断を誤りやすい点を、VPSやWordPressサイトを運用している方向けに解説します（2026年10月現在の一般的な手順と国内の制度に基づいています）。
最初の数分でやること・やってはいけないこと
不正アクセスを疑ったら、まず気づいた時刻、気づいたきっかけ（改ざんされたページ、見覚えのない管理者ユーザー、サーバー会社からの通知など）、その時点で行った操作をメモに残します。このメモは、あとで原因を調べるときにも、関係者へ報告するときにも土台になります。
この段階で避けたいのは次のような行動です。
- 不審なファイルをその場で削除する：侵入経路や攻撃者の操作を示す手がかりが失われます。削除はコピーを取ってからです。
- ログを消す・ローテーションを強制する：ログは何が起きたかを知るための最も重要な証拠です。容量が逼迫していても、外部に退避してから整理します。
- すぐに再起動・電源断する：メモリ上で動いている不審なプロセスや通信の情報が消えます（ただし、外部への攻撃や情報流出が進行中なら、次の隔離を優先します）。
- 侵害されたサーバー上でパスワードだけ変える：攻撃者がまだ入り込んでいれば、新しいパスワードも盗まれます。認証情報の変更は、安全な環境を用意してから行います。
手順1：ネットワークから隔離する
隔離の目的は、攻撃者の操作、ほかのサーバーへの侵入、情報の持ち出し、サーバーを踏み台にした外部への攻撃を止めることです。
VPSやクラウドなら、サーバー会社のコントロールパネルにあるパケットフィルターやセキュリティグループで、通信を遮断するのが有効です。サーバーの外側で止めるため、root権限を奪われていても攻撃者に解除されません。調査用に、自分の固定IPアドレスからのSSHだけを許可しておくと、隔離したまま作業を続けられます。サーバー内の ufw や iptables で遮断する方法もありますが、攻撃者が管理者権限を持っている場合は書き換えられる可能性がある点を理解しておいてください。
サイトを止められない事情があっても、侵害されたサーバーで公開を続けると、訪問者にマルウェアを配布したり、フィッシングページを表示したりする恐れがあります。メンテナンス画面を別のサーバーから出すなどして、侵害されたサーバーへの公開アクセスは止めます。
手順2：証拠を保全する
隔離できたら、状態が変わる前に情報を集めます。VPSにスナップショット機能があれば、まずディスク全体のスナップショットを取得します。後から何度でも調べ直せる、手軽で効果の大きい保全方法です。
続いて、メモリ上の情報やログをサーバーの外に保存します。侵害されたディスクにファイルを書き込むと、削除済みファイルの痕跡を上書きしてしまう可能性があるため、SSH経由で調査用の安全なPC（またはサーバー）へ直接送る方法が適しています。以下は調査用PC側から実行する例で、接続先で sudo をパスワードなしで実行できる前提です。そうでない環境では、サーバー上で同じコマンドを実行して結果をまとめてから転送します。
# 調査用PCで実行する。結果はすべて手元に保存される
H=compromised.example.com
D=ir-$(date -u +%Y%m%dT%H%MZ); mkdir "$D"
ssh admin@$H 'date -u; uptime' > "$D/time.txt"
ssh admin@$H 'sudo ps auxwwf' > "$D/ps.txt"
ssh admin@$H 'sudo ss -tunap' > "$D/ss.txt"
ssh admin@$H 'sudo last -Fiw' > "$D/last.txt"
ssh admin@$H 'sudo ls -la /etc/cron* /var/spool/cron/crontabs' > "$D/cron.txt"
ssh admin@$H 'sudo systemctl list-units --type=service --all' > "$D/services.txt"
ssh admin@$H 'sudo tar czf - /var/log' > "$D/var-log.tgz"
ssh admin@$H 'sudo tar czf - /etc' > "$D/etc.tgz"
sha256sum "$D"/* > "$D/SHA256SUMS"最後にハッシュ値を記録しておくと、あとで「収集したデータが途中で変わっていない」ことを示せます。Webサーバーのアクセスログ・エラーログ、データベースのログ、サーバー会社の管理画面に残る操作履歴も保存対象です。ログの保存期間が短いサービスもあるので、早めに取得します。
注意したいのは、侵害されたサーバー上の ps や ls などのコマンド自体が改ざんされている可能性があることです。結果が不自然に少ない場合は、スナップショットから作ったディスクを別の環境に接続して調べる方法に切り替えます。警察への相談や法的な対応が想定される場合は、自分で調査を進める前に専門の調査会社への相談も検討してください。
手順3：侵入経路と影響範囲を特定する
集めた情報から「いつ、どこから入り、何をされたか」を時系列にまとめます。WordPressサイトでよくある侵入経路は、脆弱性のあるプラグイン・テーマ、使い回しや推測されやすいパスワード、漏えいしたFTP/SSHの認証情報、同じサーバー上の別サイトからの感染です。
調べる主なポイントは次のとおりです。
- アクセスログ：不審なPOSTリクエスト、
wp-login.phpやxmlrpc.phpへの大量アクセス、プラグインのファイルへの直接アクセス - 認証ログ（
/var/log/auth.logや/var/log/secure）：見覚えのないSSHログインの成功 - 持続化の痕跡：追加されたユーザー、
~/.ssh/authorized_keysの不審な鍵、cronやsystemdのサービス、wp-content/mu-pluginsの見知らぬファイル、.user.iniやphp.iniのauto_prepend_file - WordPressの状態：見覚えのない管理者ユーザー、改ざんされたコアファイル
# WordPressのディレクトリで実行（調査用に複製した環境で行うのが望ましい）
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp core verify-checksums
wp plugin verify-checksums --all
# 画像などを置く uploads に PHP ファイルがないか
find wp-content/uploads -type f -name '*.php'
# 指定日以降に内容か属性が変わったファイル（mtime は偽装されやすいので ctime も見る）
find . -type f -name '*.php' -newerct '2026-10-01'影響範囲を考えるときは、そのサーバーに保存されていた情報も洗い出します。データベースに会員情報や問い合わせ内容があったか、wp-config.php やプラグインの設定にほかのサービスのAPIキーやSMTPのパスワードがあったか、サーバー上にほかのサーバーへ接続するSSH鍵がなかったか。これらは「漏れた可能性がある」ものとして扱います。
手順4：迷ったら「掃除」ではなく「再構築」する
不審なファイルを削除して使い続ける「掃除」は、見落としが1つでもあれば再び侵入されます。特に、root権限を取られた可能性がある場合や、侵入経路と攻撃者の操作を特定しきれない場合は、新しいサーバーを用意して作り直すほうが安全です。
再構築の流れは次のとおりです。
- 新しいサーバーを、公式のOSイメージから用意し、更新をすべて適用する
- WordPress本体、プラグイン、テーマは、公式の配布元から改めてダウンロードする（侵害されたサーバーのファイルはコピーしない）
- データベースは侵入より前のバックアップから復元し、管理者ユーザーや設定に不審な変更がないか確認する
wp-content/uploadsの画像などは中身を確認してから移す（PHPファイルや不審なファイルを除く）- 特定した侵入経路（脆弱なプラグインの更新・削除、パスワード認証の停止など）を塞いでから公開する
バックアップが侵入の後に取られたものだと、攻撃者の仕込みも一緒に戻ってしまいます。手順3で特定した侵入時期より前のバックアップを選ぶことが重要です。侵害されたサーバーやそのスナップショットは、調査が終わるまで削除せずに、隔離したまま保管しておきます。
手順5：認証情報をすべて変更する
新しい環境が用意できたら、侵害されたサーバーに関係するすべての認証情報を変えます。変更は、侵害されていないPCから行います。
- サーバーのOSユーザーのパスワードとSSH鍵（
authorized_keysは新しい鍵だけにする） - サーバー会社やドメイン、DNSの管理画面のパスワード（二段階認証も設定する）
- FTP/SFTPのアカウント
- データベースのユーザーとパスワード（
wp-config.phpも合わせて更新） - WordPressの全管理者・編集者のパスワード
wp-config.phpの認証用キーとソルト（変更するとログイン中のセッションがすべて無効になる）- サーバーに保存されていたAPIキー、SMTPパスワード、決済サービスや外部ストレージの認証情報
- そのサーバーから別のサーバーへ接続していたSSH鍵やデプロイ用の鍵
キーとソルトはWP-CLIの wp config shuffle-salts で作り直せます。APIキーは、各サービスの管理画面で古いキーを無効化し、新しいキーを発行します。
手順6：関係者へ通知・報告する
個人情報が漏えいした、またはそのおそれがある場合は、個人情報保護法に基づき、個人情報保護委員会への報告と本人への通知が求められる場合があります。不正アクセスなど不正の目的による漏えいのおそれは、件数にかかわらず報告の対象になります。報告には、発覚後速やかに行う「速報」と、原則30日以内（不正の目的によるものは60日以内）の「確報」があります。対象となる条件や期限は、個人情報保護委員会のWebサイトで最新の案内を確認してください（2026年10月現在）。
ほかにも、次の相手への連絡を検討します。
- サーバー会社（同じ基盤の別の利用者に影響していないかの確認にもなります）
- 業務を委託している制作会社や、サイトの運営を任されている場合のクライアント
- 被害を受けた可能性のある利用者（クレジットカード情報が含まれる場合は決済代行会社にも）
- JPCERT/CCやIPAへの届出、必要に応じて警察への相談
Google Search Consoleで「セキュリティの問題」が報告されている場合は、再構築が終わったあとに審査をリクエストすると、検索結果の警告を解除してもらえます。
再発を防ぐために
対応が落ち着いたら、侵入経路に対する対策を中心に見直します。WordPressとプラグインの更新を後回しにしない運用、更新が止まったプラグインの入れ替え、SSHのパスワード認証の停止と公開鍵認証への移行、管理画面の二段階認証、そしてサーバーとは別の場所に世代管理したバックアップを置くことが基本になります。ログをサーバーの外に転送しておくと、次に何かあったときに「ログが消されていた」「保存期間が過ぎていた」という事態を防げます。
まとめ
- 気づいたらまず記録を取り、ファイルやログの削除、安易な再起動は避ける
- サーバーの外側（コントロールパネルのフィルターなど）で隔離し、スナップショットとログを外部に保全する
- 時系列で侵入経路と影響範囲を特定し、サーバー上にあった情報は漏れた前提で扱う
- 判断に迷う場合は掃除ではなく、侵入前のバックアップを使って新しいサーバーに再構築する
- 安全な環境からすべての認証情報を変え、個人情報が関わる場合は報告・通知の要否を確認する