WordPressサイトがハッキングされた時の初動対応チェックリスト(7ステップ)

この記事の対象読者

  • すでに「改ざん・リダイレクト・スパムメール送信・管理画面侵入」などの被害が発覚したサイト運営者
  • 自力での一次対応を最短ルートで把握したい担当者
  • 復旧を外部に依頼するかどうかの判断材料を集めたい方

この記事でわかること

  • 被害拡大を防ぐために“最初の数時間でやるべきこと”
  • やってはいけないNG対応

重要:証拠保全前にファイルを消したり、安易にバックアップで上書き復元したりしないでください。原因究明も再発防止もできなくなります。

※レンタル共有サーバーの場合、標準提供される「アクセスログ/エラーログ/historyコマンド」あたりだけで調査となる事が多いため、兆候のあぶり出しや攻撃(日時)の大まかな推測までが限界となることがあります。安価なレンタル共有サーバーで取得できる保管期間や種別が少ないログだけで原因究明できると断言する業者にはご注意ください。


0. 全体像(7つの初動対応まとめ)

  1. サイトを一時的に閉じる / 閲覧制限をかける(被害拡大・拡散の防止)
  2. “現状のまま”フルバックアップ & ログを保全(証拠確保)
  3. すべての重要パスワードを直ちに変更し、2要素認証を有効化
  4. 管理者ユーザー・不審アカウントの棚卸し & セッション失効
  5. 被害範囲の把握(改ざん箇所、検索結果警告、ブラックリスト登録 等)
  6. 社内/関係各所への連絡と、顧客影響がある場合の告知準備
  7. 復旧計画の決定(自力で進める or 専門業者へ即依頼)

次のステップに進む:

  • 復旧の具体手順は → [自力クリーンアップ完全解説] へ内部リンク
  • 原因と再発防止は → [原因トップ5と再発防止チェックリスト] へ内部リンク
  • すぐに業者比較したい → [復旧サービス7社比較] へ内部リンク

1. サイトを一時的に閉じる / 閲覧制限をかける

目的:被害拡大(マルウェア配布・SEOスパム拡散・個人情報流出の継続)を防ぐ。

方法例

  • ひとまずメンテナンスモード(IP制限)をかける
    • Basic認証はキャッシュとの相性が良くないため非推奨
    • 2次被害の拡大防止のため、全トラフィック緊急遮断や海外IPや特定User-AgentなどをWAFルールで一時的にブロック
    • メンテナンス画面などの各種必須機能、復旧後の継続利用、コスパまで加味するとCloudflareが圧倒的にお勧めです。
  • 管理画面(/wp-admin/)へのアクセス制限
  • ECサイトや会員サイトの場合、決済関連の停止を含む業務判断をします
    • 訪問者(顧客)に対して混乱を招くため、SNSや顧客メーリングリストで緊急メンテナンス告知を推奨します。

本番環境だけの1環境で運営していて、本番環境で復旧や復旧に向けた検証を行う必要が有る場合、訪問者の方に被害がなければこの工程は対応しないケースも有ります。既にコンバージョンが限りなくゼロになっているので、本番環境の1環境だけで運営している場合、まずは復旧に全力を注ぐというケースは多いです。

遮断の方法例

  • パーミッション000で現物の凍結閉鎖
    • 同環境の調査継続と被害拡大を最小化するにはベストです。
    • ただし、復旧までの手順作成を検証環境構築して行う必要があります。
  • index.htmlでメンテナンス中を表示(.htaccessで明示的に設定)
    • AWS EC2のALBなどは便利ですが、AWSのEC2系サービスの毎月のコストを受け入れられるか?が鍵になります
  • Basic認証
    • 予期せぬ認証要求が訪問者(顧客)を不安にさせやすく、キャッシュとBasic認証は相性が良くないため、非推奨。
  • IP制限
    • .htaccessでホワイトリスト方式のIP制限を行う
    • 予期せぬ閲覧制限で訪問者(顧客)を不安にさせやすいため、管理画面(/wp-admin/)だけアクセス制限など
    • マイIPで1人につき1,100円/月~ できるため、お勧め。
  • Cloudflare「Workers+カスタムルール」でメンテナンス中を表示する

2. “現状のまま”フルバックアップ & ログ保全(証拠確保)

やる理由

  • 侵入経路や改ざん箇所の特定、法的/社内的な調査のため
  • 復旧ミスに備えて「いまの状態」をいつでも再確認できるようにするため

