NTFS はフォレンジック アナリストに三つの主要なメタデータ ソースを提供します。一日を失う最短ルートは、間違ったソースを読むことです。手早い対応表:
| アーティファクト | 何を記録するか | 時間範囲 | 粒度 | 場所 |
|---|---|---|---|---|
$MFT | ボリューム上の各ファイルとディレクトリの現在の状態 — 名前、サイズ、タイムスタンプ、親 | 「今」プラス再利用されるまでの削除済みエントリ | ファイル単位 | MFT エントリ 0 |
$UsnJrnl:$J | あらゆる作成/削除/リネーム/変更の循環ログ | 数日〜数週間 | 操作単位 | \$Extend\$UsnJrnl:$J (代替データ ストリーム) |
$LogFile | NTFS がクラッシュ復旧に用いるトランザクション ログ — メタデータ書き込みの前後イメージ | 数分〜数時間 | メタデータ トランザクション単位 | \$LogFile (MFT エントリ 2) |
本稿は実践的な決定木を示します — ある問いに対して、どのアーティファクトが答えるか。
$MFT — 「いま何が存在するか」
Master File Table は NTFS の背骨です。各ファイルやディレクトリは 1 つのエントリ (通常 1024 バイト) を持ち、$STANDARD_INFORMATION、1 つ以上の $FILE_NAME、そしてデータ ランを保持します。Microsoft は構造を NTFS リファレンス で説明し、Brian Carrier の File System Forensic Analysis が書籍長の正典的な解説です。
使い所:
- 「このボリュームに何があるか」 — 各エントリのタイムスタンプも含めて。
- 親 MFT エントリのチェーンからフル パスを再構築する (本パーサが
$MFTも与えられたとき、ジャーナル レコードのパスを解決するのに使うのと同じ方法)。 - 直近に削除されたファイルの復元 — エントリが上書きされていなければ、データ ランが無事である可能性があります。
わからないこと:
- 火曜の 14:32 にそのファイルに何が起きたか —
$MFTは$STANDARD_INFORMATIONと$FILE_NAMEの 4 つのタイムスタンプしか持たず、これは最終状態であって履歴ではありません。
ツール: Eric Zimmerman の MFTECmd が事実上の標準パーサ。代替に mft (Rust) と analyzeMFT (Python) があります。
$UsnJrnl:$J — 「いつ、何が、どの順で起きたか」
USN ジャーナルはボリューム上で起きる作成、削除、リネーム、切り詰め、属性変更、クローズを記録します。背景は本サイトの フォーマット入門 と reason コード リファレンス を参照。
使い所:
- 削除済みファイルでも、そのライフサイクルを再構築する。
- インシデント対応のタイムライン再構築、特に
RenameOldName/RenameNewNameの対とDataOverwriteのクラスタ。 - スケールしたランサムウェア パターンの検出 (専用記事 参照)。
わからないこと:
- 誰が 何をしたか — ユーザ、プロセス、コマンド ラインの情報はありません。
Security.evtx(イベント ID4663) や Sysmon と組み合わせる必要があります。 - ファイルの中身 — 変わったことだけが分かります。
- リング バッファの窓の外で起きたこと。既定サイズはクライアントで ~10 MB、サーバで 1 GB 以上で、これが数日〜数週間の履歴に相当します。
ツール: usnrs、PoorBillionaire/USN-Journal-Parser、本サイトのパーサ。
$LogFile — 「NTFS がこれから何をしようとしていたか」
NTFS がクラッシュ復旧に用いるメタデータ ジャーナルです。メタデータ書き込みごとの前後イメージ — INDEX_ALLOCATION の更新、属性変更、MFT エントリの書き換え — を記録します。フォーマットは未文書化ですがリバース エンジニアリングが進んでおり、Joachim Metz の libfsntfs リポジトリ が最も網羅的な公開リファレンスです。
使い所:
- 同じ数分以内に 作成され削除されたファイルの復元 —
$LogFileには削除の「前」イメージがまだ残っていることがあり、ファイル名と親が含まれます。 $MFTを直接触ったアンチ フォレンジック活動の検知 — 見かけの状態がきれいでも、$LogFileには書き込みが記録されます。
わからないこと:
- 最近の数千トランザクションの外側 —
$LogFileはよく回転し、活発なマシンでは 1 時間以内に上書きされることもあります。 - ファイルの中身。記録されるのはメタデータ変更のみです。
ツール: LogFileParser と libfsntfs ベースのパーサ群。
決定木
対象ファイルが分かっている?
├── はい → 現状を知りたい? → $MFT (パス、タイムスタンプ、サイズ)
│ 履歴を知りたい? → $UsnJrnl (直近のものはさらに $LogFile)
└── いいえ → 時間帯は?
├── 直近数分 → $LogFile (もっとも細かい)
├── 数日〜数週間 → $UsnJrnl (信号対雑音比が最良)
└── それより前 → $MFT のみ (残るのはタイムスタンプだけかもしれない)
ファイル間の相関を取っている?
└── 操作単位でソート可能なタイムラインを持つのは $UsnJrnl だけ。
組み合わせる
三つのアーティファクトはよく合成できます:
$MFT+$UsnJrnlが正典的な組 —$MFTがパス解決のためのディレクトリ ツリーを、$UsnJrnlが操作履歴を提供します。本サイトのパーサに両方をドロップしたときに行われているのが、まさにこれです。$LogFileは直近の過去のためのセーフティ ネット。$UsnJrnlが薄い (小さい、または無効) ときに特に有用です。- より広い文脈には、
Security.evtx(プロセス/オブジェクトのイベント)、Prefetch (実行の痕跡)、レジストリのハイブを加えます — 全景は SANS の Windows Forensic Analysis ポスター を参照。