【完全版】WordPressへの侵入経路を調査する方法|再発防止のためにやるべきログとファイルの確認ポイント
WordPressサイトがハッキング・マルウェア感染された後、改ざんやマルウェアを削除するだけでは不十分です。どこから侵入されたのか(侵入経路)を突き止めなければ、再び同じ手口でやられます。
マルウェア侵入被害を受けた場合、何かおかしい?と最初に気付いた日時(分秒も)をメモしておくことは、怪しいログや履歴を探す際に役立ちます。全体的には違和感を探すような難易度が高い作業であるため、WordPressに詳しくLinuxの知識もある程度持っている人は気付きやすいです。ただ、ログ設計がしっかりされておらず、保存期間が短く、調査不可能になることも少なくないため、早急な専門家へのご相談をおすすめします。
この記事では、WordPressに不正アクセスされた際に行うべき侵入経路の調査方法を、技術レベル別にわかりやすく解説します。
✅ この記事の対象読者様
- WordPressでサイト運営をしていて、改ざん・マルウェア被害に遭った方
- 復旧作業中または直後で、原因の特定と再発防止をしたい方
- お客様サイトの対応を任されたエンジニア・担当者の方
なぜ侵入経路の特定が重要なのか?
多くの復旧対応現場で見かける失敗が「復旧だけして、侵入経路を放置」してしまうケースです。
| 誤った対応例 | 起きるリスク |
|---|---|
| 改ざんファイルを削除 → 復旧したつもり | 数日後に再感染(再設置型マルウェア) |
| プラグインやテーマを最新版に更新しないで運用 | 同じ脆弱性を突かれて再侵入 |
| 原因がわからず業者任せで終了 | 顧客や上司に「また同じことが起きた」と言われる |
だからこそ、「なぜ侵入されたのか?」を調査することが、最も重要な再発防止策です。
調査方法は3つの軸で考える
調査すべき対象は、大きく分けて以下の3つです:
| 軸 | 内容 |
|---|---|
| ① ログ(アクセス/コマンド履歴) | 外部からのアクセスの痕跡を追う |
| ② ファイル(改ざん・隠しファイル) | 不正に追加されたファイルや書き換えられたファイルの痕跡を探す |
| ③ ユーザーアカウント/設定 | WordPress乗っ取り確認 |
① ログから侵入の痕跡を探す
🔸 アクセスログ(Apache/Nginx)
# 例(最新500件のPOSTアクセス)
grep POST /var/log/nginx/access.log | tail -n 500
確認すべき内容:
wp-login.phpへのブルートフォース攻撃eval,.ico,.phpへの不審なPOSTリクエスト/wp-content/uploads/にアクセスしてファイルを実行している形跡
上記をgrepで検索すると、怪しいアクセスを絞り込めます
grep -i 'eval' access.log
grep 'POST' access.log | grep '.ico'
🔸 historyコマンドでサーバー操作履歴を確認
history | less
チェックポイント
wget,curl,chmod,mvなどを使ってマルウェアを仕込んでいないかcrontabを設定されていないか(→ 自動再感染型)
※複数ユーザーがいる場合、それぞれの
.bash_historyを確認しましょう。
② ファイルシステムをチェック
WordPressコア/テーマ/プラグインの自動更新を有効にしている場合、自動更新の通知メールを活用すると、不正なファイル書き換えではないか?判別しやすくなります。
🔸 変更日時で不審ファイルを抽出
以下findコマンドなども有効ですが、SFTPツールのGUI目視でサッと見て異変を見つけられるケースもあります。
# 7月1日以降に更新されたファイルを表示
find ./ -type f -newermt "2025-07-01"
チェック箇所:
/wp-content/uploads/に.phpや.ico,.txtファイル.htaccess,functions.php,wp-config.phpに改ざんされた形跡.user.ini,php.iniにauto_prepend_fileのような設定
🔸 .htaccess による隠し実行設定
例:
AddHandler application/x-httpd-php .jpg
- 上記があると「画像ファイルのふりをしたPHP」が実行されてしまう
RewriteRule,Redirect,SetEnvも悪用されることあり
🔸 cronジョブ・wp-cron.php を確認
crontab -l
- 外部サイトにアクセスしたり、
sleep→rm -rfなど破壊的コマンドが登録されていないか wp-cron.phpに不審な処理(eval,base64_decodeなど)が埋め込まれていないか
③ WordPress本体・ユーザーの乗っ取り確認
🔸 管理者ユーザーに見知らぬアカウントが追加されていないか
- WordPress管理画面「ユーザー」
user_login,user_registeredの異常値(DBでも確認可)
🔸 アプリケーションパスワードを悪用されていないか
- 管理画面 → ユーザー → プロフィール → 「アプリケーションパスワード」欄を確認
- 不審なアプリケーションパスワードが追加されていないか?
🔸 使用していないサブディレクトリが放置されていないか
/backup/,/test/,/old/などに過去のWordPress・phpMyAdmin・解凍済みZipが放置されていないか
🔄 侵入経路調査まとめ
| 項目 | チェック内容 |
|---|---|
| アクセスログ | wp-login.phpの不正アクセス、POSTリクエスト先、evalや.ico |
| historyコマンド | curl/wget/chmod等の操作履歴、cron登録 |
| ファイル変更日 | wp-config.php、functions.php、.htaccess、その他のファイル |
.htaccess | AddHandler, Redirect, Rewriteの異常設定 |
.user.ini | auto_prepend_file の存在確認 |
| cron | 外部スクリプト呼び出し、バックドア |
| WordPressユーザー | 見知らぬ管理者、APIキーの生成有無 |
| サブディレクトリ | /backup, /test, /old 等の放置。身に覚えがないフォルダ。 |
🔚 再発を防ぐには「調査 → 原因除去 → 対策強化」の3段階が必須
調査をしないまま復旧だけしても、攻撃者から見れば「また入り放題のWordPress」です。
原因を特定し、脆弱性を潰し、堅牢化(セキュリティ強化)やログ設計トログ取得まで行いましょう。
✉️ 自力での調査が難しい方
- ✅ 最短2時間での緊急復旧対応 超速WordPressハッキング被害復旧|最短2時間緊急レスキュー
