← Voltar ao blog

Anti-forense NTFS: o que atacantes fazem na MFT

· 5 min de leitura

Resposta curta: as técnicas anti-forenses no NTFS visam esconder o que é um arquivo, quando foi tocado ou que ele alguma vez existiu. Nenhuma das técnicas comuns é limpa — cada uma deixa um artefato diferente em $MFT, $UsnJrnl, $LogFile ou snapshots VSS. Este post cataloga as técnicas e os indícios que as derrotam.

Timestomping

O clássico. Ferramentas como SetMACE, timestomp e one-liners PowerShell embutidos chamam SetFileTime ou escrevem $STANDARD_INFORMATION diretamente para fazer um arquivo parecer mais antigo ou mais novo do que é.

O que isso deixa:

  • Os carimbos de tempo de $STANDARD_INFORMATION e $FILE_NAME divergem — SetFileTime só atualiza SI. Veja os quatro carimbos de tempo da MFT.
  • A precisão abaixo do segundo frequentemente é zerada. A atividade natural do Windows deixa frações de segundo; muitas ferramentas de timestomping arredondam para o segundo.
  • Um criado em $STANDARD_INFORMATION mais antigo que o criado em $FILE_NAME é impossível — arquivos não podem existir antes de serem nomeados.

Como detectar: analise $MFT e marque cada registro onde SI e FN discordam por mais de alguns segundos, ou onde SI precede FN. O parser navegador deste site expõe ambos os conjuntos de carimbos de tempo por registro.

Fluxos de dados alternativos (ADS)

O NTFS permite que um arquivo carregue múltiplos atributos $DATA. O sem nome é o arquivo "real"; os nomeados (file.txt:hidden) são fluxos de dados alternativos — invisíveis para o Explorer, invisíveis para o dir e rotineiramente usados para esconder payloads.

O que isso deixa:

  • Um ADS é apenas outro atributo $DATA no mesmo registro MFT. Todo parser que percorre o fluxo de atributos os lista.
  • O ADS Zone.Identifier, adicionado automaticamente pelos navegadores, frequentemente sobrevive em payloads baixados — provando que o arquivo veio da internet e de qual zona de segurança.

Como detectar: dir /R do cmd.exe lista ADS em um sistema vivo. streams.exe do Sysinternals os enumera. O parser MFT os mostra inline com o registro. Veja fluxos de dados alternativos.

Apagar um único arquivo

Wipers sofisticados sobrescrevem os clusters do arquivo e depois excluem o registro MFT. Os menos sofisticados (del /f, SDelete com configurações padrão) sobrescrevem os dados mas deixam o registro MFT no lugar.

O que isso deixa:

  • Um registro MFT excluído com $FILE_NAME e $STANDARD_INFORMATION intactos — o nome e os carimbos de tempo sobrevivem mesmo se os dados se foram. Veja o que sobrevive quando você exclui um arquivo no NTFS.
  • Frequentemente um registro $UsnJrnl para a criação original e a exclusão.
  • Entradas em $LogFile para as operações de metadados.
  • Um snapshot VSS de antes do wipe ainda contendo o arquivo completo.

Como detectar: mesmo um arquivo "apagado" deixa um nome, um caminho e carimbos de tempo em $MFT. Combine com snapshots VSS (snapshots e $MFT) e você frequentemente recupera o conteúdo também.

Apagar o próprio registro MFT

Um atacante mais agressivo escreve um novo arquivo para reutilizar deliberadamente o slot, sobrescrevendo o registro excluído. Isso funciona — o slot se foi — mas a exclusão é em si um evento.

O que isso deixa:

  • O número de sequência do registro foi incrementado. Uma referência de $UsnJrnl ou $LogFile para a sequência antiga agora está obsoleta e lhe diz que o slot foi reutilizado desde então.
  • $UsnJrnl ainda registra tanto a criação/exclusão original quanto a criação do novo arquivo, incluindo um diretório pai diferente se o novo arquivo vive em outro lugar.
  • Cópias de snapshot da $MFT de antes da reutilização ainda contêm o registro original.

Como detectar: cruze $UsnJrnl com a $MFT atual. Uma entrada $UsnJrnl cujo número de sequência do registro alvo agora é maior que a referência da entrada indica uma reutilização.

Truncamento de $UsnJrnl

O journal de mudanças é finito. Um atacante que roda operações barulhentas (muitas gravações de arquivos) pode forçar $UsnJrnl a dar a volta, despejando entradas mais antigas.

O que isso deixa:

  • Um $UsnJrnl que começa mais tarde do que seu parâmetro $Max sugeriria é suspeito.
  • $LogFile não rotaciona da mesma forma e frequentemente ainda registra as operações que empurraram $UsnJrnl para fora.
  • As próprias operações barulhentas deixam milhares de registros MFT — eles são visíveis.

Exclusão de $UsnJrnl

fsutil usn deletejournal /D C: remove o journal por completo. Journals recriados começam com um contador USN novo.

O que isso deixa:

  • Um $UsnJrnl cujo primeiro USN é suspeitamente alto, ou cujo primeiro registro é horas ou minutos antes do incidente.
  • Uma entrada de diretório $Extend cujo número de sequência do registro MFT foi incrementado.
  • Snapshots VSS de antes da exclusão ainda contendo o journal completo.

Renomear para arquivo de sistema

Esconder malware como svchost.exe, lsass.exe ou outro binário familiar do Windows. Não é tecnicamente anti-forense da MFT, mas é o truque mais comum no mundo real para enganar o analista.

O que isso deixa:

  • Um $FILE_NAME cuja referência de diretório pai não é C:\Windows\System32.
  • Um atributo $DATA cujo tamanho e entropia não combinam com a distribuição do binário legítimo.
  • Um ADS Zone.Identifier do download.

Rabiscos na MFT por ransomware

Algumas famílias de ransomware (Petya, NotPetya e um punhado desde então) corrompem deliberadamente $MFT para tornar o volume não montável. Isso é destrutivo em vez de evasivo.

O que isso deixa:

  • Registros BAAD onde deveria estar FILE.
  • Um sistema não inicializável, mas uma imagem forensicamente valiosa — escaneie o volume por assinaturas FILE e a maior parte da tabela continua legível.

Veja padrões de ransomware na MFT para os detalhes.

O princípio geral

Toda técnica anti-forense no NTFS deixa algum artefato. A razão é estrutural: $MFT, $UsnJrnl, $LogFile e VSS cada um registra uma visão diferente dos mesmos eventos, e modificar um deles é em si um evento que os outros registram. Uma triagem que percorre os quatro juntos é difícil de derrotar.

Recursos externos