Reconstrução de atividade em NTFS: correlação entre `$MFT`, `$UsnJrnl` e `$LogFile`

O NTFS mantém diferentes estruturas para representar arquivos, controlar alterações e preservar a consistência do volume. Entre as mais relevantes para a análise forense estão a Master File Table — $MFT —, o diário de alterações $UsnJrnl e o arquivo transacional $LogFile.

Essas estruturas observam aspectos distintos da atividade no sistema de arquivos:

a $MFT descreve objetos e atributos;
o $UsnJrnl registra categorias de alterações;
o $LogFile mantém operações transacionais necessárias à consistência do NTFS.

A correlação entre elas pode revelar criação, modificação, renomeação, movimentação e exclusão de arquivos, mesmo quando o objeto já não aparece no diretório ativo.

Essa reconstrução, entretanto, exige compreender a finalidade original de cada artefato. Nenhuma dessas estruturas foi projetada como registro forense completo das ações do usuário. Seus conteúdos decorrem do funcionamento interno do sistema de arquivos e estão sujeitos a acumulação de eventos, reutilização de registros, rotação, truncamento e diferenças temporais.

O valor técnico surge da convergência entre fontes independentes, e não da leitura isolada de uma única tabela de eventos.

Três estruturas, três perspectivas

Uma operação aparentemente simples, como renomear um arquivo, pode produzir efeitos em diferentes camadas do NTFS.

A $MFT pode passar a apresentar um novo atributo de nome. O $UsnJrnl pode registrar razões correspondentes ao nome antigo e ao nome novo. O $LogFile pode conter operações transacionais relacionadas à atualização dos registros e índices envolvidos.

O fenômeno pode ser representado como:

[
E \rightarrow {M, U, L}
]

onde:

(E) representa a operação no sistema de arquivos;
(M) representa as alterações observáveis na $MFT;
(U) representa os registros do $UsnJrnl;
(L) representa as operações transacionais do $LogFile.

Essas representações não são idênticas. Cada uma registra informações diferentes, com granularidade e finalidade próprias.

A reconstrução forense procura estabelecer quais elementos de (M), (U) e (L) podem ser associados ao mesmo objeto e ao mesmo ciclo de atividade.

`$MFT`: identidade e estado do objeto

A Master File Table constitui a estrutura central do NTFS. A documentação da Microsoft informa que existe pelo menos uma entrada na MFT para cada arquivo do volume, inclusive para os próprios arquivos internos do sistema.

Informações sobre um arquivo podem estar:

diretamente dentro de seu registro na MFT;
em registros adicionais;
em clusters externos descritos por atributos da MFT.

Cada registro pode conter atributos relacionados a:

nomes;
datas e horários;
permissões;
tamanho;
conteúdo residente;
localização do conteúdo não residente;
identificadores;
listas de atributos;
fluxos de dados.

A $MFT é frequentemente descrita como um catálogo de arquivos, mas sua função é mais ampla. Ela representa objetos do sistema de arquivos por meio de registros e atributos estruturados.

Número do registro e número de sequência

Uma referência NTFS não é composta apenas pelo número da entrada na MFT. Ela também incorpora um número de sequência.

A estrutura MFT_SEGMENT_REFERENCE associa o endereço do segmento a um número de sequência circularmente reutilizado. Quando uma entrada livre é reaproveitada para outro objeto, seu número de sequência tende a mudar.

Assim, uma referência pode ser representada por:

[
FRN = (\text{registro MFT},\ \text{sequência})
]

Essa composição reduz o risco de associar uma referência antiga ao objeto novo que posteriormente ocupou a mesma entrada.

Na análise forense, utilizar somente o número da entrada pode produzir uma correlação incorreta. Um evento antigo do $UsnJrnl pode se referir ao arquivo (A), enquanto a mesma posição na MFT, no momento da aquisição, já pertence ao arquivo (B).

O número de sequência é essencial para distinguir esses ciclos.

Registros marcados como livres

Quando um arquivo é excluído, sua entrada na MFT pode ser marcada como disponível para reutilização. A Microsoft esclarece que o espaço anteriormente alocado aos registros não é imediatamente removido da MFT.

Enquanto a entrada não for reutilizada ou sobrescrita, ela poderá conservar:

nome;
identificador do registro;
referências ao diretório-pai;
atributos temporais;
tamanho;
informações sobre os fluxos;
conteúdo residente;
referências para clusters de dados.

A permanência desses elementos depende da atividade posterior do volume. Em sistemas muito ativos, entradas livres podem ser reutilizadas rapidamente.

Atributos e multiplicidade de nomes

No NTFS, informações associadas a um arquivo são implementadas como atributos. A especificação MS-FSCC sobre tipos de atributos NTFS inclui atributos para nome, conteúdo, segurança e outros componentes.

Um arquivo pode possuir mais de um atributo $FILE_NAME, especialmente quando existem múltiplas entradas de diretório, nomes compatíveis com convenções distintas ou hard links.

A estrutura FILE_NAME representa um atributo de nome para cada diretório no qual o arquivo possui entrada.

Por isso, nome e identidade devem permanecer separados:

o nome é um atributo;
o diretório-pai fornece contexto;
a referência da MFT identifica o objeto;
operações de renomeação podem alterar o nome sem criar necessariamente uma nova identidade de arquivo.

Essa distinção é indispensável ao correlacionar eventos de renomeação e movimentação.

`$UsnJrnl`: sequência de alterações no volume

O NTFS mantém um diário de alterações baseado em Update Sequence Numbers. A documentação da Microsoft sobre change journals informa que alterações em arquivos e diretórios podem gerar registros com a descrição da mudança e o nome do objeto.

Os registros são acrescentados ao fluxo em sequência. Cada um pode conter:

referência do arquivo;
referência do diretório-pai;
USN;
timestamp;
flags de razão;
informações sobre a origem da alteração;
atributos do arquivo;
nome associado ao evento.

A estrutura USN_RECORD_V2 documenta esses campos.

USN como posição ordenada

O USN é um valor relacionado à posição do registro no fluxo do diário. Novos registros são anexados ao final, o que permite estabelecer uma ordem relativa dentro da mesma instância do journal.

Se:

[
USN_A < USN_B
]

e ambos pertencem à mesma instância válida do diário, o registro (A) precede o registro (B) no fluxo.

Isso oferece uma dimensão ordenada complementar aos timestamps. Em situações nas quais horários foram alterados ou apresentam resolução insuficiente, a ordem dos USNs pode ajudar a estabelecer precedência entre eventos.

Contudo, o USN não deve ser tratado como horário. A distância entre dois valores não representa duração temporal constante.

Identificador da instância do journal

O NTFS associa um identificador de 64 bits a cada instância do diário de alterações. A documentação sobre o identificador do change journal explica que o journal pode receber novo identificador quando seus registros existentes deixam de ser considerados utilizáveis.

O par relevante pode ser representado como:

[
J = (\text{Journal ID},\ \text{USN})
]

Comparar USNs sem considerar o identificador pode misturar registros pertencentes a instâncias diferentes.

A recriação administrativa do journal também pode afetar a interpretação. Em determinados cenários, os valores reiniciam; em outros, o identificador muda enquanto a sequência continua.

O relatório técnico deve registrar, quando disponível:

identificador do journal;
primeiro USN válido;
próximo USN;
tamanho máximo;
allocation delta;
versões de registros encontradas;
sinais de recriação ou descontinuidade.

Retenção e rotação do `$UsnJrnl`

O diário possui tamanho administrável. Registros antigos podem ser removidos para conservar espaço.

A estrutura CREATE_USN_JOURNAL_DATA utiliza os parâmetros MaximumSize e AllocationDelta. O journal pode crescer além do tamanho-alvo antes de ser reduzido em um checkpoint posterior do NTFS.

A quantidade de tempo representada pelo diário depende da taxa de atividade do volume. Um mesmo tamanho pode abranger semanas em um sistema pouco utilizado e apenas horas em um servidor com intensa movimentação de arquivos.

A cobertura deve ser determinada pelos registros efetivamente preservados, e não por uma expectativa fixa de duração.

Flags de razão e semântica do evento

O campo Reason de um registro USN contém flags que indicam categorias de alteração.

Entre elas:

USN_REASON_FILE_CREATE;
USN_REASON_FILE_DELETE;
USN_REASON_RENAME_OLD_NAME;
USN_REASON_RENAME_NEW_NAME;
USN_REASON_DATA_EXTEND;
USN_REASON_DATA_OVERWRITE;
USN_REASON_DATA_TRUNCATION;
USN_REASON_BASIC_INFO_CHANGE;
USN_REASON_SECURITY_CHANGE;
USN_REASON_STREAM_CHANGE;
USN_REASON_CLOSE.

Essas flags descrevem o tipo de mudança observada no objeto. Elas não registram diretamente o conteúdo escrito, o processo responsável, o usuário que iniciou a operação ou sua intenção.

Um evento DATA_OVERWRITE, por exemplo, sustenta que ocorreu uma alteração classificada dessa maneira no fluxo de dados. Ele não informa quais bytes foram modificados.

Da mesma forma, FILE_DELETE registra uma alteração correspondente ao estado de exclusão do objeto no sistema de arquivos, mas não identifica automaticamente quem realizou a ação.

Acumulação de razões entre abertura e fechamento

O comportamento das flags exige atenção especial.

A documentação dos registros do change journal explica que razões podem ser acumuladas durante o período em que um objeto permanece aberto. Alterações repetidas do mesmo tipo podem deixar de produzir novos registros quando a razão correspondente já está presente.

Considere a sequência:

escrita no arquivo;
nova escrita;
truncamento;
outra escrita;
fechamento.

O journal pode registrar a primeira escrita, acrescentar a razão de truncamento em registro posterior e, ao final, gerar um registro com CLOSE e o conjunto acumulado de razões.

O registro final funciona como resumo das categorias observadas naquele ciclo de abertura. Ele não preserva necessariamente a ordem interna de todas as operações.

Assim:

[
{\text{overwrite},\ \text{truncate},\ \text{close}}
]

representa um conjunto acumulado de razões, e não obrigatoriamente uma lista ordenada de três ações individuais.

Esse comportamento impede que cada flag seja transformada automaticamente em um evento autônomo.

Renomeação e movimentação

Uma operação de renomeação ou movimentação normalmente produz dois registros:

RENAME_OLD_NAME;
RENAME_NEW_NAME.

Segundo a especificação MS-FSCC do USN_RECORD_V2, um registro representa o nome e o diretório-pai anteriores, enquanto outro representa o novo nome e o novo pai.

A correlação pode utilizar:

mesma referência de arquivo;
números de sequência compatíveis;
proximidade entre USNs;
razão antiga seguida da razão nova;
referências aos diretórios-pais;
nomes preservados;
registros correspondentes na MFT.

Uma alteração como:

C:\Users\Ana\Downloads\relatorio.tmp

para:

C:\Users\Ana\Documents\relatorio-final.pdf

pode envolver simultaneamente mudança de nome e de diretório.

O journal registra referências ao objeto e aos pais, mas a reconstrução do caminho completo depende da resolução da cadeia de diretórios. Se registros de pais foram reutilizados ou não estão mais disponíveis, partes do caminho podem permanecer indeterminadas.

Reconstrução de caminhos

Um registro USN fornece o nome do objeto e a referência do diretório-pai. Para construir o caminho completo, o examinador precisa resolver sucessivamente:

[
FRN_{arquivo} \rightarrow FRN_{pai} \rightarrow FRN_{avô} \rightarrow \cdots \rightarrow raiz
]

Essa operação parece direta quando todas as entradas da MFT permanecem ativas e preservadas. Ela se torna mais complexa quando:

o arquivo foi excluído;
um diretório-pai também foi excluído;
entradas foram reutilizadas;
os números de sequência mudaram;
o journal contém eventos antigos;
o nome do diretório foi alterado depois do evento;
existem múltiplos nomes ou hard links.

O caminho reconstruído a partir da MFT atual pode representar o estado presente, e não necessariamente o estado existente quando o registro USN foi gerado.

Para uma reconstrução histórica, pode ser necessário correlacionar eventos de renomeação dos próprios diretórios e manter versões temporais da relação entre referências e nomes.

`$LogFile`: operações transacionais do NTFS

O $LogFile é o arquivo de registro transacional do NTFS. A especificação de nomes reservados do NTFS identifica $LogFile como arquivo de transactional logging.

