← Voltar ao blog

Anti-forense em NTFS: o que os atacantes fazem de facto e o que os entrega

· 8 min de leitura

Toda a técnica anti-forense em NTFS deixa algo para trás. A razão é estrutural. O MFT, o USN journal, o $LogFile, e as Volume Shadow Copies cada uma regista uma vista diferente dos mesmos eventos, e modificar uma é em si um evento que as outras registam. Um atacante que se esconda de um artefacto quase sempre acende outro. Um defensor que percorra os quatro em conjunto é duro de bater.

Este é o catálogo. Para cada técnica: o que os atacantes fazem, que resíduo deixa, e que artefacto os entrega.

Timestomping

O clássico. Ferramentas como SetMACE, timestomp, os bem conhecidos scripts PowerShell Invoke-TimeStomp e qualquer número de helpers de red team chamam SetFileTime ou escrevem $STANDARD_INFORMATION directamente para fazer um ficheiro parecer mais velho ou mais novo do que é. Variantes recentes também tocam no $FILE_NAME renomeando o ficheiro (o que força o NTFS a actualizar o FN) e depois renomeando de volta. O truque do "duplo rename" é o que separa um operador competente de um script kiddie.

O que o entrega:

  • Divergência SI/FN. O SetFileTime simples só toca no SI. Os carimbos temporais FN correspondentes continuam a ser os tempos reais de criação/rename. Veja os quatro carimbos temporais do MFT. Qualquer registo onde SI created está a mais do que poucos segundos do FN created é suspeito. Quando SI created antecede FN created, é impossível naturalmente: os ficheiros não podem existir antes de serem nomeados.
  • Granularidade abaixo do segundo. O NTFS guarda carimbos temporais em ticks de 100 nanossegundos. As operações nativas deixam ruído nos dígitos mais baixos. A maior parte das ferramentas de timestomping arredonda ao segundo. Uma coluna de sufixos .0000000 alinhados certinhos em vários ficheiros é uma impressão digital.
  • Verdade do $UsnJrnl. O USN journal regista o tempo de modificação real quando as entradas são escritas. Um DATA_OVERWRITE USN para o atributo $DATA de um registo com um carimbo temporal que discorda do SI modified do MFT é timestomping apanhado em flagrante.
  • Snapshots VSS. As Volume Shadow Copies mais antigas guardam os valores pré-stomp. Diferencie o $MFT actual contra o $MFT do snapshot para o mesmo registo e a mudança é visível.

O truque do duplo rename derrota a divergência SI/FN. Não derrota entradas do USN journal nem diffs de VSS.

Alternate Data Streams como esconderijo de payload

Um atributo $DATA com nome (legit.docx:payload.exe) é invisível para o Explorador, invisível para o dir, e usado rotineiramente para guardar executáveis, scripts ou configuração codificada que o ficheiro visível não denuncia. Lançado via wmic process call create, rundll32, ou Get-Content -Stream mais Invoke-Expression.

O que o entrega:

  • Percorrer o MFT expõe todos os atributos $DATA. A enumeração ficheiro a ficheiro falha streams em ficheiros que não pensou em verificar. O MFT não. Veja alternate data streams.
  • Sysmon Event ID 15 (FileCreateStreamHash) é o único evento do Sysmon que faz hash à criação de ADS. Se o Sysmon estiver implantado e configurado, apanha o drop de streams directamente.
  • Zone.Identifier. Downloads a partir de um browser carregam este ADS. Um binário que não o tem em \Downloads\ ou nunca veio de um browser ou foi deliberadamente despido (Unblock-File).

Limpar um único ficheiro

Wipers sofisticados sobrescrevem os clusters do ficheiro e depois eliminam o registo do MFT. Os menos sofisticados (SDelete em modo por omissão, cipher /w, del /f) sobrescrevem os dados mas deixam o registo do MFT no lugar.

O que o entrega:

  • O próprio registo do MFT. Um registo eliminado com $FILE_NAME e $STANDARD_INFORMATION intactos ainda nomeia o ficheiro, dá o directório-pai, e mostra os carimbos temporais no momento da eliminação. Veja o que sobrevive a uma eliminação.
  • Entradas $UsnJrnl de criação e eliminação. Ambos os eventos são registados independentemente de os dados terem sido limpos.
  • $LogFile. Os registos de transacção para as operações de metadados ficam lá até serem reciclados.
  • Snapshots VSS. Se existia um snapshot antes da limpeza, o ficheiro está intacto dentro dele.

Limpar o próprio registo do MFT

Um atacante mais agressivo escreve novos ficheiros especificamente para forçar o NTFS a reutilizar o slot, sobrescrevendo o registo eliminado. Isto consegue: o slot desaparece. A eliminação continua a ser um evento.

O que o entrega:

  • Incremento do número de sequência. Uma referência do $UsnJrnl ou do $LogFile ao registo R sequência S está agora obsoleta; o registo actual é sequência S+1. Um cruzamento expõe a reutilização.
  • Histórico do $UsnJrnl. A criação, modificação e eliminação originais continuam registadas. A criação do novo ficheiro também. A reutilização deixa um rasto USN.
  • Snapshots VSS. Cópias do $MFT em snapshot anteriores à reutilização ainda guardam o registo original na sequência S.

Truncamento do $UsnJrnl

