Webサイト改ざんが疑われる時の初動対応｜停止判断・証拠保全・復旧チェックリスト

冒頭要約

Webサイトのロゴや文章が変わった、不審な別サイトへ転送される、作った覚えのないページが検索結果に出る、未知のスクリプトが読み込まれる。このような事象は、単なる表示崩れではなく、Webサイト改ざんの可能性があります。

重要なのは、慌ててトップページを上書きすることではありません。利用者への危険を止めながら、発見時刻、対象URL、表示内容、直近の正規変更、管理者・デプロイ・DNSのログを残し、どこまで影響したかを確認します。

まずは通常の業務端末で不審ページを何度も開かず、サイト責任者、開発・運用担当、情シスまたはCSIRTへ共有してください。フィッシング、マルウェア、不審なダウンロードへ利用者を誘導する疑いがある場合は、原因調査より先に公開停止や安全なメンテナンス表示を判断します。

---

Webサイト改ざんとは：表示変更だけではない

Webサイト改ざんとは、所有者が承認していない内容や動作が、ページ、サーバー、CMS、配信経路などへ加えられた状態です。目立つトップページ変更だけでなく、通常の閲覧では気づきにくいケースもあります。

見え方	例	最初に確認する範囲
表示改ざん	見出し、画像、連絡先、価格、リンクが意図せず変わった	CMS変更履歴、デプロイ履歴、管理者操作、キャッシュ
不審なリダイレクト	特定端末、検索流入、モバイルだけ別サイトへ移動する	CDN、タグ管理、外部スクリプト、リダイレクト設定
未知のページ	作った覚えのない商品、広告、検索スパムのページが出る	CMS投稿者、ルーティング、ファイル、データベース、サイトマップ
不審なコード	未承認のscript、iframe、外部通信、ポップアップがある	テンプレート、タグ管理、依存関係、静的ファイル、CI/CD
管理・配信経路の変更	DNS、CDN、オブジェクトストレージ、デプロイ先が変わった	レジストラ、DNS、CDN、クラウド、CI/CDの監査ログ

表示が変わっていても、予約済みデプロイ、担当者の作業、A/Bテスト、古いCDNキャッシュ、外部サービス障害で説明できる場合があります。逆に、ブラウザ上の表示が正常でも、検索向けの未知ページや一部利用者だけへの転送が残ることがあります。最初から「侵害確定」「誤検知」と断定せず、正規変更の記録と観測事実を照合します。

---

読者別の影響：誰が何を確認するか

読者	主な影響	最初の役割
一般利用者・社内報告者	不審表示、転送、警告画面、ダウンロードを目撃する	時刻、URL、端末、画面を記録し、再アクセスせず報告する
Web担当者・広報	利用者保護、公開停止、告知、ブランド影響を判断する	対象ページ、公開範囲、顧客導線、問い合わせ先を整理する
開発者・DevOps	ソース、ビルド、CI/CD、クラウド、依存関係を確認する	正常なリリース、直近の変更、デプロイ主体、成果物の差分を見る
情シス・SaaS管理者	IdP、CMS、DNS、CDN、ホスティングの管理権限を確認する	管理者、MFA、APIキー、セッション、監査ログを確認する
CSIRT・SOC	影響範囲、封じ込め、証拠保全、報告、復旧を統括する	事実と未確認事項を分け、担当と判断時刻をタイムライン化する

担当者が1人しかいない場合でも、「利用者への危険を止める作業」と「証跡を残して原因を調べる作業」を分けて記録すると、復旧を急いだために調査材料を失う事態を避けやすくなります。

---

まず確認すること：最初の15分チェックリスト

以下は、インシデントチケットへそのまま転記できる最小セットです。画面を直す前に、現時点で見えている事実を残します。

