マルウェア感染が疑われるときの初動対応を、端末隔離、証拠保全、影響確認、エスカレーション、復旧判断の順で解説。個人・情シス・開発者・SaaS管理者が最初の10分で確認するチェックリストと、電源を切る条件、避けるべき対応を公式資料に基づき整理します。
この記事の目次 13項目から選ぶ
冒頭要約：感染の断定より、拡大防止と記録を優先する
マルウェア感染が疑われたら、最初に行うのは「駆除できるソフトを探すこと」ではない。表示内容と時刻を記録し、組織の端末はネットワークから隔離し、決められた窓口へ連絡することが優先だ。
ただし、ネットワーク隔離と電源断は同じではない。電源を切るとメモリ上の情報など調査に必要な証拠を失う場合がある一方、隔離できず被害が広がっている緊急時には電源断を検討することもある。自己判断で初期化やファイル削除をせず、被害拡大の抑制と証拠保全を両立させる。
この記事では、個人、情シス、開発者、SaaS管理者が、感染を疑った最初の10分から復旧判断までに確認することを、実務で使える順番に整理する。
このページは防御・確認・報告のための一般的なガイドです。会社や学校の端末では、画面に表示された連絡先ではなく、社内の情シス、CSIRT、ヘルプデスクへ連絡し、自組織のインシデント対応手順を優先してください。
マルウェア感染とは：ウイルス感染との違い
マルウェアは、情報窃取、端末操作、暗号化など、利用者や組織へ害を与えるソフトウェアの総称である。一般に使われる「コンピューターウイルス」はマルウェアの一種であり、すべてのマルウェアが自己複製するウイルスとは限らない。用語の範囲は マルウェアとウイルスの違い で詳しく比較している。
感染の疑いは、EDRやアンチウイルスの警告、不審なサインイン、見覚えのないソフト、ファイルの暗号化、急な動作不良などから始まる。ただし、ブラウザに突然表示された「ウイルスが見つかりました」という広告だけでは、端末への感染を断定できない。画面の電話番号へ連絡したり、案内された遠隔操作ソフトを入れたりせず、正規の窓口へ相談する。
読者別の影響と最初の役割
| 読者 | 最初に守るもの | まず行うこと |
|---|---|---|
| 個人利用者 | 写真、連絡先、決済・ログイン情報 | 画面と時刻を記録し、信頼できる別端末から公式サポートや専門窓口を確認する |
| 情シス・CSIRT | 端末、社内ネットワーク、共有領域、業務継続 | 端末を識別して隔離し、利用者・時刻・兆候・実施操作を記録する |
| 開発者 | ソースコード、署名鍵、APIキー、CI/CD | 開発端末の隔離後、クリーンな端末から認証情報とリポジトリ操作を確認する |
| SaaS管理者 | IdP、メール、クラウドストレージ、管理権限 | 同じ利用者のサインイン、セッション、権限変更、外部共有を確認する |
端末の問題に見えても、認証情報やブラウザセッションが影響を受ければSaaSへ波及する。反対に、SaaS側の不審操作だけを見て端末確認を省くと、原因が残る場合がある。端末・アカウント・クラウドを一つのタイムラインで確認することが重要だ。
まず確認すること：最初の10分チェックリスト
原因究明より先に、被害拡大を止め、あとから調査できる状態を作る。
- 警告画面、検知名、発生時刻、操作していた内容を写真またはメモで残した
- 会社端末の資産番号、ホスト名、利用者、設置場所を特定した
- 有線LAN、Wi-Fi、VPNなど、現在の接続状態を確認した
- 組織端末は社内手順に従ってネットワークから隔離した
- 初期化、再起動、ファイル削除、自己流の駆除をまだ行っていない
- 情シス、CSIRT、ヘルプデスクなど正規の窓口へ連絡した
- 管理者権限、顧客情報、開発用シークレットを扱う端末か確認した
- 同じ利用者の不審なサインインやSaaS操作がないか確認を依頼した
ネットワーク隔離では、LANケーブルやWi-Fiなど通常通信を止める。組織でEDRの端末隔離機能を利用している場合は、管理通信を残しながらほかの通信を制限できることがある。製品ごとの挙動と社内手順を確認し、隔離操作の時刻と実施者も記録する。
写真には、表示全文、URLやアプリ名、時刻が分かる範囲を含めます。機密情報や個人情報が写る場合は、社内で承認された保存先に限定し、個人のチャットやクラウドへ転送しないでください。
初動対応：やること、やらないこと、記録すること
やること
- 端末を特定する：資産番号、ホスト名、利用者、OS、設置場所、業務上の重要度を記録する。
- 通信を止める：組織の手順に従い、ネットワーク隔離またはEDRの隔離機能を使う。
- 正規窓口へ連絡する：検知時刻、警告内容、直前の操作、隔離状態を伝える。
- 周辺ログを保全する：EDR、認証、メール、DNS、プロキシ、SaaS監査ログの保存期間を確認する。
- 影響範囲を分けて確認する：端末、アカウント、共有領域、ほかの端末、外部送信の順に整理する。
やらないこと
- 警告画面に表示された電話番号へ連絡したり、案内されたソフトを入れたりしない
- 感染が疑われる端末でパスワード変更や重要な業務を続けない
- 証拠保全方針を確認せず、再起動、初期化、ファイル削除を行わない
- USBメモリや外付けディスクを接続してファイルを移さない
- 不審ファイルをメールやチャットで別の担当者へ送らない
- 本番端末で攻撃の再現、検体実行、非公式な駆除ツールの試行をしない
- 「スキャンで検出なし」だけを根拠に業務利用を再開しない
記録すること
| 項目 | 記録例 |
|---|---|
| 検知 | 2026-07-18 10:14 JST、EDRアラート／利用者申告／不審な画面 |
| 対象 | 資産番号、ホスト名、利用者、部署、端末の役割 |
| 直前の状況 | メール添付を開いた、Webを閲覧した、ソフト更新直後など事実のみ |
| 隔離 | 方法、実施時刻、実施者、隔離後も可能な管理通信 |
| 証拠 | アラートID、画面記録、ログの保存先、取得担当者 |
| 影響 | アカウント、共有領域、顧客情報、開発資産、ほかの端末 |
| 未確認 | 外部通信の成否、認証情報の利用、同一兆候の有無 |
| 次の判断 | 隔離継続、専門調査、認証情報失効、再構築、報告要否 |
記録は「確認できた事実」「推測」「未確認」を分ける。インシデント証拠保全の初動 も併用すると、ログや端末を扱う順番を整理しやすい。
端末隔離と電源断の判断基準
原則は、まずネットワークから隔離し、電源を入れたまま正規窓口の指示を待つことだ。電源断は、メモリ上の情報や稼働中プロセスなど揮発性の証拠を失う可能性がある。
一方、CISAのStopRansomware Guideは、ネットワークから切り離せず、被害の拡大を止めるために必要な場合には電源断を検討する考え方も示している。これは常に電源を切るという意味ではなく、証拠損失と被害拡大のどちらが大きいかを緊急時に判断するための例外である。
| 状況 | 基本判断 | 注意点 |
|---|---|---|
| EDRやLAN操作で隔離できる | ネットワーク隔離を優先 | 隔離時刻と方法を記録し、管理通信の可否を確認する |
| 暗号化や共有領域への異常書き込みが続き、隔離できない | 社内手順に従い電源断を緊急検討 | 揮発性証拠を失うため、実施理由と時刻を必ず残す |
| 画面上の偽警告だけで、ほかの兆候が未確認 | 表示内容を記録し、正規窓口へ相談 | 表示された連絡先やダウンロードを使わない |
| 重要サーバーや医療・製造など停止影響が大きい | インシデント責任者と業務責任者が共同判断 | 安全・事業継続への影響を含め、単独で操作しない |
判断に迷う場合は、端末を使い続けるより、通信を止めて専門担当へ引き継ぐ方が安全側である。ただし、業務停止が人命や設備安全へ影響する環境では、あらかじめ定めた手順を最優先する。
影響範囲の確認方法：端末だけで終わらせない
初動後は、次の5領域を順に確認する。ここでも、攻撃を再現するのではなく、組織が保有する防御ログと資産情報から事実をそろえる。
1. 端末
- EDR・アンチウイルスの検知内容、隔離状態、最終通信時刻
- 対象ファイル、プロセス、利用者、実行時刻の関係
- 同じ兆候がほかの端末で観測されていないか
EDRアラートの見方は EDRアラートの初動対応 に、製品の役割の違いは EDRとアンチウイルスの違い に整理している。
2. アカウントとセッション
- 同じ利用者の不審なサインイン、MFA変更、パスワードリセット
- メール転送、受信トレイルール、OAuth同意、管理者権限の変更
- セッション失効やパスワード変更が必要か
認証情報の窃取が疑われる場合は、感染が疑われる端末ではなく、クリーンな管理端末からセッション失効と認証情報の変更を行う。変更の前後で監査ログを保全する。
3. データと共有領域
- クラウドストレージ、ファイルサーバー、共有リンクへの不審なアクセス
- 顧客情報、個人情報、ソースコード、認証情報へ到達できた可能性
- バックアップや同期先に異常がないか
外部送信や共有設定変更が疑われる場合は、漏えい疑い初動テンプレート へ引き継ぐ。
4. ほかの端末と共通経路
- 同じ利用者、同じメール、同じ配布ソフト、同じ管理ツールを使う端末
- 同時間帯のDNS、プロキシ、メール、認証ログに共通する兆候
- 管理者端末や開発端末など、波及時の影響が大きい資産
5. 業務影響
- 隔離によって止まる業務と代替手段
- 顧客、取引先、委託先への影響
- 法務、個人情報保護、広報、経営への報告要否
ログを読むときは、タイムゾーンと時刻同期をそろえ、セキュリティログの読み方 の手順で「通常との差分」「同時刻の事象」「事実と推測」を分ける。
危険度とエスカレーションの判断
製品画面の重大度だけではなく、端末の役割、権限、影響範囲、進行中かどうかで優先度を決める。
| 優先度 | 目安 | 推奨する動き |
|---|---|---|
| 緊急 | 暗号化や外部送信が進行中、複数端末、管理基盤・重要サーバー、業務停止 | 即時隔離、インシデント責任者招集、証拠保全、経営・法務を含む判断 |
| 高 | 管理者・開発者・経理端末、認証情報や顧客情報への到達可能性、不審な外部通信 | 隔離継続、アカウント保護、専門調査、影響範囲の優先確認 |
| 中 | 単一端末で検知、隔離済み、外部通信や権限利用は未確認 | 当日中に調査し、再接続条件を満たすまで隔離を維持 |
| 低 | 偽警告の可能性が高く、正規ログに関連兆候がない | 証跡を残して確認し、利用者教育とブラウザ設定を見直す |
次のいずれかに当てはまる場合は、一次対応者だけで完結させない。
- 複数の端末、ユーザー、拠点で同じ兆候がある
- 管理者権限、顧客情報、決済、ソースコード、認証情報が関係する
- 外部送信、権限変更、ログ削除、セキュリティ機能停止の兆候がある
- 端末の隔離ができない、または業務上隔離できない
- 何が起きたか説明できず、必要なログも取得できない
- 顧客、取引先、法令、契約上の報告判断が必要になる可能性がある
国内組織は、必要に応じて JPCERT/CCのインシデント対応依頼 も確認できる。相談時には、組織名、連絡先、発生日時、対象、現時点の事実、実施済み対応を整理しておく。
復旧と再接続のチェックリスト
「警告が消えた」「ファイルが隔離された」だけでは、業務再開の条件を満たしたとは限らない。少なくとも次を確認する。
- 原因と侵入・感染経路について、現時点で説明できる範囲を整理した
- 端末、アカウント、SaaS、共有領域、ほかの端末の影響を確認した
- 必要なログと証拠を保全し、保管場所と担当者を記録した
- 影響を受けた可能性があるセッション、認証情報、APIキーを安全な端末から失効・更新した
- OS、アプリ、セキュリティ製品を承認済みの状態へ更新した
- 駆除を継続利用するか、クリーンなイメージから再構築するか判断した
- EDR・アンチウイルス・監査ログが正常に記録されることを確認した
- 再接続後の監視項目、期間、異常時の再隔離条件を決めた
- 利用者と関係者へ、再開条件と残っている注意点を説明した
感染範囲や原因を十分に確認できない場合、重要端末を単に「駆除して継続利用」するより、承認済みイメージから再構築し、必要なデータだけを安全確認後に戻す方が信頼性を高めやすい。どちらを選ぶ場合も、復旧前に原因となった設定、脆弱性、認証情報、運用手順を見直す。
ランサムウェア特有の暗号化、共有領域、バックアップの判断が必要な場合は、最初の1時間の対応 と ランサムウェア初動テンプレート を使う。
よくある誤解
「警告が出たら、すぐ電源を切ればよい」
常に正しいとは限らない。電源断で証拠を失う場合があるため、まずネットワーク隔離を検討する。隔離できず被害が進行する緊急時は、組織の手順と責任者判断で電源断を検討する。
「アンチウイルスが駆除したので、調査は不要」
ファイルの隔離は一つの対応にすぎない。隔離前の外部通信、認証情報の利用、ほかの端末への波及を確認しなければ、影響全体は分からない。
「パスワードを変えれば端末も安全になる」
パスワード変更はアカウント保護であり、端末の復旧とは別の作業だ。感染が疑われる端末で新しいパスワードを入力せず、クリーンな端末からセッション失効と変更を行う。
「ブラウザに感染警告が出たので、表示された窓口へ電話する」
偽警告やサポート詐欺の可能性がある。画面を記録し、ブラウザやOSの公式サポート、会社の情シスなど、自分で確認した正規窓口を利用する。
関連用語・関連ページ
| 次に知りたいこと | ページ |
|---|---|
| 基本用語 | マルウェア、EDR、IOC、封じ込め、フォレンジック |
| 用語の違い | マルウェアとウイルスの違い、EDRとアンチウイルスの違い |
| アラート調査 | EDRアラートの初動対応、セキュリティログの読み方 |
| 証拠と報告 | インシデント証拠保全の初動、漏えい疑い初動テンプレート |
| ランサムウェア | 最初の1時間の対応、ランサムウェア初動テンプレート |
| 体系的な学習 | インシデントレスポンス、SIEMとログ管理、確認クイズ |
まとめ：最初の10分で「止める・残す・伝える」
マルウェア感染が疑われたときは、感染の断定や自己流の駆除より、通信を止める、証拠を残す、正規窓口へ伝えることを優先する。端末を特定し、ネットワークから隔離し、発生時刻と表示内容を記録する。電源断は一律に行わず、隔離できないまま被害が進行するなどの緊急条件と、証拠損失を比較して判断する。
その後は、端末だけでなく、同じアカウント、SaaS、共有領域、ほかの端末へ確認範囲を広げる。復旧時には、原因、影響、証拠、認証情報、再構築の要否、再接続後の監視まで確認し、「警告が消えた」だけで業務へ戻さない。
公式情報・参考情報
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management — インシデント対応を検知、対応、復旧と組織のリスク管理へつなぐ基礎資料。
- NIST SP 800-83 Rev. 1: Guide to Malware Incident Prevention and Handling for Desktops and Laptops — デスクトップ・ノートPCのマルウェア予防と対応を扱う技術ガイド。
- CISA #StopRansomware Guide — 感染疑いシステムの隔離と、隔離できない緊急時の電源断に関する考え方を確認できる。
- Microsoft Defender for Endpoint: Take response actions on a device — 端末隔離、調査情報の収集、スキャンなど製品上の防御対応を確認できる。
- JPCERT/CC インシデント対応依頼 — マルウェア感染を含む国内インシデントの相談窓口と連絡時の情報。
- IPA 中小企業の情報セキュリティ対策ガイドライン 付録8 — 中小企業向けに、検知、初動、調査、復旧、再発防止の流れを整理した手引き。
