ランサムウェア対応プレイブック|発見から復旧まで72時間の完全マニュアル

ランサムウェア被害が発生したとき、最初の72時間の対応が被害の拡大を防ぎ、復旧の成否を左右します。本記事では、感染発覚から復旧完了までの時系列に沿った対応手順を、具体的なチェックリストとともに解説します。初動の隔離判断、被害範囲の特定、復旧オプションの比較、身代金支払いの是非、ステークホルダー対応まで、実際のインシデント対応で使えるプレイブックとしてまとめています。いざという時に慌てないための事前準備についても触れています。


ランサムウェア被害が発生したとき、最初の72時間の対応が被害の拡大を防ぎ、復旧の成否を左右します。本記事では、感染発覚から復旧完了までの時系列に沿った対応手順を、具体的なチェックリストとともに解説します。初動の隔離判断、被害範囲の特定、復旧オプションの比較、身代金支払いの是非、ステークホルダー対応まで、実際のマルウェア感染インシデント対応で使えるプレイブックとしてまとめています。


ランサムウェア被害発生 - 最初の1時間

ランサムウェア感染の発覚は、多くの場合、「ファイルが開けない」「見慣れない画面が表示された」という従業員からの報告で始まります。この最初の1時間の対応が、その後の被害規模を大きく左右します。

感染発覚時の初動チェックリスト

実施時間 アクション 担当 完了確認
0〜5分 発見者:端末に触れず、IT部門に即座に連絡 発見者
5〜10分 IT部門:感染端末のネットワーク切断判断 IT担当
10〜15分 ランサムノート(脅迫文)の写真撮影・記録 IT担当
15〜20分 影響を受けた可能性のある端末のリストアップ IT担当
20〜30分 インシデント対応チーム招集、役割分担確認 CSIRT責任者
30〜60分 経営層への第一報 CSIRT責任者

発見者が取るべき5つの即座の行動

  1. 端末の操作を停止:暗号化の進行を止めるため、ファイル操作は一切しない
  2. ネットワークケーブルを抜く(または WiFi を OFF):横展開を防止
  3. 画面を写真撮影:ランサムノートや暗号化されたファイル名を記録
  4. IT部門に電話で連絡:メールではなく電話で直接連絡
  5. 電源は切らない証拠保全のためメモリ内容を維持

緊急隔離の実施

ネットワーク切断の判断基準
ランサムウェアは横展開(ラテラルムーブメント)により、ネットワーク上の他の端末やサーバーに感染を広げます。感染の疑いがある端末は即座にネットワークから隔離することが原則です。ただし、クラウドサービスへの接続が業務上必須の場合は、そのリスクと影響を勘案して判断します。
電源を落とすvs落とさない
電源を落とすと、メモリ上のマルウェア痕跡や暗号化キーが失われる可能性があります。一方、電源を維持すると暗号化が進行するリスクがあります。ネットワークから切断した状態であれば、電源は維持してメモリダンプを取得することを推奨します。メモリダンプの体制がない場合は、ネットワーク切断後にシャットダウンを検討します。
物理的なネットワーク切断
LANケーブルを抜く、Wi-Fiを無効化する方法です。確実だが、リモートでは実施できません。物理的にアクセス可能な端末では最も推奨される方法です。
論理的なネットワーク隔離
ファイアウォールルールの変更、VLANの隔離、EDRによるネットワーク隔離機能の活用などがあります。リモート対応が可能ですが、設定に時間がかかる場合があります。
サーバー・インフラ全体の停止
被害が広範囲に及ぶ場合、コアスイッチの遮断やサーバーの一斉シャットダウンを検討します。業務影響が大きいため、経営判断を仰ぎます。

経営層への第一報

報告すべき情報の最小限セット
現時点で判明している事実(感染端末数、暗号化されたデータの種類、業務影響)を簡潔に報告します。不確定な情報は「調査中」と明記します。
意思決定を求める項目
業務停止の範囲と期間、外部専門家への依頼、規制当局への報告、顧客・取引先への通知など、経営判断が必要な事項を明確にします。

被害範囲の特定 - 1〜6時間

初動対応で感染拡大を止めた後、次の段階は被害範囲の正確な把握です。復旧計画を立てるために、何が影響を受けたかを詳細に調査します。

感染範囲の調査

確認項目 確認方法 記録事項
暗号化されたファイル ファイル拡張子の変更、ランサムノートの有無 影響フォルダ・ドライブのリスト
感染端末の特定 EDRアラート、イベントログ、共有フォルダのアクセスログ ホスト名、IPアドレス、ユーザー
横展開の痕跡 認証ログ、リモートアクセスログ 不正ログオンの時刻と対象
データ窃取の可能性 ネットワークトラフィック、プロキシログ 外部への大量データ送信の有無

