WordPressセキュリティインシデント調査の実例｜WebShell・SEOスパムを解説

WordPressに見覚えのないページや管理者が増え、
「セキュリティインシデント調査では何を調べるの？」と困っていませんか？

専門的な調査報告書には、アクセスログ、WAF、WebShell、ハッシュなど、
初心者には分かりにくい言葉が数多く並びます。

そこで今回は、実際に行ったWordPressのセキュリティインシデント調査を完全に匿名化し、
何が起き、何を調べ、どのように安全を確認したのかを図解します。

よこやま良平

WordPressの復旧を多数手がけてきたよこやま良平です。今回わたしが実際に行ったログ・データベース・WAF調査と残存検査を、企業や個人を特定できない形で分かりやすく解説します。

結論から言うと、この実例では侵害と攻撃に使われた操作口を確認できました。
ただし、最初にWebShellが設置された方法は、必要な期間の証拠がなく確定できませんでした。

難しい報告書の内容を「攻撃の流れ」と「調査・対応の流れ」に分け、
2枚のイメージ図を使って順番に説明します。

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

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

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

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

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

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

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

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

WordPressセキュリティインシデント調査の実例で何が起きたか

今回のWordPressセキュリティインシデントでは、WebShellを操作口として、
バックドア、不正管理者、検索エンジン向けSEOスパムへ被害が広がっていました。

Web・エラー・FTP・WAFを合わせて200万件を超える記録とデータベースを確認し、
100回を超えるWebShellへの操作と、数千種類のスパムURLを時系列で照合しました。

実例で確認した4つの被害

今回一般化して紹介する事例では、通常のページとは別に、
検索エンジン向けの海外語スパムページが大量に生成されていました。

調査を進めると、プラグイン領域に置かれていたPHPファイルが遠隔操作され、
別の不正PHPや見覚えのない管理者が追加された流れを確認できました。

左側の外部通信が、サーバー内に既に存在した不正PHPへ到達し、
そこから3種類の被害へ枝分かれしたイメージです。

操作に使われた入口と根本原因は同じとは限らない

ログから、攻撃者がどのPHPファイルを操作したかは確認できました。
一方、そのファイルが最初に設置された日時や方法は、保存期間内のログに残っていませんでした。

この場合、「攻撃の操作口は特定」「根本の侵入経路は未確定」と分けて報告します。
証拠がない部分を、古いプラグインやパスワード漏洩が原因だと決めつけてはいけません。

クイックレスキュー

WordPress乗っ取りの原因と侵入経路｜症状別の確認・復旧・再発防止 WordPressが乗っ取られた原因を特定できず困っていませんか。脆弱性・認証情報・不正管理者・バックドアの調べ方と、証拠を残しながら復旧する順番を解説。再感染を防ぎた…

WordPressセキュリティインシデント調査の実例では証拠を保全した

WordPress改ざん調査では、慌てて削除する前に証拠を保存することが最優先です。
削除や上書きによって、侵入時刻や攻撃元を判断する手掛かりが消えるためです。

最低限保存したいデータ

ファイルは更新日時だけでなく、SHA-256などのハッシュ値も記録すると、
調査中に内容が変わっていないことを説明しやすくなります。

サイトを止める必要がある時も原本を残す

被害が続いている場合は、公開停止やアクセス制限が必要になることがあります。
ただし、停止作業の前後でバックアップを取り、何を変更したか記録してください。

感染中のWordPressへ新しいプラグインを追加すると、時刻やファイルが変わり、調査が難しくなる場合があります。

クイックレスキュー

WordPressが乗っ取られた時に最初にやること｜被害拡大を防ぐ初動対応 WordPressが乗っ取られたかもしれない時に、初心者でも落ち着いて進めやすい初動対応を解説します。被害確認、ログイン停止、バックアップ、復旧前チェック、再発防止まで…

WordPressセキュリティインシデント調査で実際に確認した5種類の記録

WordPress改ざん調査は、一つのログだけで結論を出さず、
Web・認証・WAF・データベース・ファイルを横断して確認します。

アクセスログとエラーログ

アクセスログには、送信元IP、時刻、URL、GETやPOST、ステータスコード、応答サイズなどが記録されます。
不正PHPへのPOSTが続いた直後に別ファイルへ200応答が出ていれば、操作の流れを追えることがあります。

送信元IP - 日時 "POST /plugin/example.php" 200 応答サイズ
送信元IP - 数秒後 "GET /追加された不正ファイル.php" 200 応答サイズ
別のIP   - 後日   "GET /海外語のスパムURL/" 200 応答サイズ

