PHP WebShellとは？WordPressで見つけた時に実行せず調べる方法

WordPressの公開フォルダで、見覚えのないPHPファイルや「WebShell」と疑われるコードを見つけたら、
最初の正解は開いて動作を確かめることではありません。

PHP WebShellは、ブラウザなどから命令を受けてサーバー上の処理を行える不正な入口として悪用されます。
確認のための1回のアクセスでも、攻撃者の処理を自分で動かし、証拠やファイルを変えてしまう危険があります。

よこやま良平

20年以上ITエンジニアとしてWordPress・PHP・セキュリティ対策に携わり、
多数の復旧を支援している、よこやま良平です。現場で安全性を崩さない調査順を解説します。

本記事では、攻撃用コードの作り方や実行方法は扱いません。
対象を複製して文字列として読み、ログや正規配布物と照合する防御側の調査だけに絞ります。

すでに外部転送、管理者の追加、迷惑メール送信、ファイルの連続更新が起きている場合は、
調査より先にサイトを保護し、証拠を保ったまま専門家へ引き継ぐ判断も必要です。

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

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

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

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

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

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

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

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

PHP WebShellとは外部からサーバーを操作する入口

PHP WebShellとは、HTTPリクエストなどを通じて命令を受け、サーバー上の操作を行うPHPプログラムの総称です。
単なる不審文字列ではなく、攻撃者が侵入後も操作を続けるための入口として使われる点が重要です。

設置されると、ファイル閲覧・変更、別ファイルのアップロード、データベース操作、外部通信などへつながります。
ただし、PHPファイルというだけでWebShellと断定せず、入力・処理・出力・ログを一続きで確認します。

WebShellはファイル名ではなく機能で判断する

WebShellには決まったファイル名がありません。短い英数字、画像に似せた名前、正規コアに近い名前、
既存テーマへ追記された数行など、外見を変えて置かれるためです。

見るべきなのは、外部入力を受け取る仕組み、命令を実行する処理、ファイル管理や通信の能力、
認証を装う秘密値などが組み合わさっているかです。名前の有名・無名だけで結論を出してはいけません。

正規の管理ツールと不正なWebShellは由来が違う

サーバー管理用のPHPツールや保守会社の診断ファイルにも、強い操作機能が含まれる場合があります。
それでも、設置者・設置日時・用途・入手元・ハッシュを説明できなければ安全とは扱えません。

「管理に便利そうだから残す」は危険です。正規ツールでも公開範囲や認証が不適切なら、
第三者に見つけられてWebShellと同じ被害を生むため、不要なら証拠を残して撤去します。

wp2shellという脆弱性名とは分けて考える

WebShellは不正な操作入口の一般名であり、「wp2shell」はWordPress本体の特定脆弱性を指す呼び名です。
名前が似ていても、脆弱性があることと、WebShellファイルが設置済みであることは同じではありません。

脆弱性の対象バージョン確認と、侵害後のファイル調査は別工程です。
アップデートだけで設置済みの不正ファイルが消えるとは限らないため、両方を分けて確認してください。

WordPress脆弱性wp2shellとは？初心者向け緊急対策

PHP WebShellを見つけた直後は実行・削除・上書きをしない

疑わしいファイルを見つけた直後は、状態を変える操作を止め、証拠と復旧手段を確保するのが結論です。
急いで開く、削除する、更新日時を変える行為は、被害範囲と侵入経路の判断を難しくします。

URLへアクセスして画面を確認しない

ブラウザで対象URLを開くと、GETリクエストだけで初期化、復号、外部通信、別ファイル生成が走る可能性があります。
認証画面に見えても、安全確認にはならず、攻撃者へ稼働を知らせる危険もあります。

ローカルへ複製した後でも、WebサーバーやPHPが動く場所へ置いてはいけません。
拡張子を無害なものへ変え、実行権限のない隔離場所でテキストとして扱います。

PHPコマンドやIDEの実行機能で試さない

「php suspect.php」のような実行、IDEのデバッグ、プレビュー用サーバーへの配置も禁止です。
引数がなくても自動処理が起動するコードや、環境情報を外部へ送る処理が含まれる場合があります。

構文確認も本番ファイルへ直接行わず、まず読み取り専用の複製を用意します。
調査端末でもPHP実行環境から離し、必要なら専門の解析環境へ渡すのが安全です。

証拠を残さず即削除しない

WebShellを削除すると、そのURLからの操作は止まるかもしれませんが、侵入経路や実行履歴は分からなくなります。
別の入口、cron、データベース内コード、不審な管理者が残っていれば、すぐ再設置されます。

WordPressハッキング疑いの確認リスト【未確定向け】

PHP WebShellを実行せず調べる7つの手順