やること

  • ファイル全体wp-content含む)、DBダンプの取得
  • アクセスログ/エラーログ、WAFログ、メールログなどの保存
  • バックアップファイルは安全な外部ストレージ(暗号化)に保管

NG:ここで「正常なバックアップ」に戻してしまうと、何が起きたか追えなくなります


3. すべての重要パスワードを変更し、MFAを有効化

パスワード変更対象:

  • WordPress管理者(全員)
  • サーバーコントロールパネル、FTP/SFTP、SSH、DB(phpMyAdmin)
  • お名前ドットコム等のDNS/セキュリティサービス
  • 外部連携APIキー(アプリケーションパスワード含む)

ポイント

  • すべて別の強固なパスワード(パスワードマネージャを活用)
  • WordPressの認証用ユニークキー・ソルト(wp-config.php)を再生成
  • **多要素認証(MFA)**をWordPressユーザー全員に必須化

4. 管理者ユーザーの棚おろし & セッション失効

チェックポイント

  • 管理者/編集者など特に権限の高いユーザー一覧を確認
  • 見覚えのないユーザーアカウントを即刻削除 / 権限剥奪
  • 既存ユーザーも念のためパスワード再発行
  • ログインセッションを破棄、短くする

5. 被害範囲の把握

確認すべき項目

  • 被害を受けたことは、いつ気づいたか?バックアップ保持期間を過ぎていないか?
  • トラブル発生時向けに設計した各種のログは見られるか?
  • トップページやWordPressではない主要LPが改ざんされていないか?同じサーバ内の他のWPは被害を受けていないか?
  • 不審なファイル(wp-content/uploads/ 配下など)や、不審な cron / .htaccess 書き換えは無いか?
  • WordPressコアの中も含めて不自然なファイルがないか?1つだけファイル更新年月日がセキュリティ侵害の時期の周辺であるファイルなどはわかりやすい。
  • Google 検索結果で「このサイトは危険」表示Search Consoleのセキュリティ問題警告の有無
  • ブラックリスト登録(セキュリティベンダー / メール送信ドメインの(Real-time Blackhole List)など)の確認
  • スパムメール送信の痕跡(キュー / メールログ)
  • ブラウザの開発者ツールのConsoleでエラーや謎のhttp(s)リクエスト/レスポンスは発生していないか??確認

6. 社内/関係各所への連絡・告知準備

社内向け

  • 経営層・広報・CS・法務・情シスへの即時共有
  • 業務影響の見積り(サイト停止時間、顧客影響等)と復旧計画の共有

社外向け(必要な場合)

  • 顧客・ユーザーへの影響がある場合、告知文テンプレートを準備
  • Search Consoleでの再審査依頼や、ブラックリスト解除申請の準備

7. 復旧方針の決定(自力 or 専門業者)

自力で進める場合

  • WordPress改ざん・マルウェア復旧 自力クリーンアップ完全解説
    • コア、テーマ、プラグインのファイルとデータベースの改ざん箇所やマルウェア洗い出し、駆除、修正
    • (健全なバックアップファイルが有るならば)バックアップからの安全復元
    • wp-config.phpのパラメータ追記などの改ざん確認
    • プラグイン/テーマ/WordPress本体のクリーンインストール(※証拠保全後)
    • パーミッション見直し
    • 堅牢化(セキュリティ強化)←再発防止として最重要。

業者へ依頼する場合

  • 判断基準:対応スピード / 実績 / 再発防止までやるか / クラウド移行対応可否 / 24h対応など
  • にしラボの強み:スピード復旧 / マルウェア除去だけでなく再発防止のセキュリティ強化 / クラウド移行までフルサポート

やってはいけないNG行為 TOP5

  1. 証拠保全前に、適当にファイル削除・アップデートを行う
  2. 安易にバックアップで上書きして終了(原因不明・再発リスク大)
  3. パスワード変更やMFA対応を後回しにする
  4. 不審ユーザーやAPIキーを放置
  5. 「とりあえず大丈夫そう」となんとなく見えるから再発防止策を打たない


まとめ

  • 被害拡大の遮断 → 証拠保全バックアップ → 権限/パスワードの防御強化 → 影響範囲の把握 → 復旧方針決定の順で、落ち着いて進めましょう。
  • 自力対応に不安がある場合は、スピード対応・セキュリティ強化まで一気通貫で支援できる当社にご相談ください。バックアップデータの保持日数を考えると、一刻も速く技術的に理解のある業者へ依頼することをおすすめします。

最短2時間で初動対応。無料相談はこちら