Sua função principal está associada à recuperação da consistência do sistema de arquivos. A visão geral do NTFS informa que o sistema utiliza um arquivo de log transacional e informações de checkpoint para restaurar a consistência após falhas.

O $LogFile pode conter:

registros de reinicialização;
páginas de log;
números de sequência do log;
identificadores de transação;
operações de redo;
operações de undo;
referências para estruturas modificadas;
dados necessários à repetição ou reversão de alterações.

Sua perspectiva é mais baixa do que a do $UsnJrnl. Em vez de registrar apenas uma razão como “arquivo renomeado”, ele pode conter operações relacionadas às estruturas internas que precisaram ser atualizadas para realizar a mudança.

LSN e ordem transacional

Os registros do $LogFile utilizam Log Sequence Numbers — LSNs — para organizar a sequência das operações no log.

Uma relação como:

[
LSN_A < LSN_B
]

pode indicar precedência dentro do contexto válido do log, desde que sejam considerados seus ciclos, páginas, reinicializações e estruturas de controle.

O LSN fornece ordem transacional, não horário civil direto.

Nem todo registro contém timestamp de interesse forense. A associação temporal pode depender de correlação com:

$UsnJrnl;
atributos da MFT;
eventos do sistema;
logs de aplicação;
outros artefatos temporais.

A pesquisa de Cho e Rogers sobre informações forenses de criação de diretórios no $LogFile demonstra que determinadas operações podem preservar nomes e informações temporais, mas também ressalta a complexidade e a limitada documentação pública de sua estrutura.

Redo e undo como mecanismos de consistência

Registros de redo descrevem operações que podem ser repetidas para levar as estruturas a um estado consistente. Registros de undo permitem reverter operações incompletas ou não confirmadas.

Esses conceitos não devem ser traduzidos diretamente como “ação realizada” e “ação cancelada” sem examinar:

estado da transação;
registros de confirmação;
relação entre LSNs;
checkpoint;
operação específica;
contexto da página modificada.

A presença de dados em uma operação de undo pode representar o estado anterior necessário à reversão. Já o redo pode descrever a atualização pretendida.

A interpretação exige reconstruir a lógica transacional, e não apenas extrair cadeias de caracteres do arquivo.

Granularidade e finalidade comparadas

Estrutura	Perspectiva principal	Elementos relevantes	Limitação central
`$MFT`	Estado e atributos dos objetos	registros, nomes, tempos, tamanhos, fluxos, referências	apresenta predominantemente o estado preservado no momento da aquisição
`$UsnJrnl`	Categorias de mudanças	USN, timestamp, referência, pai, nome, razões	razões podem ser acumuladas e registros antigos são removidos
`$LogFile`	Consistência transacional	LSN, transações, redo, undo, operações internas	interpretação complexa e cobertura temporal curta e variável

A correlação deve respeitar essas diferenças. Um registro em uma fonte não precisa possuir equivalente individual e perfeitamente alinhado nas demais.

Modelo de correlação

Considere um arquivo identificado pela referência:

[
F = (r, s)
]

onde (r) é o número da entrada MFT e (s) seu número de sequência.

Podem ser associados ao mesmo ciclo do objeto:

[
M_F = {\text{atributos da MFT para }F}
]

[
U_F = {\text{registros USN cuja referência é }F}
]

[
L_F = {\text{transações do LogFile relacionadas às estruturas de }F}
]

A reconstrução resultante pode ser representada como:

[
R_F = C(M_F, U_F, L_F, X)
]

onde (C) é o processo de correlação e (X) representa fontes adicionais, como logs de aplicação, registros de segurança, links recentes ou artefatos de sincronização.

A força da reconstrução depende da compatibilidade entre esses conjuntos.

Exemplo: criação, renomeação e exclusão

Considere um arquivo inicialmente criado como:

C:\Temp\R4A9.tmp

Posteriormente, ele é renomeado e movido para:

C:\Users\Marina\Documents\proposta.pdf

Após alguns minutos, o arquivo é excluído.

A análise pode identificar:

Na `$MFT`

entrada marcada como livre;
nome proposta.pdf;
referência ao diretório Documents;
tamanho e atributos;
número de sequência;
referências aos clusters do conteúdo, se ainda preservadas.

No `$UsnJrnl`