ランサムウェアの種類特定

攻撃に使われたランサムウェアの種類を特定することで、復旧オプションが明確になります。

ID Ransomwareでの判定
暗号化されたファイルのサンプルとランサムノートをアップロードすることで、ランサムウェアの種類を特定できるオンラインサービスです。無料で利用でき、復号ツールの有無も確認できます。
VirusTotal分析
ランサムウェアの実行ファイル(検体)が入手できた場合、VirusTotalで複数のアンチウイルスエンジンによる検出結果を確認できます。既知のランサムウェアファミリーかどうかが判明します。
ランサムノートの特徴分析
脅迫文の文面、連絡先のメールアドレスやTorサイトのURL、支払い要求額などから、ランサムウェアグループを推定できることがあります。
LockBit
拡張子「.lockbit」、高速暗号化が特徴。RaaS(Ransomware as a Service)モデルで運営。2024年に法執行機関の作戦を受けたが、活動継続。
BlackCat/ALPHV
Rust言語で開発、クロスプラットフォーム対応。データ窃取と公開による二重脅迫を行う。
Cl0p
ファイル転送ソフトの脆弱性を悪用した大規模攻撃で知られる。データ窃取を重視し、暗号化しないケースも。

影響システムの棚卸し

業務影響度の評価
暗号化されたシステムが業務にどの程度影響を与えるかを評価します。Tier1(基幹業務)からTier4(低影響)まで分類し、復旧優先順位を決定します。
データ重要度の分類
個人情報、財務データ、知的財産など、データの種類による重要度を評価します。情報漏洩の観点からもリスク評価が必要です。

復旧オプションの検討 - 6〜24時間

被害範囲が把握できたら、復旧オプションを比較検討します。バックアップからの復旧、復号ツールの利用、そして最終手段としての身代金支払いについて、冷静に評価します。

バックアップからの復旧可能性

バックアップの健全性確認
バックアップが攻撃者に破壊されていないか、暗号化されていないかを確認します。オフラインバックアップ、イミュータブルバックアップがあれば、復旧の見込みが高まります。
感染前のクリーンな復元ポイント
ランサムウェアの侵入日時を特定し、それより前のバックアップを選択します。侵入から発覚まで時間が経っている場合、十分に古いバックアップが必要です。
復旧所要時間の見積もり
データ量、インフラ構成、復旧手順の整備状況により異なります。現実的なRTO(Recovery Time Objective)を算出し、経営層に報告します。
復旧オプション 所要時間目安 コスト 成功確率 リスク
バックアップ復旧 24時間〜1週間 低〜中 高(バックアップ健全時) データロスの可能性
復号ツール使用 数時間〜数日 無料 低〜中(ツール存在時のみ) 最新版には未対応の場合あり
身代金支払い 数時間〜数日 高(数百万〜数億円) 中(約70%が復号可能) 再攻撃、法的リスク
システム再構築 1週間〜数か月 中〜高 過去データの喪失

復号ツールの確認

No More Ransom Project
Europol、各国警察、セキュリティベンダーが協力して運営するプロジェクトです。100種類以上のランサムウェアに対応した無料の復号ツールを提供しています。まずここで復号ツールの有無を確認してください。
セキュリティベンダーの復号ツール
Kaspersky、Avast、Emsisoftなどが独自に復号ツールを提供しています。特定のランサムウェアファミリーに対応したツールが見つかる可能性があります。
復号ツール利用時の注意点
復号ツールはランサムウェアの特定バージョンにのみ対応しています。最新版のランサムウェアには対応していないことが多いです。また、復号前に必ず暗号化されたファイルのバックアップを取得してください。復号に失敗するとデータが破損する可能性があります。

身代金支払いの検討(非推奨だが現実として)

身代金の支払いは原則として推奨しません。しかし、バックアップがなく、事業継続が危機的状況にある場合、経営判断として検討せざるを得ないケースがあります。

支払いのリスク
支払っても復号できない確率は約30%あります。復号ツールの品質が低い、一部ファイルが破損する、そもそも復号キーが提供されないケースがあります。また、支払った組織は「支払い意思がある」としてマークされ、再攻撃の標的になりやすくなります。
法的リスク
攻撃者が経済制裁対象組織(ロシア、北朝鮮関連など)の場合、身代金支払いが制裁法違反となる可能性があります。支払いを検討する場合は、法務部門および外部弁護士との協議が必須です。
支払いを検討せざるを得ないケース
医療機関で患者の生命に関わる場合、バックアップが完全に破壊され事業存続が危機的な場合など。このような場合でも、まずは復号ツールの有無確認、部分的な復旧の可能性を探ります。
交渉の専門家活用
身代金交渉を専門とするコンサルタントやセキュリティ企業が存在します。交渉による減額、復号の確実性確認、支払い手続きの支援などを行います。自力での交渉は避け、専門家を介することを推奨します。

