O aspecto do ransomware no $MFT

O ransomware faz praticamente o mesmo em cada host, de cada vez: enumera ficheiros, lê cada um, escreve uma cópia encriptada, elimina o original. Cada passo aterra no $MFT. Se conhece a forma, consegue confirmar que um incidente é uma execução de ransomware nos minutos seguintes a receber o MFT, sem nunca encontrar o binário nem ler a nota de resgate.

Este é o padrão, as variações que tenho visto, e como separo o ransomware de outras formas de actividade massiva de ficheiros que se parecem superficialmente.

Os três sinais

Mudanças de extensão em massa. Um novo ficheiro aparece com o mesmo directório-pai e o mesmo nome base de um ficheiro existente, mas com uma extensão diferente. report.docx torna-se report.docx.locked, report.encrypted, report.crypted_{guid}, ou report.docx.[victim_id].lockbit. Contar quantos desses pares aparecem numa janela curta é um dos indicadores mais limpos de ransomware no $MFT. Centenas num minuto, no perfil de um único utilizador ou numa partilha, é a assinatura.

Uma rajada de carimbos temporais SI created agrupados em segundos. A actividade normal do utilizador cria ficheiros em saltos de um ou dois. O ransomware cria-os aos milhares. Trace os carimbos SI created como um histograma ao longo da janela suspeita e a execução da encriptação aparece como um pico vertical que apaga a linha de base. A largura do pico diz-lhe quão rápido o ransomware correu (as variantes modernas multi-thread terminam um perfil de utilizador em menos de um minuto; as mais antigas single-thread demoram mais e o pico alarga).

Originais eliminados que correspondem a duplicados encriptados. Para cada report.docx.locked há tipicamente um report.docx correspondente cuja flag IN_USE está agora limpa. O registo eliminado fica no $MFT até o slot ser reutilizado. Pode recuperar o nome, tamanhos e carimbos temporais do original directamente do slot eliminado. Combine isto com os motivos FILE_DELETE do $UsnJrnl na mesma janela e a ordem das operações torna-se inequívoca.

Variações que vale a pena conhecer

Nem todas as famílias seguem o mesmo padrão. As variações que vejo:

• Encriptação no local. Algumas famílias (variantes Sodinokibi mais antigas, certas builds Conti) abrem o ficheiro original, escrevem os bytes encriptados de volta no mesmo ficheiro, e renomeiam. Não existe um ficheiro "cópia encriptada" separado; o padrão do original eliminado desaparece. DATA_OVERWRITE no $UsnJrnl para milhares de ficheiros num minuto continua a ser barulhento, e o rename deixa um par RENAME_OLD_NAME / RENAME_NEW_NAME.
• Encriptação intermitente. O BlackCat e várias famílias recentes encriptam apenas porções do ficheiro (por exemplo, um bloco de 100 KB sim, um não) para acelerar a execução. O tamanho do ficheiro mal muda, o tempo de modificação actualiza-se, mas os clusters $DATA ficam maioritariamente intactos. Parece mais leve no $MFT mas o USN journal continua a mostrar as escritas.
• Apenas renomear. Um punhado de wipers "falso ransomware" renomeia ficheiros sem os encriptar. O padrão no MFT é idêntico ao de uma execução real de ransomware; só a análise do conteúdo do ficheiro distingue um do outro.
• Impacto em drives de rede. Muitas famílias enumeram drives mapeadas e encriptam pela rede. O MFT local mostra menos alterações do que esperaria para um incidente real; o MFT do file server transporta o grosso.

Notas de resgate

A maior parte das famílias deixa uma nota de resgate em cada directório afectado, com um nome como HOW_TO_DECRYPT.txt, README_FOR_DECRYPT.html, restore-files.txt, ou uma variante específica da marca. As notas têm conteúdo idêntico, tamanho idêntico, e tempos de criação agrupados na mesma janela da encriptação. Percorrer o MFT à procura de muitos ficheiros de texto ou HTML do mesmo tamanho espalhados por muitos directórios-pai encontra-as muitas vezes antes de qualquer padrão de nome.