安全な調査は、原本を動かさず、メタ情報・静的なコード・アクセスログを順番に照合します。
1つの危険関数だけで断定せず、外部入力から実際の操作能力までを証拠でつなげることが重要です。

手順1〜2：場所・時刻・ハッシュを記録して複製する

最初にフルパス、所有者、権限、サイズ、作成・更新時刻を記録します。
サーバーのタイムゾーンも控え、アクセスログや管理作業の時刻と比較できる状態にしてください。

次に原本を変更せず複製し、SHA-256ハッシュを記録します。
調査中のファイルが最初に見つけたものと同一か確認でき、第三者へ引き継ぐ際も取り違えを防げます。

stat /path/to/suspect.php
shasum -a 256 /path/to/suspect.php
file /path/to/suspect.php

手順3〜4：正規配布物と照合し、文字列として読む

WordPressコアなら同じバージョンの公式配布物、プラグインやテーマなら正規入手元の同一版と比較します。
正規版に存在しないファイル、差分の説明がつかない追記、公開領域に不要な管理機能は強い警戒材料です。

複製はPHPとして開かず、プレーンテキストエディターで読みます。
長い1行、複数段の復号、文字列連結、意味のない変数名があっても、それだけで断定せず処理の流れを追います。

grep -nE '\$_(GET|POST|REQUEST|COOKIE|FILES|SERVER)|eval|assert|system|exec|shell_exec|passthru|proc_open|curl|fsockopen' suspect.php

上の検索は候補位置を絞るだけで、ファイルを実行しません。
一致しないから安全とは限らず、別名関数、配列、可変関数、外部ファイル読込も静的に確認します。

WordPressでよく見つかるマルウェアファイル名一覧と安全な削除方法｜感染時の初動と復旧手順

手順5〜6：入力経路と操作能力を対応づける

WebShell判定では、何を受け取り、どの処理へ渡し、何を返すかを線でつなぎます。
GET・POST・Cookie・HTTPヘッダー・アップロードファイルが、コマンド実行やファイル変更へ届くなら危険度が上がります。

秘密のパラメーターやハッシュ比較があっても、安全な認証とは限りません。
攻撃者だけが知る合言葉で入口を隠している場合があるため、認証らしい処理も目的と由来を確認します。

手順7：アクセスログと変更履歴で実行事実を確認する

静的解析でWebShellらしい能力が分かっても、実際に使われたかは別の問いです。
対象パスへのアクセス時刻、HTTPメソッド、応答コード、送受信量、送信元、User-Agentをログで照合します。

POST本文は通常のアクセスログに残らないことがあります。
それでも、不自然な連続POST、大きい応答、直後のファイル更新や外部通信を時系列へ並べると、操作の可能性を補強できます。

grep -F '/relative/path/suspect.php' access.log*
grep -F 'suspect.php' error.log*

ログ検索時も対象URLへリクエストを送る必要はありません。
ログの保存期間が短いサーバーでは、先に原本を退避し、管理画面の閲覧操作でローテーションを進めないよう注意します。

PHP WebShellの危険度はファイル・ログ・周辺変更で判断する

危険度は、コード単体ではなく、配置の不自然さ、実行能力、アクセス履歴、周辺の改変を組み合わせて判断します。
複数の証拠が同じ時刻と操作を示すほど、侵害済みとして扱う根拠が強くなります。

正常候補・要調査・高危険の3段階で整理する

正常候補は、設置者と目的を説明でき、正規配布物または社内管理物とハッシュが一致し、
公開範囲と認証方法も妥当なものです。それでも不要な管理ツールは公開領域へ残しません。

要調査は、由来が分からない、差分がある、入力処理はあるが操作能力が不明など、証拠が足りない状態です。
安全側に倒して公開領域から隔離し、正常と決めつけないことが大切です。

高危険は、任意操作の能力、対象パスへの不審アクセス、直後の改変、外部通信、別の永続化が重なる状態です。
ファイル1つの問題ではなく、WordPressとサーバー全体が侵害された前提で対応します。

同じ時刻帯の周辺ファイルとデータベースを見る

WebShellが見つかった時刻の前後には、ローダー、偽画像、改ざんされた設定、見知らぬ管理者、
不審な投稿・ウィジェット・オプションが追加されている場合があります。

更新時刻だけは攻撃者が変更できるため、絶対的な証拠ではありません。
バックアップ差分、FTP・SSH・コントロールパネルの履歴、WordPress操作履歴、メール通知も同じ時系列へ入れます。

スキャン結果は調査の入口として使う

Wordfenceなどのスキャンは、不審ファイルや公式差分の候補を広く探すのに役立ちます。
ただし、検出名だけで自動削除せず、誤検知と見逃しの両方を想定して原本・由来・ログを確認します。