200は必ずしも正常を意味しません。404でもWordPressが受け取り、
内部で不正ページを返しているケースがあるため、応答サイズや前後のアクセスも比較します。

FTP・SFTP・SSH・管理画面の操作ログ

ファイルが外部からアップロードされた疑いがある場合、
FTPやSFTP、SSH、サーバー管理画面のログが初回侵入の判断材料になります。

ただし、ホスティング会社によっては利用者が取得できず、
警察機関や弁護士による正式な要請が必要な場合があります。資料がなければ、技術的に推測できても確定はできません。

WAFログは「検知されなかった攻撃」も考える

WAFが多数の攻撃を遮断していても、今回の侵害操作が必ず記録されるとは限りません。
既に置かれたWebShellへの通常のPOSTが、ルールに一致しないこともあるためです。

「WAFが動いていたから侵害されていない」とは判断せず、
アクセスログと同じ時刻・URL・IPがWAF側にあるか照合します。

データベースは現在と過去を分けて判断する

データベースでは、管理者ユーザー、権限、投稿、オプション、Cron、セッションなどを確認します。
ただし、ダンプ時点で不正ユーザーがいなくても、過去に存在しなかったとは言えません。

アクセスログに管理者作成の操作が残り、後日のDBにユーザーが存在しない場合は、
調査前に削除された可能性を含めて時系列を整理します。

クイックレスキュー

WordPressの管理者ユーザーが勝手に増えた時の危険性と初動対応 WordPressに見知らぬ管理者ユーザーが増えて困っていませんか？削除前の証拠保全、権限停止、セッション遮断、認証情報変更、侵入口調査、投稿を失わない削除判断を初心者…

実例で行った調査と対応の全体像

重要なのは、クライアントが行った削除・移行と、
よこやま良平が行った調査・残存検査を分けて記録した点です。

現在は、公開フォルダー全体の実地検査で、感染ファイル、WebShell、
その他のマルウェアが残っていないことを確認しています。

つまり、被害の広がり方と攻撃時の操作は特定できましたが、
最初の侵入だけは証拠不足のため断定していません。

WordPressセキュリティインシデント調査は時系列で攻撃手法を確認する

WordPress改ざん調査では、個別の不審アクセスより、
複数の出来事がどの順番で発生したかを見る方が重要です。

WebShellへのPOSTから不正ファイル実行までをつなぐ

WebShellとは、ブラウザ経由でサーバー上の命令やファイル操作を行う不正プログラムです。
見た目は通常のPHPファイルで、プラグインやテーマの中へ紛れ込むことがあります。

同じIPからWebShellへPOSTが行われ、その直後に新しいPHPへアクセスがある場合、
不正ファイルを設置して動作確認した可能性が高まります。

検索エンジンだけに見せるSEOスパムを確認する

SEOスパムは、管理者や一般利用者には正常なページを見せ、
Googlebotや検索経由の訪問だけに賭博・偽通販などを表示する場合があります。

そのため、ブラウザでトップページを見るだけでは不十分です。
不審URL、User-Agent、参照元、応答サイズ、サイトマップ、Search Consoleを合わせて確認します。

クイックレスキュー

検索結果汚染をサーチコンソールで対処する方法【初心者向け完全ガイド】 サイトを検索すると見知らぬスパムページが表示される「検索結果汚染」。原因の確認からGoogleへの削除依頼、WordPress本体の修正まで、サーチコンソールを使って初心者で…

断定できることと推測を分ける

攻撃元IPが分かっても、そのIPを使った個人や組織までは断定できません。
VPN、プロキシ、侵害された別サーバーが中継に使われることがあるためです。

調査報告書には根拠と限界を一緒に残す

調査結果は、単に「感染していた」「直った」と書くだけでは不十分です。
調査したログの種類と期間、確認件数、主要な時刻、攻撃元、操作されたURLを整理します。

さらに、現在の残存、情報漏洩を示す記録、取得できなかった資料も明記してください。
後から関係者が読んでも、どの証拠から結論を出したのか判断できる報告書になります。

ログの保存期間が短い、FTPや管理画面の操作記録を取得できないなど、
調査者では解決できない制約もあります。その場合は技術不足ではなく、証拠資料の範囲による未特定だと説明します。

WordPressセキュリティインシデント調査後に行った残存確認

