$MFT liegt am Anfang jedes NTFS-Volumes und Windows hält eine exklusive Sperre darauf, solange das Volume gemountet ist. xcopy wird fehlschlagen. Robocopy wird fehlschlagen. Ein naives PowerShell Copy-Item wird fehlschlagen oder, bei bestimmten Konfigurationen, still und leise eine abgeschnittene Kopie produzieren, die größenmäßig korrekt aussieht und intern kaputt ist. Du brauchst ein Tool, das das rohe Volume liest, die Dateisystemsperre 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 MFT-Target. Es zieht $MFT, $MFTMirr, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS und eine Handvoll verwandter Dateien in einem Durchgang, bewahrt die ursprünglichen Zeitstempel der gesammelten Dateien und schreibt einen ordentlichen Verzeichnisbaum, den du zur Analyse mitnehmen kannst.

kape.exe --tsource C: --target MFT --tdest C:\triage --vss

--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, indem es den Raw-Volume-Reader von RawCopy.exe unter der Haube verwendet. 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 (derselbe Code, den KAPE unter der Haube verwendet) 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

Kopieren mit Copy-Item -Force. Manchmal gelingt es und du bekommst eine Datei. Diese Datei ist das, was Windows aus einem normalen ReadFile-Aufruf gegen das offene Handle zurückgegeben hat, was auf den meisten Builds nicht die echte $MFT ist. Verifiziere immer mit fsutil file queryextents, dass die Größe übereinstimmt.

$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.

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 und verwende diesen Pfad dann als Quelle für das Tool, das du bevorzugst:

robocopy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN" "D:\triage" "$MFT" "$MFTMirr" "$LogFile" "$Extend\$UsnJrnl:$J" /R:1 /W:1

Robocopy kann von einem VSS-Gerätepfad lesen, weil der Snapshot als separates Volume ohne die exklusive Live-Sperre gemountet ist. Hashe alles, sobald es landet, lösche den Snapshot, wenn er dir gehört (vssadmin delete shadows /shadow={GUID}), und geh weg.

Das ist die sauberste Live-Akquise, die ich kenne, die nichts erfordert, 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 kanonische MFT-Target und ist es wert, gelesen zu werden, um zu verstehen, was gesammelt wird.
Joakim Schicht, RawCopy. Der Raw-Volume-Reader unter den meisten Live-MFT-Akquise-Tools.
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