Recuperar evidências de arquivos excluídos com o journal USN

A pergunta mais comum que analistas forenses recebem de partes não técnicas é alguma variante de «você consegue provar que esse arquivo existiu?». Quando o arquivo já saiu do disco, a lixeira foi esvaziada e passou tempo suficiente para a entrada $MFT ter sido reciclada, a resposta geralmente depende do que o journal USN ainda lembra.

Este artigo percorre o que o journal preserva sobre arquivos excluídos, como extrair essa evidência e as situações em que o journal é sua última testemunha.

O que o journal mantém após a exclusão

Quando um arquivo é excluído no NTFS, várias coisas acontecem:

A entrada $FILE_NAME no diretório pai é desligada.
A entrada MFT é marcada como livre — mas não zerada.
O journal USN recebe um registro FileDelete | Close nomeando o arquivo, sua referência pai, sua entrada MFT e o timestamp.

O registro do journal é o mais resiliente dos três. A entrada de diretório some assim que o pai é reescrito; a entrada MFT pode ser reutilizada assim que um novo arquivo é criado; o registro do journal vive num buffer circular que só dá a volta após dias ou semanas de atividade.

Significa que, para arquivos excluídos há dias, o journal geralmente te dá:

O nome do arquivo (apenas a folha, não o caminho completo).
A referência MFT do diretório pai — combinada a um $MFT parseado, dá o caminho.
O timestamp de exclusão em UTC.
O número de entrada MFT que o arquivo ocupava (útil para cruzar com artefatos esculpidos).
Um rastro de ciclo de vida: os registros FileCreate, DataExtend, BasicInfoChange antes da exclusão dizem quando o arquivo foi criado, como foi escrito e se seus timestamps foram alguma vez modificados.

Um fluxo mínimo de recuperação

Com um journal parseado (o parser desta página ou usnrs servem; veja o guia de extração para obter $J e $MFT):

Filtrar por FileDelete para fazer aparecer cada exclusão na janela. Ordenar por timestamp.
Para cada exclusão de interesse, agrupar por FileReferenceNumber para ver o histórico completo do arquivo — criação, gravações, pares de rename, mudanças de atributos e, por fim, a exclusão.
Resolver o caminho do pai via $MFT. Com os dois arquivos fornecidos, nosso parser faz isso automaticamente.
Cruzar com $LogFile se a exclusão for muito recente — ele pode ainda conter a imagem «antes» da entrada de diretório, dando uma segunda testemunha independente.

A combinação «tenho uma referência MFT, um nome de arquivo, um pai, um timestamp de criação e um de exclusão» costuma ser suficiente para satisfazer uma retenção legal ou ancorar uma investigação mais profunda.

Quando o caminho do pai não pode ser resolvido

Às vezes a própria entrada MFT pai já foi reciclada quando você olha — especialmente em hosts muito ativos. Nesse caso o journal te dá o nome do arquivo e a referência pai, mas o $MFT já não sabe a qual pasta esse número correspondia.

Três coisas normalmente ajudam:

Registros RenameNewName anteriores na referência pai — podem carregar um pai resolvível no momento do rename.
Entradas de índice em $LogFile — não documentadas, mas cobertas por libfsntfs.
Arquivos irmãos sob a mesma referência pai — agrupar todos os registros do journal por pai. Se um dos irmãos foi renomeado para um diretório cuja entrada MFT ainda é válida, dá para pivotar por ele.

É também por isso que os relatórios provisórios desta ferramenta dizem «filename: notes.docx» sem caminho: preferimos não inventar um caminho que não podemos verificar.

«Apagado em segurança» não significa sumido

Algumas ferramentas de destruição de arquivos (CCleaner, Eraser, BleachBit) sobrescrevem o conteúdo e depois excluem. Deixam os mesmos registros de journal de uma exclusão normal mais os registros de sobrescrita. O journal portanto torna a «exclusão segura» barulhenta, não silenciosa:

Múltiplos DataOverwrite | Close no arquivo antes do FileDelete | Close indicam sobrescrita intencional.
Um FileCreate e um FileDelete do mesmo arquivo em segundos, com sobrescritas no meio, é o padrão canônico.
Se o shredder também limpou o espaço livre gravando arquivos temporários, esses temporários têm suas próprias sequências create/extend/overwrite/delete — um enxame de registros em torno do momento da destruição.

A técnica MITRE ATT&CK correspondente é T1485 Data Destruction e T1070.004 File Deletion.

E o conteúdo do arquivo?

O journal USN nunca carrega conteúdo — só metadados de operações. Se você precisa de bytes de volta, o journal aponta para:

O número de entrada MFT do arquivo excluído. Se a entrada não foi reusada, o MFT ainda guarda os data runs e o conteúdo pode ser recuperável via icat do The Sleuth Kit ou X-Ways.
As imagens «antes» do $LogFile para exclusões muito recentes.
As Volume Shadow Copies (VSS), se existirem — o arquivo excluído pode viver em um snapshot anterior.
Armazenamentos específicos de aplicação — lixeira do OneDrive, pasta «Autosaved» do Office, caches dos navegadores.

O papel do journal aqui é dizer que um arquivo existiu e quando foi excluído — o resto da recuperação é a jusante.

Limites práticos

O journal tem uma janela temporal. Arquivos excluídos antes de o buffer circular ter girado para o registro mais antigo que você tem simplesmente não estão mais nesse artefato. Puxe $LogFile e shadow copies como complemento.
Algumas operações não tocam o journal: mudanças de criptografia no nível de filesystem, gravações em regiões sparse que tocam só o mapa de alocação e manipulações de reparse points NTFS podem não produzir registros DataExtend/DataOverwrite.
Um FileDelete sem um FileCreate correspondente na janela significa que o arquivo foi criado antes do registro mais antigo do journal — o ciclo de vida é parcial, mas dá ainda para ancorar o timestamp de exclusão.

Para contexto de artefatos mais amplo, ver o pôster SANS Windows Forensic Analysis e a referência change journals do Microsoft Learn.