O $MFT é um ficheiro de metadados NTFS e não está numa posição fixa: o sector de arranque do volume regista o cluster onde começa (o número de cluster da MFT), e a sua runlist no registo 0 indica onde está o resto. Enquanto o volume estiver montado, o Windows não o entrega através das APIs de ficheiros normais. O xcopy falha. O Robocopy falha. O Copy-Item do PowerShell também falha: a abertura é recusada (acesso negado ou ficheiro não encontrado), por isso não obtém cópia nenhuma, nem sequer parcial. Precisa de uma ferramenta que leia o volume bruto, contorne o 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 composto FileSystem mais o target $MFTMirr. O FileSystem puxa $MFT, $LogFile, $UsnJrnl:$J, $Boot, $Secure:$SDS e o stream $T do $TxfLog numa só passagem; o $MFTMirr não faz parte dele, daí o segundo target. O KAPE 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 'FileSystem,$MFTMirr' --tdest C:\triage --vss
As plicas são para o PowerShell, onde um $MFTMirr sem aspas é expandido como uma variável (vazia). No cmd.exe, retire-as: --target FileSystem,$MFTMirr.
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 com o seu próprio leitor NTFS bruto, sem recorrer ao RawCopy.exe nem a outra ferramenta. 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,$Bitmape 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 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
Esperar que Copy-Item -Force funcione. -Force não muda nada aqui: as APIs de ficheiros normais continuam a recusar abrir o $MFT. Use uma das opções de leitura bruta acima e depois verifique o resultado: o tamanho contra fsutil file queryextents e os registos como descrito na verificação mais abaixo.
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. Se estiver a trabalhar a partir de uma imagem de disco, os passos para extrair o $UsnJrnl:$J da mesma imagem seguem a mesma lógica da exportação do $MFT.
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 (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN). Não aponte robocopy nem copy para esse caminho: $MFT, $LogFile e $UsnJrnl:$J são ficheiros de metadados NTFS, e as APIs de ficheiros normais não os entregam a partir de uma shadow copy, tal como não o fazem a partir do volume vivo. O snapshot congela os bytes; para os tirar continua a precisar de um leitor NTFS em bruto:
- KAPE com
--vss(Opção 1) lê cada snapshot com o seu próprio parser NTFS e recolhe todo o conjunto de targets. - A leitura bruta da Opção 3 também funciona contra o snapshot: abra o caminho de dispositivo da shadow copy em vez de
\\.\C:e monte o$MFTa partir do runlist do registo 0. - Offline, faça uma imagem do disco e exporte com o FTK Imager ou o
icat, como na secção seguinte.
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.
O caminho da leitura bruta não precisa de 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 composto
FileSysteme os targets por ficheiro ($MFT,$MFTMirr,$LogFile,$J...) e vale a pena ler para perceber o que é recolhido. - Joakim Schicht, RawCopy. Um leitor de volume bruto autónomo para copiar ficheiros NTFS bloqueados.
- Microsoft, Volume Shadow Copy Service. Referência para a semântica de snapshots em que confia para aquisições limpas.