VECT 2.0 opera como ransomware, mas destrói arquivos grandes por falha criptográfica

O serviço RaaS cifra Windows, Linux e VMware ESXi com ChaCha20-IETF, porém descarta nonces necessários para recuperar arquivos acima de 128 KB.

Componente	VECT Ransomware 2.0, com payloads em C++ para Windows, Linux e VMware ESXi
Vetor	Execução de lockers gerados por afiliados, com suporte a propagação por credenciais, GPO, WMI, DCOM, tarefas remotas, serviços remotos, PowerShell Remoting e SSH
Impacto	Arquivos acima de 131.072 bytes perdem três dos quatro nonces necessários à descriptografia, tornando a recuperação inviável mesmo com a chave
Prioridade	Conter execução lateral, preservar evidências antes de limpeza, restaurar a partir de backups íntegros e tratar arquivos grandes cifrados como potencialmente destruídos
Versões	A falha está presente no VECT 2.0 e também foi observada em uma variante ESXi anterior
Artefatos	Extensão .vect, nota !!!READ_ME!!!.txt, papel de parede dvm3_wall.bmp, uso de crypto_stream_chacha20_ietf_xor e nonce de 12 bytes anexado ao fim do arquivo

Resumo técnico

O VECT é um programa de ransomware como serviço que surgiu em dezembro de 2025 em um fórum de cibercrime em língua russa e passou a chamar mais atenção após reivindicar duas vítimas em janeiro de 2026. A operação tentou ampliar alcance por meio de parceria com o ator TeamPCP, associado a ataques de cadeia de suprimentos em março de 2026 envolvendo pacotes e projetos como Trivy, KICS da Checkmarx, LiteLLM e Telnyx. A proposta operacional era usar o acesso ou a exposição gerada nesses comprometimentos para pressionar empresas afetadas. Apesar dessa ambição, o site de vazamento da operação listava apenas duas vítimas no período analisado, ambas ligadas à cadeia de suprimentos explorada pelo TeamPCP.

A versão 2.0 do VECT, disponibilizada em fevereiro de 2026, oferece lockers para Windows, Linux e VMware ESXi, todos escritos em C++ e compilados estaticamente com a biblioteca libsodium incorporada. O painel de afiliados permite gerar payloads por plataforma e também apresenta uma ferramenta de exfiltração dedicada, que ainda não estava disponível no momento da análise. O serviço também anunciou a intenção de criar lockers voltados a armazenamento em nuvem, com acesso condicionado a uma espécie de validação de habilidade para afiliados. A arquitetura indica tentativa de operar como RaaS amplo, mas a implementação criptográfica reduz o valor real do modelo de extorsão.

O ponto crítico está no mecanismo de cifragem compartilhado entre as variantes. Os payloads não usam ChaCha20-Poly1305 com autenticação; usam o fluxo bruto ChaCha20-IETF por meio de crypto_stream_chacha20_ietf_xor. O formato gravado em disco contém texto cifrado e apenas um nonce de 12 bytes ao final do arquivo, sem tag Poly1305, sem MAC e sem qualquer proteção de integridade. Para arquivos pequenos, essa estrutura ainda permite reversão. Para arquivos acima de 131.072 bytes, o malware divide o conteúdo em quatro partes e gera um nonce novo para cada parte, mas grava somente o último. Os três primeiros nonces desaparecem durante a execução e não são preservados em disco, registro ou comunicação com operador.

Fluxo técnico

Em arquivos com até 131.072 bytes, o VECT executa uma única passagem de cifragem. O conteúdo é processado no próprio arquivo com uma chave de 32 bytes e um nonce de 12 bytes, e esse nonce é anexado ao fim do objeto cifrado. Nessa condição específica, o arquivo mantém os parâmetros mínimos para descriptografia, assumindo posse da chave correta. A ausência de autenticação continua sendo uma deficiência criptográfica, pois não há garantia de integridade, mas a reversão do fluxo é tecnicamente possível.

O comportamento muda em arquivos maiores que 128 KB. O locker calcula quatro regiões em deslocamentos baseados em quartos do tamanho do arquivo e chama a rotina de cifragem uma vez para cada região. Em cada chamada, randombytes() gera um novo nonce de 12 bytes. O problema é que todas as chamadas escrevem o nonce no mesmo buffer compartilhado. A segunda chamada sobrescreve o nonce da primeira, a terceira sobrescreve o da segunda e a quarta deixa no buffer apenas o valor final. No encerramento, o malware anexa ao arquivo somente esse último nonce, suficiente para reverter apenas a última região cifrada.

