WordPressサイトを運営していて、特に避けたいトラブルのひとつがマルウェア感染です。
突然サイトが正常に表示されなくなったり、知らないサイトへ転送されたり、Googleからセキュリティに関する警告が表示されたりすると、「まず何を確認すればいいのか」「どこまで削除して大丈夫なのか」と判断に迷うことも多いと思います。
この記事では、無料ツールやWordPressプラグインを使った感染確認から、SFTP・SSH・WP-CLIを使ったファイル調査、データベースの確認、復旧後の再発防止まで、WordPressサイトでマルウェア感染が疑われるときの対応を順番に解説します。
感染が疑われる場合は、いきなり不審なファイルを削除するのではなく、まず現在の状態を確認し、バックアップを残したうえで調査を進めることが重要です。
1. マルウェア感染の兆候を確認する
まず確認したいのは、サイト上でどのような異常が起きているかです。
マルウェア感染では、次のような症状が見られることがあります。
- サイトが正常に表示されない
- 意図しない広告サイトやフィッシングサイトへ転送される
- 見覚えのないページや文章が追加されている
- Google Search Consoleにセキュリティ上の問題が表示される
- 検索結果やブラウザ上で危険なサイトとして警告される
- 管理者として作成した覚えのないユーザーが追加されている
ただし、サイトが真っ白になるなどの症状は、PHPエラーやWordPress・プラグインの不具合でも発生します。
表示がおかしいからといって、必ずしもマルウェア感染とは限りません。
まずは複数の情報から状況を確認していきます。
Google Search Consoleを確認する
Google Search Consoleを利用している場合は、「セキュリティの問題」に警告が表示されていないか確認します。
Googleがマルウェアや不正なページを検出している場合、問題の種類や対象URLが表示されることがあります。
感染が疑われるページを、確認のために何度もブラウザで直接開くことはおすすめしません。
不正なJavaScriptやリダイレクト、ブラウザの脆弱性を狙ったコードが含まれている可能性もあるため、Search Consoleや外部スキャナ、サーバー内のファイル調査を使って確認していきます。
外部からサイトをスキャンする
公開されているページの状態を確認する方法として、オンラインスキャナも利用できます。
代表的なものにSucuri SiteCheckがあります。
URLを入力するだけで、
- 公開ページ上の不審なコード
- 意図しないリダイレクト
- ブラックリスト登録状況
- 既知のマルウェアの兆候
などを確認できます。
ただし、こうしたオンラインスキャナは外部からアクセスできる範囲を調べるものです。
サーバー内に置かれているすべてのPHPファイルや、非公開ディレクトリ、データベースの内容まで確認できるわけではありません。
問題が見つからなかった場合でも、それだけで「感染していない」と判断しないようにしてください。
2. WordPress内部をスキャンする
外部からの確認だけでは分からないため、次にWordPress内部のファイルを調べます。
目視ですべてのファイルを調査するのは難しいため、セキュリティプラグインや公式チェックサムを利用すると確認しやすくなります。
セキュリティプラグインで確認する
WordPressには、ファイルの改ざんや不審なコードを確認できるセキュリティプラグインがあります。
代表的なものには次のようなものがあります。
- CenterShield (センターシールド)：WordPress公式ファイルとの比較やマルウェアスキャン、ファイルの変更確認などができる国産のセキュリティプラグイン。
- Wordfence Security：WordPressのファイルスキャンやファイアウォールなどを備えたセキュリティプラグイン。
- Anti-Malware Security and Brute-Force Firewall：WordPress内の不審なコードをスキャンできるプラグイン。
当サイトを運営するWPセンターでは「CenterShield (センターシールド)」を無料で公開しています。
CenterShield (センターシールド)では、WordPress本体やWordPress.orgで公開されているプラグインについて公式ファイルとの違いを確認できるほか、不審なファイルやマルウェアパターン、前回スキャンからの変更などをまとめて確認できます。
スキャン系プラグインはサーバー上の多数のファイルを読み込むため、サイトの規模やサーバー環境によっては負荷が高くなることがあります。
共用サーバーなどで利用する場合は、サイトへの影響にも注意してください。
VirusTotalを使う場合の注意点
特定のファイルが怪しい場合は、VirusTotalを使って複数のセキュリティエンジンで確認する方法もあります。
ただし、VirusTotalへアップロードしたファイルは外部サービスへ送信されます。
そのため、
wp-config.php- データベースのバックアップ
- 個人情報や顧客情報を含むファイル
- 非公開のソースコード
- APIキーやパスワードなどを含むファイル
などはアップロードしないようにしてください。
VirusTotalは、あくまで公開して問題のない不審ファイルを個別に確認する用途で利用するのが安全です。
3. 駆除作業を始める前にバックアップを取得する
不審なファイルが見つかった場合でも、すぐに削除するのはおすすめできません。
正常なファイルまで削除すると、サイトが表示できなくなったり、調査に必要な情報まで失ったりする可能性があります。
まず現在の状態を保存しておきます。
感染している状態でもバックアップを残す
感染している可能性がある状態でも、調査前のバックアップは残しておきましょう。
あとから、
- どのファイルが変更されていたのか
- いつ頃改ざんされたのか
- 誤って削除した正常なファイルがないか
などを確認するときに役立ちます。
ファイルとデータベースの両方をバックアップします。
SSHが利用できる場合は、例えば次のようにファイルをアーカイブできます。
tar czf wordpress-backup.tar.gz /path/to/wordpress/データベースも保存しておきます。
mysqldump -u USERNAME -p DATABASE_NAME > database-backup.sqlバックアップは、できれば感染しているWebサーバーとは別の場所にも保存してください。
なお、このバックアップにはマルウェアが含まれている可能性があります。安全な復元用ではなく、調査・比較のためのバックアップとして分けて保管してください。
可能であれば隔離した環境で調査する
本番サイト上で直接ファイルを削除していくと、作業途中でサイトが停止する可能性があります。
可能であれば、
- レンタルサーバーのステージング機能
- テスト用サーバー
- ローカル環境
- Dockerなどの隔離された環境
へコピーして調査します。
ただし、感染したファイルをそのまま複製することになるため、テスト環境をインターネットへ公開した状態にはしないでください。
Basic認証やIP制限を設定し、メール送信や外部API連携なども必要に応じて停止しておくと安全です。
4. WordPress本体とプラグインの改ざんを確認する
WordPress.orgで配布されているファイルについては、文字列検索よりも先に公式チェックサムとの比較を行うと効率的です。
チェックサムを使えば、公式配布ファイルから変更されているファイルを確認できます。
WordPress本体を確認する
WP-CLIを利用できる場合は、次のコマンドでWordPress本体のファイルを確認できます。
wp core verify-checksums --include-root問題がなければ、WordPress.orgで公開されている公式ファイルと一致していることを確認できます。
変更されたファイルや余分なファイルがある場合は、内容を確認します。
独自に変更しているファイルがある場合は、その変更も差分として扱われるため注意してください。
プラグインを確認する
WordPress.orgで公開されているプラグインについては、次のようにチェックできます。
wp plugin verify-checksums --all --strictチェックサムが利用できないプラグインや、
- 有料プラグイン
- 独自開発プラグイン
- 配布元がWordPress.orgではないプラグイン
については、正常な配布ファイルやバックアップと比較して確認します。
公式ファイルと手動で比較する
テーマや独自プラグインなどは、正常な原本と現在のファイルを比較します。
例えばLinuxやmacOSでは、diffを利用できます。
diff -ru official/ current/ > diff.txtここで重要なのは、単純に「最新版」と比較しないことです。
現在サイトで使用しているバージョンと、同じバージョンの正常なファイルを用意して比較します。
バージョンが違えば、正常なアップデートによる変更まで大量に差分として表示されてしまいます。
5. 独自ファイルやuploadsディレクトリを確認する
チェックサムだけでは確認できない場所もあります。
特に次のディレクトリやファイルは個別に確認します。
wp-content/uploads/wp-content/mu-plugins/- 独自テーマ
- 独自プラグイン
wp-config.php.htaccess- WordPressのルートディレクトリ
見覚えのないPHPファイルを確認する
例えばuploadsディレクトリに、設置した覚えのないPHPファイルがある場合は注意が必要です。
また、
- ランダムな文字列のファイル名
- WordPress本体に似せた名前
- 最近になって突然追加されたPHPファイル
- 不自然に長い難読化コード
なども確認します。
eval()、base64_decode()、gzinflate()などが大量に組み合わされているコードは不審な場合があります。
ただし、これらの関数が使われているだけでマルウェアと判断してはいけません。
正規のテーマやプラグインでも利用されることがあるため、コードの内容や公式ファイルとの差分を確認して判断します。
.htaccessとwp-config.phpを確認する
.htaccessが改ざんされると、特定のアクセスだけを別サイトへ転送するなどの処理が追加されることがあります。
wp-config.phpにも、不審な外部ファイルの読み込み処理などが追加される場合があります。
正常なバックアップがある場合は、過去のファイルと比較すると確認しやすくなります。
6. 不審なファイルは削除する前に隔離する
マルウェアと思われるファイルを見つけても、可能であれば最初から完全に削除せず、一度隔離しておくと安全です。
例えば、
- Webからアクセスできないディレクトリへ移動する
- Webルート外など、PHPとして実行されない隔離領域へ移動する
- バックアップを保存してから正常な公式ファイルへ置き換える
といった方法があります。
隔離または置き換えたあと、
- サイトが正常に表示されるか
- 管理画面へログインできるか
- フォームや検索などが動作するか
- エラーログに問題が出ていないか
を確認します。
WordPress本体やWordPress.org配布プラグインの改ざんであれば、改ざん部分だけを手作業で直すよりも、正常な公式ファイルへ置き換える方が安全なケースもあります。
7. データベースも確認する
マルウェア感染は、ファイルだけで完結するとは限りません。
データベース内に、
- 不正なJavaScript
- iframe
- リダイレクト用のコード
- スパムページ
- 不審な管理者ユーザー
などが追加される場合があります。
ファイルを修復しても症状が残る場合や、投稿内容が改ざんされている場合はデータベース側も確認します。
不審な文字列を検索する
WP-CLIが利用できる場合は、wp db searchを使って特定の文字列を探すことができます。
wp db search "不審な文字列"phpMyAdminの検索機能を利用しても構いません。
重要なのは、検索結果を確認せずに文字列を一括削除しないことです。
例えばeval(やbase64_decodeといった文字列が見つかったからといって、それだけでデータベース全体から削除してはいけません。
正常なプラグイン設定や投稿データまで破壊する可能性があります。
シリアライズされたデータを直接書き換えない
WordPressのデータベースには、PHPのシリアライズ形式で保存されているデータがあります。
このデータをphpMyAdminなどから単純に書き換えると、文字列の長さ情報が合わなくなり、データが壊れる場合があります。
不正なデータを見つけた場合は、
- どのテーブル・レコードに保存されているかを確認する
- どのテーマ・プラグインが利用しているデータか確認する
- データベースのバックアップを取得する
- 必要なレコードだけを修正する
という順番で対応します。
一括置換は、対象と影響範囲を理解したうえで行うようにしてください。
管理者ユーザーも確認する
「ユーザー」画面を開き、作成した覚えのない管理者アカウントがないか確認します。
不正な管理者が追加されていた場合は、そのユーザーを削除するだけではなく、不正ログインされた原因も調査してください。
8. 復旧後に認証情報を変更する
マルウェアを削除しても、攻撃者がログイン情報を知っている状態では再び侵入される可能性があります。
復旧後は、必要に応じて次の認証情報を変更します。
- WordPress管理者のパスワード
- サーバー管理画面のパスワード
- SFTP・FTPのパスワード
- SSHの認証情報
- データベースのパスワード
- 関連するAPIキーや外部サービスの認証情報
同じパスワードをほかのサービスでも使っている場合は、そちらも変更してください。
WordPressの認証キーを再生成する
wp-config.phpには、WordPressのログイン状態を保護するための認証キーが設定されています。
感染後はこれらを再生成することで、既存のログインセッションを無効化できます。
WordPress.orgのSecret-key Serviceなどから新しい値を取得し、wp-config.phpの
AUTH_KEYSECURE_AUTH_KEYLOGGED_IN_KEYNONCE_KEY- 各SALT
を変更します。
2要素認証を設定する
管理者アカウントには、パスワードだけでなく2要素認証を設定しておくと、不正ログイン対策として有効です。
あわせて、
- ログイン試行回数の制限
- 不要な管理者アカウントの削除
- 推測されにくいパスワードの利用
なども確認しておきます。
9. 感染原因になった可能性のある箇所を修正する
マルウェアを削除してサイトが正常に戻っても、侵入経路が残っていれば再感染する可能性があります。
復旧後は、WordPress本体やプラグイン、テーマの状態を確認します。
WordPress・プラグイン・テーマを更新する
古いWordPress本体やプラグイン、テーマの脆弱性が侵入経路になることがあります。
使用しているバージョンを確認し、既知の脆弱性があるものは更新します。
すでに開発が終了しているプラグインやテーマについては、別のものへの切り替えも検討してください。
不要なプラグインやテーマを削除する
無効化しているだけのプラグインやテーマも、サーバー上にはファイルが残っています。
今後使用しないものは削除しておきましょう。
同じサーバー内のほかのサイトも確認する
1つのサーバーアカウントで複数のWordPressサイトを運用している場合は、感染したサイトだけではなく、同じサーバー内のほかのサイトも確認してください。
別サイトにバックドアが残っていると、修復したサイトが再び改ざんされることがあります。
10. Googleの警告が出ている場合は再確認を依頼する
マルウェアを除去しても、Googleの検索結果やブラウザ上の警告がすぐに消えるとは限りません。
Google Search Consoleの「セキュリティの問題」を確認し、問題をすべて修正したあとに再審査をリクエストします。
再審査を依頼する前に、
- 不正なファイルが残っていないか
- 不審なページが残っていないか
- 意図しないリダイレクトが解消されているか
- 侵入原因になった脆弱性を修正したか
をもう一度確認しておきましょう。
11. 再発を防ぐために普段から確認しておきたいこと
マルウェア感染を完全に防ぐことは難しいため、重要なのは「感染しにくい状態」と「異常に早く気付ける状態」の両方を作ることです。
定期的にファイルを確認する
WordPress本体やプラグインが書き換えられていないか、不審なファイルが追加されていないかを定期的に確認します。
CenterShield (センターシールド)やWordfenceなどのセキュリティプラグインを利用する方法もあります。
バックアップを取得する
WordPressのファイルとデータベースを定期的にバックアップします。
可能であれば、バックアップはWordPressを設置しているサーバーとは別の場所にも保存してください。
また、バックアップを取得しているだけではなく、実際に復元できるか確認しておくことも重要です。
WordPressとプラグインを定期的に更新する
WordPress本体やプラグイン、テーマのアップデートには、脆弱性の修正が含まれることがあります。
ただし、本番サイトを無条件にすべて自動更新すると、不具合が起きたときにサイトへ影響する場合があります。
サイトの重要度に応じて、
- バックアップを取得する
- ステージング環境で確認する
- 更新後に表示やフォームを確認する
といった運用を行うと安全です。
WAFやログイン対策も確認する
レンタルサーバーにWAF機能がある場合は、有効になっているか確認します。
また、
- 2要素認証
- ログイン試行回数の制限
- 不要なXML-RPCアクセスの制限
- 重要ファイルへのアクセス制限
など、WordPress側の基本的なセキュリティ設定も見直しておきましょう。
自力での復旧が難しい場合は専門家への相談も検討する
マルウェア感染の状況によっては、自力での調査が難しい場合もあります。
特に次のようなケースでは、無理にファイルを削除せず、専門家への相談も検討してください。
- 管理画面へログインできない
- ファイルを削除してもすぐに復活する
- 複数のサイトが同時に感染している
- データベースにも多数の不審なデータが見つかる
- 個人情報や顧客情報を扱っている
- 正常なファイルと不正なファイルを判断できない
- 復旧しても何度も再感染する
よくあるのが、目についたマルウェアだけを削除し、別のバックドアや侵入原因が残っているケースです。
例えば、
- 不審なPHPファイルを削除したが、別のディレクトリにバックドアが残っていた
- WordPressを修復したが、脆弱性のあるプラグインをそのまま使用していた
- ファイルを修復したが、不正な管理者アカウントが残っていた
- 同じサーバー内の別サイトが感染したままだった
といった状況です。
「マルウェアを削除した＝復旧完了」ではなく、侵入経路と再感染の原因まで確認することが重要です。
まとめ
WordPressサイトでマルウェア感染が疑われる場合は、いきなり不審なファイルを削除するのではなく、まず現在の状態を確認することから始めます。
Google Search Consoleや外部スキャナで状況を確認し、バックアップを取得したうえで、WordPress本体やプラグインの公式チェックサム、独自ファイル、データベースなどを順番に調べていきます。
不審なファイルが見つかった場合も、文字列だけでマルウェアと判断したり、データベースの内容を一括削除したりするのではなく、正常な原本や公式ファイルと比較しながら対応することが大切です。
復旧後は、パスワードやWordPressの認証キーを変更し、WordPress本体・プラグイン・テーマの更新、不要なアカウントやファイルの削除、2要素認証やWAF、定期バックアップなども見直しましょう。
マルウェア対策では、感染したファイルを削除すること以上に「なぜ侵入されたのか」「再び侵入できる状態が残っていないか」を確認することが重要です。
自力で正常なファイルと不正なファイルを判断できない場合や、復旧後も再感染を繰り返す場合は、バックアップを残した状態で専門家へ相談することをおすすめします。