復旧作業の実施 - 24〜72時間

復旧オプションが決定したら、実際の復旧作業に着手します。セキュリティを確保しながら、段階的に業務を再開します。

システム復旧の手順

ステップ 内容 所要時間目安 担当
1. 環境準備 クリーンなOSイメージ、パッチ適用済み環境の準備 4〜8時間 インフラ担当
2. システム再構築 サーバー・端末の再インストール、設定復元 8〜24時間 インフラ担当
3. データ復元 バックアップからのデータリストア 12〜48時間 バックアップ担当
4. セキュリティ強化 侵入経路の遮断、認証情報リセット 4〜8時間 セキュリティ担当
5. 動作検証 システム正常動作、データ整合性確認 4〜8時間 業務部門・IT
6. 監視強化 追加監視設定、アラート閾値調整 2〜4時間 SOC担当

業務再開の判断

安全確認のチェックポイント
マルウェアの完全駆除確認、侵入経路の遮断確認、認証情報(パスワード、APIキー等)の全リセット完了、バックドアの有無確認。これらが完了するまで業務再開は控えます。
段階的な業務再開
全システムを一度に再開するのではなく、優先度の高いシステムから段階的に再開します。各段階で監視を強化し、異常がないことを確認してから次のシステムを再開します。

再感染防止策

侵入経路の特定と遮断
フィッシングメール経由なのか、VPNの脆弱性なのか、RDP経由なのか、侵入経路を特定し、同じ経路からの再侵入を防ぎます。
脆弱性の緊急パッチ
攻撃に悪用された脆弱性、およびその他の重大な脆弱性に対してパッチを適用します。
認証情報のリセット
攻撃者に窃取された可能性のある認証情報(Active Directory、サービスアカウント、APIキーなど)を全てリセットします。

ステークホルダー対応 - 並行実施

技術的な対応と並行して、ステークホルダーへのコミュニケーションも重要な業務です。

社内コミュニケーション

従業員への通知
何が起きているか、業務への影響、従業員が取るべき行動(不審なメールを開かない、パスワード変更など)を明確に伝えます。過度な不安を煽らず、事実に基づいた情報提供を心がけます。
業務影響の説明
使用できないシステム、代替手段、復旧見込み時期を具体的に説明します。業務部門と連携し、手作業での業務継続が必要な場合はその手順を共有します。
対応状況の定期報告
経営層には少なくとも1日2回、進捗を報告します。全従業員には1日1回程度、状況アップデートを行います。

外部対応

顧客・取引先への通知判断
顧客データが影響を受けた可能性がある場合、通知が必要です。法的義務がなくても、信頼関係維持の観点から通知が望ましいケースがあります。通知のタイミング、内容、方法は法務部門と協議します。
規制当局への報告
個人情報漏洩の可能性がある場合、個人情報保護委員会への報告が義務となることがあります。業界固有の規制(金融庁、厚生労働省など)も確認します。
メディア対応の準備
大規模インシデントの場合、メディアからの問い合わせに備えます。広報部門と連携し、プレスリリースや想定問答を準備します。

事後対応と再発防止 - 72時間以降

復旧が完了したら、根本原因分析と再発防止策の策定に取り組みます。

根本原因分析

侵入経路の特定
フィッシングメール、脆弱性の悪用、認証情報の漏洩など、どの経路から侵入されたかを特定します。フォレンジック調査の結果を基に分析します。
防御が破られた要因
なぜ侵入を検知できなかったか、なぜ横展開を許したか、技術的・運用的な要因を分析します。
検知が遅れた理由
アラートが発生していたが見逃していた、ログが取得されていなかった、など検知・対応プロセスの問題点を洗い出します。

再発防止策の策定

期間 対策カテゴリ 具体例
短期(1か月以内) 緊急対応 脆弱性パッチ適用、認証強化、監視ルール追加
中期(3〜6か月) プロセス改善 インシデント対応手順見直し、セキュリティ教育強化
長期(1年以上) 組織改革 セキュリティ体制強化、組織的対策の見直し

報告書作成

経営層向けサマリー
インシデントの概要、被害規模、対応経緯、再発防止策を1〜2ページに要約します。技術的詳細は省き、経営判断に必要な情報に絞ります。
技術詳細レポート
フォレンジック結果、攻撃者のTTPs(Tactics, Techniques, Procedures)、IOC(Indicators of Compromise)、時系列の対応記録を詳細に文書化します。
改善提案書
根本原因分析に基づく改善提案を、優先順位、予算、期間とともに提示します。セキュリティROIの観点も含めます。

