Webサイトが乗っ取られていないか確かめる方法｜パッチ適用後にやる侵害チェック

なぜパッチのあとに確認が必要なのか

PHP の脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）の修正版は、2026年10月21日 23:00（日本時間）に公開される予定です［php.net］。この記事は公開前の 21日夜に書いています。脆弱性の概要はphp2shell の解説記事をご覧ください。

修正版に更新すると、その脆弱性を使ったこれからの攻撃は防げます。ただし、更新より前に攻撃を受けて、サーバーに裏口のファイルを置かれていた場合、そのファイルは更新後も残ります。海外の一部のセキュリティ企業は、修正版の公開前から攻撃の報告があったとしています［Patchstack］。一方で IPA は「悪用は確認していない」としており、情報は分かれています。

実際に入り込まれたかどうかは、サイトごとに確かめるしかありません。重点的に見るのは、情報が漏れた 10月20日ごろから、修正版に更新するまでの期間です。

公式の手引きと、セキュリティ企業の情報の違い

この記事では、出典を次の2つに分けて書いています。

21日夜の時点で、php2shell の公式の痕跡情報（IoC：攻撃に使われたファイル名や通信先などの目印）は出ていません。Huntress も IoC の欄を「未定」としています［Huntress］。JPCERT/CC のサイトにも、PHP についての注意喚起はまだ出ていません。以下の確認ポイントのうち php2shell に特有のものは、セキュリティ企業の見立てにもとづいています。

確認を始める前に

1. 修正版が実際に動いているか確かめる：ファイルを更新しても、古い PHP-FPM（PHP を動かし続けるプロセス）が残っていると修正は効きません。更新後は PHP-FPM か Web サーバーを再起動し、Web 側で動いている PHP のバージョンを確認します。コマンドの php -v と Web 側の PHP は別のことがあるため、php -v だけでは判断しません［abgeo.dev・SOCRadar］。
2. 確認は「見るだけ」にする：ファイルを消したり直したりするのは、全体を見終わってからにします。先に消すと、いつ・どこから入られたかを調べる手がかりもなくなります。
3. 出どころの分からないコードは実行しない：「php2shell の検査ツール」「PoC」を名乗るものがネット上にありますが、偽物やマルウェア入りの可能性があります［abgeo.dev・Patchstack］。

以下のコマンド例は、どれも中身を表示するだけで、サーバーの状態を変えません。パス（/var/www/html など）はサーバーによって違うので、自社の環境に合わせて読み替えてください。レンタルサーバーでコマンドが使えない場合は、管理画面のファイルマネージャーや FTP ソフトで、更新日時の新しい順に並べて確認できます。

見覚えのないファイル（Webシェル）を探す

Webシェルとは、ブラウザからサーバーを操作できるようにするために、攻撃者が置くプログラムです。PHP のサイトなら、多くは .php のファイルとして置かれます。Huntress と SOCRadar は、侵害が疑われるときは Web の公開フォルダに Webシェルや新しいファイルがないかを探すよう勧めています。見るポイントは次の3つです。

• 10月20日以降に作られた・書き換えられた .php ファイル
• 画像やアップロード用のフォルダ（WordPress なら wp-content/uploads）にある .php ファイル。通常、ここには画像や PDF が入ります
• .htaccess、index.php、テーマの header.php・footer.php・functions.php の変更。WordPress.org の公式ドキュメントは、改ざんされやすいファイルとしてこれらを挙げています

コマンドで確認する場合の例です（表示するだけです）。

# 公開フォルダで、最近2日以内に変更された .php ファイルを一覧表示
find /var/www/html -name "*.php" -mtime -2 -ls

# アップロード用フォルダにある .php ファイルを一覧表示
find /var/www/html/wp-content/uploads -name "*.php" -ls

# 公開フォルダ直下のファイルを、更新日時の新しい順に表示
ls -lat /var/www/html | head -30

