$MFT ist eine NTFS-Metadatei und liegt an keiner festen Stelle: Der Bootsektor des Volumes hält den Cluster fest, an dem sie beginnt (die MFT-Clusternummer), und ihre Runlist in Record 0 sagt, wo der Rest liegt. Solange das Volume gemountet ist, gibt Windows sie über die normalen Datei-APIs nicht heraus. xcopy wird fehlschlagen. Robocopy wird fehlschlagen. Auch PowerShells Copy-Item wird fehlschlagen: Das Öffnen wird verweigert (Zugriff verweigert oder Datei nicht gefunden), du bekommst also gar keine Kopie, keine halbe. Du brauchst ein Tool, das das rohe Volume liest, das Dateisystem umgeht und $MFT aus seinen Cluster-Runs zusammensetzt.

Es gibt drei Optionen, denen ich in der Praxis vertraue. Sie decken die Live-Host-Triage-Fälle ab, die ich Woche für Woche sehe.

Option 1: KAPE, der Standard für IR

Wenn du Incident Response machst und auf einem Windows-Host bist, lautet die Antwort KAPE mit dem Compound-Target FileSystem plus dem Target $MFTMirr. FileSystem zieht $MFT, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS und den $TxfLog-Stream $T in einem Durchgang; $MFTMirr gehört nicht dazu, daher das zweite Target. KAPE bewahrt die ursprünglichen Zeitstempel der gesammelten Dateien und schreibt einen ordentlichen Verzeichnisbaum, den du zur Analyse mitnehmen kannst.

kape.exe --tsource C: --target 'FileSystem,$MFTMirr' --tdest C:\triage --vss

Die einfachen Anführungszeichen sind für PowerShell, wo ein ungeschütztes $MFTMirr als (leere) Variable expandiert wird. In cmd.exe lässt du sie weg: --target FileSystem,$MFTMirr.

--vss ist das Flag, das Leute vergessen. Es sagt KAPE, dass es $MFT (und den Rest des Targets) auch aus jeder Volume Shadow Copy auf der Quelle ziehen soll. Ältere Snapshots sind unabhängig nützlich und du solltest sie standardmäßig sammeln. Siehe Volume Shadow Copy und $MFT, was damit zu tun ist.

KAPE behandelt das Problem gesperrter Dateien mit einem eigenen Raw-NTFS-Reader und braucht dafür weder RawCopy.exe noch ein anderes Hilfsprogramm. Die gesammelte Datei ist bit-identisch zu dem, was ein forensisches Image liefern würde. Verwende es, sofern du keinen spezifischen Grund hast, es nicht zu tun.

Option 2: FTK Imager, das GUI-Backup

FTK Imager bleibt das Standard-kostenlose GUI-Tool für die Akquise. Es ist das, wonach du greifst, wenn KAPE nicht auf dem Host ist und du $MFT einmal greifen und weggehen willst. Der Workflow:

File → Add Evidence Item → Physical Drive (verwende Logical Drive nur, wenn du von einer Remote-Freigabe oder einem gemounteten Image arbeitest).
Wähle die Platte und lass sie Volumes enumerieren.
Erweitere die Wurzel des NTFS-Volumes im Baum links. $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, $Bitmap und der Rest der Metadatendateien sind dort sichtbar, obwohl Explorer sie versteckt.
Rechtsklick auf $MFT → Export Files. Hashe es (SHA-256) sofort.

FTK Imager liest das gesperrte Volume, indem es das physische Gerät abbildet und NTFS selbst parst. Der Export ist die tatsächliche On-Disk-Datei, Fixup-Arrays und alles.

Derselbe Workflow liest .dd-, .E01- und .AFF4-Images. Wenn du ein Offline-Image hast, mounte es als Beweis und verwende denselben Export-Pfad.

Option 3: fsutil und ein roher Read, wenn du nichts installieren kannst

Auf einem gehärteten Host, auf dem du KAPE oder FTK Imager nicht ablegen kannst, sagt dir der eingebaute fsutil-Befehl, wo $MFT liegt:

fsutil file queryextents C:\$Mft

Die Ausgabe ist eine Liste von (Virtual Cluster Number, Logical Cluster Number, Länge)-Tripeln. Um daraus eine Datei zu machen, liest du das rohe Volume an jeder LCN und setzt zusammen. PowerShell mit einem P/Invoke in CreateFile(\\.\C:, GENERIC_READ) erledigt das; ebenso jedes der kleinen PowerShell-Raw-Read-Module auf GitHub. RawCopy.exe von Joakim Schicht ist das einfachste Standalone.

Das ist ein Baustein, keine endgültige Antwort. Verwende es, wenn die Richtlinie das Laden anderer Tools verbietet.

Was Leute falsch machen

Darauf hoffen, dass Copy-Item -Force funktioniert. -Force ändert hier nichts: Die normalen Datei-APIs verweigern das Öffnen von $MFT weiterhin. Nimm eine der Raw-Read-Optionen oben und prüfe dann das Ergebnis: die Größe gegen fsutil file queryextents und die Records wie unten unter Verifikation beschrieben.

