目次
重大な脆弱性へ更新を適用した時点で、「これ以上同じ穴から侵入されにくくする」という作業は前進します。しかし、更新前に侵入されていた場合、Webシェル、追加されたアカウント、盗まれた資格情報、改変された設定はパッチでは消えません。本稿は新しい脆弱性ニュースではなく、WebサーバーやWebアプリケーションで侵害の可能性が生じたとき、証拠を失わずに封じ込め、信頼できる状態へ戻すための恒久的な実務手順です。
2026年10月24日時点で確認したNIST SP 800-61 Rev.3は、インシデント対応を準備、検知、対応、復旧という継続的なリスク管理に組み込む考え方を示しています。また、JPCERT/CCが2026年10月23日に更新した注意喚起には、インターネット公開サーバー上のアプリケーションサーバーへ悪意あるWARファイルが配置され、JSP Webシェルとして機能した事例が追加されました。ここで重要なのは個別製品の名前よりも、「修正版へ更新する作業」と「侵入済みかを調べ、復旧する作業」は別だという点です。
スポンサーリンク
パッチ適用とインシデント対応は完了条件が違う
パッチ管理の完了条件は、対象資産を特定し、安全なバージョンへ更新し、サービスとセキュリティ機能が期待どおり動くことを確認することです。一方、侵害対応の完了条件は、攻撃者の足場と持続化手段を除去し、漏えいした可能性のある資格情報を失効し、信頼できる構成へ戻し、再侵入や見落としを監視できることです。前者だけを満たしても後者は自動的に満たされません。
そのため、悪用確認済みの脆弱性、外部公開された管理画面、身に覚えのないファイルやプロセス、不審な認証成功、Webサーバープロセスからのシェル起動などがある場合は、「更新できたので閉じる」ではなく、インシデントの可能性を前提に調査範囲を決めます。逆に、根拠なく侵害済みと断定する必要もありません。確認済み事実、観測できていない範囲、仮説をチケットやタイムライン上で分けて記録します。
最初の30分で守るものを決める
初動では可用性、被害拡大の防止、証拠保全が競合します。すべてを同時に最大化できないため、インターネット公開を止められるか、代替環境へ切り替えられるか、個人情報や決済情報を扱うか、攻撃が継続している兆候があるかを責任者が短時間で判断します。担当者が一人しかいない場合でも、操作を始める前に「誰が判断し、誰が記録し、どの連絡先へ報告するか」を明記しておくと、後から時系列を再構成しやすくなります。
- 公開範囲を制限する：ロードバランサー、CDN、WAF、ファイアウォールなど、対象ホストの外側で新規アクセスを絞ります。停止が難しい場合は管理機能の非公開化、許可元制限、レート制限を検討します。
- 操作時刻と担当者を記録する：端末、サーバー、クラウドの時刻源とタイムゾーンを確認し、遮断、採取、再起動、資格情報変更を分単位で記録します。
- 変更前の状態を保全する：ログ、プロセス、ネットワーク接続、ファイルのメタデータ、設定、クラウド監査記録を、可能な範囲で読み取り専用の保全先へ複製します。
- 侵害経路と権限範囲を仮置きする：Webアプリだけか、OS、データベース、CI/CD、クラウド管理面まで到達可能だったかを、推測ではなく観測結果ごとに整理します。
不審ファイルを見つけても、すぐ削除すると作成時刻、所有者、ハッシュ、関連ログといった手掛かりを失います。まずアクセスを遮断し、メタデータと複製を保全してから隔離するのが基本です。ただし、攻撃が継続していて利用者や他システムへの被害が広がる場合は、完全な証拠採取を待たず封じ込めを優先します。証拠保全は被害拡大を容認する理由にはなりません。
スポンサーリンク
ログは1台の中だけで探さない
侵害されたホストのログは消去や改変を受ける可能性があります。リバースプロキシ、CDN、WAF、ロードバランサー、Webサーバー、アプリケーション、データベース、ID基盤、EDR、DNS、クラウドのコントロールプレーンから、同じ時間帯の記録を集めます。保存期間が短いサービスでは、定常運用のエクスポートを待たず、調査用に取得することが重要です。
| 確認対象 | 残したい情報 | 注意点 |
|---|---|---|
| 入口 | 送信元、URI、メソッド、応答コード、User-Agent、転送先 | CDNやプロキシ配下では実送信元の記録方式を確認 |
| ホスト | プロセス一覧、親子関係、接続先、ログイン、スケジュール実行 | 再起動で消える揮発情報を先に採取 |
| ファイル | パス、所有者、権限、時刻、ハッシュ、署名、配布元との差分 | アクセス時刻などを不用意に更新しない |
| アプリ | 管理操作、アップロード、プラグイン、APIトークン利用、エラー | 通常の保守操作と攻撃操作を担当者記録で照合 |
| 外部管理面 | IAM、クラウド監査、CI/CD、秘密情報ストア、DNS変更 | ホスト外に残る記録を独立した証拠として扱う |
IOCの文字列一致だけでは不十分です。Microsoftが2026年4月に公開したCookie-controlled PHP webshellsの分析では、Webディレクトリやアップロード先へのPHPファイル作成、Webサーバーやphp-fpmからの不自然な子プロセス、cronによる持続化、外部通信など、振る舞いの観測が挙げられています。特定のファイル名が見つからないことを「侵害なし」の証明にせず、既知の正常状態との差分とプロセスの親子関係を確認します。
資格情報は順番を決めて失効する
Webサーバーには、データベース接続情報、クラウドキー、メール送信資格情報、SSH鍵、デプロイトークン、署名鍵、外部APIキーが置かれがちです。ファイルシステムやプロセス環境を攻撃者が読めた可能性があるなら、パスワード変更だけでなく、セッション、アクセストークン、APIキー、証明書を含めて棚卸しします。
可能であれば、まず不正利用を止め、必要な監査記録を保全してから、新しい信頼できる端末や管理面で鍵を再発行します。旧値を失効し、依存するアプリへ新しい値を配布し、旧値での利用が拒否されることまで確認します。侵害が疑われるホスト上で新しい秘密情報を生成・入力すると、その値も再び取得されるおそれがあります。
スポンサーリンク
修復ではなく再構築を選ぶ境界
侵害範囲が限定でき、改変箇所を完全に説明できる場合は、隔離、更新、不要物の除去、検証で戻せることがあります。しかし、管理者権限を奪われた可能性、未知の持続化、ログ欠損、ベースイメージ自体の不信、共有鍵の流出がある場合、「怪しいものを消した」だけでは信頼を回復できません。既知の正常なソース、署名付きパッケージ、検証済みコンテナイメージ、Infrastructure as Codeから新しい環境を作る方が、判断根拠を明確にできます。
- 侵害された可能性のある環境を調査用として分離し、再利用しない。
- ソース、依存パッケージ、ビルド手順、ベースイメージの出所とハッシュを確認する。
- 設定を旧ホストから丸ごとコピーせず、必要項目をレビューして再生成する。
- 新しい資格情報を信頼できる管理面から配布し、旧資格情報を失効する。
- 公開前に安全なバージョン、不要な管理機能の非公開化、最小権限、ログ転送を確認する。
JPCERT/CCの侵害調査に関する注意喚起も、脆弱性対応だけでなく、管理機能の公開範囲、APIアクセス制御、トークンの最小権限、侵害後の横展開対策、検知と初動対応の見直しを挙げています。なお、同注意喚起に掲載された複数事例は別々の事象であり、一つの攻撃活動として結び付ける根拠は示されていません。本稿でも個別事例を一般的な攻撃キャンペーンとは扱いません。
復旧判定をチェック項目にする
復旧は「画面が表示できた」で終わりません。安全なバージョンで起動していること、旧ノードが負荷分散先から外れていること、管理画面や診断機能が必要な範囲だけに公開されていること、旧資格情報が使えないこと、ログが外部へ届くことを確認します。さらに、攻撃時に観測したURI、メソッド、ファイル作成、プロセス起動が再現されないことを否定テストで確かめます。
- 資産台帳、配布先、実行中バージョンが一致している
- 既知の正常状態とのファイル・設定差分を説明できる
- ローテーション対象と失効結果を一覧で確認できる
- Webプロセスからのシェル、異常な外部通信、権限変更を監視できる
- 復旧後の重点監視期間、再評価日、終了条件が決まっている
スキャン結果が陰性でも、採取できなかった期間やログ欠損があれば侵害を完全には否定できません。重要システム、個人情報、法令・契約上の通知義務が関係する場合は、社内の法務・プライバシー担当や専門のインシデント対応事業者へ早期に相談します。調査の限界を隠さず、事業上受け入れる残余リスクを責任者が判断できる形にすることが復旧判定です。
平時に用意しておく最小セット
緊急時に初めて証拠保全の方法を考えると、保存先、権限、容量、時刻の不一致でつまずきます。平時に、外部ログ保管、時刻同期、連絡網、読み取り専用の調査用権限、再構築できる構成管理、秘密情報の棚卸し、復旧テストを用意します。CISA Cybersecurity Incident and Vulnerability Response Playbooksも、インシデント対応と脆弱性対応を別のプレイブックとして整理しています。自社では一枚のチェックリストへ統合しても、両者の完了条件は分けておくのが実務的です。
更新作業そのものの資産確認、検証、ロールバックは、関連記事の緊急パッチを安全に適用する実務ランブックで整理しています。実際にWebシェル設置まで確認されたケースで何を調べるかは、JPCERTがMetabase悪用とWebシェル設置を追記｜更新後に必要な侵害確認も参照してください。前者はパッチ運用、後者は個別事例、本稿は侵害の可能性がある環境を信頼できる状態へ戻す共通手順という位置付けです。
参考資料
- NIST SP 800-61 Rev.3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- CISA Cybersecurity Incident and Vulnerability Response Playbooks
- JPCERT/CC インターネット公開サーバーが侵害される事案の発生について
- Microsoft Security Blog Cookie-controlled PHP webshells: Tradecraft in Linux hosting environments