事前準備の重要性

インシデント発生時に慌てないためには、平時からの準備が不可欠です。

プレイブックの整備

役割と責任の明確化
インシデント対応チームのメンバー、各メンバーの役割、連絡先を事前に定義します。24時間対応が必要な場合の体制も検討します。
連絡体制の確立
経営層、法務、広報、外部専門家への連絡ルートを事前に確立します。連絡先リストは紙でも保管し、システムがダウンしても連絡できるようにします。
判断基準の事前合意
どの程度の被害で業務を停止するか、外部専門家を呼ぶ基準、規制当局への報告基準などを事前に合意しておきます。

定期訓練

机上演習(Tabletop Exercise)
ランサムウェア感染シナリオを想定し、関係者が集まって対応を議論します。半日程度で実施でき、対応手順の問題点や認識のズレを発見できます。年1〜2回の実施を推奨します。
実機訓練
実際に隔離環境でマルウェア検体を使用した訓練や、バックアップからの復旧訓練を行います。コストと時間がかかりますが、実践的なスキル向上に効果的です。
外部専門家との連携確認
サイバー保険の保険会社、フォレンジック業者、法律事務所など、インシデント時に連携する外部専門家との事前顔合わせ、連絡手順の確認を行います。

よくある質問(FAQ)

Q: ランサムウェアの身代金は支払うべきですか?
A: 原則として支払いは推奨しません。支払っても復号できない確率は約30%あり、再攻撃の標的になるリスクも高まります。また、反社会的組織への資金提供となる可能性もあります。バックアップからの復旧、復号ツールの利用を最優先で検討し、支払いは最終手段としてください。どうしても検討が必要な場合は、法務・コンプライアンス部門、専門家と協議してください。
Q: 復旧にはどのくらい時間がかかりますか?
A: 被害規模と準備状況により大きく異なります。端末数台程度で適切なバックアップがあれば24〜48時間、中規模企業で1週間程度、大規模被害では数週間から数か月かかることもあります。日頃からのバックアップ体制整備と復旧訓練が、復旧時間短縮の鍵です。
Q: 警察に届け出ると捜査で業務が止まりますか?
A: 通常、捜査のために業務を止める必要はありません。証拠の任意提出や事情聴取への協力は求められますが、業務復旧と並行して対応できます。むしろ、早期に届け出ることで、他組織への被害拡大防止や、将来的な被害回復(攻撃者の資産凍結など)につながる可能性があります。
Q: 従業員に何を伝えればよいですか?
A: 事実を正確に、過度な不安を煽らずに伝えます。具体的には、何が起きたか(ランサムウェア攻撃を受けた)、業務への影響(使えないシステム、代替手段)、復旧見込み、従業員が取るべき行動(パスワード変更、不審メール報告など)です。情報を隠すと噂が広まり、混乱が大きくなります。
Q: インシデント対応チームがない場合どうすればよいですか?
A: IT部門を中心に臨時のチームを編成します。経営層の判断を仰げる責任者、技術対応のリーダー、社内外コミュニケーション担当を最低限決めてください。外部のセキュリティ専門企業やサイバー保険の付帯サービスを積極的に活用することも有効です。平時からインシデント対応チーム構築を検討してください。

まとめ

ランサムウェア被害への対応は、最初の72時間が勝負です。初動での迅速な隔離、被害範囲の正確な把握、復旧オプションの冷静な比較、そして段階的な復旧作業。これらを時系列に沿って確実に実行することで、被害を最小化し、事業を継続することができます。

本記事で解説したプレイブックは、あくまで一般的なフレームワークです。自組織の環境、業務特性、リスク許容度に合わせてカスタマイズし、定期的な訓練を通じて実効性を高めてください。

マルウェア感染対策の全体像、バックアップ戦略証拠保全と法的対応についても併せてご参照ください。


重要なお知らせ

  • 本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。
  • 身代金支払いの判断は法的リスクを伴うため、必ず法務部門・専門家にご相談ください。
  • 実際にランサムウェア被害に遭われた場合は、警察(#9110)やIPA(03-5978-7509)などの公的機関にご相談ください。
  • 記載内容は作成時点の情報であり、攻撃手法は日々進化している可能性があります。

更新履歴

初稿公開

京都開発研究所

システム開発/サーバ構築・保守/技術研究

CMSの独自開発および各業務管理システム開発を行っており、 10年以上にわたり自社開発CMSにて作成してきた70,000以上のサイトを 自社で管理するサーバに保守管理する。