サイトがハッキングされた時に取るべき5つの最優先緊急復旧ステップ

サイトがハッキングされた際、最初に行うべきことは冷静さを保ち、被害を拡大させないよう対策することです。サイトの隔離、全てのアクセス権のリセット、クリーンなバックアップからの復元、悪意あるコードの除去、永続的なセキュリティ強化が必要です。特に最初の24時間で重要なのは、攻撃者のアクセス遮断、訪問者やデータへの被害拡大防止、検索エンジンへの誤ったシグナル送信回避、そして正しく検証された状態で再公開することです。

Webサイトのハッキングは、単にトップページが書き換えられるだけではありません。攻撃者は気付かれないようにスパムページを生成したり、決済フォームを改ざんしたり、管理者アカウントを追加したり、データベースに隠しリダイレクトコードを仕込んだり、サーバーをメール送信に利用することもあります。そのため復旧は「ファイル削除」だけではなく、証拠保全・クリーニングの検証・再発防止を含む体系的な対応が必要です。

本ガイドでは、サイトがハッキングされた際に実施すべき「5つの緊急復旧ステップ」を、技術的な詳細は簡潔に、実際に使えるレベルで解説します。WordPress、カスタムシステム、ECサイト、企業サイトなど種類を問わず原則は共通です：隔離、アクセス遮断、クリーンなソースへの復元、検証、強化。

サイトがハッキングされた兆候とは

ハッキングは必ずしも目に見える崩壊から始まりません。中には数週間気付かれず進行する場合もあります。以下の兆候が一つでもあれば、通常のエラーではなく「セキュリティ事件」として対応する必要があります。

• Google検索結果にギャンブル・薬・暗号通貨・アダルト関連のタイトルが表示される。
• ブラウザで「フィッシング」や「危険なサイト」警告が出る。
• 管理画面にログインできない、見覚えのない管理者ユーザーがいる。
• サーバーのCPU/RAM/ディスクやメール送信トラフィックが急増。
• .htaccess、index.php、wp-config.php、テーマファイルに不審な変更。
• 訪問者が他のドメインへリダイレクトされる。
• ホスティングアカウントから大量メールが勝手に送信される。
• セキュリティプラグインが無効化される、ログが消される。

例えば普段2,000アクセスのブログが突然30,000リクエストを受ける場合、多くは本当のユーザー増加ではなく、ボット活動やブルートフォース攻撃、悪意あるスクリプトの動作です。10MBだったテーマが数日で80MBに膨らんでいるなら、バックドアファイルの追加を疑いましょう。

ハッキング直後30分：パニックより証拠保全と制御

最初の反応で何でも削除するのはNGです。無計画なファイル削除は攻撃の痕跡を消し、復旧を困難にし、誤ったバックアップ復元につながります。まず現状の記録を残しましょう：日時・警告内容・影響URL・怪しいユーザー・直近の更新履歴・ホスティングログなど。これらは技術サポートやセキュリティ専門家による迅速な診断の助けになります。

特にECサイトや会員制サイトなど個人情報を扱う場合、影響範囲・攻撃開始日時・アクセス元IPを記録することが重要です。Hostragonsでサイトを運用している場合、サポートへ問い合わせる際はドメイン・影響フォルダ・時間帯・受け取ったエラーメッセージを共有すると対応が早まります。ホスティング選びについては 安全なウェブホスティングパッケージ をご参照ください。

1.ステップ：サイトを隔離し被害拡大を防ぐ

最初の緊急対応は、攻撃者や悪意あるコードによる更なる被害を防ぐことです。火災の消火前にガスバルブを締めるイメージです。サイト全体を停止する必要はありませんが、訪問者が危険なリダイレクトや偽決済フォーム、ウイルスファイルに触れないようにします。

メンテナンスモードや一時的アクセス制限を導入

WordPressの場合はメンテナンスページを表示、カスタムシステムでは503レスポンス、特定IPのみアクセス許可などが有効です。503コードは検索エンジンに「一時的に利用不可」と伝えます。404や空白ページより適切なシグナルです。フィッシングやマルウェア拡散の場合、完全なアクセス遮断が安全です。

• 管理画面を公開状態にせずIP制限を設ける。
• ファイルアップロードフォルダでPHP実行を一時停止。
• メール送信が悪用されている場合、SMTPアクセスを停止。
• 決済ページが影響を受けた場合、オンライン決済や連携を一時停止。

