すべての MFT レコードは、$STANDARD_INFORMATION と $FILE_NAME という 2 つの別々の属性に、それぞれ 4 つのタイムスタンプを保持しています。記録されるのは同じ 4 つの瞬間です。
- 作成 — ファイルがボリュームに最初に書き込まれた時刻
- 更新 — 中身が最後に変更された時刻
- アクセス — ファイルが最後に読み込まれた時刻
- MFT 更新 — レコード自体が最後に書き換えられた時刻
つまり 1 レコードあたり 8 つの値があり、必ずしも同期していません。
なぜ 2 組あるのか
$STANDARD_INFORMATION(SI)は通常のファイル操作のたびに更新されます。$FILE_NAME(FN)は元々 POSIX 互換性のために追加されたもので、更新頻度はずっと低く、通常は作成・リネーム・ディレクトリ間移動の時にしか書き換わりません。
実務上、SI のタイムスタンプは常に動き続け、FN のタイムスタンプは安定しています。
タイムストンピングは指紋を残す
タイムスタンプを書き換えるツールは、たいてい Windows の SetFileTime API を呼び出します。これは SI に書き込みます。FN には触れません。
そのため、タイムストンピング後の SI は攻撃者が選んだ値 — しばしば数年前にバックデートされた値 — を示す一方、FN は本来の作成日時を保持し続けます。両者の差が大きく開くことも珍しくありません。
トリアージで注目すべき 2 つのパターン:
- SI 作成日時が FN 作成日時より前。ファイルは名付けられる前に存在できないので、自然には起こりません。
- 明らかにリネームも移動もされていないファイルなのに、SI と FN の更新日時が数秒以上ズレている。
どちらもメタデータが操作された強い兆候です。
粒度がさらに多くを語る
NTFS はタイムスタンプを 100 ナノ秒精度で保持しますが、多くのタイムストンピング ツールは秒単位に丸めてしまいます。末尾が .0000000 UTC で終わるタイムスタンプは怪しいシグナルです — 通常の Windows の活動では、秒以下の精度はそのまま残るのが普通です。