サイトやサーバーが不正アクセスされたか調べる方法：レンタルサーバー・WordPress・VPS別の確認手順と、見つけたときの順番

対象：個人や小さな会社で、レンタルサーバー・WordPress・VPS を使ってサイトを運営している人。「もしかして乗っ取られた？」と思ったときに、自分のサイトとサーバーを自分で確認する手順をまとめます。本記事は WordPress.org・WP-CLI・Google 検索セントラル・各コマンドの公式マニュアル・IPA・JPCERT/CC・個人情報保護委員会の公開情報にもとづきます。攻撃の手順は扱いません。

侵入を疑うべき兆候

次のどれかに当てはまったら、下の「環境別の確認手順」に進んでください。WordPress.org の「FAQ My site was hacked」も、ハッキングの明確な兆候として、検索エンジンのブロックリストへの掲載、ホスティング事業者によるサイトの停止、許可していない新しいユーザーの作成などを挙げています。

環境別の確認手順

自分の環境に当てはまる行を確認してください。WordPress をレンタルサーバーで使っているなら、上の2行の両方が対象です。

レンタルサーバー（共用）

SSH が使えない契約でも、コントロールパネルから次の3つは確認できることが多いです（画面の名前は事業者ごとに違います）。

• ファイルマネージャーで公開フォルダを開き、更新日時の新しい順に並べる。自分が更新していない日付に変わったファイル、意味のない名前のPHPファイル、画像フォルダ（uploads など）の中のPHPファイルに注意する
• アクセスログとエラーログをダウンロードし、管理画面（WordPress なら /wp-login.php や /wp-admin/）へのアクセス元と時刻、見覚えのないURLへのアクセスを見る
• メールの送信数や送信の履歴を見られるなら、送った覚えのない大量の送信がないかを確認する

サイトの中にある .htaccess も確認してください。WordPress.org は、感染の種類にかかわらず最もよく書き換えられ、悪用されるファイルの1つとして .htaccess を挙げ、index.php・header.php・footer.php なども全ページに影響するため狙われやすいとしています。

WordPress

管理画面で次の2か所を確認します。

• 「ユーザー」→「ユーザー一覧」で、権限グループが「管理者」のユーザーに、作った覚えのない人がいないか
• 「プラグイン」→「インストール済みプラグイン」で、入れた覚えのないプラグインがないか。テーマも「外観」→「テーマ」で同じように確認する

サーバーで WP-CLI（WordPress をコマンドで操作する公式ツール）が使えるなら、ファイルが公式の配布物と一致するかを機械的に確かめられます。

# WordPress 本体のファイルが WordPress.org のチェックサムと一致するか
wp core verify-checksums
# WordPress のルートディレクトリに WordPress 以外のファイルがあれば警告する
wp core verify-checksums --include-root
# WordPress.org で配布されているプラグインを検証する
wp plugin verify-checksums --all
# 管理者権限のユーザーを登録日つきで一覧する
wp user list --role=administrator

一致すれば Success: WordPress installation verifies against checksums. と表示されます。一致しないファイルがあると、Warning: File doesn't verify against checksum: に続いてファイル名が出ます。プラグインの検証は WordPress.org のチェックサムと照合する仕組みなので、有料プラグインや自作のテーマはこの方法では確かめられません。それらは、配布元から同じ版を取り直して見比べます。

VPS（Linux）

VPS では、侵入者が次に来るための仕掛け（公開鍵・定期実行・新しいユーザー・待ち受けるプログラム）を残していないかを見ます。どれも自分のサーバーで、管理者として実行するものです。

# SSH のログイン記録（Debian/Ubuntu のユニット名は ssh、RHEL 系は sshd）
sudo journalctl -u ssh --since "2026-10-01"
# 最近のログインの一覧（Debian 13 では last の代わりに wtmpdb last。wtmpdb と libpam-wtmpdb のインストールが必要）
last -a
# 各ユーザーの最終ログイン（Debian 13 では lastlog の代わりに lastlog2。lastlog2 と libpam-lastlog2 のインストールが必要）
lastlog
# SSH の公開鍵：実行中のユーザーの分（他のユーザーは /home/*/.ssh/authorized_keys）と root の分
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys
# 定期実行（ユーザーごと・システム全体）
crontab -l
sudo crontab -l -u root
sudo cat /etc/crontab
sudo ls -la /etc/cron.d
# ユーザーと、管理者権限を持つグループ（RHEL 系は wheel）
getent passwd
getent group sudo
# 待ち受けている TCP ポートと、そのプログラム
sudo ss -tlnp
# 公開フォルダで、7日以内に内容が変わったファイル
sudo find /var/www -type f -mtime -7
# パッケージのファイルが配布時から変わっていないか
sudo debsums -s      # Debian/Ubuntu（debsums パッケージが必要）
sudo rpm -Va         # RHEL 系

結果は次のように読みます。

