← ブログに戻る

ディスクに存在しなくなったファイルがかつて存在したことを証明する

· 読了 2 分

フォレンジック業務は単一の質問を軸に展開することがよくあります。このファイルはこのコンピュータに存在したことがあるか?「今そこにあるか」(それは dir)ではありません。より難しい質問。昨日、先週、昨年、そこにあったことを示せるか? NTFS ボリュームでは答えは通常はいで、$MFT は単一のソースとして最も強力です。しばしばファイルの内容も戻ってきます。

これは、MFT メタデータだけから何を証明できるか、ジャーナルがどんな裏付けを加えるか、そして自信ある主張がレビューで崩れるケースについての実務者の視点です。

削除を生き残るもの

NTFS でファイルが削除されると、レコードヘッダの IN_USE ビットがクリアされ、親ディレクトリのインデックスエントリが削除されます。レコード自体は残り、以下を保持します。

  • 元のファイル名と親ディレクトリの MFT レコード参照を持つ $FILE_NAME
  • 削除の瞬間に凍結された 8 つのタイムスタンプ$STANDARD_INFORMATION に 4 つ、$FILE_NAME に 4 つ)。
  • ファイルのデータの 論理サイズと物理サイズ
  • 小さなファイル($DATA が約 700 バイト以下)の場合、ファイルの全内容がレコード内にインラインで格納されています。resident data を参照してください。
  • 大きなファイルの場合、データを保持していたクラスタのランリスト。これらのクラスタはまだ元のバイトを保持している場合もあれば、そうでない場合もあります。
  • レコードの シーケンス番号。これにより、現在見ているのが当時そのスロットに住んでいたファイル(後の住人ではなく)であることが証明されます。

$FILE_NAME = secret-plan.docx、親参照が \Users\bob\Documents に解決され、SI created が 2024-11-03T14:02:11Z の削除済み MFT レコードは、その日にその名前のファイルがそのディレクトリに存在したことを実証します。レコードが証拠であり、ファイルシステムドライバが書き込んだという意味で証拠は NTFS 自身によって署名されています。

証拠を防御可能にするもの

MFT レコードが、誰かがあなたのケースを崩そうとしているレビューに耐える 3 つの特性があります。

  1. NTFS 自身が書き込み、ユーザーは書き込みません。 レコードは通常の Windows API を通じてユーザーが編集できるものではありません。被告は単一のレコードが捏造されたと信用ある主張はできません。$MFT 全体が偽造されたと主張するしかなく、これは下記のジャーナルのクロスチェックを考えると高いハードルです。
  2. 8 つのタイムスタンプがクロスチェックします。 操作は通常見えてしまいます。SI が変更され FN が変更されていないのは教科書的な timestomping のシグネチャです。4 つの MFT タイムスタンプ を参照してください。SI created が FN created より前であることは自然には不可能です。
  3. $UsnJrnl$LogFile が裏付けます。 $MFT がファイルが時刻 T に作成されたと言うなら、USN ジャーナル は同じ時刻に FILE_CREATE を記録しているはずです。不一致はそれ自体が証拠です(偽造かパーサのエラーか、どちらにしても追跡する価値があります)。
  4. VSS スナップショットは独立です。 削除前のスナップショットは、ファイルが IN_USE=1 だった MFT コピーを保持しています。スナップショットは既知の時刻に VSS によって書き込まれました。2 つの独立した証人(ライブ $MFT + スナップショット $MFT)が同じファイルを示すのは、どちらか単独よりはるかに強力です。Volume Shadow Copy と $MFT を参照してください。

4 つ目のポイントは深掘りする価値があります。重要なケースでは私は常に VSS スナップショットを探します。単一の観察を、異なる時点での観察の系列に変え、ライブ MFT とは完全に異なるコードパスで書き込まれます。両方を一貫して偽造するのは困難です。

$MFT だけでは証明できないこと

