Malware VBS distribuído por WhatsApp contorna UAC e instala acesso remoto no Windows

Campanha iniciada no fim de fevereiro usa scripts VBS, utilitários legítimos renomeados, serviços de nuvem e pacotes MSI maliciosos para persistência e controle remoto em sistemas Windows.

Componente	Sistemas Windows expostos à execução manual de arquivos VBS recebidos por WhatsApp, com uso posterior de utilitários legítimos renomeados, pacotes MSI e ferramentas de acesso remoto como AnyDesk.
Vetor	Mensagens de WhatsApp entregam arquivos Visual Basic Script maliciosos; a cadeia depende de engenharia social para que o usuário execute o script inicial.
Impacto	Após a execução, a cadeia cria pastas ocultas em C:\ProgramData, baixa cargas auxiliares de serviços de nuvem, tenta enfraquecer o UAC, modifica chaves de registro e instala MSI não assinado para persistência e acesso remoto.
Prioridade	Bloquear ou conter a execução de VBS não autorizado, investigar criação de binários renomeados e MSI suspeitos, revisar alterações de UAC e remover persistência associada ao acesso remoto.
Artefatos	Foram descritos curl.exe renomeado como netapi.dll, bitsadmin.exe renomeado como sc.exe, downloads a partir de AWS S3, Tencent Cloud e Backblaze B2, além de alteração sob HKLM\Software\Microsoft\Win.
Mitigação	Reforçar políticas contra scripts recebidos por mensageria, aplicar controle de aplicativos, auditar instaladores MSI não assinados e monitorar tentativas repetidas de elevação envolvendo comando operacional omitido.

Resumo técnico

Uma campanha observada a partir do fim de fevereiro de 2026 usa mensagens de WhatsApp para distribuir arquivos Visual Basic Script maliciosos contra ambientes Windows. O ponto de entrada descrito é a execução do arquivo VBS pelo usuário, o que coloca a engenharia social como pré-condição central da intrusão. O conteúdo disponível não informa qual tema de isca foi usado nas mensagens, portanto a análise defensiva deve se concentrar no comportamento pós-execução: criação de diretórios ocultos, uso de binários legítimos renomeados, recuperação de cargas auxiliares em serviços de nuvem e instalação de pacotes MSI com finalidade maliciosa.

A cadeia combina técnicas de baixo ruído operacional com abuso de componentes comuns do próprio Windows. Depois do primeiro script, o malware prepara o sistema criando pastas ocultas em C:\ProgramData e posicionando cópias renomeadas de utilitários legítimos. O objetivo é fazer com que ações de rede e administração pareçam parte de atividade comum do sistema, dificultando a distinção entre uso legítimo e execução controlada pelo operador. Em seguida, a operação tenta obter persistência, enfraquecer mecanismos de proteção relacionados ao Controle de Conta de Usuário e instalar recursos de acesso remoto.

O impacto confirmado está associado a persistência, tentativa de elevação de privilégios e controle remoto. A cadeia termina com instaladores MSI não assinados e inclui o uso de ferramentas legítimas como AnyDesk, que podem fornecer acesso contínuo ao host quando implantadas fora de um fluxo administrativo aprovado. O contexto também indica que esse tipo de controle pode permitir roubo de dados ou implantação adicional de malware, mas essa consequência deve ser tratada como risco decorrente do acesso remoto, não como vazamento confirmado em todos os casos.

Fluxo técnico

A infecção começa quando o arquivo VBS recebido por WhatsApp é executado no endpoint. A partir desse ponto, o script cria diretórios ocultos em C:\ProgramData, área frequentemente usada por aplicações para dados compartilhados, mas também atrativa para persistência por não estar associada diretamente ao perfil do usuário. A criação com atributos ocultos reduz visibilidade em inspeções superficiais e pode atrasar a identificação por suporte técnico ou por operadores que dependem apenas de navegação manual no sistema de arquivos.

Na etapa seguinte, o malware deposita versões renomeadas de ferramentas legítimas do Windows. O contexto cita curl.exe renomeado como netapi.dll e bitsadmin.exe renomeado como sc.exe. A função defensivamente relevante desses artefatos é permitir transferência de dados e execução auxiliar enquanto os nomes em disco tentam se misturar a nomenclaturas plausíveis do sistema. Essa técnica não torna o binário legítimo malicioso por si só; o sinal de risco surge da combinação entre caminho incomum, nome inconsistente, execução por script e comunicação com repositórios de carga.

Com a base inicial criada, a cadeia usa esses binários renomeados para buscar scripts VBS auxiliares hospedados em serviços de nuvem conhecidos, incluindo AWS S3, Tencent Cloud e Backblaze B2. O uso de provedores legítimos amplia a dificuldade de bloqueio por reputação simples, porque o tráfego pode sair por destinos normalmente permitidos em redes corporativas. Para defesa, a questão principal não é bloquear todo o provedor, mas correlacionar processos incomuns iniciando conexões externas, caminhos de origem em C:\ProgramData, nomes de binários divergentes e downloads que antecedem alterações de configuração local.

Depois que as cargas secundárias estão presentes, o malware passa a interferir nas configurações do UAC. O comportamento descrito inclui tentativas contínuas de iniciar comando operacional omitido com privilégios elevados, repetindo a ação até obter elevação ou até que o processo seja encerrado à força. Também foi citada modificação de entradas de registro em HKLM\Software\Microsoft\Win e incorporação de mecanismos de persistência para sobreviver a reinicializações. O resultado pretendido é obter privilégios elevados sem interação adicional do usuário e abrir caminho para implantação de MSI não assinado.