ログと現状ファイルを保全

隔離時はアクセスログ・エラーログ・FTP履歴・コントロールパネルの操作履歴を必ず保存します。多くの攻撃の入口は古いプラグイン、弱いFTPパスワード、漏洩した管理者アカウント、書き込み権限ミスです。ログがないと原因究明が難しく、復旧後数日で再ハックのリスクがあります。

サーバーのファイルをローカルにダウンロードし、安全な環境で調査するのも有効ですが、ダウンロードしたファイル自体がマルウェアを含む場合もあるため、ウイルス対策済み端末で作業しましょう。コントロールパネルにバックアップ機能がある場合、ハック直後のバックアップは分析目的で保存し、クリーンな復元には使わないでください。定期バックアップ戦略については 自動バックアップ付きホスティングソリューション をご参照ください。

2.ステップ：全てのアクセス情報・パスワード・キーをリセット

多くのサイト管理者はハック後、管理画面のパスワードだけ変更しますが、攻撃者の侵入口はFTP・DBユーザー・ホスティングパネル・SSHキー・メールアカウント・APIトークン・外部連携など多岐に渡ります。従って全ての認証情報を包括的にリセットすることが重要です。

変更すべきパスワード一覧

• ホスティングコントロールパネルのパスワード
• FTP/SFTP/SSHユーザーのパスワード
• データベースユーザーと接続設定のパスワード
• CMS管理者アカウント全てと編集者アカウント
• メールアカウント（ドメイン経由送信のもの特に）
• APIキー・決済システムトークン・CDN・DNSパネルのアクセス情報
• Git・デプロイ・自動化・バックアップサービスのキー

強力なパスワードは16文字以上、ユニークで推測困難なものを。別のサービスと同じパスワードを使うと漏洩時に直接サイトが危険にさらされます。可能な限り二段階認証（2FA）を導入しましょう。特に管理者アカウントの2FAはブルートフォース攻撃対策に非常に効果的です。

怪しいユーザーとアクティブセッションの終了

CMS内に見覚えのないユーザーがいたら、無効化だけでなく役割・作成日時・操作履歴を確認し削除します。WordPressならセキュリティキー再生成で全ユーザーセッション終了が可能です。カスタムシステムではセッショントラブルのクリアなどを。ECサイトでは顧客アカウントより管理権限を持つスタッフアカウントの確認が優先です。

例：攻撃者が古い編集者アカウントを使い、ファイルアップロード権限のあるプラグイン経由でWebシェルを設置した場合、管理者パスワードだけ変えても編集者アカウントが残れば再侵入されます。権限マトリックスを見直し、不要な管理者や編集者は削減しましょう。ドメイン・DNS・SSL管理も安全に行う必要があります。ドメイン名管理とDNSセキュリティ と SSL証明書ソリューション もご参照ください。

3.ステップ：クリーンなバックアップ復元または感染領域の隔離

最速かつ最も安全な復旧方法は、攻撃前に取得した検証済みクリーンバックアップからの復元です。ただし「クリーン」の定義が重要です。昨日のバックアップでも攻撃が1週間前からなら感染済みの可能性があります。バックアップ取得日・ログ記録・ファイル変更日を総合的に判断しましょう。

クリーンバックアップの選定方法

まずハックの兆候が初めて確認された日時を特定します。例：Google Search Consoleで3月12日に警告が出ても、サーバーログに3月5日に怪しいPOSTリクエストがあれば、3月12日のバックアップは信頼できません。3月4日以前のバックアップを分析し、復元前にセキュリティスキャンを実施します。

• バックアップ日は攻撃開始見込みより前であること。
• バックアップ内に見覚えのない管理者ユーザーが含まれていないこと。
• ファイル整合性チェックをし、CMSコアファイルは公式パッケージと比較。
• データベース内で隠しiframe、base64コード、怪しいスクリプトやスパムを検索。
• 復元後、全ソフトウェアのアップデート実施。

バックアップ無しの場合の対処

クリーンなバックアップが無い場合は慎重な復旧が必要です。まずサイトのコピーをステージングや仮領域に移し、怪しいファイルを隔離、CMSコアは公式ソースから再インストール、テーマやプラグインもクリーンパッケージで再構築します。アップロードフォルダは攻撃者がよく隠しファイルを置く場所なので、.php、.phtml、.pharなど実行ファイルに特に注意。

