Detectar timestomping e antiforense no journal USN

Os operadores que ligam ao seu tradecraft não se limitam a eliminar evidência. Camuflam o que deixam para trás. O movimento mais comum é o timestomping — reescrever os timestamps de um ficheiro NTFS para que pareça inócuo, ou para que envelheça para fora da janela de investigação. Funcionou de forma fiável durante anos. Com o journal USN activado, como está por defeito em todos os hosts Windows modernos, deixa uma assinatura tão característica que um único filtro e uma resolução de caminho pai a fazem aparecer.

Este artigo percorre o que o timestomping faz no disco, como o journal o expõe, e que outros movimentos antiforenses se podem apanhar com o mesmo artefacto, de borla.

Uma revisão rápida dos timestamps NTFS

Cada entrada MFT carrega timestamps em dois atributos:

• $STANDARD_INFORMATION (SI). Os timestamps que as ferramentas de espaço de utilizador e a maioria das APIs lê e escreve. dir, Explorador, Get-ChildItem, os.stat, GetFileTime — todas devolvem SI. A Microsoft documenta o layout na referência File Times do NTFS.
• $FILE_NAME (FN). Os timestamps que o NTFS define internamente para cada atributo $FILE_NAME (um ficheiro pode ter vários nomes se tiver hard links). Os valores de FN são muito mais difíceis de mudar — só actualizam em operações específicas e o kernel não expõe uma API limpa para os reescrever.

As ferramentas de timestomping visam SI por defeito. O antigo timestomp.exe do Metasploit, o SetMACE e dezenas de implants personalizados feitos por operadores com tradecraft mesmo modesto reescrevem $STANDARD_INFORMATION via NtSetInformationFile com um payload FileBasicInformation. Os implants modernos (incluindo o comando timestomp do Cobalt Strike) também conseguem reescrever FN manipulando directamente o MFT, o que é mais elaborado e produz evidência adicional em $LogFile.

Em qualquer dos casos, o acto de escrever a entrada MFT acende o journal.

O que o journal regista para uma edição de timestamp

Quando os timestamps SI são escritos, o NTFS emite um registo BasicInfoChange | Close no FileReferenceNumber do ficheiro. Esse registo é o diagnóstico:

• Um touch legítimo produz BasicInfoChange | Close juntamente com um DataExtend ou DataOverwrite da escrita real que despoletou a actualização do timestamp.
• Um timestomp produz um BasicInfoChange | Close isolado sem qualquer escrita anterior no mesmo FileReferenceNumber.

Quando vir BasicInfoChange | Close sem DataOverwrite, DataExtend, FileCreate ou rename na mesma sessão de handle, está a olhar para manipulação de metadados. A grande maioria são timestomping; o restante são alternâncias de atributos (+H, +R, compressão on/off) e alterações de estado EFS.

A comparação SI vs FN

A detecção de timestomping mais autoritativa compara os timestamps SI de cada ficheiro com os seus timestamps FN. O padrão remonta à investigação forense Windows inicial da Mandiant e está coberto no File System Forensic Analysis de Brian Carrier. As formas que devem fazer parar:

• SI anterior a FN. Um ficheiro não pode legitimamente ter sido modificado antes do seu nome existir. Esta é a prova reveladora canónica.
• SI no futuro de FN por uma margem irrealista. Operador a empurrar a idade aparente para a frente para se fazer passar por ficheiro de sistema de uma instalação limpa.
• Tanto SI como FN parecem impossivelmente limpos — segundos redondos, valores M/A/C/B idênticos, todos a corresponder a uma data conhecida de instalação Windows. Vale a pena uma análise mais atenta mesmo quando nenhum par individual é sinalizado.

O journal complementa a comparação em vez de a substituir. A comparação MFT diz que algo mexeu nos timestamps. O journal diz exactamente quando aconteceu a reescrita do SI, que é o timestamp que se coloca no relatório. Combine os dois e o caso escreve-se sozinho:

1. A comparação MFT sinaliza SI < FN em \Windows\System32\drivers\suspicious.sys.
2. O journal tem um BasicInfoChange | Close no FileReferenceNumber do ficheiro às 2026-04-12 03:08:14Z sem escritas circundantes.
3. Esse timestamp é quando o operador correu o seu comando timestomp. Correlacione com o evento 1 do Sysmon e tem o processo.

$LogFile e o journal devem concordar

O journal regista escritas ao nível do ficheiro. $LogFile regista as transacções MFT subjacentes ao nível da escrita de metadados. Um timestomp produz:

• Uma transacção de escrita MFT em $LogFile, a modificar o atributo $STANDARD_INFORMATION da entrada alvo.
• Um BasicInfoChange | Close no journal.

Se $LogFile mostrar uma transacção de actualização MFT num ficheiro sem o BasicInfoChange | Close correspondente no journal, o operador pode ter eliminado o registo do journal limpando o $UsnJrnl e criando um novo. Essa manobra é possível (fsutil usn deletejournal /D /N C: seguido de fsutil usn createjournal /m ... /a ... C:), mas é em si barulhenta.

Outros movimentos antiforenses que o journal apanha

Desactivar ou limpar o journal

fsutil usn deletejournal /D /N C: remove o journal por completo. Após correr:

