← Voltar ao blog

Reconstruir uma timeline de atividade do usuário a partir do journal USN

A partir de três minutos de registros $UsnJrnl é geralmente possível reconstruir o que um usuário estava fazendo — Office, navegador, downloads, código. Como ler o journal como um log de comportamento.

5 min de leitura

Boa parte da pergunta «o que aconteceu neste computador entre 14:00 e 16:00» se responde diretamente com o journal USN. Os registros não são um log de syscall e não são marcados com usuário — mas têm algo quase tão útil: um registro de alta frequência, por operação, de cada arquivo que a máquina tocou. Com um pouco de conhecimento de padrões, você consegue recuperar o comportamento do usuário na granularidade de salvar Office, navegar, rebuild de IDE, pausa para almoço.

Este artigo é o guia de campo para ler o journal como timeline comportamental.

Por que isso funciona

O journal USN registra qual arquivo mudou, quando e como — e a maior parte das ações visíveis de um usuário num desktop produz uma assinatura reconhecível de atividade de arquivos. O usuário clica em Salvar no Word; o Word grava um temp, renomeia atomicamente e faz BasicInfoChange | Close no resultado. O Chrome abre uma nova aba; o cache de disco se estende. A IDE recompila; mil arquivos objeto nascem.

Essas assinaturas não estão documentadas em lugar oficial — são aprendidas. Abaixo um kit inicial, mais os controles do parser que as tornam tratáveis.

Office na natureza

Quando um usuário salva um Word, Excel ou PowerPoint, você vê:

FileCreate | Close            ~$<filename>.docx     (arquivo de lock)
FileCreate | Close            <filename>.tmp        (temp atômico)
DataExtend | Close            <filename>.tmp        × N
RenameOldName | Close         <filename>.docx
FileDelete | Close            <filename>.docx
RenameNewName | Close         <filename>.docx       (era <filename>.tmp)
FileDelete | Close            ~$<filename>.docx
BasicInfoChange | Close       <filename>.docx

O arquivo de lock ~$ é o sinal do Office de que um documento está aberto; seus FileCreate e FileDelete dizem o momento de abertura/fechamento do documento. A renomeação atômica .tmp.docx é o próprio salvamento. Os arquivos ~$ iniciais são surpreendentemente úteis porque existem apenas enquanto o documento está aberto.

Truque de pivot: filtrar FileCreate cujo nome começa por ~$ para enumerar todos os documentos Office abertos pelo usuário na janela. Subtrair FileDelete dos mesmos nomes para encontrar os ainda abertos no momento da aquisição (uma imagem forense tirada de uma máquina viva pode ter arquivos de lock para documentos nunca fechados corretamente).

Atividade do navegador

Navegadores modernos mantêm caches pesados no filesystem. Chrome e Edge usam \Users\<u>\AppData\Local\<browser>\User Data\Default\Cache\Cache_Data\ (ou Code Cache\); Firefox usa \Users\<u>\AppData\Local\Mozilla\Firefox\Profiles\<id>\cache2\.

O que se vê durante a navegação:

  • Uma taxa baixa e sustentada de FileCreate | Close e DataExtend | Close no diretório de cache.
  • FileDelete | Close ocasionais enquanto o LRU expulsa entradas antigas.
  • A cada poucos minutos, RenameNewName de arquivos de cache enquanto o índice se compacta.

Rajadas de gravações de cache se correlacionam bem com a visita de sites pesados em mídia ou SPAs. Períodos calmos se correlacionam com o usuário ausente ou em uma página de carregamento longo.

Os nomes dos arquivos de cache não dizem quais URLs foram visitadas (isso está no DB do próprio navegador), mas a cadência do I/O de cache diz que o usuário estava navegando. Combinar com os eventos FileCreate do journal no Downloads\ do usuário para identificar downloads deliberados.

Atividade de código

Se o usuário é desenvolvedor, rebuilds da IDE produzem rajadas muito características:

  • Webpack/Vite/Turbopack — muitos FileCreate em node_modules\.cache\ e dist\, frequentemente centenas por build.
  • Visual Studio C++FileCreate de .obj e .pdb em subárvores Debug\ ou Release\.
  • Cargo (Rust) — builds incrementais tocam target\debug\incremental\ bastante; builds completos tocam target\debug\deps\.

Uma rajada de 5 minutos de FileCreate em node_modules\ seguida de um enxame de DataExtend sobre um dist\bundle.js é «rodou o build, depois um dev server recarregou».

Downloads e instalações

Um download direto produz:

FileCreate | Close             \Users\<u>\Downloads\<file>.crdownload   (Chrome)
DataExtend | Close             \Users\<u>\Downloads\<file>.crdownload  × N
RenameNewName | Close          \Users\<u>\Downloads\<file>
BasicInfoChange | Close        \Users\<u>\Downloads\<file>

As extensões .crdownload, .part, .download são Chrome, Firefox, Edge respectivamente. A renomeação atômica no final faz o arquivo aparecer como «completo».

A instalação de um novo programa tipicamente segue: FileCreate de um instalador .exe/.msi em Downloads, depois uma rajada de FileCreate em \Program Files\ ou \Program Files (x86)\ ou \Users\<u>\AppData\Local\Programs\. O histograma minuto a minuto torna instalações triviais de identificar.

Juntando tudo: uma timeline diária

A receita para um relatório «o que o usuário fez hoje»:

  1. Puxar o journal parseado do usuário para o dia. Restringir a registros sob \Users\<u>\ para retirar o ruído do sistema.
  2. Calcular, por bucket de 10 minutos: número de FileCreate, DataExtend, BasicInfoChange.
  3. Plotar as três séries. A forma diz a atividade aproximada:
    • Muitos creates + extend: gravar/salvar conteúdo.
    • Apenas muito BasicInfoChange: navegar, rolar, edição leve.
    • Muito extend com pouco create: downloads grandes ou reprodução de mídia.
    • Creates sustentados em diretórios Cache\: navegar.
    • Creates sustentados em node_modules\ / Debug\ / target\: codar.
  4. Anotar os picos inspecionando os nomes de arquivo mais frequentes em cada bucket. Os nomes do Office são ótimas âncoras; os nomes de cache em geral podem ser ignorados.

O parser deste site expõe o histograma por minuto em seu componente timeline — clicar uma barra filtra a tabela para aquela janela, que é o workflow acima sem escrever código.

Armadilhas

  • Backups e escaneamentos AV produzem rajadas de BasicInfoChange em escala de volume que superficialmente parecem atividade do usuário. Geralmente seguem horários agendados e visitam todos os diretórios, não apenas os do usuário, o que os torna fáceis de identificar e excluir.
  • Agentes de sync (OneDrive, Dropbox) geram tráfego de journal que parece atividade do usuário mas é trabalho do próprio agente. Filtrar para registros cujo caminho está fora da pasta de sync para focar no trabalho iniciado pelo usuário.
  • Indexadores em segundo plano (SearchIndexer.exe) tocam arquivos em \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ e \ProgramData\Microsoft\Search\ — fáceis de classificar como ruído de sistema.

Para onde ir depois

O journal sozinho não substitui uma super-timeline adequada. Mas para 80% das investigações, «o que o usuário estava fazendo entre 14:00 e 16:00» é respondível só com $J e $MFT, no tempo que leva para arrastá-los para esta página.