$MFT はスナップショットです。すべてのファイルが いま どう見えるか — メタデータ、データの位置、割り当て状態 — を記述します。しかし、その状態に至るまでにどのような変更があったかは記録しません。そのために NTFS は第 2 のアーティファクトを持っています — Update Sequence Number Journal、$UsnJrnl です。
$UsnJrnl が記録するもの
ファイルが作成・変更・改名・削除されるたびに、NTFS は固定長レコードをイベント記述として $UsnJrnl に追記します。フィールドは次の通り。
- USN(単調増加する 64 ビット整数)
- 変更されたファイルの MFT レコード番号
- 親ディレクトリのレコード番号
- 理由マスク:
FILE_CREATE、DATA_OVERWRITE、RENAME_OLD_NAME、CLOSE、FILE_DELETEほか多数 - タイムスタンプ
その結果として得られるのは、ジャーナル作成または最後のローテーション以降の、ファイル システム上のあらゆる意味あるイベントの時系列ログです。標準的なシステムでは、これは数日〜数週間をカバーします。
どこに住んでいるか
$UsnJrnl は通常の NTFS ファイルで、データは名前付きストリーム $J にあります。$LogFile や $Quota などの他のシステム メタデータ ファイルと並んで、特別ディレクトリ $Extend の中に置かれています。
$MFT を取得するのと同じツールで取り出せます。
- KAPE の
MFTターゲットには$UsnJrnlが含まれる - FTK Imager は
[NTFS ボリューム]/$Extend/$UsnJrnl:$Jからエクスポートできる - フォレンジックなディスク イメージ ツールは生クラスタから直接読める
$MFT をどう補うか
両者を並べると、片方だけでは見えないパターンが現れます。
- ディスク上では見つからないのに
$UsnJrnlに出てくるファイル — 2 つのスナップショットの間で作成・削除されたが、ジャーナルが記録を保持していた。 - ランサムウェア攻撃中の改名の正確な順序 —
OPEN、DATA_OVERWRITE、RENAME_OLD_NAME、RENAME_NEW_NAME、CLOSE。 - 「変更された」ファイルが本当に書き直されたのか、ただ触られたのか —
$UsnJrnlの理由フラグはデータ上書きとメタデータ変更を区別する。
タイムライン再構築の典型的な流れは、まず $MFT で現状を歩き、次に $UsnJrnl でその状態に至った変更の履歴を歩く、というものです。
限界
$UsnJrnl はローテーションします。既定では 32 MB で、活動的なシステムでは数日分の活動しか保持しません。古いイベントは末尾から落ちていきます。事象発生から 1 週間以上経って調査に入る場合は、欠損を想定し、$MFT のスラックと $LogFile により強く依存することになります。