クイックレスキュー365にはマルウェアスキャン機能はありません。
不正ログイン防御、ログインURL変更、XML-RPC遮断、uploadsでのPHP動作禁止など、復旧後の防御強化に使い分けます。

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

PHP WebShellが高危険なら隔離後にサイト全体を復旧する

WebShellが高危険なら、ファイルの削除だけではなく、影響範囲の封じ込め、正規ファイルへの復元、認証情報の更新を行います。
攻撃者が残した別経路を閉じなければ、見つけたファイルを消しても再感染します。

証拠を保存してから外部実行を止める

対象の原本・ハッシュ・ログを保存し、サイトをメンテナンス状態へ移すか、サーバー側で対象パスへのアクセスを遮断します。
遮断方法が分からない場合は、独断で権限を大きく変えず、サーバー会社へ不正アクセスの疑いを伝えて保全を依頼します。

個人情報や決済情報を扱うサイトでは、漏えい可能性の判断も同時に始めます。
業務継続だけを優先してすぐ公開へ戻すと、被害拡大や説明責任に必要な証拠を失うおそれがあります。

WordPressを正規ファイルから再構成する

WordPressコアは同一または安全な最新版の公式配布物、テーマとプラグインは正規入手元から再配置します。
感染した環境のファイルを部分的に使い回すと、目立たないバックドアを戻す危険があります。

uploadsは画像だけとは限らないため、拡張子、MIME、実体を確認します。
wp-config.php、.htaccess、mu-plugins、drop-ins、cron、データベースのoptionsやユーザーも復旧範囲に含めます。

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

WordPress管理者、サーバー管理、FTP・SFTP・SSH、データベース、メール、APIキーを棚卸しし、
安全な端末から長く固有の値へ変更します。感染端末から変更すると、新しい情報まで盗まれる可能性があります。

セッション、Application Passwords、不要な管理者、SALTも確認し、既存セッションを失効させます。
変更後はログイン成功だけでなく、知らない接続やファイル再生成が止まったかを監視してください。

WordPressが改ざんされた時の復旧方法｜ログイン不能・マルウェア駆除ガイド

PHP WebShellの再発防止は侵入経路ごとに行う

再発防止は、見つかったファイルを置けなくするだけでなく、最初に侵入された経路を閉じる必要があります。
脆弱性、漏えい認証情報、危険なアップロード、過剰権限を分けて対策します。

WordPress・テーマ・プラグインを更新して不要品を削除する

停止中のプラグインやテーマも、サーバー上にコードが残れば攻撃対象になります。
使用中だけを正規版で更新し、不要品、配布終了品、出所不明品はバックアップ確認後に削除します。

自動更新を有効にするかは互換性と運用体制で決めますが、更新通知を放置しない責任者と期限を決めるべきです。
本番更新が不安なら、ステージングと切り戻し手順を用意します。

アップロード領域でPHPを実行させない

通常のWordPress運用では、uploads配下でPHPを実行する必要はありません。
Webサーバー設定で実行を拒否すれば、アップロードされたPHPがWebShellとして動くリスクを下げられます。

ただしApache用設定をNginxへそのまま置いても効きません。
サーバー種類、管理画面の制約、既存機能への影響を確認し、テスト後に導入します。

変更検知とログ保存を平常時から準備する

平常時のファイルハッシュ、デプロイ履歴、管理者一覧、バックアップがあれば、異常時の差分を早く説明できます。
アクセスログ・FTP・SSH・管理画面ログは、事故発見より前まで遡れる期間を確保します。

アラートは件数を増やすだけでなく、誰が何分以内に確認し、どの状態で公開停止や専門家連絡を行うか決めます。
初動手順を文書化しておくことが、慌ててWebShellを実行・削除する事故を防ぎます。

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

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

PHP WebShellでよくある質問

PHP WebShellの発見時によく迷う点を、実務上の判断に絞って回答します。
判断材料が不足する場合は、安全と断定せず隔離と追加調査を優先してください。

PHP WebShellは実行せず証拠とログで判断する

PHP WebShellが疑われる時は、URLへアクセスせず、本番上でPHPとして動かさず、削除前に証拠を保存するのが正解です。
ファイル名や危険関数1つではなく、外部入力・操作能力・実行履歴・周辺変更をつなげて判断します。

安全か不正かを説明できないファイルは、不明のまま公開領域へ残さないでください。
調査表と証拠をそろえて隔離し、技術的に判断できない段階で専門家へ引き継ぐことも適切な対応です。

WordPressの不正アクセス・乗っ取りが自分で直せない時は

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

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

いまなら期間限定で