$MFT は NTFS のメタデータファイルで、固定の位置にあるわけではありません。ボリュームのブートセクタが開始クラスタ（MFT クラスタ番号）を記録し、レコード 0 の runlist が残りの位置を示します。ボリュームがマウントされている間、Windows は通常のファイル API ではこれを渡しません。xcopy は失敗します。Robocopy も失敗します。PowerShell の Copy-Item も失敗します。オープン自体が拒否される（アクセス拒否、またはファイルが見つからない）ため、部分的なコピーすら得られず、何もコピーされません。生のボリュームを読み取り、ファイルシステムを迂回し、$MFT をクラスタランから組み立てるツールが必要です。
実務上、私が信頼するオプションは 3 つあります。毎週見るライブホストのトリアージケースをカバーしています。
選択肢 1: KAPE、IR でのデフォルト
インシデントレスポンスを実施していて Windows ホスト上にいるなら、答えは複合ターゲット FileSystem と $MFTMirr ターゲットを使った KAPE です。FileSystem は $MFT、$LogFile、$UsnJrnl:$J、$Boot、$Secure:$SDS、$TxfLog の $T ストリームを一度のパスで取得します。$MFTMirr は含まれないため、2 つ目のターゲットとして指定します。KAPE は収集されたファイルの元のタイムスタンプを保持し、分析に持ち運べるきれいなディレクトリツリーを書き出します。
kape.exe --tsource C: --target 'FileSystem,$MFTMirr' --tdest C:\triage --vss
シングルクォートは PowerShell 用です。PowerShell ではクォートしない $MFTMirr が（空の）変数として展開されてしまいます。cmd.exe から実行する場合はクォートを外してください：--target FileSystem,$MFTMirr。
--vss は人が忘れがちなフラグです。これは、ソース上のあらゆる Volume Shadow Copy からも $MFT（およびターゲットの残り）を取得するよう KAPE に指示します。古いスナップショットはそれ自体で有用で、習慣として収集すべきです。それらをどう扱うかは Volume Shadow Copy と $MFT を参照してください。
KAPE はロックされたファイルの問題に対し、独自の生 NTFS リーダーで対処します。RawCopy.exe などの外部ツールは使いません。収集されたファイルは、フォレンジックイメージから得られるものとビット同一です。特別な理由がない限り、これを使ってください。
選択肢 2: FTK Imager、GUI のフォールバック
FTK Imager は依然として取得用の標準的な無料 GUI ツールです。KAPE がホストにない状況で、$MFT を一度だけ取得して終わりにしたいときに手を伸ばすものです。ワークフロー。
File→Add Evidence Item→Physical Drive（リモート共有やマウントされたイメージで作業しているのでなければ Logical Drive は使わないでください）。- ディスクを選択して、ボリュームを列挙させます。
- 左側のツリーで NTFS ボリュームのルートを展開します。
$MFT、$MFTMirr、$LogFile、$Volume、$AttrDef、$Bitmapほかメタデータファイルは、エクスプローラが隠していてもそこに表示されます。 $MFTを右クリック →Export Files。直ちに（SHA-256 で）ハッシュ化します。
FTK Imager は物理デバイスをマッピングし NTFS を自前で解析することでロックされたボリュームを読み取ります。エクスポートはディスク上の実際のファイルで、fixup 配列もそのままです。
同じワークフローは .dd、.E01、.AFF4 イメージを読み取れます。オフラインイメージがあるなら、それを証拠としてマウントし、同じエクスポート経路を使ってください。
選択肢 3: 何もインストールできないときの fsutil と raw read
KAPE や FTK Imager を投入できない硬化されたホスト上では、組み込みの fsutil コマンドが $MFT の所在を教えてくれます。
fsutil file queryextents C:\$Mft
出力は（Virtual Cluster Number、Logical Cluster Number、length）の三つ組のリストです。これをファイルに変換するには、各 LCN で生のボリュームを読み取り組み立てます。CreateFile(\\.\C:, GENERIC_READ) への P/Invoke を持つ PowerShell で実現できます。GitHub にある小さな PowerShell 生読み取りモジュールでも同様です。Joakim Schicht の RawCopy.exe が最もシンプルなスタンドアロンです。
これは構成要素であり、最終的な答えではありません。他のツールの導入をポリシーが禁止している場合に使ってください。
人が間違える点
Copy-Item -Force で動くと期待する。 -Force を付けても何も変わりません。通常のファイル API は引き続き $MFT のオープンを拒否します。上記の raw read のいずれかを使い、その結果を確認してください。サイズは fsutil file queryextents と照合し、レコードは後述の検証の手順で確認します。
$MFTMirr とトランザクションログを忘れる。 $MFTMirr は 16 レコードの保険です。トランザクションログ（$LogFile、および $Extend\$RmMetadata 配下のリソースごとの $TxfLog ファイル）は、取得の瞬間にまだ $MFT に到達していない可能性のある操作を保持しています。一緒に取得してください。KAPE は無料でこれをやってくれます。
USN ジャーナルを取得しない。 $UsnJrnl:$J はタイムライン再構築に必須です（ジャーナルとファイルテーブルの組み合わせ を参照）。それはローテーションするので、2 日待って取りに戻ると証拠を失います。最初の機会に取得してください。ディスクイメージから作業する場合、同じイメージから $UsnJrnl:$J を取り出す手順は $MFT のエクスポートと同じ流れです。
VSS なしでライブシステムから収集する。 ライブの MFT はボリュームレベルでは整合しています（NTFS はジャーナル付き）が、ホストが忙しい場合、MFT が先に読まれたために $MFT と $UsnJrnl が数十秒の差で食い違うことがあります。VSS スナップショットを取り、その両方をスナップショットから読み取ってください。スナップショットがそれらを凍結します。
収集されたファイルの間違ったタイムスタンプを信用する。 エクスポートされた $MFT の「modified」時刻は、収集ツールが設定したものです。バイトをハッシュ化し、別のログにハッシュと取得時刻を記録し、どこでもそのログを参照してください。
私が実際に使っている VSS ベースの取得
ライブホスト上で、きれいな時点の $MFT とジャーナルとログを取得したいときに使うスニペットです。
vssadmin create shadow /for=C:
出力から Shadow Copy Volume Name（\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN）を読み取ります。ここに robocopy や copy を向けてはいけません。$MFT、$LogFile、$UsnJrnl:$J は NTFS のメタデータファイルであり、通常のファイル API はライブボリュームと同様にシャドウコピーからもそれらを渡してくれません。スナップショットはバイトを凍結するだけで、取り出すには依然として raw NTFS リーダーが必要です。
- KAPE に
--vssを付ける（選択肢 1）と、各スナップショットを独自の NTFS パーサーで読み、ターゲット一式を収集します。 - 選択肢 3 の raw read はスナップショットにも使えます。
\\.\C:の代わりにシャドウコピーのデバイスパスを開き、レコード 0 の runlist から$MFTを組み立てます。 - オフラインで作業するなら、ディスクをイメージ化し、次のセクションのように FTK Imager か
icatでエクスポートします。
すべてが届いたらハッシュ化し、自分が削除すべきスナップショットなら削除して（vssadmin delete shadows /shadow={GUID}）撤収します。
raw read の方法なら、Windows に付属する以上のものは何も必要ありません。
ディスクイメージから読み取る
すでに .dd または .E01 イメージを持っているなら、ロックを完全に回避できます。イメージを読み取り専用でマウントするか（xmount、ewfmount、VSS 対応イメージには vshadowmount）、イメージを直接消費するパーサを使用します。$MFT は常にパーティションのオフセット 0 のブートセクタから LCN MftStartLcn に位置します。Sleuth Kit の icat -o <partition_offset> image.dd 0 がファイルを抽出します。Inode 0 は常に $MFT です。
分析前の検証
取得直後にファイルを（SHA-256 で）ハッシュ化します。解析前に再度ハッシュ化します。人が認めるよりも頻繁にミスマッチが発生します。通常は取得中のディスク負荷や、部分的な読み取りを暗黙のうちに再試行するコピーツールが原因です。
次に構造チェックを実行します。最初の 10 レコードを解析し、各レコードで FILE シグネチャを確認し、レコード 0 が自己参照する $DATA ランリストを持つ $MFT 自身であることを確認し、レコード 1 が $MFTMirr であることを確認し、レコード 5 が $INDEX_ROOT 属性を持つルートディレクトリであることを確認します。いずれかが失敗した場合、取得は不良であり、やり直す必要があります。MFTECmd と mft_dump はどちらも壊れたファイルに対して警告を投げます。それらを抑制しないでください。
参考資料
- Eric Zimmerman, MFTECmd and KAPE。KapeFiles リポジトリは複合ターゲット
FileSystemと個別ターゲット（$MFT、$MFTMirr、$LogFile、$Jなど）を定義しており、何が収集されるかを理解するために読む価値があります。 - Joakim Schicht, RawCopy。ロックされた NTFS ファイルをコピーするためのスタンドアロンの生ボリュームリーダーです。
- Microsoft, Volume Shadow Copy Service。クリーンな取得のために頼るスナップショットセマンティクスのリファレンスです。