$MFT vit au début de chaque volume NTFS et Windows maintient un verrou exclusif dessus tant que le volume est monté. xcopy échouera. Robocopy échouera. Un Copy-Item PowerShell naïf échouera ou, sur certaines configurations, produira silencieusement une copie tronquée qui a l'air correcte en taille et est cassée à l'intérieur. Vous avez besoin d'un outil qui lit le volume brut, contourne le verrou du 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 MFT. Il tire $MFT, $MFTMirr, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS et une poignée de fichiers liés en une passe, 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 MFT --tdest C:\triage --vss
--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é en utilisant le lecteur de volume brut de RawCopy.exe sous le capot. 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,$Bitmapet 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 (le même code que KAPE utilise sous le capot) 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
Copier avec Copy-Item -Force. Parfois ça réussit et vous obtenez un fichier. Ce fichier est ce que Windows a renvoyé d'un appel ReadFile normal contre le handle ouvert, ce qui sur la plupart des builds n'est pas la vraie $MFT. Vérifiez toujours avec fsutil file queryextents que la taille correspond.
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.
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, puis utilisez ce chemin comme source pour l'outil que vous préférez :
robocopy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN" "D:\triage" "$MFT" "$MFTMirr" "$LogFile" "$Extend\$UsnJrnl:$J" /R:1 /W:1
Robocopy peut lire depuis un chemin de périphérique VSS parce que le snapshot est monté comme un volume séparé sans le verrou exclusif vivant. Hashez tout dès l'atterrissage, supprimez le snapshot s'il vous appartient (vssadmin delete shadows /shadow={GUID}), et partez.
C'est l'acquisition vivante la plus propre que je connaisse sans rien installer 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
MFTcanonique et vaut la lecture pour comprendre ce qui est collecté. - Joakim Schicht, RawCopy. Le lecteur de volume brut sous la plupart des outils d'acquisition MFT vivante.
- Microsoft, Volume Shadow Copy Service. Référence pour la sémantique de snapshot sur laquelle vous vous appuyez pour des acquisitions propres.