非技術系のステークホルダーからフォレンジックアナリストが最もよく受ける質問は、「このファイルが存在したことを証明できますか?」の何らかのバリエーションです。ファイルがディスクから削除され、ゴミ箱 が空にされ、$MFT のエントリが別の用途に再利用されるほどの時間が経過した後では、答えはほぼ常に USN ジャーナルがまだ覚えているかにかかってきます。私の経験では、ジャーナルは他のすべてが消されてしまった後で「このファイルが過去に存在したか」に対して最も持続的な証人です。
本記事では、ジャーナルが削除済みファイルについて何を保持するか、その証拠の取り出し方、そしてジャーナルが最後の砦になるケースを見ていきます。
削除後にジャーナルが保持するもの
NTFS でファイルが削除されると、三つのことが起こります。
- 親ディレクトリの
$FILE_NAMEエントリがリンク解除されます。ディレクトリのINDEX_ALLOCATIONがそれ抜きで書き換えられます。 - MFT エントリは未使用としてマークされますが、ゼロ化されません。そのエントリに次に割り当てられたファイルが、データラン、属性、タイムスタンプを上書きします。
- USN ジャーナルが
FileDelete | Closeレコードを取得し、ファイル名、その親参照、その MFT エントリ番号とシーケンス、削除タイムスタンプを記録します。
これら三つのうち、ジャーナルレコードが最も回復力が高いです。ディレクトリエントリは親が書き換えられた瞬間に消えます。多忙なボリュームでは数秒以内のこともあります。MFT エントリは新しいファイルが作成された瞬間に再利用される可能性があります。数分以内のこともあります。ジャーナルレコードは数日から数週間後にしか巻き戻らないリングバッファに座っています。
数日前に削除されたファイルについて、ジャーナルは通常次を提供します。
- UTF-16 LE のリーフとしての ファイル名。リーフのみ、パスなし。
- 親ディレクトリの MFT 参照番号。パース済みの
$MFTと組み合わせるとパスに解決されます。 - FILETIME UTC での 削除タイムスタンプ。
- ファイルが占めていた MFT エントリ番号とシーケンス番号。カービングしたアーティファクトや
$LogFileの before-image との相互参照に役立ちます。 - ライフサイクルトレース。同じ
FileReferenceNumber上のFileCreate、DataExtend、BasicInfoChange、リネームレコードが、ファイルがいつ作成されたか、どう書かれたか、削除前にタイムスタンプが改変されたかを教えてくれます。
4 フィールドのタプル — MFT 参照、ファイル名、親参照、削除 FILETIME — に同じジャーナル内の以前の作成イベントを加えれば、通常はリーガルホールドを満たすか、より深い調査をアンカーするのに十分です。多くの場合、同じ $J から FileCreate レコードも得られ、これがファイルの年齢と $STANDARD_INFORMATION から独立した作成タイムスタンプを与えます。
最小の回復ワークフロー
パース済みのジャーナルとパース済みの $MFT (両方の 抽出ガイド) を使用:
- 関心のある時間枠内の
FileDeleteでフィルタ します。タイムスタンプでソートします。これがトリアージ対象の削除のマスターリストです。 - 重要な削除について
FileReferenceNumberでグループ化 します。ファイルの完全な歴史が得られます: 作成、書き込み、リネームのペア、属性変更、最後の削除。 $MFTで親パスを解決します。本ページのパーサは両ファイルが供給されると自動的に行います。$MFTがないとリーフのファイル名で止まります。- 削除が非常に最近なら
$LogFileを相互確認 します。ディレクトリエントリの "before" イメージがまだ含まれていることがあり、ファイル存在の独立した二番目の証人になります。
「MFT 参照、ファイル名、親パス、作成タイムスタンプ、削除タイムスタンプ、完全ライフサイクルトレース」の組み合わせがあれば、通常は法的に通用するレポートを書くのに十分です。
親パスが解決できない場合
ときには、確認するまでに親 MFT エントリ自体が再利用されていることがあります — ファイルシステムが忙しいホスト、特にファイルサーバや CI ランナーでよく見られます。ジャーナルはまだファイル名と親参照番号を提供しますが、$MFT はその参照がどのフォルダを指していたかを知らなくなっています。
通常 3 つのフォールバックでパスが復活します。
同じ親参照に対する以前の RenameNewName レコード。 すべてのジャーナルレコードを親参照でグループ化します。未解決の参照と一致する新しい親を持ち、その自分のパスが解決できる以前の RenameNewName は、その参照がかつてどのフォルダだったかを教えます。
$LogFile のインデックスエントリ。 クラッシュリカバリログは INDEX_ALLOCATION 更新の before-image を保持します。Joachim Metz の libfsntfs と Jonas Schicht の LogFileParser がそれらを抽出します。十分新しい削除なら、ディレクトリエントリの before-image がまだ $LogFile にあり、パスに解決されます。
同じ親参照に属する兄弟ファイル。 すべてのジャーナルレコードを親参照でグループ化します。兄弟のうち、MFT エントリがまだ有効なディレクトリに リネームされた ものがあれば、それを通じてピボットします。リネーム時の古い親が、あなたの未知のフォルダです。
これらのいずれも機能しない場合、パーサはファイルを「filename: notes.docx、parent: 1234-5」のように、解決済みパスなしで浮上させます。これは意図的です。検証できないパスをでっち上げるのは、欠けていることを認めるよりも悪い結果です。
「ワイプ済み」は「消えた」を意味しない
ファイルシュレッダ — CCleaner のセキュア削除、Eraser、BleachBit、sdelete — はファイル内容を上書きしてから削除します。これらはより 騒がしい ジャーナル痕跡を残し、静かにはしません。
- ファイルの
FileDelete | Closeの前にある複数のDataOverwrite | Closeレコードは、意図的なコンテンツ上書きを示します。通常の削除は上書きを生成しません。 - 数秒以内の同じファイルに対する
FileCreateとDataOverwriteとFileDeleteは、典型的な証拠破壊シグネチャです。 - シュレッダが書き込みと削除でフィラーファイルを使って スラックスペース もワイプした場合、それらのフィラーファイルにも独自の作成/拡張/上書き/削除の系列があります — 破壊の瞬間周りのレコードの群れです。
MITRE ATT&CK のマッピングは、コンテンツ上書きについては T1485 Data Destruction、削除自体については T1070.004 File Deletion です。意図的な証拠破壊が疑われるホストでは、ジャーナルは他のどのアーティファクトよりもタイトなタイムスタンプを提供することがよくあります。
ファイルの内容については
USN ジャーナルはコンテンツを決して運びません。操作に関するメタデータだけです。バイトが必要な場合、ジャーナルは見るべき場所を指し示します。
- 削除されたファイルの MFT エントリ番号。エントリがまだ再利用されていなければ、
$MFTがデータランを保持しており、コンテンツは The Sleuth Kit のicatまたは X-Ways で復元できる可能性があります。 - 非常に最近の削除に対する
$LogFileの before-image。 - ホスト上に存在する場合の ボリュームシャドウコピー (VSS)。削除されたファイルは以前のスナップショットに存在することがあります。稼働中のホストでは
vssadmin list shadows、イメージでは libyal のvshadowmountで表面化します。 - アプリケーション固有のストア。OneDrive のオンラインゴミ箱、
\Users\<u>\AppData\Roaming\Microsoft\Office\UnsavedFiles\配下の Office の「自動保存」フォルダ、ブラウザのキャッシュ (ブラウザフォレンジックツール がカバー)、Outlook OST/PST のステージング済みコピー。 - ファイルが十分最近まで開かれていた場合の ページファイル と RAM ダンプ。
ジャーナルの役割は、ファイルが存在 した こと、そして いつ 削除されたかを教えることです。コンテンツの復元はその後の話です。
実用的な制限
リングバッファのウィンドウ。 あなたが見られる最古のレコードを上回ってジャーナルが巻き戻された前に削除されたファイルは、このアーティファクトからは消えています。補完として $LogFile とシャドウコピーを取得してください。
ジャーナルに到達しない操作。 属性だけを更新するファイルシステムレベルの暗号化変更、アロケーションマップだけに触れるスパース領域の書き込み、一部の NTFS リパースポイント操作は DataExtend や DataOverwrite レコードを生成しないことがあります。ジャーナルは NTFS がログに残すと選んだものを見ます。
先行する FileCreate のない FileDelete。 ジャーナルの現在の最古レコードより前にファイルが作成されたことを意味します。$J におけるそのライフサイクルは部分的ですが、削除タイムスタンプと親参照は引き続きレポートをアンカーします。
バインドマウントまたはボリュームマウントの共有。 データがリモートファイルシステムに存在する場合、ホストのジャーナルはローカルハンドルしか知りません。実際のホスティングファイルシステムからジャーナルを取得してください。
参考資料
- Microsoft Learn — Change Journals は
FileDeleteレコードを生成する API サーフェスとライフサイクルをカバーします。 - The Sleuth Kit の man ページ — まだ割り当てられている MFT エントリに対するコンテンツ復元には
icatとfls。 - SANS DFIR — Windows Forensic Analysis ポスター は、ジャーナルを
$LogFile、ボリュームシャドウコピー、その他の削除復元アーティファクトと文脈に置きます。 - Joachim Metz の libfsntfs — 削除が新しく、ディレクトリエントリがまだ他で上書きされていないときの
$LogFilebefore-image 抽出のオープンリファレンスです。