Falha no uso de nonces faz variantes do locker perderem material necessário para descriptografia de arquivos acima de 131.072 bytes, tornando pagamento incapaz de restaurar dados afetados.
| Componente | Lockers C++ do VECT 2.0 para Windows, Linux e ESXi, operados como ransomware-as-a-service. |
| Vetor | Execução do locker em armazenamentos locais, removíveis, acessíveis pela rede e, na variante ESXi, com tentativa de movimentação por SSH; o programa trata arquivos acima de 131.072 bytes como arquivos grandes. |
| Impacto | Arquivos grandes têm três dos quatro nonces descartados durante a criptografia, deixando as três primeiras partes irrecuperáveis até para o operador do ransomware. |
| Prioridade | Conter rapidamente a execução, preservar evidências do endpoint ou hipervisor e recuperar a partir de backups offline testados, porque o pagamento não fornece caminho técnico de restauração para arquivos grandes destruídos. |
| Versões | Variantes observadas para Windows, Linux e ESXi. |
| Artefatos | Uso alegado de ChaCha20-Poly1305 AEAD, implementação real descrita como cifra não autenticada, nonces de 12 bytes, chave de 32 bytes, opção --force-safemode, persistência em Safe Mode no Registro do Windows e scripts de execução remota. |
O VECT 2.0 é apresentado como uma operação de ransomware-as-a-service, mas o comportamento técnico dos lockers faz com que parte importante dos arquivos afetados seja destruída em vez de apenas criptografada. A falha central está no tratamento de arquivos acima de 131.072 bytes. Para esses arquivos, o malware divide o conteúdo em quatro blocos independentes e usa quatro nonces aleatórios de 12 bytes. Apenas o último nonce é anexado ao arquivo criptografado em disco. Os três primeiros nonces, necessários para reverter seus respectivos blocos, são gerados, usados e descartados sem armazenamento local, sem gravação no Registro e sem transmissão ao operador. Como a reversão depende da chave de 32 bytes e do nonce correto para cada bloco, os três primeiros quartos de cada arquivo grande ficam irrecuperáveis.
Esse detalhe altera a resposta ao incidente. Embora a operação anuncie um modelo de extorsão com exfiltração, criptografia e cobrança, o desenho real do locker impede que uma ferramenta de descriptografia recupere a maior parte dos arquivos corporativos que ultrapassam o limite de tamanho. O risco operacional é maior para bases de dados, imagens de máquinas virtuais, arquivos de configuração extensos, documentos internos, dumps, pacotes de build, repositórios compactados e outros ativos que normalmente excedem 131 KB. A decisão defensiva deve tratar o evento como destruição de dados com fachada de ransomware, priorizando isolamento, preservação forense e restauração por backup em vez de negociação como estratégia de recuperação.
A família foi rebatizada como VECT 2.0 e opera com programa de afiliados iniciado em dezembro de 2025. O acesso de novos afiliados exige taxa de 250 dólares em Monero, com isenção indicada para candidatos de países da Comunidade dos Estados Independentes. A operação também passou a se relacionar com o marketplace BreachForums e com o grupo TeamPCP, movimento descrito como forma de reduzir barreiras para operadores de ransomware e incentivar ataques a partir de dados previamente roubados. O site de vazamento da operação lista duas vítimas, ambas associadas a comprometimentos por ataques de cadeia de suprimentos ligados ao TeamPCP. Esses elementos mostram um esforço de industrialização, mas a qualidade do locker não acompanha a apresentação comercial da operação.
O locker afirma usar ChaCha20-Poly1305 AEAD, mas a implementação analisada foi descrita como uma cifra mais fraca, sem autenticação e sem proteção de integridade. O problema mais grave não é apenas a ausência de integridade: é a perda permanente de parâmetros criptográficos. Em arquivos considerados grandes, o malware aplica criptografia por quatro partes e precisa manter o nonce correspondente a cada parte para permitir a descriptografia. Ao gravar somente o quarto nonce e descartar os três anteriores, o programa elimina a própria informação necessária para reconstruir os dados. O operador pode até manter ou fornecer uma chave, mas a chave isolada não reverte blocos que dependem de nonces ausentes.
A variante Windows inclui criptografia de arquivos em armazenamento local, removível e acessível pela rede. Ela também carrega um conjunto antianálise voltado a 44 ferramentas de segurança e depuração, além de mecanismo de persistência em Safe Mode. Quando --force-safemode está ativo, o locker configura a próxima inicialização do Windows em modo de segurança e grava o caminho de seu executável no Registro para ser executado nesse próximo boot. Essa escolha busca rodar em um ambiente reduzido, com menos drivers e componentes carregados, o que pode limitar controles de segurança. O mesmo conjunto Windows contém modelos de scripts de execução remota para propagação lateral, embora os detalhes dos scripts não incluam uma lista pública de comandos ou alvos específicos no material técnico disponível.
As variantes ESXi e Linux compartilham a mesma base de código, com a versão Linux implementando um subconjunto das funções presentes no ESXi. No ESXi, o locker executa verificações de geofencing e antidepuração antes de iniciar a criptografia, além de tentar movimentação lateral via SSH. A checagem geográfica faz o programa encerrar se estiver em países da Comunidade dos Estados Independentes, e inclui a Ucrânia nessa exclusão. Esse comportamento foi considerado incomum em comparação com tendências recentes de ransomware, e há duas hipóteses técnicas plausíveis no material: reaproveitamento de uma base antiga ou trechos gerados com ajuda de ferramenta de inteligência artificial treinada em referências desatualizadas.
A superfície principal envolve hosts Windows com acesso a unidades locais, mídias removíveis e compartilhamentos de rede, além de ambientes Linux e ESXi onde o binário consiga executar. Em Windows, o risco se amplia quando a conta usada pelo malware possui permissão de gravação em compartilhamentos corporativos, diretórios de usuários, volumes anexados e caminhos de rede. Em ESXi, a tentativa de movimentação via SSH torna relevantes hipervisores com credenciais expostas, autenticação fraca ou acesso administrativo indevido. Como o limite de 131.072 bytes é baixo para ambientes corporativos, a maioria dos arquivos operacionalmente relevantes entra no caminho destrutivo.
A presença de antianálise e antidepuração muda a forma de manusear amostras, mas há uma observação importante: mecanismos de detecção de ambiente na variante Windows existem, porém não são invocados. Isso permite que equipes de segurança executem artefatos em laboratório sem acionar respostas evasivas previstas no código Windows. Esse detalhe não deve reduzir a cautela, porque o ESXi aplica geofencing e antidepuração antes da criptografia. Em qualquer plataforma, a contenção deve considerar que o dano acontece no momento da execução do locker e que a janela para salvar arquivos grandes é anterior ao início do processo de criptografia, não posterior à obtenção de uma chave.
A camada de operação também amplia a exposição. O modelo de afiliados, a cobrança de entrada em Monero, a isenção para candidatos da região CIS, o painel de operador e as parcerias com fórum criminoso e TeamPCP sugerem distribuição por operadores variados, não por um único intruso com método fixo. O material disponível não confirma uma cadeia universal de acesso inicial para todos os casos; portanto, a defesa não deve assumir um único vetor. O que está claro é que a operação busca combinar dados já roubados, pressão por vazamento e execução do locker em múltiplas plataformas.
- Windows com permissões de escrita em volumes locais, mídias removíveis e compartilhamentos acessíveis pela rede.
- Hosts ESXi onde o binário consiga executar e onde SSH possa ser usado para tentativa de deslocamento para outros sistemas.
- Ambientes Linux expostos à variante derivada da mesma base de código usada no locker ESXi.
- Arquivos acima de 131.072 bytes, incluindo ativos corporativos que normalmente dependem de recuperação íntegra após incidente.
A caça deve procurar sinais de execução do locker antes de interpretar o evento como ransomware convencional recuperável por descriptografia. Em Windows, a combinação de configuração para próximo boot em Safe Mode, gravação de caminho de executável no Registro para execução no modo de segurança e atividade intensa de escrita em arquivos grandes deve ser tratada como sinal de destruição em andamento. Alterações em arquivos em compartilhamentos de rede feitas por uma mesma conta ou host, especialmente quando acompanhadas por reinicialização planejada em modo de segurança, merecem contenção imediata. Eventos de segurança que mostrem interação com ferramentas de depuração ou produtos de proteção também podem ajudar a identificar tentativa de neutralizar análise, já que o locker mantém uma lista de 44 ferramentas visadas.
Em ESXi, a telemetria deve enfatizar execução de binários não autorizados, sessões SSH anômalas entre hosts, mudanças rápidas em arquivos de máquinas virtuais e encerramento de processos relacionados a proteção ou análise, quando disponível. A verificação de geofencing não cria por si só um indicador simples para logs corporativos, mas a ausência de criptografia em determinados contextos regionais não deve ser confundida com benignidade do artefato. A investigação deve preservar amostras, linhas de tempo de execução e artefatos de persistência, porque a perda dos nonces impede reconstrução por análise posterior dos arquivos afetados.
Equipes de DFIR também devem revisar logs de backup e armazenamento. Como arquivos grandes ficam parcialmente irrecuperáveis, a métrica defensiva mais importante é identificar o último ponto de recuperação íntegro antes da execução. Backups montados online, caches de snapshot acessíveis pela mesma credencial comprometida e repositórios de restauração com permissão de gravação pelo host afetado devem ser considerados em risco. O hunting precisa separar arquivos apenas renomeados ou criptografados de arquivos efetivamente destruídos pelo desenho do locker, pois a estratégia de restauração e comunicação interna depende dessa distinção.
- Configuração de próxima inicialização em Safe Mode combinada com autorun no Registro apontando para o executável suspeito.
- Execução com o parâmetro
--force-safemodeou artefatos que indiquem preparação para boot em modo de segurança. - Volume elevado de alterações em arquivos acima de 131.072 bytes em armazenamento local, removível ou compartilhado.
- Sessões SSH incomuns em ambientes ESXi próximas a alterações em arquivos de máquinas virtuais.
- Presença de scripts de execução remota associados ao locker ou a tentativas de propagação lateral.
A resposta deve começar pelo isolamento dos hosts suspeitos e pela interrupção de qualquer conta ou sessão com permissão de escrita em compartilhamentos, hipervisores e volumes de backup. Em Windows, isso inclui retirar o sistema da rede, impedir que a próxima inicialização em Safe Mode execute o artefato e preservar o Registro e o binário para análise. Em ESXi, a contenção deve bloquear sessões SSH suspeitas, revisar credenciais administrativas e impedir propagação entre hosts. A prioridade não é obter chave de descriptografia, porque a própria implementação do locker descarta informações necessárias para recuperar arquivos grandes.
A recuperação precisa partir de backups offline ou de pontos de restauração que não tenham sido alcançados pelo malware. Antes de restaurar, a equipe deve validar que os repositórios de backup não foram alterados pela mesma janela de comprometimento, que snapshots críticos não foram sobrescritos e que as credenciais usadas na restauração foram rotacionadas. Backups conectados continuamente ao ambiente afetado não devem ser tratados como confiáveis sem verificação. Para arquivos grandes atingidos, qualquer promessa de descriptografia deve ser avaliada contra a limitação técnica dos nonces ausentes: sem esses valores, três partes do arquivo não podem ser reconstruídas.
A contenção de longo prazo envolve reduzir permissões de escrita cruzada, separar planos de administração de servidores, proteger ESXi com controle rigoroso de SSH e testar procedimentos de restauração com arquivos grandes. Organizações também devem revisar exposição a ataques de cadeia de suprimentos e a dados previamente roubados, já que a operação tenta explorar parcerias e material já comprometido para acelerar ataques. A validação final deve incluir varredura de persistência em Windows, revisão de contas usadas para movimentação lateral, inspeção de scripts de execução remota e comparação de integridade entre dados restaurados e cópias confiáveis.
- Isolar hosts com execução suspeita e bloquear contas com permissão de escrita em compartilhamentos, volumes removíveis e hipervisores.
- Remover ou neutralizar persistência de Safe Mode antes de reinicializar sistemas Windows afetados.
- Auditar SSH em ESXi e revogar credenciais administrativas usadas durante a janela do incidente.
- Restaurar somente a partir de backups offline ou pontos de recuperação verificados como anteriores à execução do locker.
- Testar recuperação com arquivos acima de 131.072 bytes e documentar quais ativos não podem ser reconstruídos por descriptografia.
0 Comentários