新人検査担当者に NTFS について最も有用な一文を渡すとすればこれです。削除は消去ではありません。フラグ変更とインデックス更新です。ファイルの MFT レコードはそのまま残ります。データクラスタは $Bitmap で空きとマークされます。他の何かがそのスペースを要求するまで、何も上書きされません。
人々は抽象的にはこれを知っています。私が見続けている間違いは、生存期間がどんなマシンでも余裕があると思い込むことです。そうではありません。忙しいファイルサーバーではスロットは数分以内に再利用されます。週末誰も使わないワークステーションでは、削除済みレコードは 1 か月残ることがあります。何かがまだ回復可能であるという話に踏み込む前に、どちらのタイプのホストを見ているのかを把握する必要があります。
レコードに残っているもの
削除済み MFT レコードは構造的に生きたものと同一に見えます。IN_USE ビット（オフセット 0x16 のフラグフィールドのビット 0）はクリアされます。レコードが何かに引き継がれていない限り、その他は NTFS が最後に書き込んだ内容のままです。
$STANDARD_INFORMATION（属性タイプ0x10）。SI の 4 つすべてのタイムスタンプ、DOS フラグ、セキュリティディスクリプタ参照、所有者 ID、USN ポインタ。タイムスタンプは削除をそのまま乗り越えて残ります。ここで見える SI は削除の瞬間にファイルがどのような姿だったかを示すものであり、最初に作成されたときの姿ではないことに注意してください（Windows はファイルが生きている間、SI を常に更新します）。$FILE_NAME（0x30）。ハードリンクごとに 1 つ、加えてdisable8dot3がオフのボリュームでは 8.3 形式の短縮名。親ディレクトリ参照は、ファイルが存在していたディレクトリの MFT レコード番号です。その参照は、ディレクトリ自体が後で削除されても保持されます。これが、flsと MFTECmd が削除されたディレクトリ階層へのパスを再構築できる仕組みです。$DATA（0x80）。レジデントファイル（データが約 700 バイト未満）の場合、バイトそのものがレコード内にインラインで存在します。非レジデントファイルの場合、ランリストはかつてファイルであったクラスタを指します。それらのクラスタはもはやアロケート済みとしてマークされていませんが、ゼロ化もされていません。$ATTRIBUTE_LIST（0x20）が存在する場合、ファイルが使用していた拡張レコードへの参照。これらの拡張レコード自体は削除済みですが、再利用されるまでは依然として解析可能です。
シーケンス番号は、削除済みファイル分析を防御可能にする要素です。各レコードは 16 ビットのシーケンス番号を保持し、スロットが再利用されるたびに増加します。レコード 12345 のシーケンス 3 を指す USN ジャーナルエントリや $LogFile 参照は、スロットが現在シーケンス 4 になっていても、依然としてシーケンス 3 を指しています。この不一致が、スロットがその後に再利用されたことを示すのです。
スロットが実際に消えるとき
2 つのイベントが独立して回復可能性を終わらせます。
MFT レコードのスロットが再利用される。 NTFS はここで固定的なアロケーション戦略を持っていません。実務上、新しいファイルがレコードを必要とすると、ドライバは $MFT:$BITMAP を見て番号の最も小さい空きレコードを使います。削除済みレコードは概ね順に再利用されます。激しく使用されているボリュームではその順番は速く動きます。MFT 自体は成長するだけで縮小しません。したがって、現在のハイウォーターマークよりはるか上にある古い削除済みレコードは何年も残ることがあります。
データクラスタが上書きされる。 レコードとは独立した話です。クラスタは $Bitmap で空きにマークされたため、どのアロケータも要求する可能性があります。最近削除されたファイルの場合、回復が絶望的になる前に両方のイベントが起こる必要があります。レコードが残っているがクラスタはとうに失われている（メタデータとレジデントデータのみ回復）ケースも、その逆（レコードは再利用されたがクラスタは元のバイトを保持しており、カービングできる）ケースも見たことがあります。
どちらにも明確なタイマーはありません。「NTFS の削除ファイルはどれくらい残るか」への正直な答えは、「バーの空席がどれくらい残るか」と同じです。誰かがそれを取るまで、です。
ジャーナルが追加するもの
MFT は現在を見せます。USN journal は動詞を見せます。FILE_DELETE USN レコードは、ファイル名、親ディレクトリ、削除のタイムスタンプを示します。MFT スロットがその後再利用されていても、USN エントリは依然として古い名前と元のレコード/シーケンスのペアを保持しています。両者を組み合わせると次のようなものが得られます。
2026-04-12T13:08:11Z USN FILE_DELETE | CLOSE rec=44231 seq=7 path=\Users\bob\Documents\secrets.zip
2026-04-12T13:08:11Z MFT rec=44231 IN_USE=0 seq=7 (still readable, deleted)
2026-04-12T13:08:11Z MFT FN parent=12, name=secrets.zip
これは、ファイルがそれ以外なくなっていても、「このファイルが削除時にどんな姿だったか」への再構成可能な答えです。$LogFile は前後数秒のトランザクションレベルの詳細を追加します。削除は DeleteAttribute と DeallocateFileRecordSegment のペアで挟まれており、通常その周囲の操作を特定できます。
VSS が有効で削除前のスナップショットが存在する場合、スナップショットの $MFT は同じレコード/シーケンスに対して IN_USE=1 を示しており、データクラスタはコピーオンライトで保存されています。抽出の詳細については Volume Shadow Copy と $MFT を参照してください。
人々が間違える事例
セキュアな削除ツール。 SDelete はデフォルトモードでデータクラスタを上書きしますが、MFT レコードには何もしません。完全な $FILE_NAME、完全な $STANDARD_INFORMATION、そしてゼロ化されたクラスタを指す $DATA を持つ削除済みレコードが得られます。名前とタイムスタンプは完全に残ります。SDelete に対して期待する以上の徹底さがあると勘違いするユーザーが、ここでつまずきます。
ハードリンクを通じたファイル削除。 ハードリンクを 1 つ削除してもファイルは削除されません。そのリンクの $FILE_NAME 属性が削除され、ハードリンクカウントが減少します。ファイル自体は、最後のリンクが削除されたときにのみ削除されます。hardlink_count が 0 で $FILE_NAME が残っていない削除済み MFT レコードを見たら、ファイルは本当に削除されています。ハードリンクカウントがゼロでなく $FILE_NAME が欠落しているレコードを見たら、削除は部分的です。
削除前にリネームされたファイル。 一部のドロッパーは、削除直前にステージングファイルを無害な名前にリネームし、生き残った $FILE_NAME が無害に読めることを期待します。USN ジャーナルは RENAME_OLD_NAME と RENAME_NEW_NAME のペアを保持しているため、そこから元の名前を回復できます。MFT 単独では最終的な名前しか表示されません。
ごみ箱は削除ではない。 ごみ箱 に送られたファイルはリネームされ \$Recycle.Bin\<SID>\ に移動されます。MFT レコードは IN_USE=1 のままで、ファイルは $R<ID> という名前で無傷のままです。$I<ID> の伴侶ファイルが元のパスを記録します。その後ごみ箱を空にすると通常通り削除されます。
削除済みレコードを上手く読むツール
トリアージには次のいずれかを使います。
- MFTECmd に
--de 1（drop entries）を付けるか、フィルタなしの出力を下流でフィルタします。レジデントデータをタグ付けし、シーケンス番号を表示します。 omerbenamram/mft_dumpに-o json。シーケンス番号、レジデントフラグ、完全な属性リスト。IN_USE=0でかつseqが USN 参照と一致するレコードを抜き出すスクリプトに流すのに適しています。- Sleuth Kit の
fls -m -r。削除済みエントリを含む bodyfile を出力します。古典的ですが今でも使えます。icat -rはクラスタが無傷の非レジデントファイルのデータを回復します。 - analyzeMFT。純粋な Python の選択肢を特に望み、速度を気にしない場合。
このサイトの ブラウザパーサ は IN_USE=0 を 1 クリックでフィルタし、レジデントデータをインラインで表示します。ボリュームが重要で、ファイルが小さく、スロットが再利用されていない場合、テーブルでバイトが目の前にあることが多いです。
MFT 単独では答えられないこと
MFT は、レコードが存在しかつ削除されたことを教えてくれます。誰が削除したかは教えてくれません。それには、SACL が設定されていれば Security 4663（オブジェクトアクセス）、または Sysmon Event ID 23（FileDelete）が必要です。後者はユーザーとプロセスを記録します。ほとんどのホストではどちらも有効ではありません。その場合、補強する証拠に頼ります。削除ツールに対する Prefetch のヒット、ちょうどよい時刻に実行された見慣れないバイナリの Amcache エントリ、同じウィンドウからの recent file cache エントリなどです。
MFT は土台です。その上に残りの物語を組み立てます。
参考資料
- Brian Carrier, File System Forensic Analysis。NTFS の削除セマンティクスの章は依然として決定版です。
- Sleuth Kit の
flsドキュメント。削除済みエントリを含む標準的な bodyfile 出力について。 - Microsoft, Master File Table。NTFS が保証することと保証しないことの MS レベルの参考資料です。