Ransomware invisível: detectando criptografia intermitente via entropia de bloco

O cenário é familiar para qualquer engenheiro de confiabilidade de site (SRE) ou administrador de storage veterano: os sistemas de monitoramento estão verdes. A utilização da CPU está nominal. O throughput de I/O nos arrays All-Flash não apresenta picos anômalos que sugiram uma exfiltração em massa ou reescrita total. No entanto, os chamados de suporte começam a chegar. Bancos de dados não montam. Arquivos PDF abrem como páginas em branco ou corrompidas.

Você não está enfrentando um script kiddie rodando um binário mal otimizado. Você está sob ataque de uma variante moderna de ransomware que utiliza criptografia intermitente. Ao contrário das abordagens de "força bruta" que criptografam cada bit de um arquivo, essa técnica opera cirurgicamente, visando apenas blocos específicos de dados. Para o kernel do sistema operacional e para os controladores de disco, isso se parece assustadoramente com tráfego legítimo de atualização de dados.

Neste artigo, vamos dissecar como essa técnica evade a detecção tradicional e como podemos utilizar a análise de entropia de Shannon diretamente no fluxo de gravação de blocos para identificar a assinatura desse ataque antes que o volume inteiro seja comprometido.

Resumo em 30 segundos

• O Problema: O ransomware moderno criptografa apenas partes do arquivo (ex: a cada 16 bytes ou apenas cabeçalhos) para evitar picos de I/O e alertas de CPU.
• A Ciência: Dados criptografados possuem entropia máxima (próxima de 8 bits/byte). Monitorar a aleatoriedade dos blocos gravados revela o ataque.
• A Solução: Implementar análise de entropia no nível de bloco (via eBPF ou firmware de SSD) permite distinguir gravações legítimas de injeção de ruído criptográfico.

O padrão de sombra no subsistema de disco

A criptografia total de arquivos é um processo caro computacionalmente e barulhento em termos de I/O. Em um ambiente Enterprise com petabytes de dados, criptografar tudo leva tempo suficiente para que contramedidas sejam ativadas. A criptografia intermitente resolve esse "problema" para o atacante.

A lógica é simples: para tornar um arquivo de banco de dados de 100GB inutilizável, não preciso criptografar 100GB. Preciso apenas destruir o cabeçalho, a tabela de alocação interna e faixas alternadas de dados a cada N megabytes.

Figura: Comparação visual entre um arquivo íntegro e um submetido à criptografia intermitente, destacando o padrão de salto (skip-step) nos blocos de dados.

Do ponto de vista do subsistema de armazenamento, isso gera uma assinatura de I/O muito mais sutil. Em vez de uma leitura sequencial seguida de uma gravação sequencial massiva (o padrão clássico), vemos padrões de I/O aleatório (Random Write) que se misturam facilmente com cargas de trabalho de bancos de dados transacionais ou máquinas virtuais ativas.

⚠️ Perigo: Ferramentas de detecção baseadas em "taxa de alteração de arquivos" ou "consumo de IOPS" são estatisticamente cegas para criptografia intermitente. Um ataque que altera apenas 3% dos blocos de um disco pode destruir 100% da integridade lógica dos dados armazenados.

Por que a detecção baseada em extensão e CPU falha

Historicamente, defendíamos o storage monitorando a extensão dos arquivos (ex: .locked, .cry) ou picos de uso de CPU causados pelo processo de criptografia AES. Em infraestruturas modernas baseadas em NVMe e processadores de muitos núcleos, essas métricas são irrelevantes.

1. Saturação de NVMe: Um array NVMe moderno pode sustentar gigabytes por segundo de gravação. O gargalo não é mais o disco. O ransomware pode criptografar (intermitentemente) na velocidade máxima do link PCIe sem causar iowait perceptível.

2. Mascaramento de Extensão: Variantes sofisticadas não alteram a extensão do arquivo até que o processo termine, ou sequer a alteram. Elas corrompem o conteúdo mantendo o nome original.

3. Eficiência de CPU: Com instruções AES-NI presentes em quase todas as CPUs modernas, o custo de ciclo para criptografar dados é irrisório. O pico de CPU se perde no ruído de fundo de um servidor de aplicação ocupado.

Precisamos descer o nível da análise. Não podemos confiar no nome do arquivo ou no comportamento do processo no user space. Precisamos olhar para os dados que estão aterrissando no prato do disco ou na célula NAND.

A matemática forense: Entropia de Shannon

A entropia de Shannon mede a imprevisibilidade da informação contida em uma mensagem. No contexto de armazenamento, medimos a aleatoriedade dos bits dentro de um bloco de disco (geralmente 4KB).

A escala varia de 0 a 8:

• 0: Todos os bits são idênticos (ex: um bloco cheio de zeros).

• 3-5: Texto simples, código fonte, logs não comprimidos.

• 7.5-7.9: Dados comprimidos, binários executáveis densos.

• ~8.0: Dados criptografados ou ruído branco perfeito.

A criptografia forte (AES-256) é projetada para tornar a saída indistinguível de dados aleatórios. Portanto, um bloco criptografado terá uma entropia consistentemente muito próxima de 8.

Figura: Gráfico de entropia de Shannon em um fluxo de gravação: dados normais oscilam entre 3 e 5, enquanto blocos criptografados atingem um platô próximo a 8.0.

Implementando a análise no fluxo de gravação

Para detectar o ataque em tempo real, precisamos calcular a entropia dos buffers de gravação antes (ou imediatamente após) eles serem submetidos ao dispositivo de bloco.

Se analisarmos um fluxo de gravação onde, subitamente, uma sequência de blocos atinge entropia 7.99+ em endereços lógicos (LBA) que anteriormente continham dados de baixa entropia (como logs ou documentos de texto), temos um indicador de compromisso de alta fidelidade.