確認項目	記録する内容	判断につながる理由
1. 発見情報	発見者、発見時刻、報告経路、タイムゾーン	いつから影響したかの基点になる
2. 対象URL	URL、ホスト名、ページ種別、PC・モバイルの違い	単一ページかサイト全体かを分ける
3. 観測内容	スクリーンショット、表示文言、転送先、警告、HTTP状態	後で表示が変わっても最初の状態を説明できる
4. 利用者影響	フィッシング、マルウェア、不審ダウンロード、情報入力の可能性	公開停止と告知の優先度を決める
5. 正規変更	直近のリリース、CMS更新、タグ変更、キャンペーン、障害対応	正常な変更と未承認変更を切り分ける
6. 配信経路	DNS、CDN、WAF、ホスティング、オブジェクトストレージ	ソースが正常でも配信先が変わる場合がある
7. 管理権限	CMS、クラウド、Git、CI/CD、DNSの管理者と外部委託先	不明な管理者や権限変更を確認する
8. 通知	Search Console、Safe Browsing、監視、WAF、EDR、ホスティング通知	別の検知元や影響URLを把握する
9. ログ保持	各ログの保存期間、取得権限、上書きまでの時間	失われやすい証跡を優先して確保する
10. 初動責任者	公開停止、証拠保全、顧客連絡、復旧の判断者	複数担当が別々に変更するのを防ぐ

---

公開停止の判断：原因が分かるまで待たない

「すぐ止めるか、表示を維持するか」は、原因の深刻さだけでなく、利用者が今受ける危険と業務影響で判断します。

優先度	状況	推奨する初動
緊急	フィッシング入力、不審ダウンロード、マルウェア、決済改変、外部サイトへの強制転送が疑われる	安全なメンテナンス表示、該当経路の遮断、関係者への即時連絡を優先する
高	不明な管理者、未承認コード、未知ページ、認証情報の露出、広範囲の改ざんがある	変更経路を制限し、証跡確保とアカウント封じ込めを並行する
中	単一ページの未承認変更だが、利用者への直接的な危険は確認されていない	該当ページを限定停止し、変更者・経路・範囲を確認する
低	正規変更やキャッシュで説明でき、承認記録と成果物が一致する	判断根拠を記録し、監視と変更管理の改善へ回す

公開停止そのものが、ログ削除やサーバー初期化を意味するわけではありません。安全なページへの切り替え、問題のある機能だけの停止、管理画面の到達制限など、利用者保護と証拠保全を両立できる方法を、サイト構成と業務継続要件に合わせて選びます。

---

初動対応：やること・やらないこと・記録すること

やること

• インシデントIDを発行し、発見、判断、変更、復旧の時刻と担当者を1つのタイムラインへ集約する。
• 対象URL、スクリーンショット、HTTP応答、Search Console通知、監視アラート、直近の正規リリースを保全する。
• 利用者に危険が及ぶ疑いがあれば、安全なメンテナンス表示や影響機能の停止を判断する。
• CMS、ホスティング、Git、CI/CD、クラウド、DNS・CDN、タグ管理の管理者と最近の変更を確認する。
• 不明な管理者、セッション、APIキー、デプロイキーが見つかった場合は、影響する業務を確認して失効・再発行する。
• Webサーバーだけでなく、認証、管理者操作、設定変更、ファイル変更、デプロイ、WAF、DNS・CDNのログを同じ期間で確認する。
• より詳しい保全にはインシデント時の証拠保全を使い、復旧作業と調査記録を分ける。

やらないこと

• トップページや改ざんファイルだけを上書きし、直ったように見えた時点で完了にしない。
• 調査前にサーバー、CMS、監査ログ、デプロイ履歴、クラウドリソースを初期化・削除しない。
• 不審なコードやファイルを通常の業務端末で実行し、挙動を確認しない。
• 出所が確認できないバックアップや、侵害後に作られた可能性がある成果物を正常版として使わない。
• WAFで表示が止まったことを、侵入経路の解消やバックドアの除去と同一視しない。
• 公開情報とログで確認できない攻撃者名、侵入経路、漏えい範囲を断定しない。

記録テンプレート

項目	記録内容
基本情報	インシデントID、発見者、発見時刻、一次担当、判断者
観測事実	URL、端末、画面、転送先、警告、HTTP状態、再現条件
利用者影響	入力、ダウンロード、決済、問い合わせ、対象期間、対象人数
正規変更	リリースID、承認者、CMS更新、タグ変更、障害対応
管理経路	CMS、Git、CI/CD、クラウド、ホスティング、DNS、CDN、委託先
証跡	取得ログ、対象期間、タイムゾーン、取得者、保存先、保持期限
封じ込め	公開停止、権限制限、セッション失効、認証情報更新、実施時刻
復旧	正常版の根拠、復旧元、レビュー、検証結果、再公開時刻
検索対応	Search Consoleの問題種別、例示URL、修正範囲、再審査申請
未確認事項	影響期間、侵入経路、データ影響、残る管理者、確認期限