Como ChaCha20-IETF depende da mesma chave e do mesmo nonce para reconstruir o fluxo de chave, os três primeiros quartos processados ficam sem o material necessário para descriptografia. No Windows, a geração aleatória passa por fontes como SystemFunction036, RtlGenRandom e ProcessPrng; em Linux e ESXi, a libsodium obtém aleatoriedade do CSPRNG do núcleo por getrandom() ou /dev/urandom. Esses valores são projetados para serem imprevisíveis. Sem armazenamento do nonce e sem transmissão para o operador, a recuperação dos blocos afetados não é uma questão de pagamento ou cooperação: o material criptográfico deixou de existir.

A variante ESXi inclui uma otimização que verifica blocos preenchidos por zeros antes da cifragem, comportamento relevante para discos virtuais esparsos como VMDK. Se uma região inteira é composta por zeros, ela pode ser ignorada. Essa otimização não corrige a falha, porque as regiões efetivamente cifradas continuam usando o mesmo buffer de nonce. O resultado prático é que imagens de máquinas virtuais, bancos de dados, arquivos de backup, planilhas volumosas, documentos corporativos, repositórios compactados e outros arquivos operacionalmente importantes podem ser destruídos sob aparência de ransomware recuperável.

Superfície afetada

A variante Windows mira unidades locais, removíveis e recursos de rede acessíveis, renomeando arquivos com a extensão .vect antes da cifragem. Ela cria a nota !!!READ_ME!!!.txt, substitui o papel de parede por dvm3_wall.bmp e possui rotinas para evasão, persistência e movimentação lateral. Por padrão, a propagação por GPO, a montagem de recursos de rede e a autoexclusão ficam habilitadas. Isso significa que uma execução sem flags restritivas pode acionar cadeia completa de impacto, incluindo busca de hosts, acesso a volumes ocultos e limpeza posterior do executável.

Quando executado com privilégio elevado no Windows, o locker tenta encerrar serviços e processos que possam manter arquivos abertos. A lista inclui processos associados a bancos de dados e aplicações de usuário, como sql.exe, oracle.exe, mysqld.exe, excel.exe, winword.exe, outlook.exe, firefox.exe e thunderbird.exe. Diferentemente de famílias RaaS mais maduras, a lista é fixa no builder e não oferece personalização ao afiliado. O malware também implementa persistência em modo de segurança quando a opção --force-safemode é usada, configurando bcdedit /set {default} safeboot minimal e registrando o próprio caminho para execução como serviço durante o próximo boot.

A propagação em Windows usa credenciais fornecidas pelo operador por --creds e combina cópia por compartilhamentos administrativos, armazenamento via cmdkey, execução por WMI, instanciação DCOM/MMC, criação remota de tarefas agendadas, instalação de serviço por sc.exe e PowerShell Remoting. A descoberta de alvos combina enumeração de domínio Windows e varredura de sub-rede local a partir de informações dos adaptadores de rede. Há ainda mecanismos de detecção de ambiente de análise compilados no binário, mas sem chamadas ativas na construção observada, o que reduz a evasão efetiva contra depuradores e ferramentas de segurança.

No ESXi, o VECT mira hipervisores VMware e usa /vmfs/volumes como ponto padrão de atuação. Antes da cifragem, executa verificações de geofencing e antidepuração. O binário consulta timedatectl, avalia variáveis LANG e LC_ALL para identificar códigos de país excluídos e verifica TracerPid em /proc/self/status para detectar rastreamento por depurador. Também tenta desabilitar firewall por esxcli, alterar rulesets, interromper serviços de monitoramento, desligar serviços de backup, bancos de dados, componentes de hipervisor e produtos de segurança por systemctl stop, service stop, pkill -9 ou systemctl disable --now.

A variante Linux compartilha a lógica criptográfica e os parâmetros de tamanho observados no ESXi. As opções --fast, --medium e --secure são interpretadas, mas não influenciam o caminho de execução: o limite de 131.072 bytes e o tamanho máximo de chunk de 32.768 bytes continuam fixos. Isso cria risco operacional uniforme entre plataformas, porque a escolha de modo pelo operador não altera a destruição causada pelo descarte de nonces.

• Hosts Windows com unidades locais, removíveis, recursos de rede mapeados e permissões administrativas disponíveis ao operador.
• Ambientes VMware ESXi com datastores acessíveis em /vmfs/volumes, especialmente quando credenciais SSH reutilizadas permitem movimentação lateral.
• Servidores Linux ou ESXi executando payload gerado pelo builder VECT, independentemente das flags --fast, --medium ou --secure.

Hunting e telemetria

A investigação deve priorizar sinais de execução do locker e de propagação lateral antes da cifragem, porque a recuperação de arquivos grandes não deve ser presumida. Em Windows, procure criação em massa de arquivos com extensão .vect, escrita da nota !!!READ_ME!!!.txt, alteração de papel de parede para dvm3_wall.bmp, execução de bcdedit com safeboot minimal, mudanças temporárias em chaves de registro relacionadas a inicialização em modo de segurança e desabilitação do Gerenciador de Tarefas. A presença de muitas threads concorrentes acessando disco também pode gerar telemetria anômala de EDR e degradação intensa de I/O.

