← Voltar ao blog

Volume Shadow Copy e $MFT: cada snapshot é um MFT congelado

· 8 min de leitura

A maior parte dos analistas pensa nos Volume Shadow Copies como o mecanismo de backup do Windows. São também uma mina de ouro forense, porque cada snapshot contém uma cópia completa e congelada do $MFT no momento em que o snapshot foi tirado. Uma estação com cinco snapshots dá-lhe seis observações independentes do sistema de ficheiros (hoje mais cinco históricas). Cada uma assinada por um caminho de código diferente. Cada uma escrita num tempo diferente. Os diffs entre elas são a coisa mais próxima que se obtém de um registo contínuo de como o volume mudou.

Este post é sobre o que fazer com isso.

O que o VSS captura

O Volume Shadow Copy Service tira snapshots ponto-no-tempo de um volume NTFS. Cada snapshot é um delta copy-on-write: quando um bloco está prestes a ser modificado no volume vivo, o original é preservado primeiro na shadow copy. O snapshot reflecte o volume exactamente como estava no momento da criação, incluindo:

  • $MFT (a tabela inteira na altura do snapshot, com o estado de cada registo como estava então)
  • $UsnJrnl:$J (o journal até esse ponto)
  • $LogFile
  • Cada ficheiro de utilizador (módulo as exclusões VSS, que por omissão incluem pagefile.sys, hiberfil.sys, e o conteúdo de %TMP%)

Num endpoint Windows típico os snapshots são tirados automaticamente:

  • Antes de instalações do Windows Update.
  • Pelo System Restore em alterações de configuração (instalação de driver, certas instalações de software).
  • Por software de backup de terceiros (Veeam, Acronis, ferramentas RMM de MSP).
  • Por aplicações específicas que pedem snapshots antes de operações em massa.

Uma estação com actualizações regulares pode facilmente ter cinco a dez snapshots a recuar vários meses. Um servidor com software de backup pode ter muitos mais.

Porque isto importa para a forense

O MFT vivo é uma observação. Com snapshots, obtém uma série. Cada MFT histórico regista o estado do volume nesse momento, incluindo:

  • Ficheiros que existiam então e foram entretanto eliminados. Recuperáveis na íntegra do snapshot, incluindo os dados de cluster se estavam no âmbito.
  • Ficheiros que existem agora mas estavam ausentes na altura. Prova quando foram introduzidos. Fixe "este ficheiro apareceu entre o snapshot N e o snapshot N+1" e tem uma janela de criação.
  • Registos cujos carimbos temporais diferem de hoje. Expõe renames, movimentações e timestomping que aconteceram no intervalo.
  • Verificação independente do VSS. O snapshot é escrito por um caminho de código separado do volume vivo. Forjar ambos consistentemente é difícil.

Os snapshots são especialmente úteis em casos de ransomware. A maioria das famílias tenta apagar o VSS primeiro, mas por vezes falham snapshots tirados por software de backup de terceiros que usa um writer ID VSS diferente, ou não encontram snapshots em drives externas anexadas. Um único snapshot pré-encriptação dá-lhe os ficheiros originais. Veja padrões de ransomware no MFT.

Listar snapshots

A partir de um PowerShell ou cmd elevado:

vssadmin list shadows

Cada entrada mostra um caminho de Shadow Copy Volume que se parece com \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7. Esse caminho é montável como um volume separado com a mesma estrutura NTFS.

Para mais detalhe (ID de snapshot, tempo de criação, writer VSS):

vssadmin list shadows /for=C:

A partir de uma imagem forense, use libvshadow:

vshadowinfo disk.dd
vshadowmount disk.dd /mnt/shadows

O vshadowinfo enumera snapshots dentro de uma imagem .dd ou .E01. O vshadowmount expõe-os como volumes virtuais individuais (vss1, vss2, ...). Cada um é então analisável como um volume NTFS. Esta é a ferramenta padrão para extracção VSS offline; sem necessidade de máquina Windows.

Extrair o $MFT de um snapshot

Uma vez montado um snapshot (sistema vivo ou via vshadowmount), o $MFT vive no mesmo offset que no volume-pai, na raiz do snapshot. Puxe-o com as mesmas ferramentas que puxam o vivo:

  • fsutil (sistema vivo): fsutil file queryextents \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7\$Mft devolve as extents; uma leitura bruta monta o ficheiro.
  • FTK Imager: adicionar o dispositivo de shadow copy como evidência, navegar até $MFT, exportar.
  • icat do Sleuth Kit (imagem): icat -o <offset> vss1 0 > mft_vss1.bin. O inode 0 é sempre o $MFT.
  • KAPE com o target MFT e a flag --vss. O KAPE corre o target contra cada snapshot enumerado, por turnos, e produz extracções por snapshot em subdirectórios.

Veja extrair o $MFT para a mecânica do sistema vivo.

Comparar dois MFTs

A análise mais barata e útil é um diff. Analise ambos os ficheiros $MFT para CSV (uma linha por registo), ordene por número de registo, e diferencie:

mft_dump -o csv mft_today.bin > today.csv
mft_dump -o csv mft_vss3.bin  > vss3.csv
diff <(sort today.csv) <(sort vss3.csv) > changes.diff

O que está a procurar:

  • Registos presentes em vss3 mas ausentes ou marcados como eliminados em today. Ficheiros eliminados no intervalo. O snapshot tem o registo pré-eliminação; recupere os metadados e (frequentemente) os dados.
  • Registos presentes em today mas ausentes em vss3. Ficheiros introduzidos no intervalo. A sua criação cai entre o snapshot e o agora.
  • Registos cujos carimbos SI andaram para trás. Possível timestomping; o snapshot é a verdade do terreno.
  • Registos cuja referência ao pai em $FILE_NAME mudou. Ficheiro movido para outro directório.
  • Registos onde o número de sequência saltou mais do que 1. O slot foi reutilizado várias vezes no intervalo. Muita agitação ou reutilização deliberada de slot.

O mesmo diff ao nível do $UsnJrnl é ainda mais rico; emparelhe-o com o diff do MFT para um quadro completo. Alguns snapshots terão conteúdo de USN journal que já saiu rotativamente do journal vivo. Combinar journals USN de vários snapshots reconstrói um histórico de actividade mais longo do que o journal vivo sozinho preserva.

Casos que justificaram o esforço

Alguns casos concretos de engagements passados que o diff VSS-MFT resolveu:

  • Uma alegação de "apagado por engano". O utilizador disse que apagou um ficheiro por engano na terça-feira passada. O diff do MFT entre o snapshot de segunda e hoje mostrou que o ficheiro foi de facto renomeado, depois aberto por um processo não-utilizador, e eliminado três dias depois. Uma história diferente.
  • Backdoor persistente que vivia em \Windows\Temp\. O MFT vivo não tinha vestígio; o script de limpeza correu. O snapshot de duas semanas antes tinha o binário em $DATA residente. O hash bateu certo com uma família de malware conhecida.
  • MFT pré-ransomware. Uma execução de ransomware encriptou tudo no disco C:. vssadmin delete shadows tinha corrido, mas um snapshot accionado pelo Veeam num writer ID diferente sobreviveu. MFT pré-encriptação recuperado, originais restaurados, sem pagamento.

O VSS é o artefacto que transforma triagem ponto-no-tempo numa série. Recompensa o esforço de o adquirir devidamente.

Limites

Os snapshots podem ser eliminados. vssadmin delete shadows /all é uma linha para limpar tudo e está em todos os playbooks modernos de ransomware. Snapshots já despejados foram-se. O VSS mantém um máximo fixo (por omissão 64 por volume, na prática frequentemente menos com base no espaço em disco).

Os snapshots não são pontos no tempo arbitrários. Obtém o que foi agendado ou o que um instalador despoletou. Raramente há um snapshot no momento exacto de um incidente. O mais próximo geralmente está dentro de um dia para uma estação com patches regulares, dentro de horas para um servidor com software de backup.

Os dados residentes em $MFT mais antigos não são preservados para além do snapshot. Se um ficheiro existia num snapshot e era suficientemente pequeno para ser residente, esse snapshot tem os bytes. Não espere recuperá-los de qualquer snapshot tirado depois da eliminação.

Os caminhos excluídos não estão nos snapshots. %TMP%, pagefile.sys, certas exclusões de volume shadow copy no registo significam que alguns artefactos forenses não são preservados. Os artefactos de pagefile e dump de RAM cobrem o que o VSS não cobre.

Os snapshots não são crash-consistent entre processos. Um snapshot captura o volume num momento, mas não coordena com aplicações. Ficheiros abertos (bases de dados especialmente) podem estar em estados inconsistentes no snapshot. O próprio NTFS é journalled e consistente; o que está dentro dos ficheiros é o que a aplicação tinha flushed naquele momento.

Perguntas frequentes

Posso ler um snapshot VSS a partir de Linux?

Sim. O libvshadow é multiplataforma. Monte a imagem com vshadowmount, e depois qualquer ferramenta ciente de NTFS lê os volumes de snapshot como ficheiros normais.

Os snapshots incluem ficheiros de sistema como o $MFT?

Sim. Um snapshot VSS captura cada bloco no volume na altura do snapshot, incluindo os ficheiros de metadados no início do $MFT. É precisamente por isso que os snapshots são úteis.

Quantos snapshots o Windows mantém?

Até 64 por volume por omissão. A definição é MaxShadowCopies no registo e raramente é personalizada. Em servidores com software de backup, o limite efectivo é geralmente o que o software de backup mantém.

Os dados de shadow copy são resilientes à limpeza?

Resilientes a eliminar ficheiros individuais no volume vivo, é esse o ponto. Não resilientes a vssadmin delete shadows, wipe de disco completo, dano físico no suporte, ou actor hostil com privilégios de admin.

E os snapshots em drives externas?

Menos comuns mas existem. Drives externas configuradas para File History ou com o seu próprio software de backup podem ter snapshots. Procure caminhos \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN para qualquer volume em vssadmin list shadows /for=<drive>:.

Leituras adicionais

Artigos relacionados

Recursos externos