---

層別の確認方法：CMSだけに限定しない

1. 公開ページ・検索結果

• トップページだけでなく、商品、記事、問い合わせ、ログイン、エラーページを確認する。
• Search Consoleのセキュリティの問題、URL検査、通知メールを確認する。
• 身に覚えのないページ、タイトル、説明、構造化データ、サイトマップの変化を確認する。
• PCとモバイル、直接アクセスと検索流入で挙動が違うという報告があれば、条件を記録する。

Googleの公式ヘルプでは、Security Issuesレポートに示されるURLは影響ページの一例であり、完全な一覧とは限らないと説明されています。例示URLだけ直して完了にせず、共通テンプレート、CMS、配信経路を含むサイト全体を確認します。

2. CMS・管理者・外部連携

• 新規・休眠・共有の管理者、権限変更、MFA変更、パスワードリセットを確認する。
• プラグイン、テーマ、拡張機能、タグ管理、フォーム、広告・分析タグの変更を確認する。
• 外部委託先、保守会社、制作会社のアカウントと作業記録を照合する。
• 認証情報を更新するときは、個人用、サービス用、CI/CD用を区別し、依存先を記録する。

3. ソース・ビルド・CI/CD

• 正常と確認できるリリース、Git履歴、レビュー、ビルド成果物を基準に差分を見る。
• 未承認のコミット、ワークフロー変更、デプロイ先変更、シークレット更新を確認する。
• 本番サーバー上のファイルだけでなく、生成元、ビルド、アーティファクト、配布先が一致するか確認する。
• 復旧後も同じパイプラインで再改ざんされないよう、デプロイ権限と保護ルールを見直す。

4. DNS・CDN・WAF・ホスティング

• DNSレコードが勝手に変わった時の初動対応を使い、名前解決と管理者変更を確認する。
• CDNのオリジン、リダイレクト、キャッシュ、エッジスクリプト、WAFルールの変更を確認する。
• ホスティング管理者、ファイル操作、バックアップ、スナップショット、サポート操作の履歴を確認する。
• WAFとファイアウォールの違いを踏まえ、WAFだけで管理者侵害やCI/CD改ざんまで解決したと判断しない。

5. ログ・認証・データ

OWASPは、Webサーバーログだけではアプリケーション固有の状況が不足し得るため、認証成功・失敗、認可失敗、管理操作、権限変更、設定変更、データ変更などのアプリケーションログも重要だとしています。

• Web、WAF、CDN、ロードバランサー、アプリ、CMS、DB、IdP、クラウド監査ログを同じタイムゾーンで並べる。
• 管理者ログイン、権限変更、ユーザー作成、トークン発行、設定変更、ファイル更新を確認する。
• ログにアクセストークン、パスワード、秘密鍵などが残っていないかにも注意し、必要以上に複製しない。
• データ閲覧・出力・変更が疑われる場合は、Web改ざんだけでなく漏えい疑いとしてエスカレーションする。

---

復旧手順：見た目ではなく信頼できる状態へ戻す

1. 復旧基準を決める：侵害前と確認できるリリース、バックアップ、構成、管理者台帳を選ぶ。
2. 侵入経路と残存権限を扱う：脆弱性、未承認管理者、盗まれた認証情報、CI/CD、DNS・CDN設定を確認する。
3. クリーンな環境から再構築する：侵害中の本番ファイルを部分的にコピーせず、レビュー済みの成果物から復旧する。
4. 認証情報をローテーションする：CMS、ホスティング、クラウド、Git、CI/CD、DNS、DB、外部APIを依存関係順に更新する。
5. 再公開前に検証する：不審な転送、未知ページ、外部通信、管理者、検索向け表示、主要業務フローを確認する。
6. 監視を強化する：復旧直後のログ、ファイル変更、管理者操作、WAF、Search Console通知を重点監視する。
7. 事後対応を残す：原因、影響、対応時刻、改善項目、担当、期限をまとめる。

現場で使う報告・封じ込め・調査・復旧のひな型は、Web改ざん初動テンプレートにまとめています。CMSや公開Webアプリの脆弱性情報を起点に確認する場合は、Web CMS KEV初動確認チェックリストも使えます。

