← Voltar ao blog

Códigos de razão USN — lendo entre os bits

Tour campo a campo pela bitmask de razão dos registros USN_RECORD e o que cada combinação revela sobre o ciclo de vida de um arquivo em disco.

3 min de leitura

Quem passa tempo na forense de Windows acaba decorando a bitmask de razão do USN. É um campo de 32 bits que o NTFS define em cada registro do journal para resumir o que acabou de mudar em um arquivo. Os bits não dizem tudo — são aditivos, não exclusivos — mas, lidos juntos, dão um quadro notavelmente preciso do ciclo de vida.

Os bits

FlagHexO que significa na prática
DataOverwrite0x00000001Uma região do fluxo de dados principal foi sobrescrita
DataExtend0x00000002O fluxo de dados principal cresceu
DataTruncation0x00000004O fluxo de dados principal encolheu
NamedDataOverwrite / Extend / Truncation0x10 / 0x20 / 0x40O mesmo, mas em um fluxo alternativo
FileCreate0x00000100Um novo arquivo ou diretório foi criado
FileDelete0x00000200O arquivo saiu do espaço de nomes
EaChange0x00000400Atributos estendidos modificados
SecurityChange0x00000800ACL/proprietário modificados
RenameOldName0x00001000Metade «antes» de uma renomeação
RenameNewName0x00002000Metade «depois» de uma renomeação
IndexableChange0x00004000Flag indexável alternada
BasicInfoChange0x00008000Timestamps, atributos ou compressão modificados
HardLinkChange0x00010000Hard link adicionado ou removido
CompressionChange0x00020000Compressão NTFS alternada
EncryptionChange0x00040000Estado EFS modificado
ObjectIdChange0x00080000Object ID definido ou limpo
ReparsePointChange0x00100000Reparse point modificado
StreamChange0x00200000Fluxo alternativo adicionado/renomeado/removido
Close0x80000000O handle que produziu a mudança foi fechado

Close é especial: o NTFS coalesce operações sucessivas sob o mesmo handle e só emite o registro final com Close quando o handle vai embora. Um registro sem Close é o sistema escoando estado intermediário — útil, mas o registro com Close é o resumo autoritativo.

Padrões que você verá na natureza

Alguns padrões ocorrem tantas vezes que você deveria reconhecê-los de imediato:

  • Novo arquivo escrito por uma aplicação. FileCreate | DataExtendDataExtend | CloseBasicInfoChange | Close. O último é o arquivo recebendo seu mtime no fechamento.
  • Renomeação entre diretórios. Dois registros no mesmo FileReferenceNumber: RenameOldName | Close e depois RenameNewName | Close. A referência pai difere entre os dois — é assim que você reconstrói o movimento.
  • Salvar-por-renomear atômico. Muitos editores escrevem em um arquivo temporário e depois renomeiam sobre o alvo. Você vê FileCreate no temp, FileDelete | Close no original e RenameNewName | Close no temp.
  • Ransomware cifrar-depois-renomear. Registros DataOverwrite cobrindo megabytes, seguidos de RenameNewName | Close com a nova extensão. A contagem e o ritmo dos DataOverwrite são frequentemente onde você primeiro percebe uma amostra em disco.
  • Quarentena de antivírus. FileDelete | Close imediatamente após um FileCreate recente, tudo sob a mesma MFT entry. O journal fornece a prova de que o AV tocou o arquivo mesmo depois que o arquivo em si sumiu.

O que os bits não dirão

A bitmask de razão fala sobre o arquivo, não sobre o ator. Sem usuário, sem PID, sem linha de comando. Combine o journal com Security.evtx (4663 acesso a objeto) ou com Microsoft-Windows-Sysmon/Operational para anexar um ator a cada operação. O USN dá o quando e o que; outros logs dão o quem.

Receita prática de leitura

Ao abrir um journal parseado:

  1. Filtre FileCreate para ver o que é genuinamente novo na janela temporal.
  2. Procure RenameNewName para capturar movimentação e padrões de «salvar como».
  3. Plote a contagem de DataExtend ao longo do tempo — escritas em massa (backups, criptografia, staging de exfiltração) saltam aos olhos.
  4. Leia primeiro os registros com Close ativo; trate os intermediários como evidência de apoio.

A app web deste site permite filtrar por qualquer combinação de razões, o que torna os passos 1–3 um exercício de um clique.