Os logs de identidade e administração remota devem ser correlacionados com eventos de WMI, criação de serviço remoto, tarefa agendada remota, PowerShell Remoting, uso de compartilhamentos administrativos e gravação de credenciais por cmdkey. Em domínio Windows, a sequência descoberta de hosts seguida de cópia remota e execução simultânea em múltiplas máquinas é um forte indicador de tentativa de propagação do VECT. Como a autoexclusão pode remover o executável depois do impacto, a preservação de memória, logs de EDR, artefatos Prefetch, eventos de serviço e histórico de PowerShell pode ser mais importante do que buscar apenas o binário em disco.

Em ESXi e Linux, a telemetria deve incluir execução de timedatectl, leitura de /proc/self/status, uso de esxcli para firewall, interrupção de serviços por systemctl, service e pkill -9, além de conexões SSH originadas do host comprometido para outros alvos. Em hipervisores, alterações súbitas em VMDK, interrupção de serviços de gerenciamento e apagamento ou redução de logs antes da cifragem são sinais críticos. Para storage e backup, a presença de arquivos grandes parcialmente cifrados deve ser tratada como destruição de dados, não como criptografia reversível mediante chave.

• Criação de arquivos terminados em .vect acompanhada de escrita de !!!READ_ME!!!.txt no mesmo conjunto de diretórios.
• Execução de bcdedit /set {default} safeboot minimal, alterações de registro para serviço em modo de segurança e posterior remoção da configuração de boot.
• Uso de WMI, DCOM/MMC, sc.exe, tarefas agendadas remotas, PowerShell Remoting ou SSH em sequência curta a partir de uma conta com privilégios.
• Em ESXi, comandos esxcli, paradas de serviço e atividade intensa em /vmfs/volumes seguida de modificação de arquivos de máquinas virtuais.
• Arquivos acima de 131.072 bytes com texto cifrado e apenas um nonce de 12 bytes no fim, sem tag de autenticação ou metadados adicionais.

Mitigação

A resposta deve partir do princípio de que o pagamento não garante recuperação dos arquivos maiores. A primeira ação é isolar hosts afetados e contas usadas para movimentação lateral, interrompendo GPOs suspeitas, sessões remotas, chaves SSH expostas e credenciais administrativas reutilizadas. Em Windows, remova mecanismos de execução remota criados durante o incidente, valide tarefas agendadas, serviços recém-criados, entradas de modo de segurança e políticas aplicadas por domínio. Em ESXi, suspenda acessos administrativos, preserve logs disponíveis, verifique alterações de firewall e confirme a integridade dos datastores antes de religar workloads.

A restauração deve depender de backups offline, imutáveis ou logicamente segregados, com validação de data anterior à execução do locker e varredura de credenciais comprometidas. Como os payloads tentam encerrar serviços de backup e podem atingir arquivos grandes de repositório, snapshots e backups acessíveis pelo mesmo plano de credenciais do ambiente não devem ser considerados íntegros sem verificação. Para arquivos menores que 128 KB, a criptografia pode ser estruturalmente reversível caso a chave exista, mas essa possibilidade não se estende à maioria dos dados corporativos relevantes.

A contenção de médio prazo exige redução de caminhos de propagação. Credenciais usadas por administração remota devem ser rotacionadas, contas de domínio com privilégios excessivos devem ser revistas e acesso SSH entre hipervisores precisa ser restrito por necessidade operacional. Em Windows, limite WMI, PowerShell Remoting, compartilhamentos administrativos e criação remota de serviços a grupos controlados e monitore uso fora de janelas autorizadas. Em ESXi, aplique segmentação de gerenciamento, MFA onde disponível, inventário de chaves autorizadas e alertas para alterações de firewall, interrupção de serviços críticos e escrita em massa em datastores.

• Isolar sistemas afetados, bloquear contas usadas na execução e impedir novas conexões remotas antes de iniciar restauração.
• Preservar evidências de EDR, eventos de autenticação, logs de serviço, histórico de comandos e amostras de arquivos cifrados antes de limpeza.
• Restaurar dados a partir de backups testados, offline ou imutáveis, tratando arquivos grandes cifrados pelo VECT como não recuperáveis pela operação criminosa.
• Rotacionar credenciais administrativas, chaves SSH e segredos expostos em hosts alcançados pela movimentação lateral.
• Criar detecções para .vect, !!!READ_ME!!!.txt, dvm3_wall.bmp, bcdedit com safeboot minimal, uso anômalo de cmdkey, WMI remoto, sc.exe, PowerShell Remoting e comandos esxcli em hipervisores.