$MFT est un fichier de métadonnées NTFS et n'occupe pas d'emplacement fixe : le secteur de démarrage du volume enregistre le cluster où il commence (le numéro de cluster de la MFT), et son runlist dans l'enregistrement 0 indique où se trouve le reste. Tant que le volume est monté, Windows ne le livre pas via les API de fichiers normales. xcopy échouera. Robocopy échouera. Le Copy-Item de PowerShell échouera aussi : l'ouverture est refusée (accès refusé ou fichier introuvable), vous n'obtenez donc aucune copie, pas même partielle. Vous avez besoin d'un outil qui lit le volume brut, contourne le système de fichiers et réassemble $MFT depuis ses cluster runs.

Il y a trois options auxquelles je fais confiance en pratique. Elles couvrent les cas de triage d'hôte vivant que je vois semaine après semaine.

Option 1 : KAPE, le défaut pour l'IR

Si vous faites de la réponse à incident et que vous êtes sur un hôte Windows, la réponse est KAPE avec la cible composée FileSystem plus la cible $MFTMirr. FileSystem tire $MFT, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS et le flux $T de $TxfLog en une passe ; $MFTMirr n'en fait pas partie, d'où la seconde cible. KAPE préserve les horodatages d'origine des fichiers collectés, et écrit une arborescence propre que vous pouvez emporter pour l'analyse.

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

Les apostrophes servent à PowerShell, où $MFTMirr sans guillemets est interprété comme une variable (vide). Depuis cmd.exe, retirez-les : --target FileSystem,$MFTMirr.

--vss est le flag que les gens oublient. Il dit à KAPE de tirer aussi $MFT (et le reste de la cible) de chaque Volume Shadow Copy de la source. Les snapshots plus anciens sont indépendamment utiles et vous devriez les collecter par défaut. Voir Volume Shadow Copy et $MFT pour quoi en faire.

KAPE gère le problème du fichier verrouillé avec son propre lecteur NTFS brut, sans passer par RawCopy.exe ni aucun autre outil. Le fichier collecté est bit pour bit identique à ce qu'une image forensique donnerait. Utilisez-le sauf raison spécifique de ne pas le faire.

Option 2 : FTK Imager, le repli GUI

FTK Imager reste l'outil GUI gratuit standard pour l'acquisition. C'est ce vers quoi vous vous tournez quand KAPE n'est pas sur l'hôte et que vous devez attraper $MFT une fois et partir. Le workflow :

File → Add Evidence Item → Physical Drive (utilisez Logical Drive seulement si vous travaillez depuis un partage distant ou une image montée).
Choisissez le disque et laissez-le énumérer les volumes.
Développez la racine du volume NTFS dans l'arborescence de gauche. $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, $Bitmap et le reste des fichiers de métadonnées y sont visibles même si Explorer les cache.
Clic droit sur $MFT → Export Files. Hashez-le (SHA-256) immédiatement.

FTK Imager lit le volume verrouillé en mappant le périphérique physique et en parsant NTFS lui-même. L'export est le vrai fichier on-disk, tableaux fixup et tout.

Le même workflow lit les images .dd, .E01 et .AFF4. Si vous avez une image hors ligne, montez-la comme preuve et utilisez le même chemin d'export.

Option 3 : fsutil et une lecture brute, quand vous ne pouvez rien installer

Sur un hôte durci où vous ne pouvez pas déposer KAPE ou FTK Imager, la commande intégrée fsutil vous dira où vit $MFT :

fsutil file queryextents C:\$Mft

La sortie est une liste de triplets (Virtual Cluster Number, Logical Cluster Number, longueur). Pour en faire un fichier, vous lisez le volume brut à chaque LCN et assemblez. PowerShell avec un P/Invoke vers CreateFile(\\.\C:, GENERIC_READ) fait le job ; les petits modules PowerShell de lecture brute sur GitHub aussi. RawCopy.exe de Joakim Schicht est le standalone le plus simple.

C'est une brique, pas une réponse finale. Utilisez-le quand la politique interdit de charger d'autres outils.

Ce que les gens ratent

Compter sur Copy-Item -Force. -Force ne change rien ici : les API de fichiers normales refusent toujours d'ouvrir $MFT. Utilisez l'une des options de lecture brute ci-dessus, puis contrôlez le résultat : la taille avec fsutil file queryextents, et les enregistrements comme décrit dans la vérification plus bas.

Oublier $MFTMirr et les journaux de transactions. $MFTMirr, ce sont seize enregistrements d'assurance. Les journaux de transactions ($LogFile, plus les fichiers $TxfLog par ressource sous $Extend\$RmMetadata) portent les opérations qui peuvent ne pas encore avoir atterri dans $MFT au moment de l'acquisition. Acquérez-les ensemble. KAPE le fait gratuitement.