データベースのクリーニングもファイル同様に重要です。悪意あるリダイレクトはファイルではなくサイト設定やウィジェット、テーマオプション、記事本文に潜むことがあります。大規模DBの場合はscript、iframe、eval、atob、base64_decode、gzinflate、shell_exec、document.locationなどを検索。ただし全てのbase64が悪意あるとは限らないので、誤った削除はシステム障害につながります。必ず事前にDBコピーを取ってから作業を。

4.ステップ：悪意あるコードの除去・アップデート・脆弱性修正

単にバックアップ復元だけでは十分ではありません。攻撃者の侵入経路を特定しなければ、同じ脆弱性から再侵入される恐れがあります。第4ステップは、ファイル・DBのクリーニング完了、ソフトウェア脆弱性の修正、設定ミスの訂正が目的です。

ファイルシステムチェックリスト

• 直近変更されたファイルを日時でリストアップし、不審な変更を調査。
• CMSコアファイルを公式版と比較。
• アップロードフォルダに実行ファイルが無いか確認。
• 隠しファイル（.user.ini、.htaccessなど）を調査。リダイレクト用に使われることも。
• ファイル権限を厳格化。一般的にファイルは644、フォルダは755が推奨。
• 不要なテーマ、プラグイン、古いバックアップzip、テストフォルダを削除。

WordPressでは未使用プラグインは削除必須です。無効化だけではサーバーに残りリスクになります。古いスライダー・フォーム・ファイル管理系プラグインも不要なら削除。nulledテーマやライセンス無しプラグインは多くの場合バックドアが仕込まれています。短期的なコスト削減が、ブランド信用や顧客データ損失のリスクに繋がります。

アップデートの順序

クリーニング時はまずコアシステム、次にテーマ、最後にプラグインをアップデート。PHPバージョンが古い場合は互換性確認の上、最新・サポート対象に移行を。2026年時点で旧PHP利用サイトは重大リスクです—セキュリティパッチが提供されません。ホスティングでは最新PHP、アカウント隔離、定期バックアップ、WAFが重要。Hostragons ウェブホスティング も是非ご参照ください。

SSL証明書も有効か確認を。SSL自体はハッキング防止にはなりませんが、ユーザーとサーバー間の通信暗号化、偽フォームの影響軽減に役立ちます。特にログイン・決済・会員ページでは必須。証明書選びは SSL証明書購入 をご覧ください。

5.ステップ：再公開前の検証・監視・恒久的防御の構築

第5ステップは、サイトが本当にクリーンか確認し、再発防止策を組み込むことです。これを怠ると、公開後数日で同じ警告が再発することも。検証は技術的スキャンだけでなく運用フローも含めて行います。

再公開前チェックリスト

• トップページ・ログイン・決済・主要URLを複数端末でテスト。
• Google Search Consoleのセキュリティ問題・手動対策レポートを確認。
• サイトマップ・robots.txtのチェック。
• サーバーログで繰り返し発生する404、500、POST、ログイン試行を解析。
• メール送信レピュテーションを確認。ブラックリスト入りの場合は解除申請を。
• 決済フォーム、問い合わせフォーム、ファイルアップロード機能をテスト。

Googleやブラウザがサイトを「危険」とマークした場合、クリーニング後に再審査申請が必要です。申請時は何を除去したか、どの脆弱性を修正したか、どんな対策を講じたか具体的に説明を。曖昧な説明より「古いファイル管理プラグイン削除、全管理者パスワード変更、アップロードフォルダでPHP実行停止」など具体例を挙げましょう。

恒久的防御のための実践策

セキュリティは一度きりではなく継続的な取り組みです。小規模な企業サイトでも月次メンテナンス計画を立てるだけでハックリスクが大幅に下がります。最低でも週次アップデート確認、日次バックアップ、強力なパスワードポリシー、ログ監視を。アクセス数が多いサイトではWAF・CDN・高度なボット対策・外部セキュリティスキャンもおすすめです。

企業サイトでは責任分担も明文化が重要です。誰がアップデート担当、誰がバックアップ管理、セキュリティ警告時の対応担当、どんな場合にメンテナンスモードへ切り替えるか？これらは事件発生時ではなく事前に決めておきましょう。ハック時も慌てず計画通りに動けます。

