Cada registo MFT guarda quatro carimbos temporais em dois atributos separados. Isso são oito números por registo. Nem sempre estão em sincronia. A relação entre eles, e onde ela se quebra, é a base da análise temporal em NTFS. Se for aprender apenas um detalhe da forense em MFT, aprenda este.
Os quatro momentos que o NTFS regista
Tanto $STANDARD_INFORMATION (SI, tipo de atributo 0x10) como $FILE_NAME (FN, tipo de atributo 0x30) transportam carimbos temporais para os mesmos quatro eventos:
- Created: quando o ficheiro foi escrito pela primeira vez no volume.
- Modified: quando o conteúdo do ficheiro mudou pela última vez.
- Accessed: quando o ficheiro foi lido pela última vez.
- MFT-modified: quando o próprio registo foi actualizado pela última vez (qualquer alteração de atributo, não só de dados).
Os carimbos são guardados como valores de 64 bits no formato Windows FILETIME (ticks de 100 nanossegundos desde 1601-01-01 UTC). Granularidade de 100 nanossegundos. Bits suficientes para que eventos naturais deixem ruído nos dígitos mais baixos.
Porque existem dois conjuntos
O $STANDARD_INFORMATION é o conjunto de carimbos temporais que o espaço de utilizador vê. A API Win32 SetFileTime escreve aqui. Cada operação rotineira de ficheiro que toque num carimbo actualiza o SI: escrita, leitura (dependendo da configuração do access-time), rename, alteração de atributo.
O $FILE_NAME foi adicionado por compatibilidade com o subsistema POSIX nos primórdios do NT e persiste por razões históricas. É actualizado apenas quando o nome muda: criação (quando o nome é definido pela primeira vez), rename (quando o nome muda), ou movimento entre directórios (que é um rename no sentido NTFS). Depois disso, o FN fica imutável enquanto o ficheiro mantiver esse nome.
Na prática isto significa que os carimbos SI tiquetaqueiam constantemente enquanto os FN permanecem estáveis. A assimetria é o que torna o timestomping detectável.
O que o timestomping faz
As ferramentas que alteram carimbos chamam geralmente SetFileTime. Isso escreve no SI. Não toca no FN. Depois do timestomping:
- O SI mostra o que o atacante escolheu. Frequentemente recuado anos (para fazer uma ferramenta recém-largada parecer um ficheiro de sistema) ou empurrado para a frente (para obscurecer o tempo real da actividade).
- O FN continua a reflectir o tempo real de criação, possivelmente por uma margem larga.
Isto produz a assinatura canónica de timestomping: um ficheiro com SI created em 2018 e FN created há seis minutos.
Dois padrões a vigiar na triagem:
- SI created mais antigo do que FN created. É impossível naturalmente. Os ficheiros não podem existir antes de serem nomeados. Qualquer registo onde SI created antecede FN created foi tocado.
- SI modified longe de FN modified num ficheiro que claramente não foi renomeado. FN modified só se move em renames; se SI diz 2017 e FN diz ontem sem rename pelo meio, algo está errado.
O truque do duplo rename
Operadores que sabem que a divergência SI/FN é detectável usam uma manobra: renomear o ficheiro (o que força o NTFS a actualizar o FN), depois chamar SetFileTime tanto no SI como no FN, depois renomear de volta. Agora ambos os atributos mostram os valores recuados.
Isto derrota a comparação SI/FN. Não derrota:
- O USN journal. Cada rename escreve um par
RENAME_OLD_NAME/RENAME_NEW_NAME. Os dois renames necessários ao truque ficam visíveis no journal. Os seus carimbos no journal são os tempos reais, não os valores FN falsificados. $LogFile. Os registos de transacção em torno do rename ficam no log.- Snapshots VSS. Snapshots mais antigos têm os valores FN pré-stomp. Diferencie o MFT actual contra o MFT do snapshot para o mesmo registo.
O duplo rename é mais difícil de fazer em silêncio. Continua a ser comum em toolkits maduros de red team.
Granularidade abaixo do segundo, a pista da ferramenta preguiçosa
O NTFS guarda carimbos temporais em ticks de 100 nanossegundos. As operações nativas do Windows deixam ruído nos dígitos baixos. O SO não zera a componente abaixo do segundo quando escreve um carimbo; o que o relógio do kernel devolveu é o que fica gravado.
A maioria das ferramentas de timestomping arredonda ao segundo mais próximo antes de escrever. O resultado é um carimbo a terminar em .0000000 UTC. Um carimbo desses, sozinho, não é nada de especial (eventos naturais ocasionais arredondam). Uma coluna de sufixos .0000000 alinhada em muitos ficheiros é uma impressão digital.
É fácil de verificar. Pegue nas colunas created, modified, accessed e MFT-modified da sua análise de MFT. Filtre para qualquer registo onde os quatro carimbos do SI terminam em .0000000. Compare com uma baseline de actividade natural do Windows. O contraste é imediato.
O que o próprio Windows faz aos carimbos
Para usar a comparação SI/FN tem de saber o que o Windows faz por si só aos quatro campos. A cábula:
- SI created: escrito na criação. Actualizado por alguns instaladores quando "criam" um ficheiro ao extrair.
- SI modified: escrito a cada escrita de dados. Actualizado por
SetFileTime. Não actualizado por alterações apenas de metadados. - SI accessed: por omissão desactivado no Windows 7+ (defina
fsutil behavior set disablelastaccess 0para activar). Se desactivado, este campo continua a ser actualizado por certas operações (software de backup, varreduras de EDR), mas não é fiável como sinal de "última leitura" em nenhuma direcção. - SI MFT-modified: escrito em qualquer alteração de atributo, incluindo renames, alterações de ACL, criação de ADS, e escritas de dados.
- FN created: escrito quando o nome é definido pela primeira vez (criação, criação de hard link, rename).
- FN modified, FN accessed, FN MFT-modified: escritos quando o nome é definido, depois estáveis.
Numa instalação limpa, os quatro carimbos do FN tipicamente são iguais entre si (foram todos definidos no mesmo instante em que o nome foi atribuído). Quando vê FN com os quatro carimbos idênticos e os quatro do SI a divergir, isso é normal.
Windows Update e binários alvo de patch
O Windows Update toca nos carimbos SI dos binários a que aplica patch. Após uma actualização cumulativa, metade de \Windows\System32\ tem SI modified com poucos minutos entre si e FN que está estável desde o último service pack. Isto é normal. Trate-o como padrão de baseline, não como actividade anómala.
Cruze com CBS.log e setupapi.dev.log para a janela de aplicação de patches. Se SI diz que o svchost.exe foi modificado às 03:14 e o CBS log mostra uma instalação de componente às 03:14, isso é Windows Update, não um atacante.
Como faço a varredura para timestomping
A varredura que faço numa extracção fresca de MFT:
- Puxar todos os registos onde SI created < FN created. Rever manualmente cada um.
- Puxar todos os registos onde SI modified está mais de 30 dias antes de FN modified e o ficheiro está num directório escrevível pelo utilizador. Rever manualmente.
- Puxar todos os registos onde os quatro carimbos do SI terminam em
.0000000e o ficheiro não é um binário de sistema Windows. Rever manualmente. - Diferenciar o MFT actual contra o snapshot VSS mais recente. Destacar registos cujos carimbos SI andaram para trás. Rever manualmente.
Essa sequência apanha a maioria do timestomping no mundo real. Operadores sofisticados a usar o truque do duplo rename ou eliminação de VSS precisam das camadas de journal e de log de eventos para detectar, mas as quatro verificações acima vão fazê-los emergir através de outros artefactos (o rename no USN journal, a eliminação VSS no log de eventos) na mesma.
Leituras adicionais
- David Cowen, cobertura do Forensic Lunch sobre timestomping. Anos de estudos de caso de praticantes.
- SANS, Windows Time Rules cheatsheet. Referência rápida do que cada operação Windows faz a cada carimbo.
- Notas sobre
$STANDARD_INFORMATIONe$FILE_NAMEdo projecto linux-ntfs. Referência de disposição ao nível do campo.