Ne pas tirer le journal USN. $UsnJrnl:$J est essentiel pour la reconstruction de timeline (voir coupler le journal avec la table de fichiers). Il tourne, ce qui signifie qu'attendre deux jours pour revenir perd des preuves. Attrapez-le du premier coup. Si vous partez d'une image disque, les étapes pour extraire $UsnJrnl:$J de la même image suivent le même principe que l'export de $MFT.

Collecter depuis un système vivant sans VSS. La MFT vivante est cohérente au niveau du volume (NTFS est journalisé), mais si l'hôte est occupé, vous pouvez collecter une $MFT et un $UsnJrnl qui divergent de dizaines de secondes parce que la MFT a été lue en premier. Prenez un snapshot VSS, puis lisez les deux depuis le snapshot. Le snapshot les gèle.

Faire confiance au mauvais horodatage du fichier collecté. L'heure « modified » sur le $MFT exporté est ce que votre outil de collecte a positionné. Hashez les octets, écrivez le hash et l'heure d'acquisition dans un journal séparé, et référencez ce journal partout.

Une acquisition basée VSS que j'utilise vraiment

Quand je suis sur un hôte vivant et que je veux un $MFT propre à un instant donné plus le journal plus le log, voici le snippet :

vssadmin create shadow /for=C:

Lisez le Shadow Copy Volume Name dans la sortie (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN). N'y pointez pas robocopy ni copy : $MFT, $LogFile et $UsnJrnl:$J sont des fichiers de métadonnées NTFS, et les API de fichiers normales ne les livrent pas plus depuis un cliché instantané que depuis le volume vivant. Le snapshot fige les octets ; pour les extraire, il faut toujours un lecteur NTFS brut :

KAPE avec --vss (Option 1) lit chaque snapshot avec son propre parseur NTFS et collecte tout le jeu de cibles.
La lecture brute de l'Option 3 fonctionne aussi sur le snapshot : ouvrez le chemin de périphérique du cliché au lieu de \\.\C: et reconstituez $MFT à partir du runlist de l'enregistrement 0.
Hors ligne, faites une image du disque et exportez avec FTK Imager ou icat, comme dans la section suivante.

Hashez tout dès l'atterrissage, supprimez le snapshot s'il vous appartient (vssadmin delete shadows /shadow={GUID}), et partez.

La voie de la lecture brute ne demande rien au-delà de ce qui est livré dans Windows.

Lire depuis une image disque

Si vous avez déjà une image .dd ou .E01, vous évitez le verrouillage entièrement. Montez l'image en lecture seule (xmount, ewfmount, vshadowmount pour les images VSS-aware) ou utilisez un parser qui consomme les images directement. $MFT est toujours à la LCN MftStartLcn depuis le secteur de boot à l'offset 0 de la partition. icat -o <partition_offset> image.dd 0 du Sleuth Kit extrait le fichier. L'inode 0 est toujours $MFT.

Vérification avant l'analyse

Hashez le fichier (SHA-256) immédiatement après l'acquisition. Hashez-le à nouveau avant le parsing. Les non-correspondances arrivent plus souvent que les gens ne l'admettent, généralement à cause d'une pression disque en pleine acquisition ou d'outils de copie qui relancent des lectures partielles en silence.

Puis lancez un contrôle structurel. Parsez les dix premiers enregistrements, confirmez la signature FILE sur chacun, confirmez que l'enregistrement 0 est $MFT lui-même avec une runlist $DATA autoréférente, confirmez que l'enregistrement 1 est $MFTMirr, confirmez que l'enregistrement 5 est le répertoire racine avec un attribut $INDEX_ROOT. Si l'un d'eux échoue, l'acquisition est mauvaise et vous devez la refaire. MFTECmd et mft_dump lanceront tous les deux des avertissements sur un fichier corrompu ; ne les supprimez pas.

Lectures complémentaires

Eric Zimmerman, MFTECmd et KAPE. Le dépôt KapeFiles définit la cible composée FileSystem et les cibles par fichier ($MFT, $MFTMirr, $LogFile, $J...) et vaut la lecture pour comprendre ce qui est collecté.
Joakim Schicht, RawCopy. Un lecteur de volume brut autonome pour copier des fichiers NTFS verrouillés.
Microsoft, Volume Shadow Copy Service. Référence pour la sémantique de snapshot sur laquelle vous vous appuyez pour des acquisitions propres.

Extraire $MFT d'un hôte Windows vivant sans le casser