← ブログに戻る

NTFS の USN ジャーナル ($UsnJrnl:$J) を理解する

NTFS の Update Sequence Number ジャーナルへの実践的な入門。何であるか、ディスク上でどう構造化されているか、Windows フォレンジックにおいてなぜこれほど価値があるのか。

約 2 分で読了

NTFS の Update Sequence Number ジャーナル — 通称 USN ジャーナル、あるいは単に $UsnJrnl:$J — は、Windows フォレンジックにおいて最も過小評価されている痕跡の一つです。NTFS がボリューム上でファイルを作成、削除、リネーム、切り詰め、あるいは何らかの形で触れるたびに、このログにレコードを追記します。レコードは小さく (それぞれ数十バイト)、ジャーナルは固定サイズのリングバッファとして管理されているため、活動の多いマシンでもおおよそ直近の数百万件のファイル操作を保持しています。

ジャーナルの場所

ジャーナルは通常のファイルではありません。ボリューム ルートの \$Extend\$UsnJrnl に付随する 代替データ ストリーム $J です。フォレンジック イメージから取り出すには、NTFS のメタデータ ストリームを理解するツール (FTK Imager、X-Ways、The Sleuth Kit の icat など) を用います。得られる $J のバイト列が、本サイトの WebAssembly パーサや usnrs のようなツールが扱う入力です。

レコードの構造 (USN_RECORD_V2)

各レコードは USN_RECORD_V2 構造体です:

フィールドバイト意味
RecordLength4ファイル名を含むレコードの総サイズ
Major / Minor version2 + 2現在は 2.0
FileReferenceNumber8ファイルの MFT エントリ + シーケンス
ParentFileReferenceNumber8親ディレクトリの MFT エントリ + シーケンス
USN8ジャーナル内でのレコード位置
Timestamp8Windows FILETIME (1601-01-01 からの 100ns ティック)
Reason4何が変化したかを示すビットマスク (FileCreateClose 等)
SourceInfo4ヒント (例: OS 起因の変更を示す DATA_MANAGEMENT)
SecurityId4$Secure:$SII へのインデックス
FileAttributes4NTFS の標準属性
FilenameLength / Offset2 + 2レコード内における UTF-16 ファイル名の位置
FilenamenUTF-16 LE、null 終端なし

最も情報量の多いフィールドは「reason」です。これはビットマスクであり、典型的なファイルのライフサイクルは FileCreate | DataExtendDataExtend | CloseBasicInfoChange | CloseFileDelete | Close のような系列を生みます。この系列を復元することが、事後に「実際に何が起きたのか」を語る手段になります。

DFIR で価値がある理由

二点あります:

  1. 削除後も残る。 ファイル システム上から (そしてゴミ箱からも) ファイルが消えた後でも、その操作履歴はジャーナル内に残り、リング バッファが上書きするまで保持されます。
  2. 問い合わせコストが低い。 100 MB の $J は通常、数日から数週間分の活動を覆う数百万件のレコードを保持し、各レコードは自己記述的です。

ジャーナルを $MFT と突き合わせれば、ほぼすべてのレコードについてフル パスを解決できます — $MFT は各エントリの $FILE_NAME 属性を介して親チェーンを提供します。本サイトの「$MFT をドロップ」オプションは、まさにそれをあなたに代わって行います。

次に読むもの

ジャーナルを見たことがないなら、テスト用マシンから一つ取得し、本ページ上部のボックスにドロップしてみるのが手っ取り早い感覚の掴み方です。本シリーズの次回以降では、reason フラグ、ジャーナル カービングのトレードオフ、そして Windows の他のタイムライン痕跡 ($LogFile、Prefetch、ShimCache) との位置づけに踏み込んでいきます。