$MFT è un file di metadati NTFS e non si trova in una posizione fissa: il boot sector del volume registra il cluster in cui inizia (il numero di cluster della MFT), e il suo runlist nel record 0 dice dove si trova il resto. Finché il volume è montato, Windows non la restituisce tramite le normali API dei file. xcopy fallirà. Robocopy fallirà. Anche il Copy-Item di PowerShell fallirà: l'apertura viene rifiutata (accesso negato o file non trovato), quindi non ottieni nessuna copia, nemmeno parziale. Ti serve uno strumento che legga il volume grezzo, aggiri il filesystem e riassembli $MFT dai suoi cluster run.

Ci sono tre opzioni di cui mi fido nella pratica. Coprono i casi di triage su host vivo che vedo settimana dopo settimana.

Opzione 1: KAPE, il default per IR

Se fai incident response e sei su un host Windows, la risposta è KAPE con il target composto FileSystem più il target $MFTMirr. FileSystem estrae $MFT, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS e lo stream $T di $TxfLog in una sola passata; $MFTMirr non ne fa parte, da qui il secondo target. KAPE preserva i timestamp originali dei file raccolti e scrive una struttura di directory ordinata che puoi portare per l'analisi.

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

Gli apici singoli servono a PowerShell, dove $MFTMirr senza virgolette viene espanso come variabile (vuota). Da cmd.exe toglili: --target FileSystem,$MFTMirr.

--vss è il flag che la gente dimentica. Dice a KAPE di tirare anche $MFT (e il resto del target) da ogni Volume Shadow Copy sulla sorgente. Gli snapshot più vecchi sono utili in modo indipendente e dovresti raccoglierli per default. Vedi Volume Shadow Copy e $MFT per cosa farne.

KAPE gestisce il problema del file bloccato con un proprio lettore NTFS grezzo, senza ricorrere a RawCopy.exe o ad altri strumenti. Il file raccolto è bit-identico a ciò che produrrebbe un'immagine forense. Usalo a meno che non abbia una ragione specifica per non farlo.

Opzione 2: FTK Imager, il fallback GUI

FTK Imager resta lo strumento GUI gratuito standard per l'acquisizione. È quello a cui ricorri quando KAPE non è sull'host e devi afferrare $MFT una volta e andartene. Il flusso:

