初動対応で失敗しやすいデータ復旧の誤った手順

感染が疑われる環境への直接上書き

• 原因：不具合を上書きして消そうと考え、汚染されたサーバー上に直接バックアップデータを流し込む
• リスク：不正なスクリプトやバックドアが残ったままになり、復旧した瞬間に再度データが改ざんされる
• 正しい対応：既存のデータを一旦すべて削除し、ディレクトリを完全にクリーンにしてから復旧を行う

感染時期の特定を誤ったままのリストア

• 原因：最新のバックアップであれば安全だと思い込み、調査せずに直近のデータを復元する
• リスク：実は数日前から潜伏していたウイルスまで一緒に復元してしまい、被害がループする
• 正しい対応：ログを遡り、確実に安全だと言い切れる「感染前」の世代まで遡ってデータを選ぶ

バックアップの検証をせずに現行データを削除

• 原因：すぐに復旧させようと焦り、手元のバックアップファイルが正常に開けるか確認せずにサーバーを初期化する
• リスク：バックアップが破損していた場合、唯一残っていた「壊れてはいるが救出の余地があったデータ」まで完全に失う
• 正しい対応：まず手元のバックアップが正常であることを確認し、現行データも念のため別所に退避させてから作業する

脆弱性を放置したままのシステム公開

• 原因：サイトが表示されるようになったことに安心し、侵入経路となった古いプラグインなどをそのまま放置する
• リスク：攻撃者は侵入ルートを知っているため、公開から数分以内に再び同じ手法で攻撃を受ける
• 正しい対応：復旧後、一般公開する前に脆弱性を修正し、管理用パスワードをすべて変更する

二次被害を招く「とりあえず再起動」

• 原因：PCやサーバーの挙動がおかしいため、原因を調べず安易に再起動を繰り返す
• リスク：メモリ上に残っていた攻撃の痕跡（証拠）が消滅するほか、ランサムウェア等の場合は再起動をトリガーに暗号化が加速することもある
• 正しい対応：異常を感じたらネットワークを遮断して現状を維持し、専門知識を持つ者に状況を共有する

セキュリティソフトによる強制駆除のみに頼る

• 原因：ソフトが「駆除完了」と表示したので、それで安全になったと判断して運用を続ける
• リスク：ウイルスによって書き換えられた設定ファイルや、作成された不正な管理者アカウントまではソフトで消しきれないことが多い
• 正しい対応：ソフトでの駆除はあくまで一時しのぎと考え、システムの再構築（クリーンインストール）を基本とする