Programa RaaS lançado em março de 2025 combina painel para afiliados, criptografia local e em compartilhamentos SMB, remoção de cópias de sombra e variantes em evolução.
| Componente | VanHelsingRaaS e locker VanHelsing escrito em C++, com suporte declarado a Windows, Linux, BSD, ARM e ESXi. |
| Vetor | Execução do binário por afiliados com argumentos de linha de comando para criptografar unidades locais, diretórios específicos, unidades montadas e compartilhamentos SMB. |
| Impacto | Criptografia de arquivos com extensão .vanhelsing, exclusão de cópias de sombra do Windows e demanda de resgate de US$ 500.000 em Bitcoin em negociação observada. |
| Prioridade | Conter execução em endpoints Windows, bloquear propagação por SMB, revisar uso de ferramentas do tipo PsExec e validar restauração fora do alcance do host comprometido. |
| Artefatos | Nota README.txt, mutex Global\VanHelsing, imagens vhlocker.png e vhlocker.ico em C:\Windows\Web, binário copiado como vanlocker.exe em compartilhamentos. |
| Criptografia | Uso de chave pública Curve25519 embutida, valores efêmeros de 32 bytes e 12 bytes por arquivo, e criptografia de conteúdo com ChaCha20. |
O VanHelsingRaaS é uma operação de ransomware como serviço lançada em 7 de março de 2025 e estruturada para uso por afiliados. O programa combina um painel de controle para gerenciamento de campanhas com um locker chamado VanHelsing, descrito como multiplataforma e voltado a Windows, Linux, BSD, ARM e ESXi. A operação adota modelo econômico típico de RaaS: afiliados considerados confiáveis podem ingressar sem custo, novos afiliados precisam depositar US$ 5.000, e a divisão de receita observada é de 80% para afiliados e 20% para operadores principais após duas confirmações em blockchain do pagamento da vítima.
Em menos de duas semanas após a apresentação do serviço ao ecossistema criminoso, três vítimas já haviam sido infectadas. Em uma negociação observada, a demanda chegou a US$ 500.000 em Bitcoin para restauração de arquivos e exclusão de dados roubados. A operação também impõe uma restrição geográfica: sistemas em países da Comunidade de Estados Independentes, ou CIS, não devem ser criptografados, comportamento frequentemente associado a operações criminosas russófonas. Essa regra não reduz o risco técnico para outros ambientes, mas ajuda defensores a entenderem como os operadores delimitam o uso do serviço pelos afiliados.
A primeira amostra do ransomware associada ao serviço foi identificada em 16 de março de 2025. O binário é escrito em C++ e o carimbo de compilação indica implantação no mesmo dia contra a primeira vítima atribuída ao grupo afiliado analisado. A presença de funcionalidades incompletas, diferenças entre variantes compiladas com cinco dias de intervalo e erros de implementação indicam um malware ainda em evolução, mas já operacional o suficiente para criptografar dados locais e remotos, remover mecanismos de restauração e alterar o ambiente visual da vítima.
A execução do VanHelsing é controlada por argumentos de linha de comando que alteram o escopo e o modo de operação. Entre os parâmetros documentados estão -h, para exibir instruções de uso, -v, para imprimir logs, --no-logs, para suprimir logs, --Driver, para selecionar uma unidade, --Directory, para criptografar um diretório específico, e --Force, que permite múltiplas instâncias. Sem --Force, o malware tenta criar o mutex Global\VanHelsing e interrompe a execução se ele já existir, reduzindo a chance de duas instâncias padrão competirem pelos mesmos arquivos.
No Windows, a rotina de remoção de cópias de sombra inicializa COM com CoInitializeEx e CoInitializeSecurity, identifica a arquitetura do sistema por GetNativeSystemInfo e cria o objeto COM adequado por CoCreateInstance. Em seguida, o malware conecta-se ao namespace ROOT\CIMV2, consulta a classe Win32_ShadowCopy e enumera as cópias de sombra locais. Para cada item recuperado, cria processos filhos para excluir as cópias pelo identificador de sombra. A consequência prática é reduzir a capacidade de restauração nativa por VSS após a criptografia.
A criptografia local começa pela descoberta de unidades com GetLogicalDriveStringsW. O ransomware chama a função inicialmente para obter o tamanho do buffer e depois repete a chamada para receber a lista de unidades válidas. A seleção inclui unidades fixas e unidades montadas, a menos que --no-mounted seja usado. Depois disso, o binário percorre recursivamente diretórios e arquivos usando FindFirstFileW, FindNextFileW e FindClose. O malware evita alguns caminhos, arquivos e extensões associados ao funcionamento do Windows para não tornar o sistema completamente inutilizável antes da conclusão da extorsão.
A rotina de rede é ativada por padrão para unidades conectadas e compartilhamentos, salvo quando o operador específica --no-network. O malware obtém o hostname local, resolve o endereço IP correspondente e varre a faixa local de endereços [1-255) tentando conexão na porta 445. Para hosts com SMB acessível, usa NetShareEnum para enumerar recursos compartilhados e monta caminhos de rede para continuar a enumeração e criptografia. Quando executado com --spread-smb, o comportamento muda: o locker usa um psexec.exe embutido, gravado na pasta temporária, copia a si mesmo para o compartilhamento como vanlocker.exe e aciona o processo remoto. Compartilhamentos que contenham NETLOGON ou sysvol são excluídos para evitar interrupção de autenticação.
A superfície primária são hosts Windows nos quais o binário C++ do locker é executado com permissões suficientes para enumerar unidades, acessar VSS, percorrer diretórios e gravar arquivos. A operação também mira compartilhamentos SMB acessíveis a partir do host comprometido, o que torna credenciais, permissões de escrita e segmentação de rede fatores decisivos para o alcance real do incidente. O suporte declarado a Linux, BSD, ARM e ESXi amplia a preocupação para ambientes mistos, embora os detalhes técnicos recebidos se concentrem na amostra Windows.
O malware grava a nota de resgate como README.txt em cada pasta enumerada. A nota informa à vítima que a rede foi invadida e que documentos importantes, relatórios financeiros e dados pessoais foram criptografados. O binário também contém duas imagens embutidas, gravadas em C:\Windows\Web: vhlocker.png, usada para substituir o papel de parede pelo logotipo do RaaS, e vhlocker.ico, planejada para associação visual dos arquivos criptografados. Há falhas de implementação: o código tenta associar .vanlocker, mas os arquivos recebem a extensão .vanhelsing; a lista de exclusão também ignora .vanlocker, o que pode permitir dupla criptografia se uma segunda execução encontrar arquivos já alterados com .vanhelsing.
A criptografia usa uma chave pública Curve25519 embutida no código. Para cada arquivo, o malware gera valores efêmeros de 32 bytes e 12 bytes, usados como chave e nonce na criptografia ChaCha20; esses valores são criptografados pela chave pública e armazenados em formato hexadecimal no arquivo. Arquivos com cerca de 1 GB ou mais têm apenas os primeiros 30% do conteúdo criptografados a partir do início; arquivos menores são criptografados integralmente. O processamento ocorre em blocos de aproximadamente 1 MB, o que equilibra velocidade operacional e dano suficiente para inviabilizar o uso dos dados.
- Hosts Windows com acesso a unidades locais, unidades montadas e VSS.
- Compartilhamentos SMB acessíveis pela porta
445e graváveis pelo contexto de execução. - Ambientes com credenciais que permitam execução remota via ferramenta embutida do tipo
psexec.exe. - Arquivos renomeados com extensão
.vanhelsinge notasREADME.txtdistribuídas em diretórios enumerados.
A investigação deve começar pela linha de comando do processo suspeito. Parâmetros como --Driver, --Directory, --Force, --no-mounted, --no-network, --spread-smb e --Silent são fortes indicadores de execução do locker ou de preparação para criptografia dirigida. O modo --Silent merece atenção especial porque separa a criptografia da renomeação: primeiro executa a rotina normal com renomeação suprimida e depois percorre novamente os arquivos apenas para adicionar a extensão. Esse desenho busca reduzir sinais comportamentais baseados em renomeação imediata durante a escrita criptografada.
No endpoint, defensores devem correlacionar criação do mutex Global\VanHelsing, alterações de papel de parede, gravação de vhlocker.png e vhlocker.ico em C:\Windows\Web, criação de múltiplos README.txt e surgimento de arquivos .vanhelsing. A telemetria de processo também deve observar inicialização de COM seguida por consultas WMI a ROOT\CIMV2 e Win32_ShadowCopy, especialmente quando associada a processos desconhecidos ou recém-criados. Processos filhos voltados à exclusão de sombras logo antes de intensa escrita em disco indicam tentativa de reduzir opções de recuperação.
Na rede, os sinais mais relevantes são varredura sequencial da porta 445 dentro da sub-rede local, chamadas relacionadas à enumeração de compartilhamentos e gravação de executáveis em caminhos SMB. A cópia de vanlocker.exe para compartilhamentos e a execução via psexec.exe embutido devem ser tratadas como evidência de expansão lateral condicionada por permissões de escrita. Em compartilhamentos, a ausência temporária da extensão .vanhelsing durante execução com --Silent não deve ser interpretada como ausência de criptografia, pois a renomeação pode ocorrer somente na segunda passagem.
- Processos com argumentos
--spread-smb,--Silent,--Directory,--Driverou--Force. - Consultas WMI à classe
Win32_ShadowCopyseguidas por exclusão de cópias de sombra. - Conexões sucessivas para porta
445na faixa local[1-255). - Criação de
README.txt,vhlocker.png,vhlocker.icoe arquivos com extensão.vanhelsing. - Uso de
psexec.exeextraído para pasta temporária e execução remota devanlocker.exe.
A resposta deve isolar hosts com sinais de execução do VanHelsing antes de qualquer tentativa ampla de limpeza. Como o malware pode criptografar unidades locais, montadas e compartilhamentos SMB, a contenção precisa incluir desconexão de rede do endpoint, suspensão de sessões SMB suspeitas e bloqueio temporário de escrita em compartilhamentos críticos. Em paralelo, equipes de identidade devem revisar contas usadas nos hosts afetados, porque a propagação por SMB depende de permissões e da capacidade de gravar ou executar binários em recursos remotos.
A recuperação deve priorizar cópias de segurança fora do alcance do sistema comprometido. A exclusão de sombras por Win32_ShadowCopy torna restauração local via VSS pouco confiável após a execução. Antes de restaurar, é necessário confirmar que não há processos ativos do locker, tarefas remotas iniciadas por ferramenta do tipo psexec.exe ou executáveis vanlocker.exe deixados em compartilhamentos. Também é importante procurar dupla criptografia em ambientes onde uma segunda execução pode ter atingido arquivos já renomeados, já que o erro de exclusão envolvendo .vanlocker e .vanhelsing cria essa possibilidade.
A redução de exposição passa por segmentar SMB, limitar escrita em compartilhamentos, restringir execução remota administrativa, monitorar criação de mutex e endurecer políticas de execução em diretórios temporários. Ambientes Windows devem registrar eventos de WMI e criação de processos para detectar o padrão de consulta a ROOT\CIMV2 e Win32_ShadowCopy. Como o malware apresenta variantes compiladas em datas próximas e novos argumentos entre versões, regras de detecção devem combinar indicadores específicos com comportamento: enumeração ampla de arquivos, escrita criptográfica em massa, varredura de 445, remoção de sombras e distribuição de notas de resgate.
- Isolar endpoints com arquivos
.vanhelsing, notasREADME.txtou execução com argumentos do VanHelsing. - Bloquear propagação por SMB, revisar compartilhamentos graváveis e remover cópias de
vanlocker.exe. - Validar backups offline ou imutáveis antes de restaurar sistemas e dados.
- Monitorar e restringir execução de ferramentas do tipo
psexec.exea partir de diretórios temporários. - Criar detecções comportamentais para exclusão de
Win32_ShadowCopy, varredura da porta445e renomeação em massa.
0 Comentários