-mtime -2 の数字は「何日前まで」を表します。更新までの日数に合わせて変えてください。ただし、更新日時は攻撃者が書き換えられるため、日時が古いから安全とは言い切れません。バックアップがある場合は、10月20日より前のバックアップとファイルの一覧を比べる方法もあります。

WordPress の管理者を確かめる

WordPress の管理画面で「ユーザー」→「権限グループ：管理者」に絞り込み、見覚えのないアカウントがないかを見ます。IPA の「安全なウェブサイトの運用管理に向けての20ヶ条」も、不要なアカウントが登録されていないかを確認項目にしています。

• 知らない名前・メールアドレスの管理者
• もとは「投稿者」などだったのに、管理者に変わっているユーザー
• 退職者や制作会社の、使っていないアカウント

WordPress.org の公式ドキュメントは、新しいユーザーが勝手に作られることを、乗っ取りのはっきりした兆候の1つとして挙げています。サーバーのアカウント（SSH で入れるユーザー）や、レンタルサーバーの FTP アカウントも、あわせて確認します。

cron（定期実行）を確かめる

cron は、決まった時刻にコマンドを自動で実行する仕組みです。攻撃者は、裏口を消されても再び入れるように、cron に命令を登録することがあります。Huntress・SOCRadar・abgeo.dev はいずれも、新しく登録された cron を確認項目に挙げています。

# 自分のユーザーの cron を表示
crontab -l

# Web サーバーのユーザー（例：www-data）の cron を表示（管理者権限が必要）
sudo crontab -l -u www-data

# システム全体の cron の設定ファイルを一覧表示
ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly

見覚えのない登録や、外部のサーバーから何かを取ってきて実行するような命令（curl や wget を含むもの）があれば要注意です。レンタルサーバーでは、管理画面の「cron 設定」などの画面で確認できます。

PHP から不審なコマンドが動いていないか

ここは php2shell に特有の確認ポイントで、出典はセキュリティ企業です。Huntress は、悪用は「PHP が起動した不審な子プロセス」として現れる可能性が高いとしています。

• php-fpm・php-cgi・httpd・apache2 の下で、sh・bash などのシェルや、curl・wget などのダウンロード用のコマンドが動いていないか［Huntress・SOCRadar］
• Web サーバーから whoami・id・uname -a のような、サーバーの情報を調べるコマンドが実行されていないか［Huntress］

abgeo.dev は、ふつうの PHP アプリが bash や curl を子プロセスとして起動することはほとんどない、と書いています。今動いているプロセスは、次のように表示できます。

# プロセスを親子関係つきで表示し、PHP・Web サーバーの周辺を見る
ps -ef --forest | grep -E -A3 "php-fpm|apache2|httpd"

ただし、ps で見えるのは「今」動いているものだけです。過去に実行されたコマンドを追うには、EDR（サーバーの動きを記録するセキュリティ製品）や監査ログが必要になります。レンタルサーバーではこの確認はできないことが多いので、サーバー会社の告知を確かめてください。

アクセスログの見方

アクセスログは、誰がいつどのページにアクセスしたかの記録です。JPCERT/CC は Web サイト改ざんの注意喚起で、ログを見てアクセス元の IP アドレスや日時に不審な点がないかを確認するよう求めています。IPA も、Web サーバーのログを保管して定期的に確認することを勧めています。

中小企業の Web 担当者でも見つけやすいのは、次のようなアクセスです。

• 前の手順で見つけた、見覚えのないファイルへのアクセス。いつ、どの IP アドレスからアクセスされたかが分かります
• 同じ IP アドレスから、同じファイルへの GET・POST が繰り返されている。JPCERT/CC が 10月に出した国内の不正アクセスの注意喚起でも、Webシェルへの繰り返しのアクセスが報告されています（php2shell とは別の事案です）
• ふだんファイルを受け付けないページへの、大量の POST

# 見つけたファイル名（例：xxx.php）へのアクセスを探す
grep "xxx.php" /var/log/apache2/access.log