FILE_CREATE para R4A9.tmp;
DATA_EXTEND ou DATA_OVERWRITE;
RENAME_OLD_NAME para R4A9.tmp;
RENAME_NEW_NAME para proposta.pdf;
alteração do diretório-pai;
FILE_DELETE para proposta.pdf;
sequência crescente de USNs e timestamps associados.

No `$LogFile`

operações relacionadas à criação do registro;
atualização do atributo de nome;
modificação do índice do diretório anterior;
inserção no índice do novo diretório;
atualização do estado de alocação;
operações ligadas à liberação da entrada.

A convergência pode sustentar uma narrativa técnica:

o objeto foi criado sob nome temporário;
recebeu dados;
foi renomeado e movido;
permaneceu associado à mesma referência;
foi posteriormente excluído.

A conclusão sobre quem executou essas ações dependerá de outras fontes. As estruturas NTFS demonstram atividade no sistema de arquivos, mas não identificam automaticamente o agente humano.

Atribuição temporal

A correlação temporal deve distinguir três classes de valores:

Timestamps dos atributos

A MFT mantém informações temporais associadas aos atributos do arquivo. Esses valores podem refletir criação, modificação, alteração de metadados e acesso, conforme o atributo e o comportamento do sistema.

Eles descrevem propriedades do objeto, não necessariamente o instante em que o examinador espera intuitivamente.

Timestamp do USN

O TimeStamp do registro USN representa o horário absoluto do sistema em que o evento foi registrado. Ele fornece uma referência temporal direta, sujeita ao estado do relógio do sistema e ao comportamento do journal.

Ordem transacional

USNs e LSNs oferecem relações de precedência em seus respectivos fluxos. Essa ordem pode continuar útil quando os horários apresentam valores inesperados.

Uma reconstrução robusta utiliza tempo e ordem em conjunto:

[
T = {\text{timestamps}} + {\text{ordem USN}} + {\text{ordem LSN}}
]

Divergências entre essas dimensões devem ser investigadas antes de serem atribuídas a manipulação deliberada.

Alteração de atributos temporais

A flag USN_REASON_BASIC_INFO_CHANGE pode indicar modificação de atributos básicos, inclusive timestamps. Contudo, ela não informa quais campos foram alterados nem quais valores existiam antes da operação.

Uma diferença entre timestamps da MFT e a ordem do journal pode ser compatível com:

ação normal de aplicativo;
cópia ou restauração;
sincronização;
extração de arquivo compactado;
atualização administrativa;
modificação deliberada;
comportamento específico do sistema.

A hipótese de timestomping exige avaliar o conjunto de artefatos. Um timestamp isoladamente incompatível representa um indicador, não uma atribuição conclusiva.

Exclusão, reutilização e continuidade da identidade

Após a exclusão, três processos podem ocorrer em ritmos diferentes:

a entrada da MFT é marcada como livre;
os clusters do conteúdo tornam-se disponíveis;
o $UsnJrnl conserva temporariamente o registro da alteração.

A entrada e os clusters podem ser reutilizados independentemente. O conteúdo pode ser sobrescrito enquanto o evento USN permanece, ou o journal pode eliminar o evento enquanto a entrada livre ainda conserva atributos.

A reutilização da MFT exige atenção ao número de sequência. Associar um evento antigo ao atual ocupante da entrada constitui erro de identidade.

A correlação correta deve verificar:

número do registro;
número de sequência;
nomes;
referências aos pais;
datas;
razões USN;
transações compatíveis;
estado de alocação.

Aquisição e preservação

Essas estruturas são dinâmicas. Em um sistema ativo:

novos registros são inseridos no journal;
registros antigos são removidos;
entradas da MFT são atualizadas;
transações do $LogFile são sobrescritas;
diretórios mudam;
referências livres são reutilizadas.

A oportunidade da aquisição influencia diretamente a cobertura.

Quando tecnicamente viável, devem ser preservados:

$MFT;
$MFTMirr;
$LogFile;
$Extend\$UsnJrnl;
$Bitmap;
índices de diretórios;
imagem do volume;
cópias de sombra;
logs do sistema;
informações sobre o volume e o journal.

A extração individual de arquivos internos pode ser útil, mas a imagem do volume preserva relações de alocação, estruturas complementares e registros residuais que podem ser necessários para validar o resultado.