💡 Dica Pro: Não tente calcular a entropia de todo o disco. O custo de I/O de leitura seria proibitivo. O segredo é a amostragem no caminho de gravação (write path). Analise o buffer de memória antes do flush para o disco.

O desafio da distinção: compressão ou ataque?

O falso positivo clássico na análise de entropia é a compressão. Um arquivo ZIP ou um backup comprimido também terá alta entropia. Como diferenciar um usuário salvando um .tar.gz de um ransomware criptografando um .docx?

A resposta está nos metadados e no padrão de acesso:

1. Sobrescrita vs. Novo Arquivo: A compressão legítima geralmente cria um novo arquivo ou anexa dados ao final de um fluxo. O ransomware tende a realizar sobrescrita in-place (abrir arquivo existente, buscar offset, gravar dados criptografados, fechar).

2. Cabeçalhos de Arquivo (Magic Numbers): Arquivos comprimidos possuem cabeçalhos identificáveis no primeiro bloco. Dados criptografados por ransomware geralmente destroem o cabeçalho original e o substituem por ruído ou uma assinatura proprietária do malware.

3. Granularidade: A criptografia intermitente cria um padrão de "pente" (alta entropia, baixa entropia, alta entropia). A compressão é contínua.

Tabela Comparativa: Compressão Legítima vs. Criptografia Maliciosa

Característica	Compressão Legítima	Criptografia Intermitente (Ransomware)
Padrão de Gravação	Sequencial (geralmente novo arquivo)	Aleatório/Salteado (sobrescrita in-place)
Entropia	Alta (~7.5 - 7.9)	Máxima (~7.99 - 8.0)
Cabeçalho (Header)	Preservado/Legível (ex: PK..)	Corrompido/Criptografado
Contexto de I/O	Processo conhecido (tar, gzip, sql)	Processo suspeito ou injetado
Alinhamento	Alinhado ao início do arquivo	Alinhado a offsets arbitrários

Rastreamento cirúrgico com eBPF e Syscalls

Para implementar essa detecção sem introduzir latência inaceitável no kernel, ferramentas modernas como eBPF (Extended Berkeley Packet Filter) são essenciais. Não precisamos modificar o código do kernel; podemos apenas "grampear" as chamadas de sistema relevantes.

Ao instrumentar tracepoints como vfs_write ou bio_add_page, podemos inspecionar uma amostra do payload de dados.

Um fluxo de investigação típico envolveria:

1. Capturar o PID que iniciou a gravação.

2. Calcular a entropia de uma amostra de 4KB do buffer.

3. Se Entropia > 7.8 E o arquivo alvo não está em uma lista de permitidos (ex: diretório de backups comprimidos), disparar alerta.

4. Correlacionar com a taxa de sobrescrita.

Figura: Fluxo da pilha de I/O do Linux demonstrando onde sondas eBPF podem ser inseridas (camada VFS) para extrair métricas de entropia sem interromper o fluxo de dados para o disco.

O futuro está no firmware (Computational Storage)

A execução dessa análise na CPU do host, mesmo com eBPF, consome ciclos preciosos. A tendência inevitável para ambientes de alta performance é mover essa lógica para o próprio dispositivo de armazenamento.

O conceito de Computational Storage (CS) permite que SSDs NVMe com processadores ARM ou RISC-V integrados executem a análise de entropia in-situ. O dado entra no SSD, e o firmware do disco calcula a entropia antes de cometer o dado à memória NAND. Se o disco detectar um padrão de gravação de alta entropia em setores que não deveriam tê-lo, ele pode bloquear a operação de I/O e alertar o host via banda lateral (NVMe-MI).

Isso representa a última linha de defesa: o próprio hardware recusando-se a participar de sua própria corrupção.

Referências & Leitura Complementar

Para aprofundar a implementação técnica e entender os padrões atuais, consulte as seguintes fontes primárias:

• NIST SP 800-209: Security Guidelines for Storage Infrastructure (Foco em proteção de dados em repouso e trânsito).

• SNIA Computational Storage Architecture: Especificações sobre como mover computação para o dispositivo de armazenamento.

• Shannon, C. E. (1948): "A Mathematical Theory of Communication" (A base teórica para o cálculo de entropia).

• Kernel.org Documentation: Documentação sobre eBPF e instrumentação do subsistema de blocos (blk-mq).

FAQ: Perguntas Frequentes

O que é exatamente a criptografia intermitente?

É uma técnica de evasão onde o ransomware não criptografa o arquivo inteiro. Em vez disso, ele criptografa blocos alternados (ex: a cada 16 bytes ou apenas os cabeçalhos e rodapés) ou faixas de dados a cada N megabytes. Isso permite que o malware corrompa dados muito mais rápido e evite detecções baseadas em volume massivo de I/O, mantendo o arquivo inutilizável para a vítima.

Como a entropia de Shannon ajuda na detecção forense?

Arquivos normais (texto, logs, bancos de dados não comprimidos) possuem padrões previsíveis e, portanto, baixa entropia. Dados criptografados são matematicamente indistinguíveis de ruído aleatório, possuindo entropia máxima. Monitorar mudanças súbitas de baixa para alta entropia em blocos específicos (especialmente em operações de sobrescrita) é um indicador fortíssimo de atividade de ransomware.

Essa análise impacta a performance do storage?

Se realizada via software no sistema operacional para cada byte gravado, sim, o impacto é severo. A solução viável envolve amostragem estatística inteligente (analisar 1 bloco a cada 100, por exemplo) ou o uso de hardware dedicado, como placas de Computational Storage (SSDs inteligentes) que realizam esse cálculo no próprio controlador do disco, sem onerar a CPU do servidor.