MFT は、ファイルが特定の時刻に特定のディレクトリに存在し、レコードに記載された特定のサイズとタイムスタンプを持っていたことを証明します。次のことは証明しません。

  • 誰がそれを作成またはアクセスしたか。 これには Security イベントログ(SACL が設定されていれば 4663、Sysmon Event ID 11/15、またはコマンドラインでファイルが名指しされた場合はコマンドラインのある 4688 プロセス作成)が必要です。
  • どのプログラムがそれを生成したか。 PrefetchAmcacheShimcache がここで役立ちます。Sysmon Event ID 1 が有効化されていればゴールドスタンダードです。
  • データクラスタを回復しない限り、大きなファイルの中身。 レジデントファイルはバイトを与えます。非レジデントファイルは、クラスタランリストが依然として未割り当てで未上書きのスペースを指していることが必要です。
  • ユーザーが実際にそれを開いたか。 Jump listsLNK ファイルRecentFileCache の方がここでは有用です。
  • ディレクトリの所有ユーザー以外の誰かに見られたか。 これには ACL 監査ログが必要です。

完全な答えは通常、MFT を周辺アーティファクトと融合させます。MFT が要であるのは、それなしでは他のピースに何も繋ぐところがないからです。secret-tool.exe の Prefetch ヒットは興味深いです。同じヒットが、同じ分にプロセス(Sysmon Event ID 1 がタイムラインにある)によって secret-tool.exe\Temp\ に投下されたことを示す MFT レコードと組み合わさると、決定的です。

レビューに耐えるワークフロー

  1. $MFT$UsnJrnl:$J$LogFile、すべての VSS スナップショットを取得します。 すべてハッシュ化(SHA-256)します。取得時刻を文書化します。
  2. MFT を解析します。 問題のファイルのレコードを、生死を問わず見つけます。シーケンス番号、親参照、8 つのタイムスタンプすべて、レジデント $DATA があれば、そしてなければクラスタランリストを取得します。
  3. 親参照を解決 します。親の MFT レコードをたどります。ルート(レコード 5)に到達するまで繰り返します。結果のチェーンがディレクトリパスです。ログや目撃証言から得たパスとクロスチェックしてください。
  4. USN ジャーナルとクロスリファレンス します。同じレコード/シーケンスペアについて、すべての USN エントリを列挙します。FILE_CREATE が元の作成を、FILE_DELETE が削除を与えます。中間の理由はファイルの履歴です。
  5. VSS スナップショット MFT と比較 します。各スナップショットの同じレコードのコピーがチェックポイントを提供します。3 つのスナップショットがレコードを IN_USE=1 で一貫したタイムスタンプと共に示し、ライブ MFT が IN_USE=0 を示すなら、ファイルの存在について 4 つの独立した証人が一致し、削除について 1 つの証人があります。
  6. 除外した不可能性を文書化 します。SI/FN の乖離をチェック済み。シーケンス番号が一貫。スナップショットのタイムスタンプが整合。被告側の物語は、結論を覆すためにこれらすべてを説明しなければなりません。

最後のステップが、所見を主張から分けます。チェックしたものと除外したものをリスト化することで、推論の連鎖が可視化されます。

噛みつくエッジケース

ハードリンク。 複数のハードリンクを持つファイルは複数の $FILE_NAME 属性にまたがって存在します。リンクを 1 つ削除しても、その名前が削除されるだけでファイルは残ります。追跡している削除がファイルの消失と実際に対応していることを、単一の名前の削除ではないことを確認してください。

削除前にリネームされたファイル。 一部のドロッパーは、削除直前にステージングファイルを無害な名前にリネームし、生き残った $FILE_NAME が無害に読めることを期待します。USN ジャーナルは RENAME_OLD_NAME / RENAME_NEW_NAME のペアを保持しています。取得してください。

レコードスロットの再利用。 削除されたファイルのスロットは、新しいファイルによって認領されています。現在の MFT レコードはシーケンス N の新しいファイルです。ジャーナルはシーケンス N-1 の古いファイルを参照します。曖昧さをなくすためにシーケンス番号を使用してください。現在のものとは異なるシーケンスを指す参照は、以前の住人を指しています。

ファイルは存在したことがなく、誰かが嘘をついている。 あまり一般的ではありませんが知っておく価値があります。MFT、USN、VSS にわたって一貫してメタデータを偽造するのは困難ですが、管理者アクセスを持つ決意ある操作者にはツールがあります。一致すべきアーティファクト間の不一致を探してください。

参考資料

外部リソース