← ブログに戻る

USN ジャーナルで削除済みファイルの痕跡を取り戻す

ファイルが削除され、ごみ箱からも消え、MFT エントリが再利用された後でも、USN ジャーナルには名前、親、時系列が残っていることが多いです。その痕跡の取り出し方。

約 2 分で読了

フォレンジック アナリストが非技術者から最もよく受ける質問は、いずれも 「このファイルが存在したことを証明できる?」 の変奏です。ファイルがディスクから削除され、ごみ箱が空にされ、$MFT エントリが再利用されるほどの時間が経ったとき、答えは多くの場合 USN ジャーナル がまだ覚えていることに依存します。

本記事では、ジャーナルが削除済みファイルについて何を保持するか、それをどう取り出すか、そしてジャーナルが最後の証人になる場面を順に見ていきます。

削除後にジャーナルが残すもの

NTFS でファイルが削除されると、いくつかのことが起きます:

  1. 親ディレクトリの $FILE_NAME エントリが切り離されます。
  2. MFT エントリは使用中ではないとマークされます — ただしゼロ化はされません。
  3. USN ジャーナルが FileDelete | Close レコードを受け取り、ファイル名、親参照、MFT エントリ番号、タイムスタンプを記録します。

ジャーナル レコードはこの三者の中で 最も頑健 です。ディレクトリ エントリは親が書き換えられた瞬間に消え、MFT エントリは新しいファイルが作成された途端に再利用されえますが、ジャーナル レコードは数日〜数週間の活動の後にしか巻き戻らないリング バッファに残ります。

つまり、数日前に削除されたファイルについてもジャーナルはしばしば次を与えてくれます:

  • ファイル名(末端の名前のみ、フル パスではない)。
  • 親ディレクトリの MFT 参照 — パース済み $MFT と合わせればパスになる。
  • 削除タイムスタンプ(UTC)。
  • ファイルが占めていた MFT エントリ番号(カービング済みアーティファクトとの相互参照に有用)。
  • ライフサイクルの軌跡:削除前の FileCreate、DataExtend、BasicInfoChange のレコードが、いつ作成され、どのように書かれ、タイムスタンプが書き換えられたかを示します。

最小のリカバリ ワークフロー

パース済みジャーナルが手元にあれば(本ページのパーサや usnrs で OK;$J と $MFT の取得は 抽出ガイド を参照):

  1. FileDelete でフィルタしてウィンドウ内の各削除を浮かび上がらせる。タイムスタンプでソート。
  2. 注目する削除ごとに FileReferenceNumber でグルーピングし、ファイルの完全な履歴 — 作成、書き込み、リネーム対、属性変更、最終的な削除 — を確認。
  3. $MFT を介して親パスを解決。両ファイルが渡されていれば、本パーサがこれを自動で行います。
  4. 削除がきわめて新鮮なら $LogFile をクロス チェック — ディレクトリ エントリの「前」イメージがまだ残っており、独立した第二の証人になりえます。

「MFT 参照、ファイル名、親、作成タイムスタンプ、削除タイムスタンプを持っている」という組み合わせは、リーガル ホールドを満たすか、より深い調査を錨付けするのに十分なことが多いです。

親パスが解決できないとき

時として、調べる時点で MFT の親エントリ自体がすでに再利用されています — 特に活動の多いホストで顕著です。その場合、ジャーナルはファイル名と親参照は与えてくれますが、$MFT はもうその番号が何のフォルダだったかを知りません。

通常は次の三つが助けになります:

  • 親参照に対する過去の RenameNewName レコード — リネーム時点で解決可能な親を運んでいることがあります。
  • $LogFile のインデックス エントリ — 非公式だが libfsntfs でカバーされる。
  • 同じ親参照の兄弟ファイル — すべてのジャーナル レコードを親でグルーピング。兄弟の一つが MFT エントリの有効な別ディレクトリへ リネーム されていれば、それを経由できます。

これは本ツールの暫定レポートが「filename: notes.docx」とパスなしで返す理由でもあります — 検証できないパスは作り出さない、という方針です。

「ワイプ」は「消えた」ではない

少数のシュレッダー系ツール(CCleaner、Eraser、BleachBit)はファイルの内容を上書きしてから削除します。通常の削除と同じジャーナル レコードに加えて、上書きレコードを残します。よってジャーナルは「セキュア デリート」を静かなものではなく、騒がしいものにします:

  • ファイルの FileDelete | Close の前に複数の DataOverwrite | Close レコードがあれば、意図的な内容上書きを示します。
  • 同じファイルの FileCreate と FileDelete が数秒以内に発生し、間に上書きが挟まる — 典型的なパターン。
  • シュレッダーが スラック領域 も一時ファイル書き込みで掃除した場合、それらの一時ファイル自体に独自の create/extend/overwrite/delete 列がつき、証拠破壊の瞬間の周辺にレコードの群れが現れます。

対応する MITRE ATT&CK テクニックは T1485 Data Destruction と T1070.004 File Deletion です。

ファイルの 内容 は?

USN ジャーナルは内容を運びません — 操作のメタデータのみです。バイトを取り戻したい場合、ジャーナルは次に手掛かりを与えます:

  • 削除されたファイルの MFT エントリ番号。エントリが再利用されていなければ、MFT はまだデータ ランを保持しており、内容は The Sleuth Kit の icat や X-Ways で復元しうる。
  • きわめて新鮮な削除に対する $LogFile の「前」イメージ。
  • Volume Shadow Copies(VSS)があれば — 削除されたファイルは過去のスナップショットに残っているかもしれない。
  • アプリ別ストア — OneDrive のごみ箱、Office の自動保存フォルダ、ブラウザのキャッシュ。

ここでのジャーナルの役割は、ファイルが「存在した」ことと「いつ削除されたか」を語ること — その後のリカバリは下流の話です。

実務的な限界

  • ジャーナルには 時間ウィンドウ があります。あなたが持つ最古のレコードよりも前にリング バッファが巻き取られていた場合、その削除はこの痕跡にはもうありません。補助として $LogFile とシャドウ コピーを引き出してください。
  • 一部の操作は ジャーナルに触れません:ファイル システム レベルの暗号化変更、スパース領域のみへの書き込み(割り当てマップだけ触る)、NTFS のリパース ポイント操作などは DataExtend/DataOverwrite を生成しないことがあります。
  • ウィンドウ内に対応する FileCreate のない FileDelete は、ファイルがジャーナルの現在最古のレコードより 前 に作成されたことを意味します — ライフサイクルは部分的でも、削除タイムスタンプは依然として錨付けできます。

より広いアーティファクト文脈は SANS の Windows Forensic Analysis ポスター と Microsoft Learn のチェンジ ジャーナル リファレンス を参照してください。