O change journal é finito. Um atacante a correr operações ruidosas (muitas escritas de ficheiro) pode forçar o $UsnJrnl a dar a volta, expulsando entradas mais antigas. O tamanho por omissão é 32 MB na maioria das instalações; maior em Server.

O que o entrega:

  • Um $UsnJrnl curto com um USN inicial alto. Se o primeiro registo do journal está horas ou minutos antes do incidente num host que esteve online há semanas, foi rodado de forma não natural e rápida. Calcule a taxa esperada.
  • O $LogFile não roda da mesma forma. É dimensionado pelo volume e sobrescreve por uma política diferente. Operações que empurraram o USN journal para fora estão por vezes ainda no $LogFile.
  • As próprias operações ruidosas deixam milhares de registos no MFT. Os milhares de ficheiros agitados necessários para dar a volta ao journal são visíveis no $MFT. A técnica é barulhenta.

Eliminação do $UsnJrnl

fsutil usn deletejournal /D C: remove o journal por inteiro. O journal recriado começa com um contador USN fresco. O número de sequência do registo MFT $Extend\$UsnJrnl incrementa para reflectir a eliminação-e-recriação.

O que o entrega:

  • Primeiro USN suspeitosamente alto ou primeiro registo suspeitosamente recente. Um $UsnJrnl recém-criado cujo primeiro registo é posterior ao incidente é uma pista.
  • Número de sequência da entrada do directório $Extend incrementado. O registo MFT do próprio $UsnJrnl tem uma sequência mais alta do que o baseline.
  • Snapshots VSS. Os snapshots anteriores à eliminação ainda contêm o journal original completo. Monte-os com vshadowmount e extraia.

Renomear malware para um nome de ficheiro de sistema

Esconder uma ferramenta como svchost.exe, lsass.exe, cmd.exe, ou outro binário familiar do Windows. Não é estritamente anti-forense de MFT, mas é o truque mais comum no mundo real para confundir analistas.

O que o entrega:

  • Referência ao directório-pai em $FILE_NAME. O svchost.exe legítimo vive em C:\Windows\System32. Um ficheiro com esse nome em \Users\bob\AppData\Local\Temp\ não é ele. Verifique a referência ao pai, não só o nome.
  • Tamanho e hash do $DATA. O binário legítimo é bem conhecido. Faça SHA-256 ao impostor e compare. As discrepâncias são imediatas.
  • ADS Zone.Identifier se foi descarregado.
  • Assinatura de código. Os binários da Microsoft estão assinados. Verifique a assinatura Authenticode no ficheiro em disco; o impostor não terá uma ou terá uma não-Microsoft.

Menos comum mas vale a pena saber. Múltiplos atributos $FILE_NAME no mesmo registo MFT permitem a um atacante ter o mesmo payload a aparecer em dois directórios ao mesmo tempo. Eliminar de um remove apenas um $FILE_NAME; o ficheiro vive até o último link sair.

O que o entrega:

  • Campo hardlink_count no cabeçalho do registo. Se um registo tem contador > 1, cada $FILE_NAME é um dos links. O MFT mostra todos.
  • Motivo HARD_LINK_CHANGE no $UsnJrnl na criação e remoção de hard links.

Manipulação do $LogFile

O fsutil não oferece uma opção "apagar o ficheiro de log", mas o log roda por si e operações que enchem o volume podem empurrar entradas para fora. Operadores sofisticados ocasionalmente tentam esfregar o $LogFile para remover registos de transacção em torno de um incidente.

O que o entrega:

  • O $LogFile está bloqueado enquanto o Windows corre. Mexer requer desmontar o volume, o que é em si um evento.
  • Snapshots VSS anteriores à manipulação ainda guardam o log completo.

Garatujas de ransomware no MFT

Algumas famílias de ransomware (Petya, NotPetya, um punhado desde então) corrompem deliberadamente o $MFT para tornar o volume impossível de montar. Isto é destrutivo em vez de evasivo; o objectivo é negação de serviço, não furtividade.

O que o entrega:

  • Registos BAAD onde devia estar FILE. A lápide do chkdsk para registos irreparáveis é o que o NTFS deixa após a limpeza. Por vezes o que faz a garatuja não escreve BAAD, caso em que os registos ficam não analisáveis mas ainda procuráveis por assinatura.
  • Um sistema que não arranca, mas uma imagem forense valiosa. Os clusters de dados estão geralmente intactos. Faça varredura por assinatura do volume para registos FILE e a maior parte da tabela é legível. Veja padrões de ransomware no MFT para os detalhes.

O princípio geral

Toda a técnica anti-forense em NTFS deixa um artefacto algures. A razão é estrutural: $MFT, $UsnJrnl, $LogFile e VSS cada um regista uma vista diferente dos mesmos eventos. O atacante que esfrega o MFT deixa entradas USN. O atacante que elimina o USN journal deixa um bump no número de sequência fresco em $Extend\$UsnJrnl e snapshots VSS intactos. O atacante que corre vssadmin delete shadows deixa entradas no Windows Event Log (System 8224, Application VSS 8194) e possivelmente Sysmon Event ID 1 para a invocação de vssadmin.exe.

Uma triagem que percorre os quatro artefactos NTFS mais os logs de eventos e o VSS é o que apanha operadores sofisticados. A triagem de artefacto único falha-os.

Leituras adicionais

Artigos relacionados

Recursos externos