ほとんどのアナリストは Volume Shadow Copy を Windows のバックアップメカニズムとして考えています。フォレンジック上の金鉱でもあります。各スナップショットは、スナップショットが取られた瞬間の $MFT の完全な凍結コピーを含むからです。5 つのスナップショットを持つワークステーションは、ファイルシステムの 6 つの独立した観察（今日 + 過去の 5 つ）を提供します。それぞれが異なるコードパスで署名されています。それぞれが異なる時刻に書き込まれました。それらの間の差分は、ボリュームがどう変化したかの連続的な記録に最も近いものです。
この投稿はそれをどう使うかについてです。
VSS が何をキャプチャするか
Volume Shadow Copy Service は NTFS ボリュームの特定時点のスナップショットを取ります。各スナップショットはコピーオンライトのデルタです。ライブボリューム上のブロックが変更されようとするとき、オリジナルが先にシャドウコピーに保存されます。スナップショットは、作成の瞬間のボリュームをそのまま反映し、以下を含みます。
$MFT（スナップショット時のテーブル全体、当時の各レコードの状態を含む）$UsnJrnl:$J（その時点までのジャーナル）$LogFile- すべてのユーザーファイル（VSS の除外設定は除く。デフォルトでは
pagefile.sys、hiberfil.sys、%TMP%の内容を含みます）
典型的な Windows エンドポイントでは、スナップショットは自動的に取られます。
- Windows Update インストールの前。
- 構成変更（ドライバインストール、特定のソフトウェアインストール）に対する System Restore による。
- サードパーティのバックアップソフトウェア（Veeam、Acronis、MSP RMM ツール）による。
- 大量操作の前にスナップショットを要求する特定のアプリケーションによる。
定期的に更新されるワークステーションは、数か月にさかのぼる 5 〜 10 のスナップショットを簡単に持てます。バックアップソフトウェアを持つサーバーははるかに多くを持てます。
なぜこれがフォレンジックで重要か
ライブ MFT は 1 つの観察です。スナップショットがあれば系列が得られます。各歴史的 MFT はその瞬間のボリュームの状態を記録し、以下を含みます。
- 当時存在し、その後削除されたファイル。 スナップショットから完全に回復可能で、範囲内であればクラスタデータも含みます。
- 現在存在するが当時は存在しなかったファイル。 いつ導入されたかを証明します。「このファイルはスナップショット N とスナップショット N+1 の間に現れた」と固定すれば、作成ウィンドウが得られます。
- タイムスタンプが今日と異なるレコード。 インターバル中に発生したリネーム、移動、timestomping を露わにします。
- VSS 非依存の検証。 スナップショットはライブボリュームとは別のコードパスで書き込まれます。両方を一貫して偽造するのは困難です。
スナップショットはランサムウェアケースで特に有用です。ほとんどのファミリーはまず VSS を削除しようとしますが、異なる VSS writer ID を使うサードパーティのバックアップソフトウェアが取ったスナップショットを見逃すことがあり、または接続された外部ドライブ上のスナップショットを見つけられないことがあります。1 つの暗号化前スナップショットが生き残っていれば、オリジナルファイルが手に入ります。MFT におけるランサムウェアパターン を参照してください。
スナップショットの列挙
昇格された PowerShell または cmd から。
vssadmin list shadows
各エントリは Shadow Copy Volume パスを示し、\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7 のような形をしています。そのパスは同じ NTFS 構造を持つ別個のボリュームとしてマウント可能です。
詳細（スナップショット ID、作成時刻、VSS writer）について。
vssadmin list shadows /for=C:
フォレンジックイメージから、libvshadow を使用します。
vshadowinfo disk.dd
vshadowmount disk.dd /mnt/shadows
vshadowinfo は .dd または .E01 イメージ内のスナップショットを列挙します。vshadowmount はそれらを個別の仮想ボリューム（vss1、vss2、...）として公開します。各 NTFS ボリュームとして解析可能です。これがオフライン VSS 抽出の標準ツールで、Windows マシンは不要です。
スナップショットから $MFT を抽出する
スナップショットがマウントされたら（ライブシステム経由または vshadowmount 経由）、$MFT は親ボリュームと同じオフセット、スナップショットのルートに存在します。ライブと同じツールで取得します。
fsutil（ライブシステム）。fsutil file queryextents \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7\$Mftがエクステントを返し、生の読み取りがファイルを組み立てます。- FTK Imager。シャドウコピーデバイスを証拠として追加し、
$MFTに移動し、エクスポートします。 - Sleuth Kit の
icat（イメージ）。icat -o <offset> vss1 0 > mft_vss1.bin。Inode 0 は常に$MFTです。 - KAPE に
MFTターゲットと--vssフラグを付ける。KAPE は列挙された各スナップショットに対して順番にターゲットを実行し、スナップショットごとの抽出をサブディレクトリに生成します。
ライブシステムのメカニクスは $MFT の抽出 を参照してください。
2 つの MFT を比較する
最も安価で有用な分析は差分です。両方の $MFT ファイルを CSV（レコードごとに 1 行）に解析し、レコード番号でソートし、差分を取ります。
mft_dump -o csv mft_today.bin > today.csv
mft_dump -o csv mft_vss3.bin > vss3.csv
diff <(sort today.csv) <(sort vss3.csv) > changes.diff
探しているもの。
vss3に存在するがtodayに欠落または削除済みとマークされているレコード。 インターバル中に削除されたファイル。スナップショットは削除前のレコードを保持しており、メタデータと（しばしば）データを回復します。todayに存在するがvss3に存在しないレコード。 インターバル中に導入されたファイル。それらの作成はスナップショットと今日の間に収まります。- SI タイムスタンプが逆行したレコード。 可能性のある timestomping。スナップショットがグラウンドトゥルースです。
$FILE_NAME親参照が変更されたレコード。 ファイルが別のディレクトリに移動しました。- シーケンス番号が 1 以上ジャンプしたレコード。 スロットがインターバル中に複数回再利用されました。激しいチャーンか意図的なスロット再利用です。
$UsnJrnl レベルで同じ差分はさらに豊富です。MFT 差分とペアにして完全な絵を得てください。一部のスナップショットには、ライブジャーナルから既にローテートアウトされた USN ジャーナル内容があります。複数のスナップショットの USN ジャーナルを組み合わせると、ライブジャーナル単独が保存するよりも長い活動履歴が再構築されます。
努力を正当化したケース
VSS-MFT 差分が解決した過去の業務からの具体的なケースをいくつか。
- 「誤って削除した」という主張。 ユーザーは先週の火曜日に誤ってファイルを削除したと言いました。月曜日のスナップショットと今日の間の MFT 差分は、ファイルが実際にはリネームされ、その後非ユーザープロセスによって開かれ、3 日後に削除されたことを示しました。違う話です。
\Windows\Temp\に存在する永続的なバックドア。 ライブ MFT には痕跡がなく、クリーンアップスクリプトが実行されていました。2 週間前のスナップショットには、レジデント$DATA内にバイナリがありました。ハッシュは既知のマルウェアファミリーと一致しました。- 暗号化前の MFT。 ランサムウェア実行が C: ドライブ上のすべてを暗号化しました。
vssadmin delete shadowsが実行されていましたが、異なる writer ID で Veeam がトリガーしたスナップショットが生き残りました。暗号化前 MFT を回復し、オリジナルを復元し、支払いなしで済みました。
VSS は、特定時点のトリアージを系列に変えるアーティファクトです。きちんと取得する努力は報われます。
限界
スナップショットは削除できます。 vssadmin delete shadows /all は 1 行のワイプで、すべての最新のランサムウェアプレイブックに含まれています。すでに追い出されたスナップショットは失われます。VSS は固定の最大値を保持します（デフォルトはボリュームあたり 64、ディスクスペースに基づく実務上はそれより少ないことが多い）。
スナップショットは任意の時点ではありません。 スケジュールされたものまたはインストーラがトリガーしたものを得ます。インシデントの正確な瞬間のスナップショットはまれです。最も近いのは、定期的にパッチを当てたワークステーションで通常 1 日以内、バックアップソフトウェアを持つサーバーで数時間以内です。
古い $MFT のレジデントデータはスナップショットを超えて保持されません。 スナップショットにファイルが存在し、レジデントになるくらい小さければ、そのスナップショットがバイトを持っています。削除後に取られたスナップショットからは回復することを期待しないでください。
除外されたパスはスナップショットに入りません。 %TMP%、pagefile.sys、レジストリ内の特定のボリュームシャドウコピー除外があり、一部のフォレンジックアーティファクトは保存されません。ページファイル と RAM ダンプ のアーティファクトは VSS が扱わないものをカバーします。
スナップショットはプロセス間でクラッシュコンシステントではありません。 スナップショットは 1 つの瞬間にボリュームをキャプチャしますが、アプリケーションとは協調しません。開いているファイル（特にデータベース）はスナップショット内で不整合な状態にあるかもしれません。NTFS 自身はジャーナル付きで整合しています。ファイル 内 にあるのは、その瞬間にアプリケーションがフラッシュしたものです。
よくある質問
Linux から VSS スナップショットを読めますか？
はい。libvshadow はクロスプラットフォームです。vshadowmount でイメージをマウントし、NTFS 対応の任意のツールでスナップショットボリュームを通常のファイルとして読み取れます。
スナップショットには $MFT のようなシステムファイルが含まれますか？
はい。VSS スナップショットはスナップショット時のボリューム上のすべてのブロックをキャプチャし、$MFT の先頭のメタデータファイルを含みます。これがまさにスナップショットが有用な理由です。
Windows は何個のスナップショットを保持しますか？
デフォルトでボリュームあたり最大 64 個。設定はレジストリ内の MaxShadowCopies で、ほとんどカスタマイズされません。バックアップソフトウェアを持つサーバーでは、実効的な限度は通常バックアップソフトウェアが保持する量です。
シャドウコピーデータはワイプに対して耐性がありますか？
ライブボリュームでの個別ファイルの削除には耐性があります。それが目的です。vssadmin delete shadows、フルディスクワイプ、物理メディアの損傷、または管理者権限を持つ敵対的アクターには耐性がありません。
外部ドライブ上のスナップショットはどうですか？
あまり一般的ではありませんが存在します。File History 用に構成された、または独自のバックアップソフトウェアを持つ外部ドライブはスナップショットを持つことがあります。任意のボリュームについて vssadmin list shadows /for=<drive>: で \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN パスを探してください。
参考資料
- Microsoft, Volume Shadow Copy Service。アーキテクチャリファレンス。
- libyal, libvshadow ドキュメント。任意のプラットフォームからスナップショットをマウント、解析、列挙する。
- Joachim Metz, Volume Shadow Snapshot（VSS）形式仕様。スナップショットストア自体のディスク上のレイアウト。