【自力で復旧したい方へ】WordPress改ざん・マルウェア感染時の復旧手順まとめ
「サイトが改ざんされていた…」
「Google検索で “このサイトは危険です” と表示された…」
「突然、大量のスパムメールが送信されていた…」
WordPressサイトがハッキング・マルウェア感染された場合、正しい手順での復旧が非常に重要です。
この記事では、被害の原因調査から、改ざんファイルの除去、サイトの安全な復元まで、自力で対応するための復旧手順を解説します。
バックアップからサンドボックスの検証環境を作り、もっと丁寧に掘り下げて検証し、復旧手順を作ってから本番環境で復旧作業する場合などに比較すると、すべて本番環境でぶっつけで行い、レンタル共有サーバー上における安価で最低限の復旧対応ではよくある手順となっています。自己責任となります。
本番環境で全作業を行うため、基本的にメンテナンスモード表示は行わない方法です。
✅ この記事でわかること
- WordPressハッキング被害の代表的な症状
- 不審ファイルや改ざん箇所の見つけ方
- バックアップや再インストールによる復旧方法
- 自力復旧が難しいケースと判断のポイント
初動対応がまだの方は、まずこちらから:
👉 [WordPressサイトがハッキングされたときの初動対応チェックリスト]
0. 事前準備キャッシュ無効化
症状確認の前に、プラグインのキャッシュ機能、サーバー側のキャッシュ機能、CDNのキャッシュ機能など、キャッシュ機能はすべて無効化します。キャッシュが効いていない状態になったことを確認してから、症状確認をしないと正しく診断できません。ブラウザのシークレットウィンドウで各種履歴などを全部削除しながらクリーンな状態で確認が必要です。
仕組みを理解せず、パフォーマンス対策のためになんとなくキャッシュ機能を使っているケースは多いですが、大切な作業前準備となります。
キャッシュやCDNのチューニング作業は、完全復旧してから行うようにしてください。
1. よくあるハッキングの症状を確認
まず、次のような現象が出ていないかチェックしましょう。
- サイトが勝手に他サイトへリダイレクトされる
- WordPress管理画面にログインできない
- サイト上に英語の謎のリンクや広告が表示されている
wp-content/uploads/に**.phpファイル**などが増えている(表層解析)- Google検索で警告表示が出ている(例:「このサイトは危険です」)
- ブラウザのディべロッパーツールのconsoleでWordPressと関係ない通信を個々に把握する(動的解析)←大事ですが、本来サンドボックスで行います。
2. サイトの構成とバージョンを把握
復旧作業を進める前に、可能な限り、SFTPやSSH接続で以下を確認・メモしておきましょう。今後もFTPは利用しないようにしてください。
- WordPressのバージョン
- 使用テーマとバージョン(親/子テーマどちらも)
- インストールされているプラグインの一覧とバージョン
- PHPバージョン
- MySQLなどのデータベースバージョン
- ApacheやNginxやIISなどWEBサーバの種類とバージョン
古いプラグインや古いテーマは、脆弱性の原因になっている可能性があります。既知の脆弱製であれば、「プラグイン名(テーマ名) バージョン vulnerability」で検索するとCVE(脆弱性のグローバルな識別番号)が見つかります。WordPressの場合、patchstackが脆弱性データベースとしては世界的に有名です。
3. ログのバックアップ、ログの調査
レンタル共有サーバーである場合、取得できるログの限界があるため、調査できることの限界はありますが、アクセスログにて事象発生開始期間の年月日時分秒のhttpsリクエスト、エラーログを見ながら怪しいリクエストやレスポンスの箇所を探します。
4. バックアップを使って復旧する(可能なら推奨)
✅ ファイルとデータベースの安全なバックアップが有る場合限定
- ファイルとデータベースを丸ごとバックアップから復元する
- 「バックアップの作成日時がハッキング後だった」場合、基本的に作業ミスによる作業やり直しなどが起きない限り、ハッキング後バックアップデータは使わないようにしてください。
5. 安全なバックアップが無い場合の手動復旧手順
phpバージョンが古い場合、この工程の中でphpバージョンも最新安定版まで引き上げるようにしてください。
✅ ステップ0:作業ミス発生時のロールバック向けバックアップ取得
※作業を行うPCがWindowsである場合、最新のWindows Update状態になっているか確認し、最新でない場合は最新化を行ってからバックアップ取得作業を実施してください。
マルウェア侵害を受けていても、正常なコンテンツが残っている部分もあるため、ファイルもデータベースも作業前バックアップを必ず取得してください。復旧作業をミスしたときに非常に役立ちます。
WindowsローカルへFileZilla等のSFTPで全ファイルを取得する際、Windows Defenderはファイル転送中にマルウェア(の一部)を見つけて隔離してくれる場合があります。隔離されたファイルがマルウェアであれば、本番環境で削除します。
※調査検証対策向けにマルウェアを残す場合、他者や第三者へ流出しないようにすることが非常に大切です。復旧作業の完全終了後、Windowsローカルにダウンロードしたマルウェアを含むバックアップはすべて削除することを強く推奨します。
IPA(独立行政法人情報処理推進機構セキュリティセンター)への届出
以下にて届け出が可能です。
✅ ステップ1:最新バージョンをWordPress公式からダウンロード
WordPress本体はgithub(WordPress)、公式テーマ(親)はWordPressテーマディレクトリ、公式プラグインはWordPress Pluginsなどで、最新バージョンをダウンロードしてWindowsローカルに原本資材として保管します。有料テーマもテーマ配信元でクリーンな最新バージョンを取得します。
テーマの過去バージョンはgithubで探せる場合があります。公式プラグインの過去バージョンはSVNで探すことが可能です。
バージョン更新の継続が停止してしまっている古いままのテーマや古いままのプラグインは、基本的に使わないようにしてください。
※被害を受けたバージョンが古い場合、最新バージョンを復旧で利用すると、アップロード直後に真っ白画面等のマルウェア被害と関係ない単純エラー発生の可能性が上がります。
理想としては、DockerなどでサンドボックスのWordPress検証環境をバックアップから事前に構築し、真っ白画面など、エラーが出ないか事前検証、エラーが出る場合は対処方法まで事前に手順書を確立しておくことが推奨されます。
WordPress検証環境を構築する場合、事象発生時の本番環境と全要素が完全に同じ状況の検証環境構築は難しいため、本番環境と検証環境の環境差を把握して検証することが重要です。
✅ ステップ2:WordPressのrootフォルダ、wp-content/themes、wp-content/pluginsなどの既存のファイル削除
入手できた原本資材について、相当するサーバー内の該当フォルダ(WordPressのrootフォルダ、wp-content/themes、wp-content/plugins、など)該当のファイルをすべて削除します。
※該当しないフォルダやファイル、特にwp-config.phpや.htaccess、アクセス解析ツールの認証用ファイル、オリジナルテーマ、オリジナルプラグインなどを削除しないようにご注意ください。
削除完了後、入手できたアップロード資材をアップロードします。
※「3. 不審ファイルやコードの洗い出し」でマルウェア洗い出し駆除を行うため、クリーンインストールを許容出来ない場合、上書きアップロードを行ってください。ただ、コンバージョンが限りなくゼロに近い状態であることを経営層に伝えれば、クリーンインストールの許可を得られることもあります。 マルウェアを完全に120%削除できた!と言い切るための根拠資料を最終的に短時間で低コストで用意することは容易ではないため、「クリーンインストール」を強く推奨します。あくまでも、標準提出できるのは作業証跡となります。
✅ ステップ3:WordPress本体のアップロード
- ステップ1で入手した最新バージョンWordPress本体をSSH/SFTPでフォルダ階層を間違えないように慎重に上書きアップロードします。
✅ ステップ4:テーマ・プラグインのアップロード
- ステップ1で入手した最新バージョンテーマ・最新バージョンプラグインをSSH/SFTPでフォルダ階層を間違えないように慎重に上書きアップロードします。
- 不要なテーマやプラグインは、アップロードをしないで削除しますが、必ず削除前にテーマ名やプラグイン名を控えておいてください。データベースクリーニング時に不要なDBテーブル削除作業で威力を発揮します。また、options.php の読み込み肥大によるページパフォーマンス悪化に対しても有用です。
✅ ステップ5:アップロードフォルダの確認
wp-content/uploads/に.phpや.icoなど本来不要なファイルがないか確認し、削除- 特に年/月フォルダに仕込まれていることが多いため注意!
6. 不審ファイルやコードの洗い出し
🔍 方法①:セキュリティプラグインでスキャン
- Wordfence Security – Firewall, Malware Scan, and Login Security
- Sucuri Security
- MalCare
- Anti-Malware Security and Brute-Force Firewall
- WPDoctor Malware Scanner & Vulnerability Checker & IP blocker with Hack monitor Lite
などのプラグインをインストール、スキャンを実行します。検出結果の差が出るため、メジャーなマルウェアスキャンプラグインは全部実施してください。スキャン結果に「unknown file」「modified core file」「malware suspected」などが出たらマルウェアである可能性が高いです。
マルウェアであるかどうか?については、難読化をデコードしたうえで、ここまでの時系列把握を元にサイバーキルチェーンではどこの段階であるか?考えながらソースコードを読んで判断します。自身がない方は専門家に依頼しましょう。※難読化されている時点でマルウェアである可能性は高です。
ファイルだけでなく、データベースのスキャンも重要です。
🔍 方法②:手動で確認する主な箇所
/wp-content/uploads/に .phpファイルがある.htaccessに不審なコードが追加されているfunctions.php,index.phpにeval(),base64_decode()などの怪しいコード- 不審なcronジョブ(定期実行コード)が登録されていないか確認
☑️【参考】:【完全版】WordPressへの侵入経路を調査する方法|再発防止のためにやるべきログとファイルの確認ポイント
7. データベースの確認と復元
- 投稿本文・ウィジェット・カスタムフィールドにスパムリンクやjavascriptが埋め込まれていないか確認
- 確認にはレンタル共有サーバーの phpMyAdmin などを使用したり、SQLダンプファイルに対して静的解析ツールを利用します。
- 異常が多い場合、健全なバックアップがあれば、DBをリストアする方が確実です
wp_options、wp_users、wp_usermeta、wp_terms、wp_termmeta、wp_links、などのパラメータ数が少なくて目視しやすいDBテーブルあたりは、目視でも見つけやすいです。
EX) wp_options の siteurl や home などがリダイレクトするように書き換えられている!など。
8. 正常化確認
インシデント事象の挙動がすべて無くなったことを確認します。
「1. よくあるハッキングの症状を確認」で動的解析した結果、マルウェアによる影響だと判定された通信がブラウザのディべロッパーツールのconsoleで全てなくなったことを確認します。←大事です。
監視ツールを導入し、監視します。再発する場合、相手はボットであるため早ければ数時間で再発します。2~3日、監視で問題なければ基本的には完全復旧です。この記事に書いているので、攻撃者は4日後を狙ってくるかもしれませんが・・・。
キャッシュチューニングは、この後、行ってください。
9. Search Consoleで再審査申請を行う
✅ Google検索で警告が出ていた場合
- Search Consoleにログイン
- 「セキュリティの問題」タブを開く
- 「審査をリクエスト」からクリーンアップ済である旨を申請
クリーンアップが不完全な場合、申請が却下されるので要注意です。
10. 再発防止のための確認ポイント
マルウェア削除して復旧後、即座に堅牢化を行うことが再発防止として最重要です。
予算とマンパワーに応じて、再発防止策を検討します。
- 復旧後の早急な堅牢化(セキュリティ強化)実施
- コア、テーマ、プラグインの更新(永続)
- 新規CVEチェックと定期的なパッチ当て
- 定期的な脆弱性診断の実施
- 固定IPや踏み台を活用した管理者アクセスの厳格な制限
- 管理ユーザーと権限を再確認(不審な管理者がいないか)
- デフォルトログインURLの変更
- 多要素認証(MFA)の導入
- セキュリティプラグイン設定(Solid Security など)
- 不慣れな方は、専門家と相談することをおすすめします。
- 不要なテーマ・プラグインの削除
- 本番環境でむやみにプラグインをインストール/アンインストールしたり試さない
- phpバージョンを最新安定版に更新(永続)
- 更新が継続されていないプラグインやテーマの採用禁止
- patchstackで脆弱性の傾向を確認
- WordPress公式のプラグインやgithubで開発継続の有無を確認
- WAF導入
- レンタル共有サーバーのWAFは柔軟性や自由度が低いですが侮れません。
- マーケティング向けにWAFのチューニングが必要な場合はコスパでCloudflareを推奨
- (可能であれば)無駄なポートのクローズ
- 不要なデータベーステーブルやoptionについての正しい削除
- コア、テーマ、プラグインの更新(永続)
自力復旧が難しいときの判断基準
次のような場合は、復旧代行業者に相談するのが得策です:
- 検出されたソースコードがマルウェアであるかどうか?判定できない。
- ウイルスやスパム送信の影響でパーミッション000になっているなどパーミッションがよくわからない。
- ECサイトや個人情報を扱っていて損害が大きい。
- クライアント案件で早急な対応が求められている。
- 正直なところ、自分で出来るか不安。
まとめ:復旧は冷静に「順番」と「証拠保全」を意識して
- 最初にやるべきは「現状のままのバックアップとログの保全」
- クリーンアップは慎重に、完全な削除→再構築→再検査が基本
- 自信がないときは、無理せず専門家に頼るのが安全
次におすすめの記事
- 👉 [WordPressがハッキングされたときの初動チェックリスト]
- 👉 [ハッキングの原因と再発防止策まとめ]
✉️ にしラボなら…
最短2時間で復旧したこともある、復旧支援サービス行っています。
- ✅ WordPress復旧からWAF・クラウド移行まで対応
- ✅ お詫び文や報告書の「下書き」生成も技術サポート込みで支援
- ✅ 安全な再運用の設計までトータルサポート
