O $MFT diz-lhe como o sistema de ficheiros está agora. Não lhe diz a ordem das operações que produziram este estado. Para isso o NTFS mantém um segundo artefacto, o Update Sequence Number Journal, chamado $UsnJrnl. Emparelhe os dois e um snapshot estático torna-se um filme. Leia o site dedicado ao parser USN para o mergulho profundo específico do journal; este post é sobre porque o lê em conjunto com o MFT e o que a combinação mostra que nenhum dos dois mostra sozinho.
O que o $UsnJrnl regista
Cada vez que um ficheiro é criado, modificado, renomeado, ou eliminado, o NTFS acrescenta ao journal um registo de tamanho fixo a descrever o evento. Os campos de cada registo USN:
- USN: contador monotonicamente crescente de 64 bits. A posição no journal.
- Número de registo MFT do ficheiro alterado.
- Número de sequência desse registo no momento da alteração.
- Número de registo MFT (e sequência) do directório-pai.
- Reason mask: OR bit a bit das operações que despoletaram esta entrada. A lista completa está nos reason codes USN da Microsoft. Os que se lê mais:
FILE_CREATE(0x00000100)FILE_DELETE(0x00000200)DATA_OVERWRITE(0x00000001)DATA_EXTEND(0x00000002)DATA_TRUNCATION(0x00000004)RENAME_OLD_NAME(0x00001000)RENAME_NEW_NAME(0x00002000)OBJECT_ID_CHANGE(0x00080000)REPARSE_POINT_CHANGE(0x00100000)STREAM_CHANGE(0x00200000)CLOSE(0x80000000)
- Source info: bitmask que indica fontes de caso especial (gestão de dados, indexação, replicação). Geralmente zero.
- Security ID.
- Nome do ficheiro no momento da alteração.
- Carimbo temporal da alteração.
O CLOSE é o bit que deve conhecer. A maioria das entradas USN tem-no ligado, indicando que o handle de ficheiro foi fechado quando o evento foi gravado. Entradas sem CLOSE são handles ainda abertos cujas alterações foram dadas como flushed; pode ver entradas seguintes para o mesmo registo com o CLOSE final mais tarde. O padrão importa para análise de ransomware: um FILE_CREATE | DATA_EXTEND | CLOSE num ficheiro .locked emparelhado com um FILE_DELETE | CLOSE no original é o padrão de encriptação numa só sequência de journal.
Onde vive
O $UsnJrnl é um ficheiro NTFS normal com os seus dados no fluxo de dados com nome $J. O registo MFT dele fica sob o directório $Extend (o registo MFT 11 é o $Extend). O caminho a partir da raiz do volume é \$Extend\$UsnJrnl:$J. Há também um pequeno fluxo $Max com a configuração do journal (tamanho máximo, delta de alocação, USN da primeira entrada válida).
Adquire-o com as mesmas ferramentas que agarram o $MFT:
- O target
MFTdo KAPE inclui o$UsnJrnl:$Jautomaticamente. - O FTK Imager pode exportá-lo via
[volume NTFS]/$Extend/$UsnJrnl:$J. O ficheiro é sparse; não se surpreenda quando o "tamanho" for enorme e o conteúdo real for muito menor. - Sleuth Kit numa imagem de disco:
icat -o <offset_partição> image.dd <inode>onde o inode é o número de registo MFT do$UsnJrnl. Ofls -pencontra o inode. - O
mft_dumpe o MFTECmd têm ambos modos de parsing de$J.
Como complementa o $MFT
O MFT mostra-lhe o estado presente. O USN journal mostra-lhe os verbos que o produziram. Emparelhe-os e emergem padrões que nenhum mostra sozinho:
- Ficheiros que já não existem em disco mas aparecem no
$UsnJrnl. Criados e eliminados entre snapshots, mas o journal preservou o registo. O slot do MFT pode até ter sido reutilizado entretanto; a entrada USN continua a nomear o ficheiro e a apontar para o registo/sequência original. - A ordem exacta dos renames durante uma execução de ransomware.
OPEN,DATA_OVERWRITE,RENAME_OLD_NAME,RENAME_NEW_NAME,CLOSE. O diff do MFT entre snapshots diz-lhe que o ficheiro se moveu; o journal diz-lhe a ordem em que se moveu. - Se um ficheiro "modificado" foi mesmo reescrito ou apenas tocado.
DATA_OVERWRITEsignifica que o conteúdo mudou. Uma alteração apenas de metadados (actualização de ACL, set de atributo) mostra flags de reason diferentes e nenhuma relacionada com dados. - Que grupo de processos escreveu que ficheiro. O journal não regista o processo directamente, mas combinado com Sysmon Event ID 11 (criação de ficheiro) e Event ID 23 (eliminação de ficheiro), quase sempre consegue atribuir entradas do journal a processos específicos.
O fluxo de merge
A forma como junto dados de MFT e USN para timeline:
- Analisar o
$MFTpara um CSV plano linha-por-registo (MFTECmd,mft_dump -o csv, ou export do parser de browser). - Analisar o
$UsnJrnl:$Jpara um CSV plano linha-por-evento. - Acrescentar uma coluna
sourcea cada (MFTeUSN). - Concatenar e ordenar por carimbo temporal.
- Focar nos registos que combinam com o caso (números de registo específicos, nomes de ficheiro específicos, directórios-pais específicos).
- Ler a timeline como prosa: para cada número de registo, listar os eventos por ordem.
A saída para um único ficheiro parece-se com isto:
2026-05-15T10:23:01.123Z USN FILE_CREATE | DATA_EXTEND | CLOSE rec=12345 seq=3 parent=99 name=secret.docx
2026-05-15T10:23:01.123Z MFT IN_USE=1 SI_created=10:23:01.123Z FN_created=10:23:01.123Z
2026-05-15T10:24:18.456Z USN DATA_OVERWRITE | CLOSE rec=12345 seq=3 name=secret.docx
2026-05-15T10:24:18.456Z MFT SI_modified=10:24:18.456Z
2026-05-16T08:11:02.000Z USN RENAME_OLD_NAME rec=12345 seq=3 name=secret.docx
2026-05-16T08:11:02.000Z USN RENAME_NEW_NAME | CLOSE rec=12345 seq=3 name=secret.docx.locked
2026-05-16T08:11:02.001Z USN FILE_DELETE | CLOSE rec=12345 seq=3 name=secret.docx.locked
Essa sequência é a vida inteira do ficheiro. Criado, modificado, renomeado (para acrescentar a extensão .locked), eliminado. Cinco operações, um ficheiro, menos de 24 horas.
Limites e armadilhas
O journal roda. O tamanho por omissão é 32 MB na maioria das instalações, por vezes maior em SKUs Server e em builds recentes do Windows 11. Num host ocupado dá para alguns dias. Eventos mais antigos caem da ponta à medida que novos entram. Chegue uma semana após um incidente e espere lacunas.
O journal pode ser eliminado. fsutil usn deletejournal /D C: remove-o por inteiro. Um novo começa com um contador fresco. A recriação deixa pegadas (veja anti-forense NTFS) mas as entradas históricas foram-se.
O wrap-around parece uma rotação normal. O primeiro USN que vê num $J capturado é onde o journal por acaso começava nesse momento. Não há histórico de "isto é o que estava aqui na semana passada". Se quiser uma janela maior, procure cópias mais antigas do $UsnJrnl em snapshots VSS; cada snapshot tem a sua própria cópia do journal no momento do snapshot.
Os carimbos temporais divergem dos do MFT em milissegundos. Não dependa demasiado do alinhamento. Ordene ao segundo e use os reason codes do USN como desempate.
Reutilização de número de registo. Uma entrada USN referencia rec=12345 seq=3. Se o MFT actual mostra esse registo em sequência 4, o slot foi reutilizado entretanto. A entrada USN continua a nomear o ficheiro original; o MFT actual mostra o sucessor. Cruze sempre os números de sequência.
Minifilters de driver podem suprimir entradas. Algum software EDR e de backup suprime certos motivos USN para reduzir o ruído. O journal não os regista. Se os seus dados USN parecem escassos para uma categoria de operação que devia ser frequente (acesso a ficheiro, por exemplo), verifique que minifilters estão instalados.
$LogFile, brevemente
O $LogFile regista operações ao nível de transacção: alocar este atributo, desalocar aquele, actualizar esta entrada de índice. Granular mas de nível mais baixo que o USN. Útil nos segundos imediatamente em torno de um crash ou de um evento intensivo em metadados. O MFTECmd analisa-o; nada mais comum o faz. Se tiver um USN journal adulterado, o $LogFile é por vezes o único registo restante do que realmente aconteceu.
Um fluxo que se aguenta
- Adquira sempre
$MFT,$UsnJrnl:$J,$LogFilee as cópias dos três em snapshots VSS, em conjunto. - Faça hash a tudo (SHA-256) imediatamente.
- Analise os três.
- Funda MFT e USN numa única timeline. Sobreponha o
$LogFileem cima para os segundos em torno de qualquer evento de interesse. - Cruze com Sysmon, logs de Security, Prefetch, Amcache.
- Documente o que excluiu, tal como o que concluiu.
O par MFT-mais-USN é a coisa mais próxima de um log completo de actividade do sistema de ficheiros que o NTFS lhe dá. Trate-o como tal.
Leituras adicionais
- Microsoft, USN Record Structures. Referência autoritativa para o formato de registo e os reason codes.
- Eric Zimmerman, modos de parsing USN do MFTECmd. O parser mais completo, com resiliência para journals parciais/que deram a volta.
- TZWorks
jpe a ferramenta de browser usnparser.com para parsers alternativos quando o MFTECmd não está disponível.