# POST のアクセスだけを表示（最後の50行）
grep '"POST ' /var/log/nginx/access.log | tail -50

IPA はアクセスログから攻撃の痕跡を探すツール「iLogScanner」を公開しています。ただし、php2shell 向けの検出に対応しているかは、21日夜の時点では確認できていません。ログの場所はサーバーによって違い、レンタルサーバーでは管理画面からダウンロードする形が一般的です。ログは一定期間で消えることがあるので、10月20日以降の分は早めに手元に保存しておきます。

見つけたときの初動

怪しいものを見つけても、すぐには消さないでください。先に消すと「いつ・どこから・何をされたか」が分からなくなり、情報が漏れたかどうかも判断できなくなります。IPA の「中小企業のためのセキュリティインシデント対応の手引き」は、対応を「検知・初動対応」「報告・公表」「復旧・再発防止」の3段階に分け、初動対応のなかで証拠保全を挙げています。

1. 切り離す：サイトの公開を止める、またはサーバーをネットワークから切り離します。侵害の兆候があればまずサーバーを隔離する、というのは Huntress と SOCRadar の勧めでもあります。レンタルサーバーなら、サーバー会社に連絡して相談します。
2. ログを残す：Web サーバーと PHP のログを、サーバーとは別の場所にコピーします［Huntress・SOCRadar］。見つけたファイルも消さずに残します。
3. 記録する：気づいた日時、何を見てそう思ったか、誰が何をしたかをメモします。WordPress.org の公式ドキュメントでも、最初の手順は記録です。
4. パスワードや鍵を変える：データベース、FTP / SFTP、WordPress の管理画面、サーバーの管理画面のパスワードを変えます。サーバーに置いていた API キーやクラウドの認証情報も変えます。WordPress は、wp-config.php の秘密鍵を新しくすると、ログイン中のユーザーを全員ログアウトさせられます［WordPress.org］。
5. きれいにしたあと、もう一度パスワードを変える：WordPress.org の公式ドキュメントは、発見時に変えた場合でも、裏口を取り除いたあとに再度変えるよう求めています。

パスワードの変更は、なるべくサーバーとは別の、安全な端末から行います。JPCERT/CC の注意喚起では、サイトの更新に使っている PC がマルウェアに感染していないかも確認項目に入っています。

相談・届出先

IPA の手引きは、ウイルスや不正アクセスの被害、個人情報の漏えいは関係機関への届け出が必要になるとしています。主な窓口は次のとおりです。

個人情報保護委員会は、不正の目的で行われたおそれがある漏えい等（そのおそれを含む）を報告の対象にしています。不正アクセスによるものは、これに当たる可能性があります。報告は、まず発覚から3〜5日以内に速報、そのあと確報です。確報の期限は通常30日以内で、不正の目的によるおそれがある場合は60日以内です［個人情報保護委員会］。お問い合わせフォームの送信内容や会員情報をサーバーに保存していた場合は、早めに確認してください。

異常がなかった場合

確認した日時と、見た場所・結果を記録しておきます。後で別の情報が出たときに、どこまで確認済みかがすぐに分かります。公式の IoC が出たら、それをもとにもう一度確認してください。

参考にした情報

• php.net（PHP 公式のセキュリティリリース告知）
• IPA「不正アクセス対策特設サイト」 / 中小企業の情報セキュリティ対策ガイドライン（付録8 セキュリティインシデント対応の手引き）
• IPA「安全なウェブサイトの運用管理に向けての20ヶ条」 / iLogScanner
• IPA「コンピュータウイルス・不正アクセスに関する届出」
• JPCERT/CC「Web サイト改ざんに関する注意喚起」 / 「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」 / インシデント対応依頼
• 警察庁「サイバー事案に関する相談窓口」
• 個人情報保護委員会（漏えい等の報告）
• WordPress.org「FAQ My site was hacked」
• Huntress / SOCRadar / abgeo.dev / Patchstack（いずれも二次情報）