SEO・ブランド信頼・ユーザー保護のための追加復旧ステップ

技術的にクリーンになっても、SEO面での追加チェックが必要です。攻撃者は大量のスパムURLを生成することが多く、検索エンジンにインデックスされてしまった場合は、復旧後404/410や適切なリダイレクト戦略が必要です。全てのスパムURLをトップページにリダイレクトするのは逆効果で、Googleの品質評価に悪影響を与えます。

Search Consoleでインデックスページ・セキュリティ問題・手動対策・サイトマップを確認し、悪意あるコンテンツ除去後にサイトマップ再提出を。ただし、スパムページが本当に削除されたか確認してから行いましょう。ブランド検索で悪意あるタイトルが表示される場合、クリーンなページの再クロール申請も効果的です。

ユーザー信頼回復のため、透明性あるが過度な不安を煽らないコミュニケーションが大切です。もしユーザーデータ・決済情報・会員情報が影響を受けた可能性がある場合は、法的義務やデータ保護プロセスも考慮する必要があります。単なる宣伝サイトなら影響は小さいですが、ECや会員制では専門的な対応が求められます。

避けるべきよくあるミス

復旧作業中のミスは、攻撃そのものより深刻な損害につながることも。最も多いのは「サイト公開＝復旧完了」と思い込むこと。バックドアファイルが残れば攻撃者は後日再侵入できます。二つ目はバックアップ検証なしで復元すること。感染済みバックアップは悪意あるコードを再公開します。

• クリーニング前にバックアップを取らない。
• 見える悪意ファイルだけ削除し、根本原因調査を怠る。
• 古いプラグインやテーマを継続利用。
• 全管理者に不要なフル権限を付与。
• ログを削除・未確認で上書き。
• SSLだから安全と過信。
• 信頼できないソースからテーマやプラグインをダウンロード。

特にファイル権限設定で過度な許可（777など）は攻撃者の侵入を容易にします。緊急時でも本番環境では最小限の権限設定を徹底し、書き込み権限は本当に必要なフォルダのみ許可しましょう。

緊急対応のまとめ

サイトがハッキングされた時は順序を守ることが成功の鍵です：まず隔離、次に全アクセス情報のリセット、クリーン復元またはコントロールされたクリーニング、脆弱性修正、公開前の検証。この流れで技術リスクだけでなくSEOやブランド損失も最小化できます。

Hostragonsならセキュアなホスティング、SSL証明書、ドメイン管理、バックアップソリューションでサイト耐性を高められます。現状のサイト運用環境を見直したい場合は Hostragons ホスティングパッケージ や ドメイン検索とドメイン管理 をご参照ください。購入前に「速度・セキュリティ・バックアップ・サポート」のバランスが最重要であることを忘れずに。

よくある質問

ハッキングされたらすぐ公開停止すべき？

サイトがマルウェア配布・リダイレクト・決済フォーム改ざんなど重大影響の場合は即時アクセス制限が必須です。軽度なら503メンテナンスやIP制限でも対応可能。目的は訪問者保護と検索エンジンに「一時的な対応」と伝えることです。

クリーンバックアップ復元だけで十分？

いいえ。クリーンバックアップは迅速な復旧に役立ちますが、侵入経路を特定しないと再ハックのリスクがあります。復元後にパスワード変更・アップデート・権限設定見直し・脆弱性プラグインやテーマの除去を必ず実施してください。

ハックされたサイトはSEO順位を失う？

短期間で適切対応すれば恒久的なSEO損失は避けられますが、スパムページがインデックスされたり、Google警告が出たり、長期公開停止の場合は順位低下の可能性。復旧後はSearch Consoleの確認・再審査申請・スパムURL除去が必要です。

WordPressサイトが繰り返しハックされる理由は？

繰り返しハックの主因は残留バックドアファイル、未更新プラグイン、弱いパスワード、不要な管理者アカウント、過度なファイル権限、感染済みバックアップです。見える悪意コード削除だけでなく、根本原因分析と全アクセス情報のリセットを。

ホスティング選びはサイトセキュリティに影響する？

はい。アカウント隔離設計、最新PHP、定期バックアップ、WAF、マルウェアスキャン、迅速なサポート、SSL対応はセキュリティに直結します。セキュアなホスティングが全てのリスクを防ぐわけではありませんが、攻撃面の縮小と復旧の迅速化に大きく寄与します。