O NTFS dá a um analista forense três grandes artefactos de metadados, e a maneira mais certa de perder um dia é ler o errado para a pergunta que efectivamente se tem. A versão curta:
| Artefacto | O que regista | Período | Granularidade | Onde vive |
|---|---|---|---|---|
$MFT | Estado actual de cada ficheiro e directório — nome, tamanho, timestamps, pai | «Neste momento» mais entradas recentemente eliminadas | Por ficheiro | Entrada MFT 0 |
$UsnJrnl:$J | Log circular de cada criação/eliminação/rename/modificação | Dias a semanas | Por operação | \$Extend\$UsnJrnl:$J (fluxo de dados alternativo) |
$LogFile | Log de transacções que o NTFS usa para recuperação após crash — imagens brutas before/after das escritas de metadados | Minutos a horas | Por transacção de metadados | \$LogFile (entrada MFT 2) |
Continue a ler para a árvore de decisão que de facto uso, e as razões pelas quais cada artefacto o vai deixar ficar mal sozinho.
$MFT — «o que existe, agora mesmo»
A Master File Table é a espinha dorsal do NTFS. Cada ficheiro ou directório tem pelo menos uma entrada de 1024 bytes que contém $STANDARD_INFORMATION, um ou mais atributos $FILE_NAME e os data runs que apontam para o conteúdo real.
Recorra a $MFT quando a pergunta for:
- O que existe neste volume agora mesmo, incluindo entradas recentemente eliminadas antes de serem reutilizadas.
- Quais são os quatro timestamps NTFS (M/A/C/B em
$STANDARD_INFORMATIONe$FILE_NAME) para um ficheiro específico. - Posso recuperar os bytes de um ficheiro eliminado cuja entrada ainda está alocada.
- Qual é o caminho completo de um registo que só carrega um número de referência do pai — é exactamente como o parser desta página resolve os registos USN quando se também larga o
$MFT.
O que não lhe vai dizer por mais que olhe:
- O que aconteceu a um ficheiro na terça-feira às 14:32. Os quatro timestamps são um estado final, não um histórico. Dizem-lhe quando o ficheiro foi criado e quando foi tocado pela última vez. Não dizem que foi renomeado, depois renomeado de volta, depois truncado, depois sobrescrito, depois eliminado, e que um novo ficheiro foi criado na mesma entrada MFT.
Ferramentas: o MFTECmd do Eric Zimmerman é o parser de facto. O crate Rust mft de Omer BenAmram e o script Python analyzeMFT de David Kovar cobrem o lado open-source.
$UsnJrnl:$J — «o que aconteceu, por que ordem»
O Update Sequence Number Journal regista cada criação, eliminação, mudança de nome, truncamento, alteração de atributo e fecho que acontece no volume. Para enquadramento, o artigo de introdução cobre o formato em disco e o artigo sobre códigos de razão é a referência ao nível do bit.
Recorra a ele quando a pergunta for:
- Qual foi o ciclo de vida deste ficheiro, incluindo renomeações, antes de ser eliminado.
- Houve alguma coisa que cifrou em massa ficheiros neste volume — ver detecção de ransomware.
- Houve alguma coisa que fez staging e arquivou ficheiros em massa para exfiltração — ver detecção de exfiltração.
- Os timestamps foram alterados — ver timestomping.
- O que o utilizador esteve a fazer entre as 14:00 e as 16:00 — ver reconstrução de timeline de actividade.
O que não lhe vai dizer:
- Quem fez qualquer coisa. Sem utilizador, sem processo, sem linha de comandos. Correlacione com o Security.evtx
4663(apenas se houve SACLs configurados) ou o evento 11 do Sysmon. - O conteúdo de qualquer ficheiro. O journal regista que um stream mudou, não que bytes lá costumavam estar.
- Qualquer coisa mais antiga do que a janela do buffer circular. As predefinições vão de ~10 MB num cliente despojado até 1 GB ou mais num servidor adequadamente dimensionado, traduzindo-se em dias ou semanas de histórico.
Ferramentas: o usnrs da Airbus CERT, o USN-Journal-Parser do PoorBillionaire, o MFTECmd do Eric Zimmerman (que parseia $J também), e o parser WebAssembly desta página.
$LogFile — «o que o NTFS estava prestes a fazer»
Este é o journal de metadados que o NTFS usa para recuperação após crash. Regista imagens before/after de cada escrita de metadados — actualizações de INDEX_ALLOCATION, alterações de atributos, reescritas de entradas MFT. O formato não está documentado mas está bem feito o reverse-engineering; o libfsntfs de Joachim Metz é a referência aberta mais completa.
Recorra a ele quando:
- Um ficheiro foi criado e eliminado dentro das mesmas milhares de transacções e a entrada do directório pai já foi sobrescrita.
$LogFilepode ainda conter a imagem «before» com o nome folha e o pai. - Suspeita de manipulação directa do
$MFT.$LogFileregista a escrita bruta mesmo quando o estado visível parece limpo depois. - O journal é demasiado esparso (pequeno ou recentemente rodado) para cobrir o momento de interesse, mas aconteceu dentro da última hora.
O que não lhe vai dar:
- Qualquer coisa fora da janela de rotação.
$LogFileé pequeno e muito reutilizado. Num file server ocupado o histórico de transacções inteiro pode dar a volta em menos de uma hora. - Conteúdo do ficheiro. As imagens before/after são só metadados.
Ferramentas: o LogFileParser de Jonas Schicht e qualquer parser construído sobre libfsntfs.
A árvore de decisão que de facto uso
Sabe QUAL ficheiro?
├── Sim → Quer estado actual? → $MFT (caminho, timestamps, tamanho)
│ Quer histórico? → $UsnJrnl primeiro, $LogFile para o passado muito recente
└── Não → Janela temporal?
├── Últimos minutos → $LogFile (mais granular)
├── Últimos dias/semanas → $UsnJrnl (melhor sinal/ruído)
└── Há muito tempo → Apenas $MFT, espere contentar-se com timestamps de estado final
Está a correlacionar muitos ficheiros ao mesmo tempo?
└── $UsnJrnl é o único dos três com uma timeline ordenável por operação.
O ficheiro foi eliminado e precisa de provar que existiu?
└── $UsnJrnl primeiro (o registo FileDelete carrega referência ao pai e timestamp)
$LogFile como rede de segurança se a eliminação for recente
$MFT apenas se a entrada ainda não tiver sido reutilizada
Combiná-los é onde o trabalho real acontece
Os três artefactos compõem-se bem, parte que ninguém realça até precisar.
$MFT + $UsnJrnl é o par canónico. O MFT fornece a árvore de directórios para resolução de caminhos; o journal fornece o histórico de operações. O parser desta página resolve automaticamente caminhos completos para cada registo do journal quando se larga ambos os ficheiros. Adquira-os juntos; vai poupar-se a uma ida e volta nove em cada dez vezes.
$LogFile é a rede de segurança. Quando o journal é demasiado pequeno para cobrir o momento de interesse, ou quando suspeita de manipulação directa do MFT, é a $LogFile que recorre.
Para contexto mais amplo, junte os três artefactos NTFS com EVTX (eventos de processo e objecto), Prefetch e AmCache (evidência de execução), Shimcache (programa correu nalgum momento), hives do registo, ficheiros LNK e jump lists para evidência de ficheiros abertos pelo utilizador, histórico de browser, SRUM para uso de recursos, e o RecentFileCache.
Leituras adicionais
- Microsoft Learn — Master File Table e Change Journals.
- Brian Carrier, File System Forensic Analysis — continua a ser a referência ao nível de livro sobre os internals do NTFS.
- Joachim Metz, documentação do
libfsntfs— a referência aberta mais detalhada sobre os internals do$LogFile. - SANS DFIR — o poster Windows Forensic Analysis é uma única página plastificada que põe a pilha de artefactos toda no mesmo sítio.