VECT 2.0 falha em nonces e converte o ransomware em apagar irreversível de dados

Um erro no VECT 2.0 converte o suposto ransomware em um rascunho irreversível: pesquisadores do Check Point descobriram que a versão 2.0 do VECT falha em lidar com os nonces durante a criptografia por blocos, o que provoca que grandes arquivos fiquem permanentemente inseridos em vez de simplesmente criptografados. Esta falha não é um detalhe menor de implementação: afeta o mecanismo criptográfico básico que garante que cada bloco cifrado possa ser recuperado de forma independente.

Em termos técnicos, o VECT tenta acelerar a criptografia de arquivos grandes dividindo-os em partes (chunks) e gerando um nonce por cada chunk. No entanto, todos os nonces são gerados no mesmo búfer de memória e se sobrescreverem em cada iteração; ao finalizar a operação só fica escrito em disco o último nonce. O efeito é que, na prática, apenas a última porção do arquivo (aproximadamente 25% segundo as análises) conserva o nonce necessário para decifrar. O resto fica irreversível mutilado porque os nonces anteriores nunca são enviados ao operador nem preservados no disco.

As implicações para ambientes empresariais são severas. Check Point sublinha que o limiar que VECT considera "arquivo grande" é de apenas 128 KB, muito menor do que o habitual em discos virtuais, backups, bases de dados e muitos documentos empresariais; isso faz com que a conduta de "borrado acidental" afecte a maioria dos ativos críticos. Além disso, a mesma lógica defeituosa está presente nas variantes para Windows, Linux e ESXi, de modo que servidores e sistemas de virtualização ficam igualmente expostos. Mais detalhes técnicos estão disponíveis no relatório Check Point: Check Point Research sobre VECT 2.0.

O contexto operacional aumenta a gravidade do problema: VECT foi promovido em fóruns clandestinos tipo BreachForums com um modelo de afiliados e, segundo relatos, os operadores anunciaram uma associação com o grupo TeamPCP, envolvido em recentes compromissos de cadeias de fornecimento que afetaram projetos como Trivy ou LiteLLM e serviços como Telnyx. Essa colaboração sugere que o VECT poderia ter sido projetado para se implantar após compromissos de fornecedores ou software, um vetor que multiplica o dano potencial e complica a resposta.

É importante entender por que pagar o resgate pode não servir: como os nonces perdidos não são encaminhados ao atacante, mesmo que uma vítima satisfizesse as demandas não haveria chaves suficientes para reconstruir os blocos anteriores ao último. Na prática, isto transforma um ataque de ransomware (onde há esperança de recuperação após pagamento) em um ato de destruição de dados irreversível para a maioria dos arquivos afetados.

Para organizações e responsáveis pela segurança, a prioridade imediata é conter e preservar: isolar máquinas afetadas, parar a propagação, tirar imagens forenses de discos e memória e conectar-se com uma equipe de resposta a incidentes especializados. Embora os nonces possam ter sido sobrescritos em memória, capturar uma imagem RAM o mais rapidamente possível continua a ser uma ação de valor para a pesquisa forense e para determinar a sequência do ataque e o ponto de entrada.

A melhor defesa continua a ser a prevenção e a resiliência de dados. Isso inclui manter cópias de segurança robustas, com controles de integridade e testes regulares de restauração; empregar versões imutáveis ou air-gapped de backups quando possível; segmentar redes e privilegiar o princípio de menor privilégio para reduzir o alcance de movimentos laterais; e implantar detecção em endpoints e telemetria de rede para identificar atividade suspeita precoce.

Além disso, é crítico reforçar controlos de segurança na cadeia de abastecimento: auditar e monitorizar dependências, assegurar pipelines de CI/CD, assinar e verificar artefatos, e exigir práticas de segurança a fornecedores. A literatura criptográfica também lembra a importância de lidar com os nonces e vetores de inicialização com rigor; para uma referência técnica sobre o uso correto de modos AEAD (como GCM) e a gestão de nonces, pode ser consultada a orientação técnica do NIST: NIST SP 800-38D.

Do ponto de vista de resposta público-privada, as organizações em causa devem notificar as autoridades e os reguladores de acordo com as suas obrigações legais e de privacidade, e comunicar com transparência os clientes e parceiros o impacto. Dado que o VECT está a ser distribuído por afiliados e fóruns, a partilha de indicadores de compromisso com a comunidade e com centros de coordenação sectoriais pode ajudar a detectar novos destacamentos e a mitigar o risco.

Uma mensagem para CISOs e equipamentos técnicos: Reveja urgentemente as cópias de segurança e políticas de retenção, active testes de restauração em diferentes cenários, coloque em quarentena sistemas suspeitos e prepare planos de continuidade que considerem a possibilidade de perda parcial ou total de ativos críticos. Se a sua organização depende de fornecedores de software ou serviços terceirizados, priorize a avaliação desses fornecedores e a verificação de integridade de artefatos.

Em suma, o incidente VECT 2.0 é um lembrete de que os erros de implementação criptográfica podem converter um malware criptografado em um destruidor de dados e que a combinação de modelos criminosos de afiliados e ataques à cadeia de fornecimento amplifica o risco sistémico. A defesa requer tanto controlos técnicos precisos como práticas operacionais e contratuais que reduzam a probabilidade de intrusão e aumentem a possibilidade real de recuperação se ocorrer um compromisso.