$MFTMirr und die Transaktionsprotokolle vergessen. $MFTMirr sind sechzehn Datensätze Versicherung. Die Transaktionsprotokolle ($LogFile, plus die per-Ressource $TxfLog-Dateien unter $Extend\$RmMetadata) tragen die Operationen, die zum Zeitpunkt der Akquise möglicherweise noch nicht in $MFT gelandet sind. Erwirb sie zusammen. KAPE macht das kostenlos.

Das USN-Journal nicht ziehen. $UsnJrnl:$J ist essenziell für die Timeline-Rekonstruktion (siehe Journal mit der Dateitabelle koppeln). Es rotiert, was bedeutet, dass das Warten von zwei Tagen, um zurückzukommen, Beweise verliert. Schnapp es dir beim ersten Mal. Wenn Sie mit einem Disk-Image arbeiten, folgt das Extrahieren von $UsnJrnl:$J aus demselben Image denselben Schritten wie der $MFT-Export.

Sammeln aus einem Live-System ohne VSS. Die Live-MFT ist auf Volume-Ebene konsistent (NTFS ist journaled), aber wenn der Host beschäftigt ist, kannst du eine $MFT und ein $UsnJrnl sammeln, die um Zehntelsekunden voneinander abweichen, weil die MFT zuerst gelesen wurde. Nimm einen VSS-Snapshot und lies dann beide aus dem Snapshot. Der Snapshot friert sie ein.

Dem falschen Zeitstempel auf der gesammelten Datei vertrauen. Die "Modified"-Zeit auf der exportierten $MFT ist das, was dein Sammel-Tool gesetzt hat. Hashe die Bytes, schreibe den Hash und die Akquise-Zeit in ein separates Log und referenziere dieses Log überall.

Eine VSS-basierte Akquise, die ich tatsächlich verwende

Wenn ich auf einem Live-Host bin und eine saubere Punkt-in-Zeit-$MFT plus Journal plus Log will, ist dies das Snippet:

vssadmin create shadow /for=C:

Lies den Shadow Copy Volume Name aus der Ausgabe (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN). Richte kein robocopy oder copy darauf: $MFT, $LogFile und $UsnJrnl:$J sind NTFS-Metadateien, und die normalen Datei-APIs geben sie aus einer Schattenkopie genauso wenig heraus wie vom Live-Volume. Der Snapshot friert die Bytes ein; um sie herauszuholen, brauchst du trotzdem einen rohen NTFS-Reader:

KAPE mit --vss (Option 1) liest jeden Snapshot mit seinem eigenen NTFS-Parser und sammelt das komplette Target-Set.
Der rohe Read aus Option 3 funktioniert auch gegen den Snapshot: Öffne den Gerätepfad der Schattenkopie statt \\.\C: und setze $MFT aus der Runlist von Record 0 zusammen.
Offline erstellst du ein Image der Platte und exportierst mit FTK Imager oder icat, wie im nächsten Abschnitt.

Hashe alles, sobald es landet, lösche den Snapshot, wenn er dir gehört (vssadmin delete shadows /shadow={GUID}), und geh weg.

Der Weg über den rohen Read braucht nichts, was nicht in Windows enthalten ist.

Von einem Disk-Image lesen

Wenn du bereits ein .dd- oder .E01-Image hast, überspringst du das Sperren komplett. Mounte das Image read-only (xmount, ewfmount, vshadowmount für VSS-fähige Images) oder verwende einen Parser, der Images direkt konsumiert. $MFT liegt immer bei LCN MftStartLcn aus dem Bootsektor am Offset 0 der Partition. Sleuth Kits icat -o <partition_offset> image.dd 0 extrahiert die Datei. Inode 0 ist immer $MFT.

Verifikation vor der Analyse

Hashe die Datei (SHA-256) sofort nach der Akquise. Hashe sie erneut vor dem Parsen. Mismatches passieren häufiger, als die Leute zugeben, meist wegen Plattenstress während der Akquise oder Kopier-Tools, die still und leise teilweise Lesevorgänge wiederholen.

Dann führe eine strukturelle Prüfung durch. Parse die ersten zehn Datensätze, bestätige die FILE-Signatur auf jedem, bestätige, dass Datensatz 0 $MFT selbst mit einer selbstreferenzierenden $DATA-Runliste ist, bestätige, dass Datensatz 1 $MFTMirr ist, bestätige, dass Datensatz 5 das Wurzelverzeichnis mit einem $INDEX_ROOT-Attribut ist. Wenn etwas davon fehlschlägt, ist die Akquise schlecht und du musst sie wiederholen. MFTECmd und mft_dump werfen beide Warnungen bei einer korrumpierten Datei; unterdrücke sie nicht.

Weiterführende Literatur

Eric Zimmerman, MFTECmd und KAPE. Das KapeFiles-Repo definiert das Compound-Target FileSystem und die Einzel-Targets ($MFT, $MFTMirr, $LogFile, $J...) und ist es wert, gelesen zu werden, um zu verstehen, was gesammelt wird.
Joakim Schicht, RawCopy. Ein eigenständiger Raw-Volume-Reader zum Kopieren gesperrter NTFS-Dateien.
Microsoft, Volume Shadow Copy Service. Referenz für die Snapshot-Semantik, auf die du dich bei sauberen Akquisen verlässt.

$MFT von einem laufenden Windows-Host extrahieren, ohne es zu zerstören