• O ficheiro do journal é reconstruído vazio. Registos anteriores à chamada perdem-se para sempre.
• A entrada MFT de $UsnJrnl é reescrita de novo, o que $LogFile regista.
• O log de segurança regista um evento de Sensitive Privilege Use para SeRestorePrivilege ou SeManageVolumePrivilege, se houver SACLs configurados (o que geralmente não há).

O journal não pode dizer o que continha antes, mas o acto de o desactivar é por si só um sinal forte de antiforense. A Microsoft documenta os comandos de gestão na referência fsutil usn.

Os operadores que sabem que o journal existe tendem a fazer uma de duas coisas: limpá-lo à saída (barulhento), ou evitar deixar evidências nele de forma selectiva (mais difícil, exige ficar fora do disco). Num host onde o journal está suspeitosamente vazio em redor de uma janela de incidente conhecida, trate isso como hipótese a testar.

Fluxos de dados alternativos

A ocultação por ADS é mais velha que eu, e o journal regista-a de forma limpa. O bit de razão StreamChange dispara quando um fluxo de dados alternativo é adicionado, renomeado ou removido de um ficheiro. Filtre por StreamChange e cada evento de criação/modificação de ADS no volume aparece.

Falsos positivos esperados: fluxos Zone.Identifier legítimos de downloads do browser (emparelhados com o FileCreate do ficheiro host), fluxos Mark-of-the-Web de clientes de email, e o estado do SmartScreen. Qualquer outra coisa que produza registos StreamChange em binários de sistema assinados, em ficheiros em \Windows\System32\, ou em binários do perfil de utilizador fora do fluxo normal de descarregamento por browser merece atenção.

Truques com hard links

HardLinkChange dispara quando hard links são adicionados ou removidos. Por vezes os operadores usam hard links para tornar um binário malicioso acessível a partir de dois pais, o que pode derrotar regras AppLocker e controlos EDR baseados em caminhos. Pivote em FileReferenceNumber para ver todos os pais de um dado inode.

Abuso de reparse points

ReparsePointChange ilumina-se quando um reparse point — junction, symbolic link, mount point — é adicionado, modificado ou removido. Procure reparse points a serem criados em \$Recycle.Bin\, \Users\Default\, \ProgramData\ ou outras localizações onde normalmente não existiriam. O parser da reciclagem é o artefacto complementar do lado de $Recycle.Bin.

Alterações de segurança e de object ID

SecurityChange expõe reescritas de ACL e de owner. ObjectIdChange expõe as manipulações mais raras de object ID. Ambas são quietas num host saudável. Rajadas de qualquer uma em binários do perfil de utilizador ou em ficheiros de sistema merecem investigação.

Um procedimento prático de varredura

A triagem mais rápida para timestomping com um journal parseado:

1. Filtre os registos cuja máscara de razão é exactamente BasicInfoChange | Close. A maioria dos parsers, por defeito, faz "contém o bit"; para esta varredura quer correspondência exacta.
2. Para cada candidato, observe os cinco minutos anteriores de registos no mesmo FileReferenceNumber. Se não houver DataOverwrite, DataExtend, FileCreate ou rename, sinalize o registo.
3. Para os registos sinalizados, calcule o delta SI-vs-FN no MFT. Ordene pelo delta absoluto.

O topo da lista é o seu timestomping. As restantes entradas sinalizadas são normalmente invocações de attrib +H ou attrib +R, ou scripts a alternar read-only — dependentes do contexto, raramente interessantes para uma investigação típica de IR, mas vale a pena manter na saída ordenada por completude.

O parser desta página expõe filtragem por máscara exacta. Para o passo 3, precisa de um $MFT parseado aberto ao lado — a maioria dos analistas usa o MFTECmd do Eric Zimmerman para a exportação CSV e o pivot numa folha de cálculo.

O que não consegue apanhar por esta via

Uma lista curta de movimentos antiforenses que contornam totalmente o journal:

• Arrancar a partir de media externo e reescrever o disco. Nunca tocou no SO em execução, nunca escreveu no journal.
• Reescritas userland de ficheiros que preservam o tamanho do conteúdo no mesmo offset sem actualização do SI. Produz registos DataOverwrite mas perde o conteúdo original. O journal vê a escrita, não o que estava lá antes.
• Desactivar o journal antes de fazer qualquer outra coisa. O journal só pode registar o que aconteceu enquanto estava a correr.

Para esses casos, precisa de $LogFile, Volume Shadow Copies, telemetria fora do host, ou um dump de RAM adquirido suficientemente próximo do incidente para ainda conter o estado relevante.

Leituras adicionais

• Microsoft Learn — File Times e a referência da API NtSetInformationFile. Esta última é a syscall que toda a ferramenta de timestomping acaba por chamar.
• MFTECmd do Eric Zimmerman — o parser offline canónico para timestamps SI e FN num CSV plano.
• A documentação do libfsntfs de Joachim Metz — a referência aberta mais completa sobre os internals do $LogFile, que é a segunda testemunha quando o journal só não chega.
• Brian Carrier, File System Forensic Analysis — o capítulo sobre atributos de metadados NTFS continua a ser a referência canónica para o comportamento de SI e FN sob diferentes operações.