• journalctl の出力で、ログインに成功した記録（Accepted）の接続元に、自分のものでないIPアドレスがないか。何も表示されないときはユニット名が違う可能性があるので、systemctl list-units --type=service で SSH のサービス名を確かめる
• authorized_keys に、登録した覚えのない公開鍵がないか。サーバーに入る鍵の管理は SSH鍵の最小権限 で解説しています
• cron に、知らないURLからファイルを取ってきて実行するような行がないか
• ss の一覧に、自分で起動していないプログラムの待ち受けがないか
• debsums -s は問題のあるファイルだけを表示し、rpm -Va は変わったファイルについて、サイズ（S）・ダイジェスト（5）・更新日時（T）などの違いを記号で示す

Google Search Console

Search Console にサイトを登録していない場合は、まず登録して所有権を確認します。

• 「セキュリティの問題」レポートで、問題が出ていないかを確認する。問題の種類は大きく「ハッキングされたコンテンツ」「マルウェアや望ましくないソフトウェア」「ソーシャル エンジニアリング」の3種類で、問題ごとにサンプルURLが示される。ただしサンプルURLが表示されない問題もあり、Google はその場合も影響を受けたページがないわけではないとしている
• Google 検索で site:自分のドメイン と検索し、作った覚えのないページがないかを見る。Google は、ハッカーが追加したページを含めて、サイトのページの一覧を確認できるとしています
• 疑わしいページは URL 検査ツールに入れて、Google からどう見えているかを確かめる

用語の整理として、ここで探しているような「すでに起きた侵害の痕跡」を IOC（侵害指標）と呼びます。詳しくは IOC（侵害指標）とは、進行中の動きで気づく考え方は IOA（攻撃指標）とは を参照してください。

見つけたときの対応の順番

順番を間違えると、証拠が消えたり、侵入者の入口が残ったまま戻されたりします。上から順に進めてください。

個人情報が漏れたおそれがあるとき

事業として個人情報を扱っていて、問い合わせフォームの送信内容や会員情報などが漏れたおそれがある場合は、個人情報保護委員会の「漏えい等の対応とお役立ち資料」を確認してください。

• 報告が必要になるのは、要配慮個人情報、財産的被害のおそれ、不正の目的によるおそれ、本人の数が1,000人を超える、の4類型。不正アクセスによる漏えいは「不正の目的」の例として挙げられている
• 期限は、速報が発覚日から3〜5日以内、確報が30日以内（不正の目的によるおそれがある場合は60日以内）
• 報告は委員会の「漏えい等報告フォーム」から行う。業種によっては、権限委任先の省庁に報告する
• 報告対象になる場合は、本人への通知も必要になる（個人情報保護法第26条第2項）

相談・届出の窓口

出典（公式情報）

• WordPress.org「FAQ My site was hacked」 — wordpress.org
• WordPress.org「管理画面」（日本語版ドキュメント） — ja.wordpress.org
• WP-CLI「wp core verify-checksums」 — developer.wordpress.org
• WP-CLI「wp plugin verify-checksums」 — developer.wordpress.org
• WP-CLI「wp user list」 — developer.wordpress.org
• Google「セキュリティの問題レポート」（Search Console ヘルプ） — support.google.com
• Google「サイトがハッキングされているかどうかを確認する方法」（web.dev） — web.dev
• Google「キーワードとリンクのクローキングによるハッキングを解決する」（web.dev） — web.dev
• Google 検索セントラル ブログ「望まない不正なモバイル リダイレクトを検出して除去する」（2015年10月） — developers.google.com
• Google 検索ヘルプ「Google 検索の問題を報告する」（「ハッキングされている可能性があります」の表示について） — support.google.com
• Debian マニュアルページ：journalctl(1)、last(1)、lastlog(8)、sshd(8)、crontab(1)、cron(8)、ss(8)、find(1)、debsums(1) — manpages.debian.org
• RPM「rpm(8)」（--verify の出力の読み方） — rpm.org
• Debian 13（trixie）リリースノート 5.1.9「The last, lastb and lastlog commands have been replaced」 — debian.org
• 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」 — ppc.go.jp
• 個人情報保護委員会「漏えい等の対応とお役立ち資料」 — ppc.go.jp
• JPCERT/CC「インシデント対応依頼」 — jpcert.or.jp
• IPA「コンピュータウイルス・不正アクセスに関する届出について」 — ipa.go.jp

次に読む

• 個人のアカウントの場合：不正アクセスされていないか確認する方法（ログイン履歴・ログイン中の端末・転送設定）
• 事業者側が侵害されたとき：レンタルサーバーが不正アクセスされたとき、利用者は何をすべきか（自分の設定では防げない場合の備え）
• 置き場所の点検：公開ディレクトリに秘密ファイルを置き忘れていないか ／ レンタルサーバーで .env を公開しないための配置と設定
• WordPress：WordPressのセキュリティ対策 ／ 入口の典型：ファイルアップロードの脆弱性
• 用語：IOC（侵害指標）とは ／ IOA（攻撃指標）とは ／ バックドアとは ／ マルウェアとは
• 復旧：バックアップと復旧の基本