← Voltar ao blog

Journal USN vs $MFT vs $LogFile: qual artefato NTFS para qual pergunta?

Referência comparativa dos três artefatos de metadados NTFS que toda investigação forense de Windows acaba tocando — o que cada um registra, o que não registra, e quando recorrer a qual.

4 min de leitura

O NTFS oferece ao analista forense três grandes fontes de metadados, e a maneira mais rápida de perder um dia é olhar a errada. Mapa rápido:

ArtefatoO que registraJanela temporalGranularidadeLocalização
$MFTO estado atual de cada arquivo e diretório do volume — nomes, tamanhos, timestamps, pai"Agora" mais entradas excluídas até serem reutilizadasPor arquivoEntrada MFT 0
$UsnJrnl:$JLog circular de cada criação/exclusão/renomeação/modificaçãoDias a semanasPor operação\$Extend\$UsnJrnl:$J (fluxo alternativo)
$LogFileLog transacional usado pelo NTFS para recuperação após crash — imagens antes/depois de gravações de metadadosMinutos a horasPor transação de metadados\$LogFile (entrada MFT 2)

Este artigo dá a árvore de decisão prática: dada uma pergunta, qual artefato responde.

$MFT — "o que existe, agora mesmo"

A Master File Table é a espinha dorsal do NTFS. Cada arquivo ou diretório tem uma entrada (tipicamente 1024 bytes), contendo $STANDARD_INFORMATION, um ou mais $FILE_NAME e os data runs. A Microsoft documenta a estrutura na referência do NTFS e File System Forensic Analysis do Brian Carrier é o tratamento canônico em formato livro.

Use para:

  • "O que tem neste volume?" — incluindo timestamps por entrada.
  • Reconstituir caminhos completos pela cadeia de entradas MFT pais (é assim que o nosso parser resolve caminhos dos registros do journal quando você também fornece $MFT).
  • Recuperar arquivos recentemente excluídos — enquanto a entrada não foi sobrescrita, os data runs podem estar intactos.

Não vai te dizer:

  • O que aconteceu com um arquivo terça às 14:32 — $MFT só carrega os quatro timestamps de $STANDARD_INFORMATION e $FILE_NAME, que são um estado final, não um histórico.

Ferramentas: MFTECmd do Eric Zimmerman é o parser de fato, com mft (Rust) e analyzeMFT (Python) como alternativas sólidas em open source.

$UsnJrnl:$J — "o que aconteceu, em que ordem"

O journal Update Sequence Number registra cada criação, exclusão, renomeação, truncamento, alteração de atributo e fechamento que ocorre no volume. Para o contexto, veja a nossa introdução ao formato e a referência dos códigos de razão.

Use para:

  • Reconstituir o ciclo de vida de um arquivo mesmo após exclusão.
  • Reconstrução de linhas do tempo em resposta a incidentes, especialmente pares RenameOldName/RenameNewName e clusters de DataOverwrite.
  • Detectar padrões de ransomware em escala (ver nosso artigo dedicado).

Não vai te dizer:

  • Quem fez o quê — sem usuário, processo ou linha de comando. Casar com Security.evtx (event ID 4663) ou com Sysmon.
  • O conteúdo de nenhum arquivo — apenas que ele mudou.
  • Nada fora da janela do ring buffer. Tamanhos padrão vão de ~10 MB num cliente a 1 GB+ num servidor, o que se traduz em dias/semanas de histórico.

Ferramentas: usnrs, PoorBillionaire/USN-Journal-Parser, o parser deste site.

$LogFile — "o que o NTFS ia fazer"

É o journal de metadados que o NTFS usa para recuperação após crash. Registra imagens antes/depois de cada gravação de metadados — atualizações de INDEX_ALLOCATION, alterações de atributos, regravações de entradas MFT. O formato não é documentado mas está bem reengenheirado; o repo libfsntfs do Joachim Metz é a referência aberta mais completa.

Use para:

  • Recuperar arquivos criados e excluídos dentro dos mesmos minutos$LogFile pode ainda ter a imagem "antes" da exclusão, que contém o nome e o pai.
  • Detectar atividade anti-forense que tocou $MFT diretamente — $LogFile registra a gravação mesmo que o estado visível pareça limpo.

Não vai te dizer:

  • Nada além das últimas milhares de transações — $LogFile gira rápido, às vezes em menos de uma hora numa máquina ativa.
  • O conteúdo dos arquivos. Só mudanças de metadados são registradas.

Ferramentas: LogFileParser e os parsers construídos sobre libfsntfs.

A árvore de decisão

Você sabe qual arquivo?
├── Sim → Estado atual? → $MFT (caminho, timestamps, tamanho)
│        Histórico?     → $UsnJrnl (depois $LogFile para o muito recente)
└── Não → Janela temporal?
          ├── Últimos minutos     → $LogFile (a mais granular)
          ├── Últimos dias/semanas → $UsnJrnl (melhor relação sinal/ruído)
          └── Há mais tempo       → só $MFT (talvez só restem timestamps)

Está correlacionando entre arquivos?
└── $UsnJrnl é o único com linha do tempo ordenável, por operação.

Combiná-los

Os três artefatos compõem bem:

  1. $MFT + $UsnJrnl é o par canônico — $MFT fornece a árvore de diretórios para resolução de caminhos, $UsnJrnl fornece o histórico de operações. É exatamente o que o parser desta página faz quando você solta os dois arquivos.
  2. $LogFile é uma rede de proteção para o passado bem recente, particularmente útil quando $UsnJrnl é muito esparso (pequeno ou desativado).
  3. Para um contexto mais amplo, adicione Security.evtx (eventos processo/objeto), Prefetch (evidência de execução) e os hives do registro — veja o poster SANS Windows Forensic Analysis para a visão geral.