WordPress改ざん調査後は、見つかったファイルだけでなく、
Web公開領域全体とデータベースを確認して残存を判断します。

ファイル・ユーザー・自動実行を横断する

また、管理画面を守るための.htaccessを置く場所にも注意が必要です。
wp-admin全体を遮断すると、フォームやAjax、外部通知、一部の自動処理が止まることがあります。

認証情報とWordPressを更新する

残存がないことを確認したら、WordPress、サーバー管理画面、FTP・SFTP、DB、関連メールの認証情報を更新します。
WordPressの認証キーを再生成し、既存セッションも失効させます。

WordPress本体、テーマ、プラグインは、互換性とバックアップを確認したうえで、
サポートされている最新版へ更新してください。使っていない拡張機能は停止だけでなく削除します。

クイックレスキュー

WordPressマルウェア駆除後にやることは？再感染を防ぐ設定と見直しポイント WordPressマルウェア駆除後にやることが分からず不安な方へ。再感染を防ぐ設定見直し、管理者・パスワード・uploads制限・バックアップ・監視ポイントまで初心者向けに解説…

WordPressセキュリティインシデント調査で情報漏洩を確認した結果

WordPress改ざん調査では、サイトの復旧だけでなく、
顧客情報や認証情報が外部へ送られた形跡も確認します。

ただし、ログに大量ダウンロードや外部送信が見つからないことと、
情報漏洩が絶対になかったことは同じではありません。

確認できた事実と技術上の可能性を分ける

アクセスログにDBの取得、大量ファイルのダウンロード、不審な外部送信がなければ、
現資料上は「漏洩を示す記録は確認されなかった」と表現します。

一方、WebShellが動作していた場合は、サーバー上の情報へ触れられた可能性があります。
そのため、「漏洩なし」と断定せず、保存されているログの範囲と限界を報告書へ記載します。

漏洩が確認できなくても認証情報を交換する

漏洩を示す記録がなくても、侵害されたサーバーに保存されていた秘密情報は、
見られた可能性を考えて交換する方が安全です。

WordPress管理者、サーバー、FTP・SFTP、DB、SMTP、外部APIのパスワードやキーを棚卸しし、
安全な端末から更新します。使っていない連携やセッションは無効化してください。

WordPress改ざん調査を自分で続けない方がよい状態

WordPress改ざん調査で不審なPHPや管理者が複数見つかった場合は、
自分で削除を続けず、現在の状態を保存して専門家へ相談してください。

理由は、操作を重ねるほどログや更新日時が変わり、
侵入経路の特定と完全な残存確認が難しくなるためです。

わたしの実務では、削除後の再調査より、変更前の証拠が残っている段階の方が、原因と被害範囲を正確に判断できます。

WordPress改ざん調査のよくある質問

不正ファイルを削除すれば調査は終わりですか？

終わりではありません。別のバックドア、不正管理者、Cron、設定改ざん、検索スパムが残っていないか、ファイルとDBとログを横断して確認する必要があります。

WAFが有効なら侵入されませんか？

完全には防げません。WAFは多くの攻撃を遮断しますが、既設WebShellへの操作やルールに一致しない通信が記録されない場合があります。アクセスログやファイル監視との併用が必要です。

データベースに不正データがなければ安全ですか？

DBダンプは取得時点の状態です。過去に作成された不正管理者や投稿が既に削除されている可能性があるため、アクセスログと時系列で照合してください。

侵入経路を必ず特定できますか？

必要な期間のWeb・FTP・SFTP・SSH・管理画面ログがそろっていれば特定できる可能性が高まります。ただし、ログが保存されていない場合は、操作口まで特定できても最初の設置方法は未確定になります。

WordPressセキュリティインシデント調査実例のまとめ

WordPress改ざん調査では、感染ファイルを消す前に原本とログを保存し、
Web、WAF、認証、データベース、ファイルを同じ時系列で確認します。

見えている症状だけを直すと、侵入口や別のバックドアが残る恐れがあります。
特定できた事実と未確定部分を分け、再発しない状態まで確認することが大切です。

WordPress改ざん調査で困ったら自分で作業せずご相談ください

不審ファイルを自分で削除すると、証拠が消えたり、サイトが動かなくなったりすることがあります。
困ったら自分で行わないで、今すぐ弊社へご連絡ください。

現在の状態をできるだけ変更せず、発生日時・症状・サーバー名・バックアップの有無をお知らせください。初期費用・調査費用0円で状況を確認します。