O $MFT vive no início de todos os volumes NTFS e o Windows mantém um lock exclusivo sobre ele enquanto o volume estiver montado. O xcopy falha. O Robocopy falha. Um Copy-Item ingénuo do PowerShell falha ou, em certas configurações, produz silenciosamente uma cópia truncada que parece correcta em tamanho e está internamente partida. Precisa de uma ferramenta que leia o volume bruto, contorne o lock do sistema de ficheiros, e monte o $MFT a partir das suas runs de cluster.

Há três opções em que confio na prática. Cobrem os casos de triagem em host vivo com que me cruzo semana após semana.

Opção 1: KAPE, o padrão para IR

Se está a fazer resposta a incidentes e está num host Windows, a resposta é o KAPE com o target MFT. Puxa $MFT, $MFTMirr, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS, e um punhado de ficheiros relacionados numa só passagem, preserva os carimbos temporais originais nos ficheiros recolhidos, e escreve uma árvore de directórios arrumada que pode levar para análise.

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

O --vss é a flag que as pessoas esquecem. Diz ao KAPE para puxar $MFT (e o resto do target) de todas as Volume Shadow Copies da origem. Os snapshots mais antigos são úteis por si só e deve recolhê-los por hábito. Veja Volume Shadow Copy e $MFT para saber o que fazer com eles.

O KAPE lida com o problema do ficheiro bloqueado usando o leitor de volume bruto do RawCopy.exe por baixo. O ficheiro recolhido é idêntico bit a bit ao que uma imagem forense produziria. Use-o a menos que tenha um motivo específico para não o fazer.

Opção 2: FTK Imager, o fallback gráfico

O FTK Imager continua a ser a ferramenta gratuita gráfica padrão para aquisição. É a que se usa quando o KAPE não está no host e precisa de agarrar o $MFT uma única vez e ir-se embora. O fluxo:

File → Add Evidence Item → Physical Drive (use Logical Drive só se estiver a trabalhar a partir de uma partilha remota ou de uma imagem montada).
Escolha o disco e deixe-o enumerar os volumes.
Expanda a raiz do volume NTFS na árvore à esquerda. $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef, $Bitmap e o resto dos ficheiros de metadados aparecem ali, mesmo que o Explorador os esconda.
Botão direito em $MFT → Export Files. Faça-lhe hash (SHA-256) imediatamente.

O FTK Imager lê o volume bloqueado mapeando o dispositivo físico e analisando o NTFS ele próprio. A exportação é o ficheiro real em disco, com fixup arrays e tudo.

O mesmo fluxo lê imagens .dd, .E01 e .AFF4. Se tiver uma imagem offline, monte-a como evidência e use o mesmo caminho de exportação.

Opção 3: fsutil e leitura bruta, quando não pode instalar nada

Num host endurecido onde não pode largar o KAPE ou o FTK Imager, o comando interno fsutil diz-lhe onde vive o $MFT:

fsutil file queryextents C:\$Mft

A saída é uma lista de triplos (Virtual Cluster Number, Logical Cluster Number, length). Para a transformar num ficheiro, lê o volume bruto em cada LCN e monta-o. PowerShell com um P/Invoke para CreateFile(\\.\C:, GENERIC_READ) faz o serviço; também faz qualquer um dos pequenos módulos de leitura bruta em PowerShell no GitHub. O RawCopy.exe de Joakim Schicht (o mesmo código que o KAPE usa por baixo) é o standalone mais simples.

Isto é um bloco de construção, não uma resposta final. Use-o quando a política proibir carregar outras ferramentas.

O que as pessoas erram

Copiar com Copy-Item -Force. Por vezes corre bem e fica com um ficheiro. Esse ficheiro é o que o Windows devolveu a uma chamada ReadFile normal contra o handle aberto, que na maioria das builds não é o verdadeiro $MFT. Verifique sempre com fsutil file queryextents que o tamanho corresponde.

Esquecer $MFTMirr e os logs de transacções. O $MFTMirr são dezasseis registos de seguro. Os logs de transacções ($LogFile, mais os ficheiros $TxfLog por recurso, sob $Extend\$RmMetadata) carregam as operações que podem não ter chegado ao $MFT no momento da aquisição. Adquira-os em conjunto. O KAPE faz isto de graça.

Não puxar o USN journal. O $UsnJrnl:$J é essencial para a reconstrução de timeline (veja emparelhar o journal com a file table). Roda, o que significa que esperar dois dias para o ir buscar perde evidência. Agarre-o à primeira.

Recolher de um sistema vivo sem VSS. O MFT vivo é consistente ao nível do volume (o NTFS é journalled), mas se o host estiver ocupado pode recolher um $MFT e um $UsnJrnl que discordam em dezenas de segundos porque o MFT foi lido primeiro. Tire um snapshot VSS, e depois leia ambos a partir do snapshot. O snapshot congela-os.

Confiar no carimbo temporal errado no ficheiro recolhido. O tempo "modified" no $MFT exportado é o que a sua ferramenta de recolha definiu. Faça hash aos bytes, escreva o hash e o tempo de aquisição num log separado, e referencie esse log em todo o lado.

Uma aquisição baseada em VSS que uso na prática

Quando estou num host vivo e quero um $MFT mais journal mais log num ponto no tempo limpo, este é o snippet:

vssadmin create shadow /for=C:

Leia o Shadow Copy Volume Name na saída, e depois use esse caminho como origem para a ferramenta que preferir:

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

O Robocopy consegue ler de um caminho de dispositivo VSS porque o snapshot é montado como um volume separado sem o lock exclusivo vivo. Faça hash a tudo assim que aterrar, apague o snapshot se for seu para apagar (vssadmin delete shadows /shadow={GUID}), e siga em frente.

Esta é a aquisição em vivo mais limpa que conheço sem instalar nada além do que vem com o Windows.

Ler a partir de uma imagem de disco

Se já tem uma imagem .dd ou .E01, salta inteiramente o bloqueio. Monte a imagem em só leitura (xmount, ewfmount, vshadowmount para imagens com VSS) ou use um parser que consome imagens directamente. O $MFT está sempre no LCN MftStartLcn a partir do boot sector no offset 0 da partição. O icat -o <partition_offset> image.dd 0 do Sleuth Kit extrai o ficheiro. O inode 0 é sempre o $MFT.

Verificação antes da análise

Faça hash ao ficheiro (SHA-256) imediatamente após a aquisição. Volte a fazer hash antes de o analisar. As discrepâncias acontecem mais do que as pessoas admitem, geralmente por causa de pressão de disco a meio da aquisição ou de ferramentas de cópia que retentam leituras parciais em silêncio.

Depois corra uma verificação estrutural. Analise os primeiros dez registos, confirme a assinatura FILE em cada um, confirme que o registo 0 é o próprio $MFT com uma runlist $DATA auto-referente, confirme que o registo 1 é $MFTMirr, confirme que o registo 5 é o directório raiz com um atributo $INDEX_ROOT. Se alguma destas falhar, a aquisição está má e tem de a repetir. Tanto o MFTECmd como o mft_dump lançam avisos num ficheiro corrompido; não os silencie.

Leituras adicionais

Eric Zimmerman, MFTECmd e KAPE. O repositório KapeFiles define o target MFT canónico e vale a pena ler para perceber o que é recolhido.
Joakim Schicht, RawCopy. O leitor de volume bruto por baixo da maior parte das ferramentas de aquisição de MFT em vivo.
Microsoft, Volume Shadow Copy Service. Referência para a semântica de snapshots em que confia para aquisições limpas.

Extrair o $MFT de um host Windows vivo sem o partir