File → Add Evidence Item → Physical Drive (usa Logical Drive solo se lavori da una condivisione remota o da un'immagine montata).
Scegli il disco e lascia che enumeri i volumi.
Espandi la radice del volume NTFS nell'albero a sinistra. $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, $Bitmap e il resto dei file di metadati sono visibili lì anche se Explorer li nasconde.
Tasto destro su $MFT → Export Files. Fai subito l'hash (SHA-256).

FTK Imager legge il volume bloccato mappando il dispositivo fisico e parsando NTFS da sé. L'esportazione è il file effettivo on-disk, array di fixup e tutto.

Lo stesso flusso legge immagini .dd, .E01 e .AFF4. Se hai un'immagine offline, montala come prova e usa lo stesso percorso di esportazione.

Opzione 3: fsutil e una lettura grezza, quando non puoi installare nulla

Su un host indurito dove non puoi rilasciare KAPE o FTK Imager, il comando integrato fsutil ti dirà dove vive $MFT:

fsutil file queryextents C:\$Mft

L'output è una lista di triple (Virtual Cluster Number, Logical Cluster Number, lunghezza). Per trasformarla in un file leggi il volume grezzo a ogni LCN e assembli. PowerShell con un P/Invoke verso CreateFile(\\.\C:, GENERIC_READ) fa il lavoro; lo stesso fanno i piccoli moduli PowerShell di lettura grezza su GitHub. RawCopy.exe di Joakim Schicht è lo standalone più semplice.

È un mattoncino, non una risposta finale. Usalo quando la policy proibisce il caricamento di altri strumenti.

Cosa sbaglia la gente

Aspettarsi che Copy-Item -Force funzioni. -Force qui non cambia nulla: le normali API dei file continuano a rifiutarsi di aprire $MFT. Usa una delle opzioni di lettura grezza sopra, poi controlla il risultato: la dimensione rispetto a fsutil file queryextents e i record come descritto più sotto nella verifica.

Dimenticare $MFTMirr e i log delle transazioni. $MFTMirr è sedici record di assicurazione. I log delle transazioni ($LogFile, più i file $TxfLog per risorsa sotto $Extend\$RmMetadata) portano le operazioni che potrebbero non aver ancora raggiunto $MFT al momento dell'acquisizione. Acquisiscili insieme. KAPE lo fa gratis.

Non tirare il journal USN. $UsnJrnl:$J è essenziale per la ricostruzione della timeline (vedi accoppiare il journal con la tabella dei file). Ruota, il che significa che aspettare due giorni a tornare per prenderlo perde prove. Prendilo la prima volta. Se lavori da un'immagine disco, i passaggi per estrarre $UsnJrnl:$J dalla stessa immagine ricalcano l'esportazione di $MFT.

Raccogliere da un sistema vivo senza VSS. La MFT viva è coerente a livello di volume (NTFS è journaled), ma se l'host è occupato puoi raccogliere una $MFT e un $UsnJrnl che divergono di decine di secondi perché la MFT è stata letta prima. Prendi uno snapshot VSS, poi leggi entrambi dallo snapshot. Lo snapshot li congela.

Fidarsi del timestamp sbagliato sul file raccolto. L'orario "modified" sul $MFT esportato è quello che ha impostato il tuo strumento di raccolta. Fai l'hash dei byte, scrivi l'hash e l'orario di acquisizione in un log separato, e referenzia quel log ovunque.

Un'acquisizione basata su VSS che uso davvero

Quando sono su un host vivo e voglio una $MFT pulita a un istante preciso più journal più log, questo è lo snippet:

vssadmin create shadow /for=C:

Leggi il Shadow Copy Volume Name dall'output (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN). Non puntarci robocopy o copy: $MFT, $LogFile e $UsnJrnl:$J sono file di metadati NTFS, e le normali API dei file non li restituiscono da una shadow copy più di quanto facciano dal volume vivo. Lo snapshot congela i byte; per tirarli fuori ti serve comunque un lettore NTFS grezzo:

KAPE con --vss (Opzione 1) legge ogni snapshot con il proprio parser NTFS e raccoglie l'intero set di target.
La lettura grezza dell'Opzione 3 funziona anche sullo snapshot: apri il percorso di dispositivo della shadow copy invece di \\.\C: e ricomponi $MFT dal runlist del record 0.
Offline, crea un'immagine del disco ed esporta con FTK Imager o icat, come nella sezione successiva.

Fai l'hash di tutto appena atterra, elimina lo snapshot se ti appartiene (vssadmin delete shadows /shadow={GUID}) e vai.

La strada della lettura grezza non richiede nulla oltre a ciò che è incluso in Windows.

Leggere da un'immagine disco

Se hai già un'immagine .dd o .E01, salti completamente il locking. Monta l'immagine in sola lettura (xmount, ewfmount, vshadowmount per le immagini VSS-aware) o usa un parser che consuma immagini direttamente. $MFT si trova sempre alla LCN MftStartLcn dal settore di boot all'offset 0 della partizione. icat -o <partition_offset> image.dd 0 del Sleuth Kit estrae il file. L'inode 0 è sempre $MFT.

Verifica prima dell'analisi

Fai l'hash del file (SHA-256) immediatamente dopo l'acquisizione. Fallo di nuovo prima del parsing. Le mancate corrispondenze succedono più spesso di quanto la gente ammetta, di solito per pressione disco a metà acquisizione o strumenti di copia che riprovano silenziosamente letture parziali.

Poi esegui un controllo strutturale. Parsa i primi dieci record, conferma la firma FILE su ciascuno, conferma che il record 0 sia $MFT stesso con una runlist $DATA autoreferenziale, conferma che il record 1 sia $MFTMirr, conferma che il record 5 sia la directory radice con un attributo $INDEX_ROOT. Se uno qualsiasi di questi fallisce, l'acquisizione è cattiva e devi ripeterla. MFTECmd e mft_dump lanciano entrambi avvertimenti su un file corrotto; non sopprimerli.

Letture aggiuntive

Eric Zimmerman, MFTECmd e KAPE. Il repo KapeFiles definisce il target composto FileSystem e i target per singolo file ($MFT, $MFTMirr, $LogFile, $J...) e vale la lettura per capire cosa viene raccolto.
Joakim Schicht, RawCopy. Un raw volume reader standalone per copiare file NTFS bloccati.
Microsoft, Volume Shadow Copy Service. Riferimento per la semantica degli snapshot su cui ti basi per acquisizioni pulite.

Estrarre $MFT da un host Windows vivo senza romperlo