USN の Reason コード — ビットの裏を読む

Windows フォレンジックに時間を費やすほど、USN の reason ビットマスクは身体感覚として身についていきます。これは NTFS が各ジャーナル レコードに設定する 32 ビットのフィールドで、ファイルに今ちょうど起きた変化を要約します。ビット単体ではすべてを語りませんが — 加算的であって排他的ではないため — 合わせて読むと、ライフサイクルの相当に精密な像が浮かびます。

ビットの一覧

Close は特別です。NTFS は同一ハンドル下の連続する操作を結合し、ハンドルが消えた段階で Close 付きの最終レコードのみを発行します。Close の付かないレコードは、システムが中間状態をフラッシュしている様子を見ています — 有用ですが、Close 付きのレコードこそが正式な総括です。

実地で頻出するパターン

いくつかのパターンは見た瞬間に判別できるくらい頻繁に現れます:

• アプリが書いた新規ファイル。 FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close。最後はファイルがクローズ時に mtime を刻まれる動きです。
• ディレクトリ間のリネーム。 同一の FileReferenceNumber に対する二件: RenameOldName | Close の次に RenameNewName | Close。親参照が両者で異なる — それが移動を再構成する手掛かりです。
• アトミックな save-by-rename。 多くのエディタは一時ファイルに書き、続けてターゲットへリネームします。一時側に FileCreate、元ファイルに FileDelete | Close、一時側に RenameNewName | Close が並びます。
• ランサムウェアの「暗号化→リネーム」。 メガバイト単位を覆う DataOverwrite の連続に、新拡張子での RenameNewName | Close が続きます。DataOverwrite の件数と時間分布は、サンプルをディスク上で最初に察知する手掛かりになることが多いです。
• アンチウイルスの隔離。 直近の FileCreate の直後に FileDelete | Close、すべて同一の MFT エントリ下で発生します。ファイル自体が消えた後でも、AV がファイルを触った決定的な証拠を提供します。

ビットからは分からないこと

reason ビットマスクは ファイルについて語り、行為者については語りません。ユーザもプロセス ID もコマンド ラインも含まれません。各操作に行為者を紐づけるには、ジャーナルを Security.evtx (4663 オブジェクト アクセス) や Microsoft-Windows-Sysmon/Operational と組み合わせます。USN は いつ と 何を を、他のログが 誰が を担います。

実用的な読み手順

パース済みジャーナルを開いたら:

1. 時間窓の中で本当に新規のものを把握するため FileCreate をフィルタする。
2. 移動や「名前を付けて保存」のパターンを捕らえるため RenameNewName を探す。
3. 時系列で DataExtend の件数をプロットする — バックアップ、暗号化、流出のステージングといった大量書き込みが浮かび上がる。
4. まず Close の立ったレコードを読み、途中状態は補助証拠として扱う。

本サイトの Web アプリは任意の reason 組み合わせでフィルタできるため、ステップ 1〜3 はクリック一つで済む作業になります。