---

Search Consoleと検索結果の復旧

改ざんによって、検索結果やブラウザに警告が出る、未知のページがインデックスされる、検索流入が減る場合があります。検索上の見え方だけを先に整えるのではなく、サイトの安全な復旧を優先します。

1. Search Consoleの「セキュリティの問題」で、問題種別、検出日、例示URLを確認する。
2. 例示URLだけでなく、同じ仕組みから生成・配信されるページをサイト全体で修正する。
3. 不審なページ、コード、管理者、認証情報、原因となった脆弱性や設定を処理する。
4. 修正後に主要ページ、モバイル表示、外部リソース、リダイレクトを再確認する。
5. すべての問題を修正した後、原因、実施した修正、確認結果を記載して再審査を申請する。

Googleは、再審査には時間がかかる場合があると案内しています。申請した直後に警告や検索結果が変わらなくても、同じ申請を繰り返さず、審査状況と再発兆候を監視します。検索結果から一時的にURLを隠す操作は、侵入経路の修正やサイト全体の清掃の代わりにはなりません。

---

よくある誤解

トップページを戻せば復旧できる

改ざんの入口がCMS管理者、プラグイン、CI/CD、ホスティング、DNSに残っていれば再発します。未知ページや外部スクリプトも含め、生成元と配信経路を確認します。

WAFがブロックしたのでサーバーは安全

WAFはHTTP/HTTPSの攻撃を検知・遮断する防御層ですが、盗まれた正規アカウント、CI/CD権限、ホスティング管理者、DNS変更まで自動的に解決するものではありません。

バックアップから戻せば原因も消える

バックアップに不審なコードが含まれる、復旧後も同じ認証情報や脆弱性が残る、配信経路が改ざんされたままという場合があります。復旧元の時刻と信頼性、侵入経路、管理権限を別々に確認します。

Search Consoleに1件しか出ていないので影響も1ページだけ

公式ヘルプが示す影響URLはサンプルであり、完全な一覧ではありません。共通テンプレート、CMS、データベース、サイトマップ、配信設定を横断して確認します。

改ざんはWeb担当だけで処理できる

管理者、認証情報、顧客データ、DNS、クラウド、検索警告が関係すると、情シス、CSIRT、法務、広報、委託先の判断が必要になります。単独で「漏えいなし」「報告不要」と決めません。

---

関連用語・関連ページ

次の目的	内部リンク
すぐに対応を始める	Web改ざん初動テンプレート、インシデント対応トピックハブ
証拠を失わない	インシデント時の証拠保全、Forensics、Chain of Custody
公開経路を点検する	公開管理画面の緊急点検、DNSレコード変更の初動対応
CMS脆弱性を確認する	Web CMS KEV初動確認チェックリスト、CVEトラッカー
防御層を理解する	WAFとは、WAFとファイアウォールの違い、インシデントレスポンスとは
基礎から学ぶ	インシデント対応の基本、セキュリティログの読み方、用語クイズ

---

公式情報・参考情報

• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management - インシデント対応を組織のリスク管理、検知、対応、復旧へ組み込むための現行指針。
• NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response - ファイル、OS、ネットワーク、アプリケーションの証跡を扱う際の基本的な考え方。
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks - 検知・分析、封じ込め、根絶、復旧、事後対応を分けて進める実務プレイブック。
• OWASP Cheat Sheet Series: Logging - Webアプリで確認すべき認証、認可、管理操作、設定変更などのログ設計。
• Google Search Console ヘルプ：セキュリティの問題レポート - 影響URLの確認、サイト全体の修正、セキュリティ再審査の流れ。

---

まとめ

Webサイト改ざんが疑われるときは、表示を戻すことと、安全な状態へ復旧することを分けます。最初の15分で、発見情報、対象URL、利用者影響、正規変更、配信経路、管理権限、通知、ログ保持を記録し、利用者への危険がある場合は公開停止や安全なメンテナンス表示を優先してください。

その後、CMSだけでなく、Git・CI/CD、クラウド、ホスティング、DNS・CDN、管理者、認証情報、各種ログを横断して確認します。既知の正常な成果物から復旧し、残存権限と侵入経路を処理し、サイト全体の安全を確認してからSearch Consoleの再審査へ進むことが、再改ざんと利用者被害を防ぐ基本です。