Validação das ferramentas

Parsers de NTFS precisam interpretar estruturas binárias complexas, variações de versão, páginas parcialmente sobrescritas e registros fragmentados.

Resultados diferentes entre ferramentas podem decorrer de:

suporte desigual a versões;
critérios distintos de validação;
recuperação de registros residuais;
tratamento de entradas corrompidas;
reconstrução de caminhos;
normalização de timestamps;
interpretação de flags acumuladas;
associação de transações.

A validação pode incluir:

comparação com documentação técnica;
teste em volumes controlados;
verificação manual de registros relevantes;
comparação entre ferramentas independentes;
preservação dos offsets e bytes originais;
conferência dos números de sequência;
confirmação das cadeias de diretórios.

A exportação CSV de uma ferramenta é uma interpretação dos bytes, e não a fonte primária.

Linguagem recomendada no relatório técnico

Em vez de:

O usuário criou e apagou o arquivo.

Uma formulação tecnicamente delimitada seria:

Foram identificados registros NTFS compatíveis com criação, gravação, renomeação e posterior exclusão do objeto representado pela referência MFT 48219-3. As estruturas examinadas não identificam, isoladamente, o usuário ou processo responsável pelas operações.

Para renomeação:

Dois registros USN consecutivos, associados à mesma referência de arquivo, apresentam as razões RENAME_OLD_NAME e RENAME_NEW_NAME, com nomes e diretórios-pais distintos. A MFT preserva o nome mais recente.

Para cobertura limitada:

O primeiro USN válido disponível é posterior ao início do período investigado. A reconstrução abrange somente a parcela preservada do journal.

Para uma entrada reutilizada:

O número da entrada MFT coincide com o registro USN histórico, mas o número de sequência é diferente. O atual ocupante da entrada representa outro ciclo de utilização e não foi associado ao evento anterior.

Para flags acumuladas:

O registro final contém razões de sobrescrita, truncamento e fechamento. Essas flags resumem categorias acumuladas durante o ciclo de abertura e não determinam a ordem individual de todas as operações.

Síntese e implicações técnico-forenses

A $MFT, o $UsnJrnl e o $LogFile representam camadas complementares da atividade em volumes NTFS.

A $MFT permite identificar objetos, atributos e relações. O $UsnJrnl oferece uma sequência de mudanças com referências, nomes e razões. O $LogFile preserva operações transacionais relacionadas à consistência interna do sistema de arquivos.

A correlação entre essas fontes pode:

reconstruir ciclos de criação e exclusão;
acompanhar renomeações e movimentações;
recuperar nomes anteriores;
estabelecer precedência entre eventos;
diferenciar reutilizações da mesma entrada MFT;
identificar alterações de dados e atributos;
avaliar divergências temporais;
sustentar reconstruções mesmo após a remoção do objeto.

Essa capacidade depende da preservação dos artefatos, da verificação dos números de sequência, da cobertura temporal dos journals e da interpretação correta de suas semânticas.

O objetivo da análise não é transformar cada registro interno em ação humana individual. O objetivo é determinar quais operações o sistema de arquivos registrou, como elas se relacionam e quais inferências podem ser sustentadas pela convergência das estruturas disponíveis.

Referências

CHO, Gyu-Sang; ROGERS, Marcus. Finding Forensic Information on Creating a Folder in $LogFile of NTFS. ICDF2C, Springer, 2012.
MICROSOFT. Change Journals. Microsoft Learn.
MICROSOFT. Change Journal Records. Microsoft Learn.
MICROSOFT. Master File Table. Microsoft Learn.
MICROSOFT. MFT_SEGMENT_REFERENCE structure. Microsoft Learn.
MICROSOFT. NTFS Attribute Types — MS-FSCC. Microsoft Open Specifications.
MICROSOFT. NTFS Reserved File Names — MS-FSCC. Microsoft Open Specifications.
MICROSOFT. NTFS Overview. Microsoft Learn.
MICROSOFT. USN_RECORD_V2 — MS-FSCC. Microsoft Open Specifications.
MICROSOFT. Using the Change Journal Identifier. Microsoft Learn.

Reconstrução de atividade em NTFS: correlação entre $MFT, $UsnJrnl e $LogFile