Superfície afetada

A superfície de risco inclui estáções Windows em que usuários conseguem receber arquivos por WhatsApp e executar scripts VBS. Ambientes com associação padrão permissiva para scripts, ausência de controle de aplicativos, visibilidade limitada sobre diretórios de dados compartilhados e permissão para instalação de MSI não assinado ficam mais expostos. Como a cadeia depende de ação inicial do usuário, controles de endpoint e identidade continuam relevantes, mas não substituem restrições explícitas sobre execução de script e instaladores fora do fluxo de TI.

A campanha também pressiona modelos de segurança baseados apenas em reputação de domínio. AWS S3, Tencent Cloud e Backblaze B2 são plataformas legítimas e podem aparecer em tráfego corporativo normal. O risco surge quando scripts e binários locais atípicos usam esses serviços para buscar cargas que antecedem mudanças de UAC, persistência e instalação remota. Equipes de segurança devem tratar esse padrão como uma sequência comportamental, não como um único indicador estático.

• Endpoints Windows com execução permitida de arquivos VBS recebidos por aplicativos de mensageria.
• Diretórios ocultos recém-criados em C:\ProgramData após abertura de arquivo enviado por usuário externo ou não verificado.
• Cópias renomeadas de curl.exe e bitsadmin.exe executadas a partir de caminhos incomuns.
• Instaladores MSI não assinados associados à instalação de AnyDesk ou outro componente de acesso remoto fora de processo aprovado.

Hunting e telemetria

A investigação deve começar pela linha temporal do usuário que recebeu ou abriu o arquivo VBS. Eventos de criação de processo envolvendo host de script do Windows, criação de arquivos em C:\ProgramData, alteração de atributos para ocultação e execução subsequente de binários com nomes inconsistentes são sinais fortes. A presença de um arquivo chamado netapi.dll que se comporta como ferramenta de transferência, ou de um sc.exe fora do caminho esperado e associado a tráfego externo, deve ser analisada com prioridade.

No endpoint, a telemetria de processo deve correlacionar o script inicial com downloads, execução de comando operacional omitido, gravação de chaves em HKLM e instalação de MSI. Em rede, a defesa deve observar conexões iniciadas por processos incomuns para objetos em serviços de armazenamento de nuvem. Em logs de instalação, a criação de produtos MSI não assinados e a instalação de ferramentas de acesso remoto devem ser cruzadas com o solicitante, o horário, a origem do processo pai e a existência de chamado ou política autorizando a ação.

A detecção mais robusta vem da cadeia completa. Um único acesso a AWS S3 ou a execução isolada de AnyDesk pode ser legítimo; já a combinação de VBS recebido por mensageria, pasta oculta, utilitário renomeado, tentativa repetida de elevação e MSI não assinado descreve um fluxo de comprometimento. Esse encadeamento ajuda a reduzir falsos positivos e também orienta a resposta, porque evidencia que a atividade não se limita a um download, mas envolve persistência e tentativa de controle duradouro.

• Criação ou execução de arquivos VBS seguida por escrita em C:\ProgramData com atributo oculto.
• Processos com nomes netapi.dll ou sc.exe executando fora dos caminhos esperados e realizando tráfego de download.
• Tentativas repetidas de iniciar comando operacional omitido com elevação em curto intervalo de tempo.
• Alterações de registro sob HKLM\Software\Microsoft\Win próximas à execução de scripts ou instaladores.
• Instalação de MSI não assinado e presença de AnyDesk sem vínculo com política administrativa conhecida.

Mitigação

A resposta deve priorizar contenção do host onde o VBS foi executado, porque a cadeia busca persistência e acesso remoto. O isolamento de rede reduz a chance de novas cargas serem baixadas e impede que ferramentas de controle remoto sejam usadas durante a investigação. Em seguida, a equipe deve preservar telemetria de processo, instalação, registro e rede para reconstruir a sequência sem depender apenas dos arquivos ainda presentes no disco.

No controle preventivo, organizações devem restringir execução de VBS a casos aprovados, aplicar regras de controle de aplicativos para bloquear scripts originados de diretórios de usuário e mensageria, e exigir assinatura ou origem confiável para pacotes MSI. Também é necessário revisar exceções para ferramentas de administração remota: AnyDesk e softwares semelhantes podem ser úteis para suporte, mas precisam ter inventário, responsáveis, política de uso e alerta quando aparecem em máquinas fora do escopo aprovado.

A remediação deve remover scripts, binários renomeados, diretórios ocultos criados pela cadeia, entradas de persistência e instaladores indevidos. Alterações relacionadas ao UAC e ao registro precisam ser comparadas com a configuração padrão da organização antes de liberar o ativo. Caso uma ferramenta de acesso remoto tenha sido instalada, a equipe deve revisar sessões, horários de conexão, contas locais e credenciais usadas no host. Como a cadeia pode permitir ações adicionais após o controle remoto, a validação final deve incluir busca por novos artefatos baixados, outras persistências e sinais de movimentação posterior somente quando houver telemetria que sustente essa hipótese.

• Isolar endpoints com execução suspeita de VBS e preservar eventos de processo, rede, registro e instalação.
• Bloquear execução não autorizada de scripts VBS e reforçar políticas de controle de aplicativos.
• Auditar e remover MSI não assinado, AnyDesk não autorizado e binários renomeados em C:\ProgramData.
• Reverter alterações indevidas de UAC e chaves de registro usadas para persistência.
• Criar detecções encadeadas para VBS, pasta oculta, utilitário renomeado, download em nuvem, elevação e instalação MSI.