Da primeira vez que construí uma timeline de Windows a partir do $MFT, emiti oito linhas por registo, ordenei por carimbo temporal, abri-as no Excel e senti que tinha reconstruído a realidade. Não tinha. Tinha um log ordenado de alterações de metadados NTFS. Isso é uma coisa útil. Não é, por si só, uma investigação.
Este post é o que gostava que alguém me tivesse dito sobre timelines do MFT antes de entregar o meu primeiro relatório.
O que é, de facto, uma timeline do MFT
Cada registo activo e eliminado do MFT transporta oito carimbos temporais que se podem extrair de forma fiável: quatro em $STANDARD_INFORMATION (SI) e quatro em $FILE_NAME (FN). Created, modified, accessed e MFT-modified, em ambos os atributos. Percorra a tabela, emita uma linha por carimbo temporal não nulo, ordene por tempo, e tem uma timeline de quando o NTFS escreveu bytes concretos de registos concretos. Esse é o piso.
O tecto é uma supertimeline que funde o MFT com o USN journal, o $LogFile, o Prefetch, o Sysmon, o Shimcache, o Amcache, as hives do registo, o histórico de browser e o SRUM. O MFT é a espinha dorsal porque é o mais denso e o mais difícil de um atacante falsificar por completo. Tudo o resto fica alinhado contra ele.
A disposição que efectivamente uso
Esqueça o mactime como formato de destino. Use-o como intermediário. A forma que se aguenta em tribunal é uma linha por evento com proveniência defensável:
timestamp_utc | source | attribute | mft_record | seq | path | event
2026-05-15T10:23:01.123Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | created
2026-05-15T10:23:01.123Z | MFT | FN | 12345 | 3 | /Users/alice/notes.txt | name_created
2026-05-15T10:24:18.456Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | modified
2026-05-15T10:24:18.501Z | USN | - | 12345 | 3 | /Users/alice/notes.txt | DATA_OVERWRITE | CLOSE
O source e o par registo/sequência são as colunas que os analistas saltam e depois se arrependem de ter saltado. O número de sequência é o que lhe diz se dois eventos que partilham um número de registo se referem à mesma encarnação de um ficheiro ou a um predecessor eliminado cujo slot foi reutilizado. Sem ele, a sua timeline confunde-os silenciosamente.
A saída CSV do MFTECmd é a disposição pronta a usar mais próxima desta. Passe as suas linhas por um script fino que adicione source=MFT e emita uma linha por carimbo temporal, e tem um corpus de trabalho.
Os carimbos temporais pela ordem de quanto mentem
O SI move-se em essencialmente todas as operações que o Windows faz a um ficheiro. As leituras actualizam accessed se o NTFS quiser (o Windows 7+ por omissão não actualiza accessed por questões de desempenho, a menos que fsutil behavior set disablelastaccess 0 esteja definido). As escritas actualizam modified e MFT-modified. Os renames actualizam MFT-modified. O timestomping com SetFileTime actualiza aqueles dos quatro a que o atacante apontou.
O FN é actualizado em rename, criação de hard link, e na criação inicial do ficheiro. Depois disso, o FN fica praticamente quieto. A granularidade das actualizações ao FN pelo Windows também é mais grosseira; muitos ficheiros terminam em .0000000 legitimamente se o FN tiver sido definido na criação e nunca mais tocado.
Na prática:
- FN created é o sinal mais fiável de "este ficheiro apareceu pela primeira vez neste directório" que se obtém só a partir do MFT.
- SI created é o mais fácil de forjar. Trate-o como uma pista, não como um facto.
- SI modified é o cavalo de batalha. Combinado com o
DATA_OVERWRITEcorrespondente no USN, diz-lhe que os bytes do ficheiro mudaram efectivamente naquele instante. - SI accessed no Windows 7+ está desactivado por omissão. Se o vir a mudar, ou um administrador reactivou-o, ou o volume está num SKU de Server, ou algo está a montar volumes e a percorrer ficheiros (software de backup, varreduras de AV, introspecção de EDR).
A granularidade abaixo do segundo é o sinal revelador. O NTFS guarda carimbos temporais em ticks de 100 nanossegundos. As operações nativas do Windows deixam ruído nos dígitos mais baixos. As ferramentas de timestomping como o SetMACE e o conhecido timestomp.exe arredondam para o segundo. Uma coluna de sufixos .0000000 alinhados certinhos é uma impressão digital.
Fundir com o USN journal
O MFT mostra-lhe o presente e um histórico congelado de metadados. O USN journal mostra-lhe os verbos. Junte-os e uma única linha na timeline torna-se uma frase.
A forma como junto: analiso $UsnJrnl:$J em separado, emito uma linha por registo com source=USN, depois ordeno o fluxo combinado por carimbo temporal. Os reason codes do USN (FILE_CREATE, DATA_OVERWRITE, RENAME_OLD_NAME, RENAME_NEW_NAME, FILE_DELETE, CLOSE) dão-lhe a operação; o MFT fornece o estado resultante. Um RENAME_OLD_NAME do USN imediatamente seguido de RENAME_NEW_NAME no mesmo USN revela o rename. Sem o journal, um diff do MFT entre dois snapshots talvez lhe diga que o ficheiro se moveu; não lhe pode dizer a ordem.
Uma armadilha: os carimbos temporais do USN e os do SI no MFT divergem em milissegundos para o mesmo evento. Não dependa demasiado do alinhamento. Ordene ao segundo e use o reason code do USN como critério de desempate.
O que estraga timelines do MFT
Aquisição fora de ordem. Se recolher MFT e USN com dez minutos de diferença num sistema vivo, o journal continuou a andar. Junte-os a partir do mesmo ponto no tempo, idealmente de um snapshot VSS que tenha desencadeado.
Esquecer o fixup array. Qualquer parser que valha a pena trata disto, mas se está a fazer o seu (por favor não faça, a menos que esteja a aprender), ler chunks brutos de 1.024 bytes dá-lhe lixo nos offsets 510 e 1022 de cada registo. Aplique os fixups primeiro.
Confundir números de registo entre fronteiras de sequência. O registo 12345 sequência 3 não é o mesmo ficheiro que o registo 12345 sequência 5. O slot foi reutilizado. Se a sua timeline agrupar só por número de registo, vai misturar um ficheiro eliminado com aquele que ocupou o slot.
Confiar no SI em binários de sistema. O Windows Update toca no SI dos ficheiros que aplica. Um SI modificado em C:\Windows\System32\svchost.exe é quase sempre uma instalação CBS, não uma intrusão. Cruze com setupapi.dev.log e CBS.log antes de fazer afirmações.
Tratar a timeline como a conclusão. É o input da análise. Continua a precisar de saber o que cada evento significa no contexto do host, do utilizador e do caso.
Um fluxo de trabalho que se aguenta
- Adquira
$MFT,$UsnJrnl:$J,$LogFile, e quaisquer cópias disponíveis dos mesmos em snapshots VSS. Faça hash a tudo (SHA-256) imediatamente. - Analise MFT e USN com o MFTECmd ou o
mft_dumpmais um parser de USN. Verifique que os parsers correram sem avisos. - Emita linhas normalizadas: uma por carimbo temporal para o MFT, uma por registo para o USN, com
source,mft_record,seqepathexplícitos. - Ordene por carimbo temporal num fluxo único. Não deduplique ainda; quase-duplicados transportam sinal.
- Foque-se no período de interesse. Puxe uma janela de duas horas antes e duas horas depois do evento suspeito.
- Sobreponha o resto: Prefetch, Amcache, Sysmon 1/11/15, artefactos LNK e jump list, registos
$Ida Reciclagem, SRUM para uso de rede e recursos de processo. - Procure ordenações impossíveis. SI created antes de FN created. Um reason
DATA_OVERWRITEdo USN sem a correspondente alteração de SI modified no MFT. Dois eventosFILE_CREATEno mesmo número de registo com a mesma sequência (o parser está partido).
Essa última etapa é onde as timelines do MFT pagam o seu sustento. Expõem impossibilidades. Cada impossibilidade ou é um bug de parser ou um artefacto de atacante, e ambos valem a perseguição.
O que o MFT não lhe pode dizer
Não lhe pode dizer que processo tocou num ficheiro. Não lhe pode dizer que utilizador. Não lhe pode dizer o que estava dentro de um ficheiro maior do que algumas centenas de bytes que foi eliminado e parcialmente sobrescrito. Para isso, precisa dos artefactos circundantes: 4688 com auditoria de linha de comandos (ou Sysmon 1), a cadeia de logon ID do log de Security, e num bom dia um dump de RAM que apanhou o processo ainda residente.
O MFT é a espinha. Os outros artefactos são os músculos. Nenhum anda sem o outro.
Leituras adicionais
- Eric Zimmerman, MFTECmd. A disposição CSV canónica e o parser em que a maior parte das equipas de IR se padroniza.
- SANS, Windows Forensic Analysis Poster. Encaixa correctamente os eventos do MFT na timeline mais ampla.
- Harlan Carvey, Investigating Windows Systems. Os capítulos sobre construção de timeline continuam a ser a referência prática.