As notas também são forensicamente úteis como linha de base. O seu tempo de criação é essencialmente o carimbo "instante mais cedo em que o ransomware esteve activo neste directório". Se um directório tiver uma nota datada às 02:14 mas ficheiros encriptados às 02:09 no mesmo directório, o ransomware enumerou e encriptou antes de deixar a nota. Isso diz-lhe um pouco sobre o fluxo da família.

O que o $MFT não lhe diz

O MFT confirma o o quê e o quando. Não lhe diz que processo fez a escrita, por onde o operador entrou, ou como o ransomware chegou ao host. Para isso:

• Prefetch, Amcache, e Shimcache para evidência de que executável correu na janela.
• Sysmon Event ID 1 para criação de processo com linha de comandos, pai e hashes.
• Security Event 4688 para criação de processo se a auditoria de linha de comandos estava activada.
• USN journal $J para a ordem precisa das operações de abertura/leitura/escrita/rename/eliminação de ficheiros.
• Dump de RAM se a máquina ainda estiver viva e o processo de encriptação ainda estiver residente. Por vezes apanha-se a chave de encriptação em memória.
• Histórico de browser e artefactos de email para o vector de acesso inicial.

O MFT sozinho responde às perguntas operacionais urgentes: quando começou a execução, quão extensa é, e que ficheiros foram tocados. Isso é o suficiente para tomar a decisão de recuperação. A atribuição é um exercício separado que usa o MFT como input.

Eliminação de VSS como pista

A maior parte das famílias de ransomware tenta eliminar Volume Shadow Copies antes de começar a encriptar, porque os snapshots VSS permitiriam à vítima restaurar sem pagar. O comando habitual é vssadmin delete shadows /all /quiet. Isto deixa:

• Uma entrada no Windows System Event Log (Event ID 8224 para mensagens do serviço VSS).
• Um Sysmon Event ID 1 para a invocação de vssadmin.exe se o Sysmon estiver implantado.
• O estado VSS recente mas vazio no host. vssadmin list shadows devolve nada ou apenas snapshots pós-incidente.

Se vir um host sem snapshots VSS e números de sequência do registo MFT de \$Extend\$UsnJrnl a indicar recriação recente, tem preparação de ransomware mesmo que a execução de encriptação ainda não tenha começado visivelmente. Veja VSS e $MFT para o que ainda pode recuperar.

A sequência de triagem que sigo

1. Puxe $MFT e $UsnJrnl:$J do host suspeito (ou do snapshot, se o VSS ainda tiver um de antes).
2. Analise o MFT com o MFTECmd ou o mft_dump. Ordene SI created descendente. Olhe para as 1.000 primeiras entradas.
3. Se as entradas do topo se agruparem numa janela de minutos e muitas delas tiverem extensões invulgares, tem um footprint de ransomware.
4. Puxe os registos eliminados correspondentes. Os seus atributos $FILE_NAME dão-lhe os nomes de ficheiro originais. Agora sabe o que foi encriptado.
5. Cruze com o USN journal. FILE_CREATE para o ficheiro encriptado mais FILE_DELETE para o original no mesmo instante confirma o padrão.
6. Identifique a nota de resgate: um ficheiro pequeno com um nome invulgar (HOW_TO_DECRYPT, RECOVERY, README_RESTORE) que aparece em muitos directórios ao mesmo tempo. O seu conteúdo nomeia a família.
7. Salte do nome da família para IOCs conhecidos: hashes de ficheiro, domínios C2, persistência no registo, e artefactos de kill chain conhecidos nos outros logs.

Essa sequência demora geralmente menos de trinta minutos num único host e dá-lhe o suficiente para decidir contenção e começar o planeamento de recuperação.

Leituras adicionais

• Os estudos de caso de ransomware do DFIR Report. Cada writeup emparelha evidência de MFT e journal com o resto da kill chain.
• Análises técnicas de LockBit, BlackCat, Cl0p no The Record e no Microsoft Security Blog. Os footprints específicos de cada família no MFT diferem nos detalhes.
• MITRE ATT&CK, T1486 Data Encrypted for Impact. O catálogo de técnicas para o que o ransomware faz e os artefactos que cada comportamento deixa.